CPCWiki forum

General Category => Emulators => Topic started by: arnoldemu on 21:56, 20 January 16

Title: amstrad cpc "acid" test
Post by: arnoldemu on 21:56, 20 January 16
Accuracy is important in emulation.

I present the tests I have written to test Arnold emulator and the devices it emulates. The "acid" test for CPCs.

Download the Arnold source (Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/arnoldsrc.zip)) and look in the test folder.

I am sharing these so that all emulators both hardware (e.g. FreeMac's CPC hardware) and software can be made more accurate.

All tests have been run on real CPCs and Plus's and pass. You can confirm this for yourself by running them on real
machines.

Feel free to run the tests on your favourite emulator and see how it matches up.

Some tests are only applicable to the Plus because they test Plus features others will run on CPC and Plus.

I will continue to add more tests at each Arnold release.

If there is a specific hardware feature or device you want to see a test for. Post here and I will add it as soon as I can.

The most important directories:

test/cpctests
- Many tests for cpc/plus. Includes PSG,PPI,CRTC, Plus features

test/z80tests
- I converted two tests from Spectrum to CPC. I had to disable the in/out instructions on these. All the other tests work ok.

test/fdctest
- My nec765 tester from back in 2002. I updated the build scripts and added a description of each test.

Enjoy!


Title: Re: amstrad cpc "acid" test
Post by: Lone on 23:06, 20 January 16
That's GREAT tools !


Thanks for them, I'll use them as soon as I finish my current works.


Title: Re: amstrad cpc "acid" test
Post by: remax on 23:30, 20 January 16
I did an acid test on my Amstrad (mine was clorhydric i think), and it melted down...


What next ?
Title: Re: amstrad cpc "acid" test
Post by: Bryce on 10:52, 21 January 16
I did an acid test on my Amstrad (mine was clorhydric i think), and it melted down...


What next ?

Strange, my Acid test went quite well:
- Plug in cartridge.
- Check for 5V across pins 1 and 16.
- Check for address bits on pin 2 and pins 9 to 15.
- Check for CLK signal.
- Check for SIN signal.

Yup, the Acid is working :)

Bryce.

P.s. Great set of tools Arnoldemu.
Title: Re: amstrad cpc "acid" test
Post by: remax on 17:35, 21 January 16
un jour un étudiant voulant suivre des cours d'anglais, cherche des prix imbattables, car il était vraiment pauvre.

Il commence donc à regarder : british school ? trop cher , americain center ? aussi...
puis miracle , il voit une annonce dans le journal : comment parler l'anglais couramment en une semaine , à 30 euros ... Ben voila ! dit-il, c'est parfait, c'est exactement ce que je cherchais , il prend l'adresse et sa mobylette pour aller s'inscrire , il cherche, ne voit rien, demande aux passants , personne ne connait d’école d'anglais dans le coin, finalement il trouve un appartement correspondant à l'adresse , il sonne, un tout petit monsieur ouvre :


- Bonjour, je cherche les cours d'anglais à 30 €, c'est pas ici ?!? demande-t-il perplexe.

Et l'autre lui répond d'un air accueillant


-IF IF !! Between ! between !
Title: Re: amstrad cpc "acid" test
Post by: TFM on 20:48, 21 January 16
nothing...


You could at least tell a joke...  ;)
Title: Re: amstrad cpc "acid" test
Post by: remax on 21:54, 21 January 16

You could at least tell a joke...  ;)


done
Title: Re: amstrad cpc "acid" test
Post by: Bryce on 23:07, 21 January 16
That was a joke??[nb]Ok, it's not that bad[/nb]

Bryce.
Title: Re: amstrad cpc "acid" test
Post by: remax on 23:10, 21 January 16
That was a joke??

Bryce.


which post do you talk about ?  ;D
Title: Re: amstrad cpc "acid" test
Post by: Bryce on 23:18, 21 January 16
The "Si Si entre entre" joke.

Bryce.
Title: Re: amstrad cpc "acid" test
Post by: remax on 23:18, 21 January 16
The "Si Si entre entre" joke.

Bryce.


Yes, it's one of my favorite  ;D  (but it's better when told with big gestures).
Title: Re: amstrad cpc "acid" test
Post by: robcfg on 23:27, 21 January 16
If if!
Title: Re: amstrad cpc "acid" test
Post by: andycadley on 01:25, 22 January 16
Very cool, I shall have to have a good dig through this and the Arnold release and do my best to find any quirks you've missed. ;-)
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:01, 22 January 16
Very cool, I shall have to have a good dig through this and the Arnold release and do my best to find any quirks you've missed. ;-)
yes please. I can add tests for those and update Arnold to do that quirk :)
Title: Re: amstrad cpc "acid" test
Post by: Executioner on 23:45, 13 February 16
Download the Arnold source (Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/arnoldsrc.zip)) and look in the test folder.

I did, and there are none of the above mentioned tests in the current src zip file.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 12:52, 14 February 16
I did, and there are none of the above mentioned tests in the current src zip file.
Sorry. I've zipped it separately here:

Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/test.zip)
Title: Re: amstrad cpc "acid" test
Post by: Executioner on 22:58, 14 February 16
Sorry. I've zipped it separately here:

Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/test.zip)

Thanks Kev.
Title: Re: amstrad cpc "acid" test
Post by: Lone on 11:56, 29 March 16
Hi there


I would like to thanks again @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) for his great tests compilation.


Last night I was (finally) able to run the whole z80 tests without error (as on my 6128) thanks to it !
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 10:24, 18 April 16


Accuracy is important in emulation.

I present the tests I have written to test Arnold emulator and the devices it emulates. The "acid" test for CPCs.

I read some asic tests and they are quite simple. Really simple.

I'm currently coding an intro with Winape with an ASIC split each line EQ that means that i change 6801,6802,6803 & 6804 register every lines. As the splits are following a curve, i'm doing some computations and i can't change every registers in a short time. Registers changing is dispatched along the 64 nops i have for a line. I finally managed to set the timing FOR Winape. The code works, the intro is fine. But when i sent my code to a friend how own a real CPC+, everything goes wrong...

So i ask Offset/Futur's because his emulator seems to be the most advanced and accurate to give me some tips about the ASIC. Here is an extract of his very interresting answer:

(original)
Il y a plein de cas limites et d'artefacts. (...)   les splits sprite hard qui sont décalés d'un ou deux pixels lorsqu'ils sont faits avec certains instructions du Z80 (...) lors de la HBL le CPC+ fait des tonnes de choses avec une séquence bien précise, et les timings dépendent des fonctionnalités activées... et de ce que font les DMA (un DMA en pause induira des timings Z80 différents d'un DMA en écriture de registre, etc..).

(translation)
There is many limit cases and artifacts / doing split with hardware sprite (change hardware sprites coordinates/size during the display of them for example) may occurs some pixel translation according to the Z80 instruction doin' the change / during the HBL, ASIC refresh his own registers in a specific order. Timings of ASIC management depends on features enabled...   AND of what DMA are doing!!!!!! A paused DMA will cause differents timing than a DMA writing a register.


Personnaly, i plan to create ACID tests, because I need to develop on emulator and translate my code quickly for the real machine. (i do not own a real CPC+ :/ )

I will also share my work here,

Hope the Offset's informations about the ASIC will give you some ideas for the ASIC emulation.

And if you are looking for one existing CPC+ intro where most of emulator failed to run cause of heavy hardcore ASIC programming  delirium tremens mainpart preview [cpc+] &copy hard'os (2001) (http://www.cpc-power.com/index.php?page=detail&onglet=dumps&num=7530)
And the real result https://www.youtube.com/watch?v=yJcBsQwMzuw (https://www.youtube.com/watch?v=yJcBsQwMzuw)

++
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 11:31, 18 April 16

I read some asic tests and they are quite simple. Really simple.
Yes some are but they are effective and they reproduce the bugs and the pri bug you discussed.


