Friday, September 15, 2017

Disassembling the VDPTEST program for the Third Millenium Enginnering Arcade Board

So I thought I'd have a look at what the VDPTEST program actually does.

Doing a PR#1 and LOAD VDPTEST and LIST gets me:



What you see the basic program do is to BLOAD VDPTST which goes to address $1000 (4096) and it will patch it with the proper io addresses for the slot number. So every occurrence of C0C0 and C0C1 will get patched.

It will CALL 4096 after the patching and it writes the entire 16K ($4000) of the TMS9918 with the value held in memory location $104C and then reads it back, comparing it to what's in $104C.

If it gets an error, it writes $00 to address $2000 (8192), but if everything is cool it writes $CC to address $2000 (8192).

What is complete BS is the error reporting in the basic program. It looks for error information at 8193, 8194, 8195 and 8196, but quite frankly I don't see where it's getting this information, because the assembly program just doesn't write those locations. There should be an STX $2003, an STY $2004 or something.

It'll tell you there's an error, but the information reported is bogus.

I kept trying to figure out what the CALL 768 does. The CALL 768 in the program is setup in the HELLO program on the disk. It just resets the apple video output on reset according to the REM remarks.






So for fun, I thought I'd patch it by hand with the monitor so it would send the proper values to the basic program if there were an error. There's nothing like changing those values by hand.

I tested it using the mame debugger and changing the values in the TMS9918 vram by hand to simulate a memory error.

What was really driving me crazy is that the basic VDPTEST program kept patching the addresses after I'd changed them. A little "175 GOTO 210" fixed that. I changed the instances of $C0C1 to $C0C3 and $C0C0 to $C0C2 to get it to run under mame 189.



No comments:

Post a Comment