Post by willymanilly on Sept 20, 2018 11:38:47 GMT
Thanks heaps. It's much appreciated. I will let you know when it arrives. That will greatly assist when I start doing tests in interlaced other modes standard monochrome has difficulty displaying.
I have updated the tests to show lightpen values reasonably close to the trigger point. The format is LIGHTPEN: LPY LPX
I have also include the number of cycles for the block fill command to execute. It doesn't deduct the actual setup time (which is a constant value) from the result at the moment so the result will show a value a bit higher than the true result.
Some things I've noticed.
Lightpen can be triggered and latched multiple times on each frame
The internal row counter seems to increase to next value around character counter 7 (assuming LPY and LPX use those to determine screen position) Set delay value to 4BD and increase the delay by pressing the D key a couple of times. This assumes VDC is in PAL mode. If not press key P.
Block fill time to execute and release the busy flag varies depending when the register is written to but seems to be predictable. I just need to analyze it and create some more tests to see if I can work out a pattern
LPX=~38 line 0: 4CB C2 140 C2 140 line 1: 50A 83 101 83 101 line 2: 549 44 C2 44 C2 line 3: 586 44 83 44 83 line 4: 5C5 44 44 44 44 line 5: 604 44 44 44 44 line 6: 643 44 44 44 44 line 7: 682 44 44 44 44
What I conclude from this so far is:
Each line requires 85 VDC cycles to fetch character graphics data. ($44-$1A=$2A, $2A = 42 cpu cycles, 2000000 X 42 / 985248 =~85 VDC cycles) I'm guessing this is 80 character fetches + 5 DRAM refresh cycles. note: I've tested increasing/decrease register 36 an confirm this affects time. I have not included those results this time.
Extra fetches are required on the first line to get character pointers. Attributes require even more VDC cycles as expected.
PAL has an additional cycle per line so has the extra free cycle to action the block fill of 1 one line earlier than NTSC. When using block fill of 2 the result is the same as NTSC because it cannot complete the blockfill before the next line of character graphics data fetches. i.e. ($C2-$98=$2A) $2A is the same value as used in the first dot point implying an extra line was read before completing the blockfill
Next stage will be to implement this into Z64K so it's busy flag behavior is the same as a real C128. I also need to test DRAM refresh cycles and double pixel modes influence on the busy flag.
Thanks for sharing. I'd be curious if you or anyone else get the same results as I got by adjusting the delay to the same positions as in my results. Be sure to press P or N if your default frequencies don't match the PAL or NTSC in my results. Next test update I plan on including automatic calculation of the c128 main cpu speed and the number of VIC cycles/VDC line, VDC version number, and VDC RAM size. It might be a little while before I update the test because I'm now working on implementing improved VDC busy flag behaviour in Z64K based on the results I have on hand.
First 6 pics are PAL, the next 6 NTSC (my 1084 doesn't seem to mind). On blockfill test 1 and 2 in NTSC the white line is doubled, but this doesn't show in the pictures of test 1.
Thanks heaps for this. The PAL tests match perfectly with the results I posted. I noticed you used the delay of 4D6 I used for PAL instead of 4CB for the NTSC but I double checked using your values and confirm all your results match my real C128 perfectly!
I'm currently rewriting Z64Ks VDC emulation from scratch to incorporate everything discovered and discussed in this thread. Of course I will be doing thorough testing of everything to ensure I don't break anything before releasing the major update.
You need to make the test program generate the numerical data as a QR code so people can post a photo of it which you scan to get the results into a spreadsheet/database
Seriously though, this is great work and I am so happy to have an emulator I can test my code against and know there is a fighting chance it acts the same on real hardware.
It won't be as easy as scanning a QR code but once I have implemented everything I have discovered so far, I will be updating the test suite to automatically plot results into a table and save them to disk. It might take some time because before I work on that because my retro time is now being spent rewriting all of Z64K's VDC emulation.
Considering the work you are putting in I have posted your replacement chip today. I don't know how long it will take so let me know when it gets there Enjoy.
I just got back from holidays and this was waiting for me. Thanks again. I will have to wait until this weekend to get the correct tool to do the replacement though. I also got my hands on a 1084S monitor in very good working condition which will be getting a lot of use.