I'm currently coding an intro with Winape with an ASIC split each line EQ that means that i change 6801,6802,6803 & 6804 register every lines. As the splits are following a curve, i'm doing some computations and i can't change every registers in a short time. Registers changing is dispatched along the 64 nops i have for a line. I finally managed to set the timing FOR Winape. The code works, the intro is fine. But when i sent my code to a friend how own a real CPC+, everything goes wrong...

Have you tried the acid tests on winape?


So i ask Offset/Futur's because his emulator seems to be the most advanced and accurate to give me some tips about the ASIC. Here is an extract of his very interresting answer:


(original)
Il y a plein de cas limites et d'artefacts. (...)   les splits sprite hard qui sont décalés d'un ou deux pixels lorsqu'ils sont faits avec certains instructions du Z80 (...) lors de la HBL le CPC+ fait des tonnes de choses avec une séquence bien précise, et les timings dépendent des fonctionnalités activées... et de ce que font les DMA (un DMA en pause induira des timings Z80 différents d'un DMA en écriture de registre, etc..).

(translation)
There is many limit cases and artifacts / doing split with hardware sprite (change hardware sprites coordinates/size during the display of them for example) may occurs some pixel translation according to the Z80 instruction doin' the change / during the HBL, ASIC refresh his own registers in a specific order. Timings of ASIC management depends on features enabled...   AND of what DMA are doing!!!!!! A paused DMA will cause differents timing than a DMA writing a register.
Interesting.
True DMA doing a pause and DMA writing are different and I have a test that shows that. run dmatiming ;)
I will try different combinations now :)

Arnold doesn't emulate that demo properly because it also needs exact instruction timing which arnold doesn't have.
And timings on asic are 2 us behind normal crtc.

I will post more tests soon that show these delays and things :)


Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:51, 18 April 16
Do these tests pass 100% on Ace?
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 20:59, 18 April 16
Do these tests pass 100% on Ace?


since i do not have a powerPC, i can't run ACE :(
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 23:33, 19 April 16
Arnold doesn't emulate that demo properly because it also needs exact instruction timing which arnold doesn't have.


when you say "exact instruction timing", you mean doing things (read/write) at the exact time, instead of executing the whole instruction and add total time of the instruction?


i had test the double interrupt "problem" with a real CPC+ and Winape


in my example, Winape execute LD (#6800),A in zero nop (!!!) then winape add 4 nops to ticker
in a real CPC+ (i guess), Z80 start to decode instruction (1 nop) then read the adress (2 nops) and finally write register A (1 nop)
that will explain the differences in the two screenshots below

ASM source: Uplea - Advanced File hosting (http://uplea.com/dl/DE59AF21B461564)
And the DSK: Uplea - Advanced File hosting (http://uplea.com/dl/851F56F99587802)


(http://reho.st/self/dd05554f9601703fec46847aad3aa9534160f951.jpg)

(http://reho.st/self/9327f195c575e38f779a382e734aec0a14c08595.png)


Title: Re: amstrad cpc "acid" test
Post by: Executioner on 02:54, 20 April 16
WinAPE currently doesn't implements the DMA imposing wait states on the Z80 during IN/OUT/PSG reads as per the spec properly, that's something I have to work on. As far as I know, however, it does read the instruction first, read the two address bytes, then do the palette switch when you do LD (nnnn),A with the correct timing. You may see early changes due to the lack of DMA WAIT states.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:05, 20 April 16

when you say "exact instruction timing", you mean doing things (read/write) at the exact time, instead of executing the whole instruction and add total time of the instruction?
correct. It is on my list to do.
*BUT* I have analysed when Plus, CRTC and GA use values and I have emulated most (I can't say all because I haven't tested all and I can't confirm all in all cases).

Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 10:15, 03 June 16
correct. It is on my list to do.
*BUT* I have analysed when Plus, CRTC and GA use values and I have emulated most (I can't say all because I haven't tested all and I can't confirm all in all cases).
Arnold now emulates the Delirium Tremens intro fully AND AE2015 demo :)

Split on plus:
* at most times, the split value is captured when HCC=R1 (i.e. border starts on horizontal). BUT when VCC=R4 and RCC=R9 (i.e. last scanline of frame) the split value is captured at HCC=R0 and is then used when RCC=1, VCC=0.  :)

Delirium Tremens intro relies on the VCC=R4, RCC=R9 case.

EDIT: No interaction with other ASIC registers, I can test this on it's own and it happens just like this.

I wanted to fix this before I released a new version of Arnold :)

I didn't need to fix the instruction timings just yet.
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 21:41, 08 June 16

Did you create your own tests to validate this behaviour?


Cause i have an intro to debug (it works on Winape but not on a real CPC+ :/ ) and i don't know how to fix it
Title: Re: amstrad cpc "acid" test
Post by: GOB on 21:57, 08 June 16
Arnold now emulates the Delirium Tremens intro fully AND AE2015 demo :)

Split on plus:
* at most times, the split value is captured when HCC=R1 (i.e. border starts on horizontal). BUT when VCC=R4 and RCC=R9 (i.e. last scanline of frame) the split value is captured at HCC=R0 and is then used when RCC=1, VCC=0.  :)

Delirium Tremens intro relies on the VCC=R4, RCC=R9 case.

EDIT: No interaction with other ASIC registers, I can test this on it's own and it happens just like this.

I wanted to fix this before I released a new version of Arnold :)

I didn't need to fix the instruction timings just yet.

I want to see my delirium tremens intro on your emulator !!! Make a vidéo please ;)
Title: Re: amstrad cpc "acid" test
Post by: Ast on 22:55, 08 June 16
Did you create your own tests to validate this behaviour?


Cause i have an intro to debug (it works on Winape but not on a real CPC+ :/ ) and i don't know how to fix it
Just timing problems Roud... I already had the same problem during the developpement of Synergy in 2007.
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 23:01, 08 June 16

Like peace on earth, it's "just" a matter of will...

Title: Re: amstrad cpc "acid" test
Post by: Ast on 23:06, 08 June 16

when you say "exact instruction timing", you mean doing things (read/write) at the exact time, instead of executing the whole instruction and add total time of the instruction?


i had test the double interrupt "problem" with a real CPC+ and Winape


