QuarterArcade Coin-Op Tech Net

Introduction FIDE Software Sign Utility Programming 9010A Code Generator

Intro to Scripting Intermediate Programming

Introduction

This article will show you some techniques that you can use to build a reusable script. It will focus on ROM testing, and how you can use existing information to build a ROM script to test a board. It assumes that you have some familiarity with script programming, the Fluke 9010A, and you know how to connect your Pod to your board.

Reasons for Testing ROMs

Sometimes a board is perfectly fine, but one or more ROMs has an error. If this is the case, your board may not do anything, including self-tests. Sometimes the ROMs are fine, but the CPU can't read from the ROMs due to a control line failure. One of the more useful scripts that you can right is a simple ROM test so that you can verify that the ROM is working.

Getting Started

The basic Fluke script command that you will use is the "ROM Test" command. It has the following format:

	!! Do a ROM test
	ROM test @ A000-AFFF SIG 9D35

The statement begins with "ROM test @" followed by the address range to test (in hex) and then a "signature" for that area. The signature is like a CRC, but it's a prioprietary numerical analysis that Fluke created.

Obviously you have a couple of question such as: (a) what addressed do I test and (b) how do I know what the signature should be? Figuring out the address map requires that you do a little bit of homework. Luckily, you have a few tools at your disposal:

Schematics: to effectively do board debugging, you will need schematics. From the schematics you should be able to figure out which addresses are mapped to which chips (ROMs). Unfortunately it can be easy to make a mistake going by the schematics alone. It also requires that you have a firm grounding in reading schematics and are able to convert the schematics into addresses.
Manuals: some manuals contain a full memory map or at least enough of one that you can figure out the addresses yourself. For example, Atari documentation is usually really good. Early Taito documetation actually puts the addresses right on the schematic and restates it in the manual.
MAME Source Code: Yes, MAME is a fairly accurate representation of the hardware, just as they state. You don't have to compile MAME in order to use it as a tool (although compiling it in DEBUG mode can be helpful). Looking in $/drivers directory for the appropriate source file can save you a bit of time. You may have to search for the game that you are working on (many games are grouped together in the same driver). But take a look at a snippet of code from Space Dungeon:
```
ROM_START( sdungeon )
	ROM_REGION( 0x10000, REGION_CPU1, 0 )
	ROM_LOAD( "sd14.u14", 0xa000, 0x1000, 0x7024b55a )
	ROM_LOAD( "sd15.u15", 0xb000, 0x1000, 0xa3ac9040 )
	ROM_LOAD( "sd16.u16", 0xc000, 0x1000, 0xcc20b580 )
	ROM_LOAD( "sd17.u17", 0xd000, 0x1000, 0x4663e4b8 )
	ROM_LOAD( "sd18.u18", 0xe000, 0x1000, 0x7ef1ffc0 )
	ROM_LOAD( "sd19.u19", 0xf000, 0x1000, 0x7b20b7ac )
	// ... cut
```
You can see right there that there is a mapping of ROM u14 from $A000 (0xa000 or A000h or however you like to represent hex values) and that size of the ROM is $1000. You're just about halfway there.

Let's say that you've figured out your memory map. You must now figure out what the signature ought to be. As mentioned aboved, the signature is a proprietary formula developed by Fluke. It's not the same as a CRC check, or an HP signature or an Atari signature. Unfortunately it's specific to Fluke. Note that because a different ROM set has different binary code, the signature will be different for that version of the ROM. So this problem can get complicated!

You can capture a signature from a known working board. But fortunately, even if you don't have a working board you can use MAME ROMs and the FIDE program to pregenerate some signatures for you.

Collecting Signatures

Using FIDE, under the Tools menu there is an option to build a signature from a ROM file. As of version 4.1.0, this could be done provided that you had unzipped the MAME ROM. What you can do is select several of the ROMs, and in this case we're going to do a quick pre-check and put each test it is own routine. You'll see why later. What you end up with is something as follows:

Fluke Signature Analysis: calculating from a MAME ROM file

Fluke Signature Analysis: calculating from a MAME ROM file

What you'll notice is the FIDE didn't know what address map to use. So, we get a code template that we can use, but not under we fill in the blanks. I selected the option to do a quick "pre-check" before running the full check. That's because a ROM check takes a long time. If I'm going to have a problem reading a ROM there is a very good chance that I can do a "spot check" and know that right away. If there is a subtle problem with the ROM, I'll let the signature analysis figure that out.

In this example I am using the Zoo Keeper board set and I am building a test suite for testing the ROMs off the video processor board. This means that I am testing ROMs U3 - U10. You will have to change your script to suite your needs.

