News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

amstrad cpc "acid" test

Started by arnoldemu, 20:56, 20 January 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

arnoldemu

I have uploaded updated tests:
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. :)


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Lone

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).


arnoldemu

Quote from: Lone on 22:25, 19 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.

Quote from: Lone on 22:25, 19 August 16

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

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

OffseT

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!

arnoldemu

Quote from: OffseT on 17: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!
Fantasic! I will read through it and then get back to you with questions :)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: OffseT on 17:10, 21 August 16
As expected I had a look at your tests.
@OffseT:

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?



My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

@OffseT :

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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

OffseT

#57

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: arnoldemuDo 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.

gerald

Quote from: OffseT on 09:20, 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.

arnoldemu

Quote from: OffseT on 09:20, 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.


Quote from: OffseT on 09:20, 27 August 16
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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Lone

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, do you remember the reason of this difference ?








arnoldemu

Quote from: Lone on 12: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 ?
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.

Quote from: Lone on 12:45, 22 October 16
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, 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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Fredouille

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 ?

arnoldemu

Quote from: Fredouille on 12: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 ?
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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

#64
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).
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Fredouille

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 ?

arnoldemu

Quote from: Fredouille on 13: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 ?
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).


Quote from: Fredouille on 13:57, 28 October 16
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

Quote from: Fredouille on 13:57, 28 October 16
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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Fredouille

#67
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, could you tell me what is wrong in my understanding ?

OffseT


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.

Lone

@Fredouille , @arnoldemu : 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)

arnoldemu

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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Fredouille

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 ?

roudoudou

Quote from: Fredouille on 08: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 ?


it depends mostly on the drive belt. It's very quick with a new 3.5 floppy drive
My pronouns are RASM and ACE

arnoldemu

Quote from: roudoudou on 10:18, 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.

:)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Fredouille

Hi @arnoldemu !! Any idea when new tests will be available ?

Powered by SMFPacks Menu Editor Mod