in my example, Winape execute LD (#6800),A in zero nop (!!!) then winape add 4 nops to ticker
in a real CPC+ (i guess), Z80 start to decode instruction (1 nop) then read the adress (2 nops) and finally write register A (1 nop)
that will explain the differences in the two screenshots below

ASM source: Uplea - Advanced File hosting (http://uplea.com/dl/DE59AF21B461564)
And the DSK: Uplea - Advanced File hosting (http://uplea.com/dl/851F56F99587802)


(http://reho.st/self/dd05554f9601703fec46847aad3aa9534160f951.jpg)

(http://reho.st/self/9327f195c575e38f779a382e734aec0a14c08595.png)
@Roudoudou : Can you post the code source without this fucking website link please ?
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 08:59, 09 June 16
Did you create your own tests to validate this behaviour?
Yes.

I disassembled the demo and I knew when the ASIC registers were written. I first thought it was a timing bug in Arnold. I also knew that my emulation of split was not exact because it didn't emulate the split bug correctly.

So I wrote more tests and found this difference. I fixed it in Arnold. I ran the demo again and it worked fine :) This time I was confident I found how the demo worked.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:00, 09 June 16
I want to see my delirium tremens intro on your emulator !!! Make a vidéo please ;)
[ You are not allowed to view attachments ]  [ You are not allowed to view attachments ]

Two pictures made with "Save screenshot" in the emulator. I will make a video and post that soon so you can see it works correctly. :)
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:04, 09 June 16
Did you create your own tests to validate this behaviour?


Cause i have an intro to debug (it works on Winape but not on a real CPC+ :/ ) and i don't know how to fix it
In a private message tell me the effect you want to make and share some of your code (or the demo itself). I can debug it in Arnold (I hope it shows it correct, but if not I can use it's debugger to find the problem) and I hope I can tell you exactly what to change.
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 12:13, 09 June 16
In a private message tell me the effect you want to make and share some of your code (or the demo itself). I can debug it in Arnold (I hope it shows it correct, but if not I can use it's debugger to find the problem) and I hope I can tell you exactly what to change.


I bought a real CPC+ last week (just need to get it as it is still 300km far from me!) and a C4CPC extension


So i will debug by myself.


I may try already with your informations
Quote
at most times, the split value is captured when HCC=R1 (i.e. border starts on horizontal). BUT when VCC=R4 and RCC=R9 (i.e. last scanline of frame) the split value is captured at HCC=R0 and is then used when RCC=1, VCC=0
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 12:26, 09 June 16
When you wrote "the split value is captured"


And the block information contained in the SoftScrollRegister?


Cause i update both of them, the 6802/6803 value is updated before HCC=R1 for sure but i update SSR after to avoid visible artifacts.
Title: Re: amstrad cpc "acid" test
Post by: GOB on 12:47, 09 June 16
[ You are not allowed to view attachments ]  [ You are not allowed to view attachments ]

Two pictures made with "Save screenshot" in the emulator. I will make a video and post that soon so you can see it works correctly. :)

Very nice !!! Great !!! :)

Title: Re: amstrad cpc "acid" test
Post by: Ast on 14:20, 09 June 16
@Arnoldemu : can you give us arnold's link ?
We want to test it.
Did you add the sna in your emulator?
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:32, 09 June 16
When you wrote "the split value is captured"
When I say "captured" I mean the conditions that must be true for the data to be read and used. :)

For split and soft scroll you need to think in CRTC coordinates (HCC for horizontal matching against R1,R0 and R2, RCC and VCC for vertical, RCC counter matching against R9, VCC matching against R4 and R7).

Split screen comparison is like this:

SPLT7 SPLT6 SPLT5 SPLT4 SPLT3 SPLT2 SPLT1 SPLT0 == VC4    VC3   VC2   VC1   VC0    RC2   RC1    RC0

SPLT7->SPLT0 are the bit 7 to bit 0 of value written to 6801.
VC4 to VC0 are bits from VCC counter.
RC2 to RC0 are bits from RCC counter.

VCC counter is 7 bits. RCC counter is 5 bits. So some bits are ignored.
For split screen the values are "captured" or "collected" under these conditions:
- If VCC!=R4 and RCC!=R9 and SPLT line is matched (see above), and HCC=R1 then the value in 6802/6803 is stored.

This means you must set 6801 before HCC=R1 and 6802/6803 before HCC=R1 for the split to use your values.

- If VCC==R4 and RCC=R9 and SPLT line is matched (see above), and HCC=(R0-1) (or it could be HCC=R0 I can't tell exactly at the moment), then the value in 6802/6803 is stored. It will not be stored when HCC=R1 in *this* case.

This means you must set 6801 before HCC=R0 and 6802/6803 before HCC=R0. They are ignored at HCC=R1.

MA is the counter inside the CRTC which makes part of the ram address. It is incremented for each char horizontally. At the end of the line it is often reloaded from a stored value. So it resets each scanline. Without split (6801=0), MA is captured at HC=R1 and RCC=R9 and used on the next scanline (i.e. VCC=VCC+1 and RCC=0).

SPLT takes priority.

When SPLT is used:

- When VCC!=0 and RCC!=0 (i.e. not first scanline), stored value is used to set MA at the start of the next scan line.

(e.g. "captured" on VCC=1, RCC=2, stored value used on VCC=1, RCC=3. If "captured" on VCC=1, RCC=7, used on VCC=2 and RCC=0.)

- When VCC=0 and RCC=0 (start of frame) then R12/R13 is *ALWAYS* used for MA. The stored value is then used when VCC=0 and RCC=1.

MA will continue to count with new value until you set a new SPLT which matches OR until RCC=R9 when normal operation continues.

For Delerium Tremens, although R1 is set on last scanline, split happens at the end of the scanline. Also, because R12/R13 is used for first scanline then the left column is always the same, the remaining columns change using the split value.

Soft scroll:

Note: Split has priority over soft scroll and normal operation. If you set the split it uses it.

With vertical soft scroll the RCC=R9 condition to capture MA when HCC=R1 is altered.

It takes SSCR and adds it to RCC. If the condition matches R9 then MA is captured when HCC=R1 and used on next scanline.

Like this:

SSCR=0, R9=7
0 + 0 -> 0
1 + 0 -> 1
2 + 0 -> 2
3 + 0 -> 3
4 + 0 -> 4
5 + 0 -> 5
6 + 0 -> 6
7 + 0 -> 7 <<<MA is captured this line if HCC=R1


SSCR = 5, R9=7
0 + 5 -> 5
1 + 5 -> 6
2 + 5 -> 7 <- MA captured on this line.
3 + 5 -> 0
4 + 5 -> 1
5 + 5 -> 2
6 + 5 -> 3
7 + 5 -> 4

For scroll we also need to look at the RA "outputs" from the ASIC "CRTC":

For soft scroll it appears to make RA+SSCR.

EDIT: Added ASCII art:
Code: [Select]
HCC=0                                   HCC=R1                  HCC=R0
-----------------------------------------------------------------
|                                        |XXXXXXXXXXXXXXXXXXXXXXX
-----------------------------------------------------------------
                                         ^
                                         capture here


HCC=0                                   HCC=R1                  HCC=R0
-----------------------------------------------------------------
|                                        |XXXXXXXXXXXXXXXXXXXXXXX
-----------------------------------------------------------------
                                                                ^
                                                                capture here                                                                 
                                                               

                                                               
HCC=0                                   HCC=R1                  HCC=R0
-----------------------------------------------------------------
|                                        |XXXXXXXXXXXXXXXXXXXXXXX
-----------------------------------------------------------------
^
used here
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:33, 09 June 16
@Arnoldemu : can you give us arnold's link ?
We want to test it.
Did you add the sna in your emulator?
I will make a download in a couple of days. One more thing I need to fix.

SNA is still a little bit broken in Arnold, please use DSK or CDT :)
Title: Re: amstrad cpc "acid" test
Post by: Ast on 00:44, 10 June 16
I will make a download in a couple of days. One more thing I need to fix.

SNA is still a little bit broken in Arnold, please use DSK or CDT :)
I was thinking about sending you "beast+" to test it in Arnold. I'll do a proper dsk for your tests...
Title: Re: amstrad cpc "acid" test
Post by: ||C|-|E|| on 00:58, 10 June 16
You can send a copy to me as well to test in my real computer  ;D ;D
Title: Re: amstrad cpc "acid" test
Post by: Ast on 01:42, 10 June 16
Petit filou, va... :-D
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:55, 10 June 16
I was thinking about sending you "beast+" to test it in Arnold. I'll do a proper dsk for your tests...
I have your beast+ snapshot :)
But because there is a bug in arnold with snapshot (which I will fix next time) when I ran the snapshot it didn't work :(
Please send a dsk :)

Title: Re: amstrad cpc "acid" test
Post by: CraigsBar on 15:05, 22 June 16

since i do not have a powerPC, i can't run ACE :(


I do have a PowerPC Mac Mini running MorphOS and ACE has become my Amstrad Emulator of choice.


So if you can clarify which tests you want running (Better yet provide a DSK with them on, as the TEST.DSK in the archive seems to be blank to me) then I can certainly run them for you.