Here is the code that I will have after generating my template:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za10
!! Purpose: ROM test based on file 
!! 	0000:  4C F5 57 F5 9A FB 8F 34    76 DC 03 1E 89 43 DD 03 
!! 	0010:  D6 01 C1 24 26 1C DE 03    33 C9 01 09 FF 94 02 D6 
!! 	0020:  02 F7 94 00 33 C9 04 00    FF 94 02 F7 94 00 DC 03 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za10
	read @ 0000
	if DAT = 4C goto L0
	aux ERROR AT ADDR 00
	aux ___GOT 4C
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig 7F4B	! from file: za10
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za3
!! Purpose: ROM test based on file 
!! 	0000:  7E E5 D9 3B FF FF 7E E7    64 00 00 01 00 00 01 01 
!! 	0010:  01 BB 63 BB 89 BB AF BB    D5 08 0D 00 FE 20 00 70 
!! 	0020:  20 20 20 20 70 00 00 00    00 60 00 10 10 20 20 20 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za3
	read @ 0000
	if DAT = 7E goto L0
	aux ERROR AT ADDR 00
	aux ___GOT 7E
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig 9D35	! from file: za3
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za4
!! Purpose: ROM test based on file 
!! 	0000:  20 00 00 20 20 20 70 60    00 70 20 20 70 00 60 00 
!! 	0010:  20 20 20 70 60 00 00 20    20 70 20 20 60 00 20 70 
!! 	0020:  20 20 20 60 00 70 20 20    20 70 70 00 00 20 20 20 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za4
	read @ 0000
	if DAT = 20 goto L0
	aux ERROR AT ADDR 00
	aux ___GOT 20
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig 8AB7	! from file: za4
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za5
!! Purpose: ROM test based on file 
!! 	0000:  7E E5 D9 3B FF FF 7E E7    64 00 00 01 00 00 01 01 
!! 	0010:  01 BB 63 BB 89 BB AF BB    D5 CF 04 CF 38 CF 41 CF 
!! 	0020:  52 CF BC CF C7 D0 55 D1    2E D1 3A D2 BE D2 D2 D2 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za5
	read @ 0000
	if DAT = 7E goto L0
	aux ERROR AT ADDR 00
	aux ___GOT 7E
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig 2020	! from file: za5
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za6
!! Purpose: ROM test based on file 
!! 	0000:  E0 D0 C8 0A 03 00 00 00    60 60 00 60 60 20 40 01 
!! 	0010:  03 00 04 02 C0 C0 40 80    08 05 70 C8 C0 70 08 08 
!! 	0020:  C8 70 08 06 FC 30 30 30    30 30 30 30 08 05 C8 C8 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za6
	read @ 0000
	if DAT = E0 goto L0
	aux ERROR AT ADDR 00
	aux ___GOT E0
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig 63D6	! from file: za6
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za7
!! Purpose: ROM test based on file 
!! 	0000:  10 10 A0 40 00 00 00 00    20 40 00 00 00 30 00 10 
!! 	0010:  10 10 30 10 10 00 00 60    00 00 00 00 00 00 00 10 
!! 	0020:  10 10 10 A0 00 10 10 00    00 20 20 00 00 00 A0 A0 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za7
	read @ 0000
	if DAT = 10 goto L0
	aux ERROR AT ADDR 00
	aux ___GOT 10
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig D72	! from file: za7
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za8
!! Purpose: ROM test based on file 
!! 	0000:  27 50 DD 3E 9E 3E 6D 63    26 25 86 05 34 02 86 05 
!! 	0010:  A0 E4 48 EC C6 31 8B 10    9F 39 10 BF 94 02 B6 94 
!! 	0020:  00 95 3B 27 08 6A E4 26    E5 35 02 20 D0 35 02 6A 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za8
	read @ 0000
	if DAT = 27 goto L0
	aux ERROR AT ADDR 00
	aux ___GOT 27
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig D7AF	! from file: za8
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: za9
!! Purpose: ROM test based on file 
!! 	0000:  BD DF 6A BD CE D1 35 52    39 34 06 96 2A 44 44 44 
!! 	0010:  44 C6 0A 3D 96 2A 84 0F    34 02 EB E0 86 0C 3D CB 
!! 	0020:  54 1F 98 C6 21 0D 2D 27    02 C6 85 DD 3C 34 06 BD 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program za9
	read @ 0000
	if DAT = BD goto L0
	aux ERROR AT ADDR 00
	aux ___GOT BD
	aux ___EXPECTED $DAT
	goto ErrCond
 
L0:
	ROM test @ aaaa-bbbb sig F73	! from file: za9
	goto ProgDone
 
ErrCond:
	dpy # ERROR \1
	aux ERROR
 
ProgDone:

Add in the memory map

