Firstly, thanks very much Kev and John for the info to get me started, I really appreciate it. Please note with my comments below I haven't hardly started reading the docs, just looking at scripts and ideas... Does anyone use the mame source code drivers memory map and hardware info to help with writing the scripts? I've been putting one together based on Kev's and the galaga.c mame driver to get started. So far I've done almost nothing but begin to add some comments in and the galaga memory map to the bottom, otherwise it is still the unedited V3 script from Kev. Do you use RKSIC.EXE or 9LC.EXE to compile it? or either? What are the pros and cons of each one? (I'm trying to work out what I can get away with with comments and script format)
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures? I don't understand this feature yet?
You know how when the 9010A fails a test command <RAM SHORT @ 0-3FF> it stops?
By tying pins 2 to 3 & adding additional code to test the state of the 232 port your program can be "fault tolerant". IE you could create a program that would let you go get a beer and when you got back it wouldn't be stopped at the first fault it found but could list every fault it found.
I see a SETUP MESSAGES code called SET-EXERCISE ERRORS? on the reference card that has this description: "Determines whether error messages and prompts for looping on errors are displayed" You could also use REG8 or REG9 to keep user entered script controls and counts: a) Have a user input yes/no to a "stop on errors" prompt at the start of the script, or is the setup code only allowed at the script start? b) Count the number of errors? and display it at the end of the tests if non-zero. If there were 8 tests, you could store a bit pattern in the register, and then report which tests failed at the end based on which bits were on. (if this thing will do the appropriate math on the register?)
The other problem I've noticed when coding I've strung a bunch of RAMs together & check each pair (2114s on Pole), but when it gives you an error message it just says RAM error at $4401, so now you've got to go back to the memory map & figure out which ram it is. Be nicer if it said VIDEO RAM 7F 8F BAD.
Isn't it possible to split the ram tests up into memory mapped pieces that match the chips or chip pairs? If there's a fault could it branch to a sub-test program that poked 0x00 and 0xFF into the failed address and reported the faulty read-back result? This would show which of the 4bit 2114's may be at fault. If the ram (or rom) test failed couldn't the script go to a sub-test that just poked that address only, continuously, so you could find the chip enable on the faulty ram/rom ? (or is that the looping function anyway :-) ) Cheers, Marc "9010A Galaga Script 1.txt" (missing attachment)