Craig

Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 16:54, 22 June 16
@CraigsBar (http://www.cpcwiki.eu/forum/index.php?action=profile;u=482) : I will send you the disks :)
Title: Re: amstrad cpc &quot;acid&quot; test
Post by: CraigsBar on 16:57, 22 June 16
@CraigsBar (http://www.cpcwiki.eu/forum/index.php?action=profile;u=482) : I will send you the disks :)
Perfect, I'll get it done today then.....  Little boy permitting!
Title: Re: amstrad cpc "acid" test
Post by: Wanderer on 18:07, 23 June 16
Firefox is busting my #$%^&*

Trying to download the test.zip file from this post (http://www.cpcwiki.eu/forum/emulators/amstrad-cpc-'acid'-test/msg119719/#msg119719), it's complaining about an insecure connection and certificate (cpctech.cpc-live.com uses an invalid security certificate). I added an exception to the site and then tried to download it again, now it complains that "/test.zip was not found on the server". I used IE and downloaded it in a sec but i'm guessing that the site's certificate needs a fix.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 11:15, 24 June 16
Firefox is busting my #$%^&*

Trying to download the test.zip file from this post (http://www.cpcwiki.eu/forum/emulators/amstrad-cpc-'acid'-test/msg119719/#msg119719), it's complaining about an insecure connection and certificate (cpctech.cpc-live.com uses an invalid security certificate). I added an exception to the site and then tried to download it again, now it complains that "/test.zip was not found on the server". I used IE and downloaded it in a sec but i'm guessing that the site's certificate needs a fix.
Sorry I think I deleted it a few days ago. I will re-upload it this weekend.

Are you using https or http?
Title: Re: amstrad cpc "acid" test
Post by: Wanderer on 00:31, 26 June 16
Sorry I think I deleted it a few days ago. I will re-upload it this weekend.

Are you using https or http?


Well, now i get "The requested URL /test.zip was not found on this server" with http. The previous problem was created with https. Anyway, i managed to download it with IE on that day...
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 10:04, 27 June 16
I have uploaded updated tests:
http://cpctech.cpc-live.com/test.zip (http://cpctech.cpc-live.com/test.zip)

What is new?
I forgot to write down what has changed. So here is what I remember.

* Tests for symbiface 2 (ram and rom tested here)
* Tests for Dk'tronics compatible ram (in progress do not rely on results)
* Vortex 512KB internal ram expansion tests (tested against mine, complete except for disabling all ram)
* inicron tests (in progress do not rely on results - furthur testing is required to confirm this one)
* moved pri tests into it's own file (pritest) was in asictest.
* asic split screen tests (this is visual)
* interlace picture test (all crtcs including type 2)
* "flood" mode test. I *almost* got type 2 to work correctly with r4=0 and r9=0.
* various crtc register tests (testing when values are used. You need to use joystick to change the number and see the comments in the test to see what is expected. I need to organise these better and add pictures)
* asic/cost-down status register tests
* added initial IDE command testing (covers X-mass and symbiface 2)

More tests to follow at next Arnold release and I will continue to extend and re-organise some of the tests.

I am trying to make as many as possible automatic with SUCCESS or FAILURE but some have to be visual. Next time I will include photos from a real monitor so you can see the results.

If you don't believe the results - that's ok - run them on real CPCs and Pluses to confirm for yourself. :)


Title: Re: amstrad cpc "acid" test
Post by: Lone on 00:25, 20 August 16
Hello,


About this marvellous suite (so usefull to make emulation better !).
I've done some work with the PPI test (ppi.bin/asm).


The test seems to have a little bug on the "mode 0: port b read" test :
It seems to display 2x of the tested result. (line 1750 - the 'simple_results' juste display the number of result in bc, so no need to ld bc, 256*2)


In the same test, I think we can have different result if a printer is plugged (but I can't test on my CPC, as I don't have any printer) - Guess 1E instead of 5E


As for now, my 8255 emulation works exactly like my beloved 6128... (all tests give same almost same results).

Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 10:16, 20 August 16
Hello,


About this marvellous suite (so usefull to make emulation better !).
I've done some work with the PPI test (ppi.bin/asm).


The test seems to have a little bug on the "mode 0: port b read" test :
It seems to display 2x of the tested result. (line 1750 - the 'simple_results' juste display the number of result in bc, so no need to ld bc, 256*2)


In the same test, I think we can have different result if a printer is plugged (but I can't test on my CPC, as I don't have any printer) - Guess 1E instead of 5E
Yes it will. This is something I will test. The same is true of the ppi mode 1 and 2 tests.  The result depends on the inputs and I didn't test all computer names and I didn't test with printer etc.

I don't have a printer but I think I can add some switches to an edge connector and use that to force busy etc.


As for now, my 8255 emulation works exactly like my beloved 6128... (all tests give same almost same results).
:)

Title: Re: amstrad cpc "acid" test
Post by: OffseT on 19:10, 21 August 16
As expected I had a look at your tests.

First, I want to congratulate you, because it is well done and covers a lot of cases already. I didn't go through all the tests yet, but I will check them all and update my report accordingly.

The main issue I noticed, is that several tests are failing on real CPC. Maybe everything is not finished yet?
Also, you are doing extensive tests one secondary features (for instance CRTC register 8 and laced modes; which is almost never used in softwares), while some others which might be very important regarding demos are missing (I saw no register overflow tests?).

Anyway, it is already very nice to have this test suite. I guess I have some test routines that could be added to your acid test, I just need to sort them out.

So, I started a report page here:
http://ace.cpcscene.net/tests:arnold_test_suite

All the result are related to ACE 1.13 (not released yet) in which I already fixed numerous minor issues.

I tried to write down all my remarks. Feel free to ask me additional information!
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:44, 23 August 16
As expected I had a look at your tests.

First, I want to congratulate you, because it is well done and covers a lot of cases already. I didn't go through all the tests yet, but I will check them all and update my report accordingly.

The main issue I noticed, is that several tests are failing on real CPC. Maybe everything is not finished yet?
Also, you are doing extensive tests one secondary features (for instance CRTC register 8 and laced modes; which is almost never used in softwares), while some others which might be very important regarding demos are missing (I saw no register overflow tests?).

Anyway, it is already very nice to have this test suite. I guess I have some test routines that could be added to your acid test, I just need to sort them out.

So, I started a report page here:
http://ace.cpcscene.net/tests:arnold_test_suite

All the result are related to ACE 1.13 (not released yet) in which I already fixed numerous minor issues.

I tried to write down all my remarks. Feel free to ask me additional information!
Fantasic! I will read through it and then get back to you with questions :)
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:55, 23 August 16
As expected I had a look at your tests.
@OffseT (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1826):

 Question:

Most of the CRTC register tests (e.g. crtc_r5) require you to move the position of the raster using the joystick/joypad ( be patient because there is no repeat on the buttons ;) ). The number on the screen changes. The results are written as comments in the code and say what to expect at certain numbers. Did you try this with these tests?



Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:57, 23 August 16
@OffseT (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1826) :

Do you know if there is a way to detect Plus ASIC revisions from code?

I *thought* it was the colour of the border at power on, but I now believe that to be random.

Title: Re: amstrad cpc "acid" test
Post by: OffseT on 11:20, 27 August 16

Quote from: arnoldemu
Most of the CRTC register tests (e.g. crtc_r5) require you to move the position of the raster using the joystick/joypad [...]
 


Oh! I didn't see that. What a strange idea to use the joystick anyway. :P
I guess that your tests can trigger overflow situations by this way. So, that's even better than I thought. :D
I will update my report as soon I have time... and once I've found a joystick somewhere!


Quote from: arnoldemu
Do you know if there is a way to detect Plus ASIC revisions from code?
I *thought* it was the colour of the border at power on, but I now believe that to be random.


I thought also about the color at power on, but it does not seem to be reliable (my rev A is green and my rev G is pink).