I have to fill a couple of holes though. The memory map isn't filled out, and every "pre-check" is done based on address "0000" which isn't correct. But, reading through the Zoo Keeper documentation and MAME driver, I find that the memory map is:

U3	A000-AFFF
U4	B000-BFFF
U5	A000-AFFF
U6	B000-BFFF
U7	C000-CFFF
U8	D000-DFFF
U9	E000-EFFF
U10	F000-FFFF

Notice that U3, U4 and U5, U6 share the same address space? Well, that's because ZK uses paging. This is somewhat of an important point, as if you were testing by hand (without writing a script), you'd have to remember that you need to select the proper page before running each test. Very easy to forget if you're not taking good notes. So I took this memory map, and updated my scripts. I also created two new routines labeled "Page0" and "Page1". Executing that routine will make sure that the specific page is set. Again, this is from information in the ZK manual. Not all manuals will be as detailed.

Putting it all together

One thing that I haven't done yet is made an easy way to select when test I want to run. Maybe this is a new board under test and I want to test all ROMs. Maybe I'm having a problem with just one ROM and I want to re-test because I suspect a chip select or chip enable line is faulty. Well, we're going to write a simple menu program that will allow the operator to choose what they want to do. I have a fairly standard format. It would look something like:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Program: MenuMenu
!! Purpose: Switch between various commands. 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program Menu

declarations
	assign REGB to INPUT
	
	!! introduce program
	dpy ZOOKEEPER VID ROM SCRIPT
	aux ZOOKEEPER VID ROM SCRIPT

	stop
Menu:
	INPUT = 0

	!! fully describe options through serial port
	aux _
	aux _
	aux TEST ROM MENU
	aux ____3=ROM TEST U3_ A000-AFFF P1 
	aux ____4=ROM TEST U4_ B000-BFFF P1
	aux ____5=ROM TEST U5_ A000-AFFF P0
	aux ____6=ROM TEST U6_ B000-BFFF P0
	aux ____7=ROM TEST U7_ C000-CFFF P0
	aux ____8=ROM TEST U8_ D000-DFFF P0
	aux ____9=ROM TEST U9_ E000-EFFF P0
	aux ____1=ROM TEST U10 F000-FFFF P0
	aux _
	aux ____A=ROM TEST ALL
	aux _
	aux COMMAND>
	dpy CMD ROM>3-9,1, A=ALL/B

	!! only control we have -- if (statement) goto (label)
	if INPUT = 3 goto Menu3
	if INPUT = 4 goto Menu4
	if INPUT = 5 goto Menu5
	if INPUT = 6 goto Menu6
	if INPUT = 7 goto Menu7
	if INPUT = 8 goto Menu8
	if INPUT = 9 goto Menu9
	if INPUT = 1 goto Menu1

	if INPUT = A goto MenuA
	goto Menu

!! Each time label executes our ROM test
Menu3:
	execute za3
	dpy ROM U3 DONE
	stop
	goto Menu
		
Menu4:
	execute za4
	dpy ROM U4 DONE
	stop
	goto Menu

Menu5:
	execute za5
	dpy ROM U5 DONE
	stop
	goto Menu

Menu6:
	execute za6
	dpy ROM U6 DONE 
	stop
	goto Menu

Menu7:
	execute za7
	dpy ROM U7 DONE 
	stop
	goto Menu

Menu8:
	execute za8
	dpy ROM U8 DONE 
	stop
	goto Menu

Menu9:
	execute za9
	dpy ROM U9 DONE 
	stop
	goto Menu

Menu1:
	execute za10
	dpy ROM U10 DONE 
	stop
	goto Menu

MenuA:
	execute za3
	execute za4
	execute za5
	execute za6
	execute za7
	execute za8
	execute za9
	execute za10
	dpy #
	dpy #
	dpy ALL ROM DONE 
	stop
	goto Menu

Conclusion

That's about it. Well, you say what do you mean that's about it? That was a lot of work. Yes, that may be true the first time you do this. But it gets easier with each new board. Also, once you do it right the first time, you don't have to go back and figure it out again. You've got all of your tests for ROMs in one place. Zoo Keeper isn't the easist board to work on anyways, so this example really shows many points. Also, it doesn't show you how to test many different ROM versions or tell you what to do when you've found a bad ROM. (Usually you've found the problem when you've found one bad ROM, but there are exceptions.)

Some things that could done to make this program better:

Dump out portions of ROM memory in the even of failure. That will help you figure out if you have a chip enable/chip select problem.
Fix the "stop" commands and just prompt the user. Using "stop" requires that the user hit "continue" to proceed. Not intuitive to the operator.

The program should have some set up code in order to make it "complete." Here is the full program for you to review: ZK Example 1.9lc.

this page took approx. 0.014s