Started by arnoldemu, 21:56, 20 January 16
0 Members and 1 Guest are viewing this topic.
Quote from: Lone on 00:25, 20 August 16Hello,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
Quote from: Lone on 00:25, 20 August 16As for now, my 8255 emulation works exactly like my beloved 6128... (all tests give same almost same results).
Quote from: OffseT on 19:10, 21 August 16As 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_suiteAll 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!
Quote from: OffseT on 19:10, 21 August 16As expected I had a look at your tests.
Quote from: arnoldemuMost of the CRTC register tests (e.g. crtc_r5) require you to move the position of the raster using the joystick/joypad [...]
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.
Quote from: OffseT on 11:20, 27 August 16Also, 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.
Quote from: OffseT on 11:20, 27 August 16 Oh! I didn't see that. What a strange idea to use the joystick anyway. I guess that your tests can trigger overflow situations by this way. So, that's even better than I thought. I will update my report as soon I have time... and once I've found a joystick somewhere!
Quote from: OffseT on 11:20, 27 August 16I 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.
Quote from: Lone on 14:45, 22 October 16Hello,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 ?
Quote from: Lone on 14:45, 22 October 16The 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 &80I 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 ?
Quote from: Fredouille on 14:28, 28 October 16Hello,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 ?
Quote from: Fredouille on 15:57, 28 October 16Thank 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 ?
Quote from: Fredouille on 15:57, 28 October 16I 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 ?
Quote from: Fredouille on 15:57, 28 October 16When 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 ?
Quote from: Fredouille on 09:35, 09 November 16I 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 ?
Quote from: roudoudou on 11:18, 09 November 16it depends mostly on the drive belt. It's very quick with a new 3.5 floppy drive
Page created in 0.160 seconds with 49 queries.