Also, I checked the boards (compared revA, D and G) and it seems that they are electronically identical. It is just a matter on integrating the patches to the PCB over the time. Chips used seems to be always the same as well.
Title: Re: amstrad cpc "acid" test
Post by: gerald on 13:08, 27 August 16
Also, I checked the boards (compared revA, D and G) and it seems that they are electronically identical. It is just a matter on integrating the patches to the PCB over the time. Chips used seems to be always the same as well.
A database of reset color and ASIC date code may be usefull to check if the color are random or related to a specific revision.
Power consumption can also help. I've a GX4000 that is consuming 100mA (about 25%) less than the others.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 14:09, 27 August 16
 


Oh! I didn't see that. What a strange idea to use the joystick anyway. :P
I guess that your tests can trigger overflow situations by this way. So, that's even better than I thought. :D
I will update my report as soon I have time... and once I've found a joystick somewhere!
I hope they do yes.

A lot of plus testing was done using a C4CPC cart and a GX4000. So joystick control was necessary. I found it so quick to build on pc, make a cpr, copy to c4cpc, boot and use joystick :)

Also the keyboard on my 464 Plus has failed so using a the C4CPC here and a joystick made it easier here too and my 6128 Plus's keyboard is a bit flaky too :(

I wanted to change the delay when I make register changes. The raster indicates the end of the delay. This allowed me to identify when the register values are used and if they are latched or not AND i could cause register overflows easily.

I would run the test, use the joystick to move the raster, then note down the number and the result in the test.
I would then run it on my emulator and match that up with the CRTC counter values.

My emulator is not accurate to know if some trigger on HTOT or HC=0 and both are easy to check in hardware.

I have not turned these crtc tests into automatic visual tests yet.


I thought also about the color at power on, but it does not seem to be reliable (my rev A is green and my rev G is pink).


Also, I checked the boards (compared revA, D and G) and it seems that they are electronically identical. It is just a matter on integrating the patches to the PCB over the time. Chips used seems to be always the same as well.
I will try some power on tests and see if there is a common value for each asic. I believe however the result will show up in other tests.

Offset I hope that when you run the test on your Pluses your results from the tests will show a difference that I can then make a specific test for.

Title: Re: amstrad cpc "acid" test
Post by: Lone on 14:45, 22 October 16
Hello,


Back to this subject, as I'm trying to fix the FDC emulation of Sugarbox with these tests.
I worked on the 40 first tests at this point.
A remark, and a question :


- The test &18 (read data on unformatted track) does not give the expected result on a CPC : I get 40 04 00 08 00 41 02 (with 04 instead of expected 01), with the testdisk.dsk. I suppose it can be that there is an existing track with adress mark on it ?


The question is on the test &28 : The purpose of the test is to check the correct behaviour of DTL when the size is set to 0.
So the command is :


&42 &0C 00 &01 &00 &01 &2a &80
I understand this as : Read a track, each sector has a size of &80, read one sector only.


Expected result check that &50 bytes only are read. And at this point, I can't figure out why there is &30 bytes missing ?
The CPC pass the test, so there is no mistake.
The first sector on the test disk is a standard sector (size 2).


@arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122), do you remember the reason of this difference ?







Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 18:01, 22 October 16
Hello,


Back to this subject, as I'm trying to fix the FDC emulation of Sugarbox with these tests.
I worked on the 40 first tests at this point.
A remark, and a question :


- The test &18 (read data on unformatted track) does not give the expected result on a CPC : I get 40 04 00 08 00 41 02 (with 04 instead of expected 01), with the testdisk.dsk. I suppose it can be that there is an existing track with adress mark on it ?
Hmm.. I think it's correct although unexpected. I found it hard to get a true unformatted track when I made these tests. I know I could write a large sector to make something similar but it's not perfect. I will try and check this again.

The question is on the test &28 : The purpose of the test is to check the correct behaviour of DTL when the size is set to 0.
So the command is :


&42 &0C 00 &01 &00 &01 &2a &80
I understand this as : Read a track, each sector has a size of &80, read one sector only.


Expected result check that &50 bytes only are read. And at this point, I can't figure out why there is &30 bytes missing ?
The CPC pass the test, so there is no mistake.
The first sector on the test disk is a standard sector (size 2).


@arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122), do you remember the reason of this difference ?
Yes there is no mistake. All my extra tests show that N=0 and using DTL and MFM is broken on a real FDC. I think in one doc I read that it should not be used with MFM.

I have done some more tests and sometimes it reads &28 sometimes &50. The FDC can't do it. I didn't test with FM yet.

Testing so far indicates if bit 0 of DTL is set to 0, then 0x028 is read, otherwise it's 0x050, but there is more to it. (Of course testing shows that DTL really is ignored for other sectors sizes - I can set any DTL and it ignores it).

I am making some new tests which are much more exhaustive. For example I test *ALL* C,H,R,N values, I test all SC values, the tests run for a long time but they check much more. I have also added some tests with DMA enabled and FM instead of MFM.

(Regarding FM. On CPC, the FDC has 4Mhz (except on 664 and possibly some DDI-1). So we will not get a true single density, I think we will get single density bits but with the wrong clock rate).

Also in the new tests I will be using read track to read the gap, sync etc and check the bytes are exactly correct.

Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 14:28, 28 October 16
Hello,
I am currently writting an emulator based on Caprice32. I have completely upgraded the original FDC emulation is to able to load protected games. But the FDC is not fully emulated as protected games do not use all aspects of FDC.

Hence, I was really happy to discover your tests and I began to rewrite my code to pass any of your tests.

However, Maxit shows me screenshots from his real CPC where many tests are failed : 00, 18, 1E, 2A, 33, 34... 5E, 60.

Today, I am a little confused.
Why should I pass tests that are failing on real CPC ?
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:01, 28 October 16
Hello,
I am currently writting an emulator based on Caprice32. I have completely upgraded the original FDC emulation is to able to load protected games. But the FDC is not fully emulated as protected games do not use all aspects of FDC.

Hence, I was really happy to discover your tests and I began to rewrite my code to pass any of your tests.

However, Maxit shows me screenshots from his real CPC where many tests are failed : 00, 18, 1E, 2A, 33, 34... 5E, 60.

Today, I am a little confused.
Why should I pass tests that are failing on real CPC ?
Some tests require an 80 track double sided drive. I think 00 needs this because it checks the "equipment check" error if you try and seek more than 77 tracks.

I am updating the tests now and adding new ones too.

I will add names to the tests and ask the user to choose the drive id and type of drive used and skip any tests that can't be done on that drive.

I will verify all tests run on real cpc and tell you the configuration of the cpc used in the documentation.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:39, 28 October 16
Additional requirements:

drive must be write enabled
drive must have real ready (not forced ready for example)

I didn't test on hxc or gotek. All tests done on a real cpc with real drive.

Please keep the feedback coming it will help me to make the tests easier to use and it will help me to add more tests.


EDIT: A new version of the acid tests will be released when I release Arnold (currently scheduled for end of November).
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 15:57, 28 October 16
Thank you very much for your reply. Of course we will keep feedback.

I am focused on real CPC, not HxC nor Gotek.

As almost all CPC do not have 80 tracks drive, is it possible to adapt tests for original CPC only ?

I remember I have read at the beginning of this thread there are others tests for other CPC peripherals. Please could you tell me where I can find them ?

When I have first use your tests, I have made the data disk using my emulator. Later, I have discovered that my data disc was very different from the one provided with the test program.

What is the best way to be confident about data test disk structure ?
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 14:42, 29 October 16
Thank you very much for your reply. Of course we will keep feedback.

I am focused on real CPC, not HxC nor Gotek.

As almost all CPC do not have 80 tracks drive, is it possible to adapt tests for original CPC only ?
Some tests need double sided drive or 80 track drive and if you want to test all of the fdc features then these will be needed.
I will allow the user to choose the drive type, some tests will be skipped (if they are not possible on that drive) and there will be special ones for each drive (e.g. trying to read side 2 of a single sided drive).


I remember I have read at the beginning of this thread there are others tests for other CPC peripherals. Please could you tell me where I can find them ?
in the cpctests directory.

I will move the tests into their own directory to make them easier to find.

These are:

yarek4mb.asm - Yarek's 4MB internal ram expansion
vortexram.asm - Vortex 512KB internal ram expansion
sym2.asm - Symbiface 2 (rom, ram, rtc etc)
ide.asm - Symbiface 2 and X-Mass
ideinfo.asm - general ide reporting
kempston.asm - kempston mouse
brunwordmk2.asm - brunword mk2
dkram.asm - many dk'ram compatible expansions including 64kb external ram on 464 and the c3 configuration.
inicronram.asm - inicron ram test
mf2.asm - multiface 2 test

When I have first use your tests, I have made the data disk using my emulator. Later, I have discovered that my data disc was very different from the one provided with the test program.

What is the best way to be confident about data test disk structure ?
Ok this is difficult because the code doesn't verify this. Of course I would say a real cpc will do this, but then that assumes all is working perfect on the real computer.
(e.g. the drive is not starting to fail).

I will think about a way I can do some tests and to verify the disc structure.
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 15:33, 07 November 16
acid tests are really good because I can now fill all my else conditions with something correct.

I am trying to pass FDC test &5E but there are something strange I do not understand.

Here are commands from my emulator:
MOTOR=ON
CMD Command=SEEK : 0F 01 0F
RESULT Command=INTSTAT : 08
RESULT Result=21 0F
CMD Command=WRITE : 45 01 0F 00 01 00 01 2A FF
RESULT Result=41 80 00 0F 00 01 00
MOTOR=ON
CMD Command=WRITE : 45 01 0F 00 01 00 01 2A 80
RESULT Result=41 80 00 0F 00 01 00
MOTOR=ON
CMD Command=READ : 46 01 09 00 01 00 01 2A FF
RESULT Result=41 04 10 09 00 01 00
MOTOR=OFF


In that test, 128 bytes of first sector in track 15 are written with &AA. 128 bytes are written using DTL with &55.
Then, sector is read but CHRN is expecting the cylinder 9. So my emulator doesn't find the sector.

Please, @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122), could you tell me what is wrong in my understanding ?
Title: Re: amstrad cpc "acid" test
Post by: OffseT on 22:33, 07 November 16

FYI.


I just released a new version of ACE (v1.13).
I already introduced somes minor fixes thanks to your test suite.


I will go on integrating fixes and I will update the related page accordingly.


I'm sorry, I'm not coming here very often, but I'm still working with your tests when I have spare time.
Title: Re: amstrad cpc "acid" test
Post by: Lone on 12:29, 08 November 16
@Fredouille (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1930) , @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) : The test fails the same way on a CPC with standard FDC.
I change the test itself (to read cylinder 15 instead of 9), and the result is joined with this post (hopefully), but I cannot run it on real hardware atm.
If someone can run it and post a photo of the test 5E, it would help us a lot !


(Note : Rename the "asm" extension into "dsk" to get it right)
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:41, 08 November 16
I have nearly finished re-organising all the tests into sub-directories and adding a description page to the start of each test.

The description page describes the test and for some it describes the expected result. I will take photos of the results too.

I think a couple more days and the organisation work is done.

Then I will take a few more days to run the tests on my cpcs improve the output and check the new tests I added.

Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 09:35, 09 November 16
I just have a silly question that only people with real CPC can answer.
I am new in this forum so maybe the answer is already hidden somewhere.

I am just wandering what is the time needed by the floppy drive to become "ready" when motor is starting ?
And also the time to become "not ready" when motor is stopping ?
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 11:18, 09 November 16
I just have a silly question that only people with real CPC can answer.
I am new in this forum so maybe the answer is already hidden somewhere.

I am just wandering what is the time needed by the floppy drive to become "ready" when motor is starting ?
And also the time to become "not ready" when motor is stopping ?


it depends mostly on the drive belt. It's very quick with a new 3.5 floppy drive
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 11:40, 09 November 16

it depends mostly on the drive belt. It's very quick with a new 3.5 floppy drive
I will add a test and find out.

:)
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 13:28, 24 December 16
Hi @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) !! Any idea when new tests will be available ?
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 11:33, 15 January 17
Hi @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) !! Any idea when new tests will be available ?
Sorry not yet.

I have re-written the disc tests. The code is simpler, the results are more stable and accurate and the tests cover more.

It is still in progress.

I am also busy at work so progress has slowed down a little, but I make progress every day.

It will be worth the wait.

Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 12:54, 18 February 17
I am *still* re-writing the tests. Each day I think up a new thing to test.

The original fdc tests missed a lot of things. In fact there are so many tests now they are split into multiple parts. Each is around 32kb in size.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:00, 13 May 17
New tests!

http://www.cpctech.org.uk/test.zip

I have re-organised them. I hope it is easier to find tests and use them.
I have added more tests.
A lot have information about what is tested.
CRTC and Plus tests were not updated this time. I need to add the "intro" message to them all.
Some tests are still unorganised (cpctests).
I have also described the configuration of my test computers.

It has taken a lot of work (almost daily) to get this far and I still need to do more work on them. (e.g. fdctest3).
Where the result can be tested and verified it will say "PASS" or "FAIL" depending on the result and list the result bytes. For FDC it will be data like size read and the result phase bytes. Look at the source to see what the numbers mean I tried to format the text to make it easier to read.

See the TODO for the list of tests I have thought about but not added yet.

I have taken all the feedback and used that to improve the tests. :)

I welcome feedback and questions.

Thank you.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 16:08, 13 May 17
I just have a silly question that only people with real CPC can answer.
I am new in this forum so maybe the answer is already hidden somewhere.

I am just wandering what is the time needed by the floppy drive to become "ready" when motor is starting ?
And also the time to become "not ready" when motor is stopping ?
It depends on the drive. My 3.5" drive is very quick to go ready and not-ready (the test can't measure it).

My 3" drives are much slower and they are not all the same.

In my new tests I have numbers:

3" on type 1 6128:
on: 6c7, a04,93f
off: 0,0,0

The numbers are the number of iterations of the testing loop. I will find out what this means in seconds or milliseconds.

These are min, max and average times.
It takes time from not-ready to ready, but seems to be not-ready almost immediately. (The test is not accurate enough to measure this).

The test does a not-ready to ready and ready to not-ready 32 times and calculates the result. The not-ready to ready definitely depends on the drive belt age, 3.5" has direct drive so is very quick.

It's also worth noting that drives can't always handle the faster step rates and the result is often different when seeking 0->39 and 39->0.

My 3.5" can handle all but the fastest step rate with both directions.

The test (disc/drivetest) sets the step rate time and makes it seek to track 39. It then does a seek from 39 to 0. It will then read the id from the track it reached to discover where it got to. 3.5" can do all step rates except 1. My 3" drives, can't handle below 4, and it also seems if the step rate is too slow they can also have problems.  So I can't give an exact answer.

If others can do measurements then perhaps we can find an average value for a 3" drive.

Title: Re: amstrad cpc "acid" test
Post by: Lone on 18:12, 13 May 17
Hello,


It seems that the first link is not correct. Using http://www.cpctech.org.uk/test.zip instead works (the zip file is recent)


Anyway, thanks for this amazing tool !
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 18:18, 13 May 17
Hello,


It seems that the first link is not correct. Using http://www.cpctech.org.uk/test.zip (http://www.cpctech.org.uk/test.zip) instead works (the zip file is recent)


Anyway, thanks for this amazing tool !
Yes you are correct it is test.zip. Sorry for the bad link.
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 11:55, 26 May 17
Hello Kevin,

I am beginning to play with your new tests and I feel very happy with them.
We just need the disk containing the test and an empty one to perform tests.

Furthermore, that is just easy to recompile them... And for that, a great THANK YOU !!


For the moment, I just have one question: How to interpret those errors ?
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 15:54, 26 May 17
Hello Kevin,

I am beginning to play with your new tests and I feel very happy with them.

We just need the disk containing the test and an empty one to perform tests.
good :)

The disc tests are split into many parts because I ran out of ram if they are all together AND each part needs it's own disc format for the tests. The older test was incomplete. In fact these tests are still incomplete, I thought about as many tests as possible, but still I think up more today.

Each disc test will first test the drive and make a test format of 5 tracks. Then the test disk is formatted and the deleted data sectors are marked. Then the tests run.

Do you want me to make a dump of the test disk for each test (fdc_seek, fdc_write etc)?

If your emulator is passing a lot and you don't want to wait, you can edit the code and comment out each "DEFINE_TEST" if you wish and build it. Then you can concentrate on the fails. The tests are meant to be independent. The only ones to be careful of are the dma tests, these need to be last.

For the test you show in the picture it is in test\disc\fdc_write
code is in fdctest.asm in that directory.

Each test uses a pasmo macro

DEFINE_TEST "description",test_addr

The test that has failed is "dd_wc". Find it by looking for the DEFINE_TEST line in the code :)

This test uses write deleted data and track 13. It calls "cm_wc" or "common_wc".

The expected results are in res_dd_wc. I have structured them in the code to try and make it easier to read. Bytes &fe,&00 is "end of test data". If you see &fe,&01 this means to take the previous byte and OR the drive number to it. (bit 1,0) fe,&02, means to take the previous byte and OR the drive and side to it. (bits 2,1,0)

The test disc format is this label: test_disk_format_data

And in there is the definition for track 13.

;; dd_wc
defb 13
defb 0   
defb %01000000

defb 2
defb 1
defb def_format_gap
defb def_format_filler
defb 14,&0,&41,2

This means: track 13, side 0, double density, format with size 2, 1 sector per track, default gap and default filler byte and the chrn value.

The code initialises various write deleted data parameters and counts the number of bytes written and takes the result data.

In this case the result data is like this:

2 bytes size written (the number of bytes in the execution phase)
1 byte number of bytes in fdc result phase (7)
then fdc result phase bytes.

Furthermore, that is just easy to recompile them... And for that, a great THANK YOU !!
great :) I tried hard to make them much easier to use.

if using windows then run the "buildall.bat", or for each test there is a "build.bat". Windows makes bin and dsks.
For linux use the makefile in each dir. linux doesn't make a dsk. I can add that for next release of the tests.

On windows, you need pasmo and cpcxfs in c:\tools

cpcxfs can be downloaded from www.cpctech.org.uk/download.html (http://www.cpctech.org.uk/download.html)

For the moment, I just have one question: How to interpret those errors ?
In the code I have expected bytes these are the results I got from a real cpc.
Result of "FAIL" means 1 or more bytes is not the expected value.

if the result byte is ok it just puts the byte and "Ok". This byte matches the expected.
if the result byte is different it puts the value YOUR EMULATOR gives and the byte it wants.

So "xx got expected yy". xx is from your emulator, yy is the result I got from the real cpc.

The results for each test are not all formatted in the same way, but the pattern is similar.

If in doubt look at the test in the source, look and the format information, and look at the result bytes. Each test is written to be similar in structure so it should be easy to find what you need.

EDIT: The 16-bit number is the position in the test results (ignoring &fe,xx). (0001: got 02 - OK) it is second byte in test results, 0 is first, your emulator reported 2, it wanted 2 and that was correct)

I hope that helps :)
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 16:59, 26 May 17
Thank you, I do not need any dumps for the moment.
Your steps to create the test disk seems OK.

As you said, I have already changed tests order to remove FM and MFM, as I know there are not relevant for me because my emulator doesn't handle FM mode, no DMA as well.

I am not sure, but i believe I have found some bug into disc\fdc_write\fdctest.asm:
line 1766: "ld hl,res_d_ov_fill" instead of "ld hl,res_d_wc"
line 1782: "ld hl,res_dd_ov_fill" instead of "ld hl,res_d_wc"

I will try to test using a real CPC...
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 17:49, 26 May 17
Thank you, I do not need any dumps for the moment.
Your steps to create the test disk seems OK.

As you said, I have already changed tests order to remove FM and MFM, as I know there are not relevant for me because my emulator doesn't handle FM mode, no DMA as well.

I am not sure, but i believe I have found some bug into disc\fdc_write\fdctest.asm:
line 1766: "ld hl,res_d_ov_fill" instead of "ld hl,res_d_wc"
line 1782: "ld hl,res_dd_ov_fill" instead of "ld hl,res_d_wc"

I will try to test using a real CPC...
Ah yes, that one needs to be finished, same with "write deleted data (overrun - thrash data register)" and "write deleted data (ready change during sector)".

On this test it will show a grid of numbers.

My notes say:

write deleted data (overrun - fill byte):

UM8272 - it's the last byte in the data register (0-7f, 7f repeated)

So you will see 0-7f, then 7f repeated to the end of the list of numbers.

write deleted data (overrun - thrash data register):

On this test I cause an overrun and then write the data register with values until the execution phase is complete.

You will see 0-7f, 7f repeated 4 more times, then 0,2,3,4,6,7,8,a,b,c,d,e,f and some more numbers.


On "write deleted data (ready change during sector)" it says:

0 for most of sector data, then 07,40,20,60 etc.

In this one I write data and the stop the drive motor, the pll can't lock properly and you will get some strange bytes at the end as the pll tries to lock to the data which is now coming in at a slower and slower rate.

EDIT: Yes try on a real cpc.
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 19:25, 26 May 17
Tests done with same results (failure on both Caprice and real CPC6128).
I have tried to attach pictures without success...

Attach CPC Picture: Your attachment has failed security checks and cannot be uploaded. Please consult the forum administrator.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 22:17, 26 May 17
Tests done with same results (failure on both Caprice and real CPC6128).
I have tried to attach pictures without success...

Attach CPC Picture: Your attachment has failed security checks and cannot be uploaded. Please consult the forum administrator.
What is the configuration of the CPC you tested? Do you know the model of the FDC, the data seperator, GA etc? This is important because FDCs do different things in tests like this one and it would be good to know which configuration you have.

I expected these results for these tests and the "fail" is expected because the results are not checked in this test - sorry I should have disabled it before I released the tests.

Please continue with the other tests.

The numbers (7f etc) are the important ones.

On UM8728 FDC in one of my CPCs, I can make overrun, then write data to the data register and it writes into the sector. So here this is another difference in FDCs.

Continue to compare against the real CPC :)

fdctest3 test does not have checking for all tests yet. fdc_seek, fdc_gen are good (you may get different results on the tests with "unformatted" tracks because this is different on various fdcs and I need to test more - you will need to know the model of the fdc you have in your cpc to get the same results.

Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 23:14, 26 May 17
btw on some tests you will see this:

"ready change during command-008 007 006 005 004 003 002 001 001 PASS"

These are not result bytes so please ignore them. They are a progress indicator. I add these when the test is a lot of work. :)


 
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 11:16, 27 May 17
I have performed my tests yesterday on a CPC6128 French including UM6845R (CRTC) and UM8272A (FDC).
I will try to fix the drive of another 6128 French including HD6845SP (CRTC) and D765AC-2 (FDC).

I am using HxC to execute FDCTEST and all tests are performed on internal drive.

Edit : I can also try on a 664 French including HD6845SP (CRTC) and D765AC (FDC).

3 differents FDC !!
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 12:31, 27 May 17
I have performed my tests yesterday on a CPC6128 French including UM6845R (CRTC) and UM8272A (FDC).
I will try to fix the drive of another 6128 French including HD6845SP (CRTC) and D765AC-2 (FDC).

I am using HxC to execute FDCTEST and all tests are performed on internal drive.

Edit : I can also try on a 664 French including HD6845SP (CRTC) and D765AC (FDC).

3 differents FDC !!
Fantastic.

Please continue to report bugs :) I am adding some new tests today and I will fix all the problems reported :)

I didn't try the tests on a 664 or DDI-1 yet. I do have them but I didn't have time to run them yet. It is possible one of these does support single density :)


Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 13:14, 27 May 17
Fantastic.

Please continue to report bugs :) I am adding some new tests today and I will fix all the problems reported :)

I didn't try the tests on a 664 or DDI-1 yet. I do have them but I didn't have time to run them yet. It is possible one of these does support single density :)

Of course, I forgot the DDI-1... I will test with it as well !!


I have many problems with test "write data (wrong cylinder)" on a real CPC.
What is the meaning of the 2nd  results ?
0000: got 00 - OK
0001: got 00 expected 02 - FAIL

Edit: I believe I have found. First bytes are the size of data transferred. 512 or 0 depending on operation failure.
Title: Re: amstrad cpc "acid" test
Post by: Fredouille on 17:05, 27 May 17
Here is the test "write deleted data (wrong cylinder)" resource working for both of my CPC6128:

res_d_wc:
defw &0
defb 7,&40,&fe,&02,&4,&10,4,0,&41,&2
defw &200
defb 7,&40,&fe,&02,&80,&0,3,0,&41,&2
defw &0
defb 7,&40,&fe,&02,&4,&0,3,1,&41,&2
defw &0
defb 7,&40,&fe,&02,&4,&0,3,1,&41,&3
defw &0
defb 7,&40,&fe,&02,&4,&10,4,1,&41,&2
defw &0
defb 7,&40,&fe,&02,&4,&10,4,1,&41,&3
defb &fe,&00
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 09:46, 30 May 17
Thank you.

I am working through the tests and fixing the problems reported and checking all the tests again.

Known: fm and unformatted tests - the c,h,r,n values seem to be random, or not initialized. I try to find the results by reading a valid track and then reading the fm/unformatted track. My attempt is to find how the values are decided. I will disable these tests for now.


Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 23:06, 02 August 17
Hello, today i wanna criticize some emulators so i made a test  :P


Here is the result, it's about split-raster


Pictures only as an illustration, please run the real test in CPR



Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 17:39, 04 August 17
was tryin' to reproduce a reported bug with sprites priorities when i saw this problem with Arnold / Winape
i guess it's the same problem as splitraster management, it's only NOP accurate and not Cycle accurate (one cycle is 1/4 nop)
on a real CPC, the sprite in mode 2 has almost disappear
on a real CPC, mode 1 & mode 0 sprite x-change occur a little further/later
as usual, screenshot only to illustrate, run the f*ck*ng CPR !!!



Title: Re: amstrad cpc "acid" test
Post by: Lone on 16:35, 06 August 17
Hey Roudoudou,


As I don't have any PLUS at home, do you have a photo of the complete screen of your plus, to check ?

Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 16:48, 06 August 17
As I don't have any PLUS at home, do you have a photo of the complete screen of your plus, to check ?


There is no differences with the sprites in the upper screen. I tried to reproduce a priority bug but i failed. Maybe Offset has a code for this.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 17:00, 06 August 17

There is no differences with the sprites in the upper screen. I tried to reproduce a priority bug but i failed. Maybe Offset has a code for this.
I haven't heard of this bug. There is a bug with the sprite priorities?
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 18:50, 06 August 17
I haven't heard of this bug. There is a bug with the sprite priorities?


Be sure as soon as i have more informations about it, you will be the first informed  8) ;D
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 19:16, 06 August 17

Be sure as soon as i have more informations about it, you will be the first informed  8) ;D
The Plus specification says that the sprite is removed for the duration of a write. I don't know if this is x,y,mag or sprite data.

This is something I didn't test yet.

Title: Re: amstrad cpc "acid" test
Post by: andycadley on 21:13, 06 August 17
Looks like Kev has already updated the wiki but my tests seem to agree, accessing the sprite pixel data disables the sprite for the duration of the read/write. Accessing the position registers doesn't seem to have the same effect.
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 21:36, 06 August 17
Looks like Kev has already updated the wiki but my tests seem to agree, accessing the sprite pixel data disables the sprite for the duration of the read/write. Accessing the position registers doesn't seem to have the same effect.
yeah it didn't take that long to test :)

Title: Re: amstrad cpc "acid" test
Post by: andycadley on 22:32, 06 August 17

yeah it didn't take that long to test :)


yeah, a few quick and dirty tests demonstrates it. :-)
Title: Re: amstrad cpc "acid" test
Post by: arnoldemu on 10:54, 07 August 17

yeah, a few quick and dirty tests demonstrates it. :-)
It takes a bit longer to make a nice polished test that tries all of the possibilities in one screen, but that's what I'll do :)

Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 21:16, 07 August 17
I'm trying to do a cool SPLIT_ADR test cartridge but i think i have to work better on DMA cause i do not succeed in highlitghting the wait-state effect of DMA


Some capture to show you what it looks like now


But i can already tell:
- low byte of SPLIT_ADR & high byte of SPLIT_ADR are taken into account simultaneously
- Arnold is reading SPLIT_ADR 2 nops too late (the screen goes wrong 2 lines before the real CPC when the code has more NOPS before the register override)


Will work tomorrow on it  ;D


code extract
Code: [Select]


macro InnerSplit64
attente=15
repeat 16
ld e,(hl) : inc h : ld d,(hl) : inc h : ld a,c : ld (#6801),a : ld (#6802),de
defs attente+8,0
exx : ld (hl),b : exx ; <- Here is the register override
if attente>0
defs 15-attente,0
endif
; update counters
inc c : ld a,(hl) : inc l : dec h : dec h : ld (#6804),a ; the purpose is not to test the SSR
defs 64-31-15-8,0
attente=attente-1
rend
mend
Title: Re: amstrad cpc "acid" test
Post by: ThomH on 06:03, 27 June 18
It depends on the drive. My 3.5" drive is very quick to go ready and not-ready (the test can't measure it).

My 3" drives are much slower and they are not all the same.

I'm a year late, but while having terrible difficulty trying to get good substantive detail on the FDC I stumbled upon this thread.

Almost certainly the 3" drives implement the traditional meaning of RDY: it goes active two index pulses after motor on. The assumption is that proper speed will have been reached by then. How long it takes you to get to two index pulses obviously depends on initial rotation position plus how long your drive motor actually takes to get up to speed.

IBM redefined it. With any drive intended for a PC, RDY is inactive when you insert a disk. It becomes active after the head has stepped. It remains active until the disk has been ejected. So it's no longer related to rotation speed at all, it's effectively a disk-has-changed indicator.
Title: Re: amstrad cpc "acid" test
Post by: roudoudou on 15:01, 08 November 19
Hey, i discussed with Offset about ACE emulator and testing AND sprites artefacts some people found
During the discussion, we were talking about splitrasters timing changes according to the instruction doing the change (see the previous pages of the topic)
Offset told me the time-shift between instructions used is always the same BUT there is another time-shift between functionnalities used in the ASIC
So i made a little (an incomplete test)
During sprite drawing, i'm changing X, then i'm changing zoom (to zero)
I noticed there is a little difference with changing X, then changing zoom to smaller width (i think it's the real end of the big sprite/2 width)
Then 4 lines doin nothing
Then changing X and changing Y position. This time we can see a very small and delicate line when switching back to full width
The CPR is not finished, i may change the visuals (for a moar visible evidence)
Juste some screens attached to this post
(https://reho.st/self/0141ce9425417eb1cc2f55c17583ea5e6afac881.png)

(https://reho.st/self/0c52aa2512673a724cf5758a8da7a812f4114f1d.jpg)