Let me begin by saying I am not a programmer, my background mainly being digital and analog electronics - hardware rather than software. So the programs here really are home brew creations and mainly written for the purpose of troubleshooting arcade PCB hardware.
I've mentioned most of these test programs before in various PCB repair logs but as they share a common goal it seems worthwhile to gather them onto a single page.
Many arcade titles have inbuilt diagnostic routines which run upon startup or when a 'test' input is selected. But many, especially earlier or lesser known games have none. And what to do when a hardware fault prevents existing on board diagnostics from running?
That's when we reach for the test equipment be it logic probe, oscilloscope or if we are especially well equipped we may have a made for purpose tester such as the Fluke 9010A which connects to the PCB via the CPU socket (using a CPU specific test pod) and can perform various tests on the system resources from the CPU's point of view.
Sadly I don't have the funds (or the bench space) for a dedicated system tester and rely upon my analog oscilloscope for most fault tracing but it occurred to me that we could write some simple firmware and enlist the PCBs own CPU to assist with some of the troubleshooting tasks.
That was the case in this first example which I wrote to assist with a PCB repair; Missile Command by Atari. The game would not run, when test mode was selected the on board RAM test would complete (after I duly replaced one faulty 4116 RAM IC) but before the remaining diagnostic tests could run the program would freeze and the watchdog timer reset the 6502 CPU.
Although the RAM was now known to be good and I had already removed and verified the program ROMs, some other hardware issue was preventing the program from proceeding. Using the oscilloscope to trace the signals on board did not reveal anything as the program would fail too quickly to observe much activity.
Missile Command test cable and test EPROMs, 2020
My answer to this problem was the 'reading every address' loop. That program did little more than read every address from 0000 to 7fff in a continuous loop. It did nothing with the data read, what it did achieve was to create some predictable activity on the CPU address bus which could be viewed on an oscilloscope enabling hardware faults to be easily traced.
With the aid of the program loop I soon identified the address decoder issue affecting one half of one 2k Byte ROM and replaced the faulty component. With the PCB now running and on board diagnostics working correctly, at the time there was no need to develop the 'reading every address' program beyond that purpose.
I may revisit this program at a later date and add some testing routines which are not included in Atari's on board diagnostics such as the multiplexed RAM addressing modes. Meanwhile the 'reading every address' loop proved so successful for fault tracing I have incorporated that into my subsequent test ROM programs.
My next attempt at a test ROM, for the z80 CPU in Exerion by Jaleco was more ambitious. Exerion included no diagnostic software so I wrote a test routine which checked three areas of RAM, outputting results to that PCBs text layer, followed by a version of the 'reading every address' loop for good measure which also placed a character on screen for every address read to indicate continuing activity.
Exerion Test ROM, 2021 - running in MAME
Apart from filling every RAM address with each data value from 00 to FF Hex and reading those back the program could also identify addressing issues where data might be written to an incorrect address location and potentially overwritten by other data written to the same address.
To test for this type of issue the address of each RAM location is written as data and once complete each RAM address read back and its data compared to the address. As each 16 bit address amounts to two bytes of information the routine involves two passes, first for the high order address byte then for the lower.
For the Sprite RAM address testing I also wrote a rudimentary error display routine to assist with troubleshooting an issue where the tests would Pass when run in MAME but not on actual hardware. It turned out although the Sprite RAM comprises 1k Byte ( 2 x 2114 1k x 4 bit ICs) on the actual game PCB their upper 3 address inputs are tied to ground so only 128 Bytes of Sprite RAM are actually available.
I've since updated the RAM testing routines to only check those 128 bytes of Sprite RAM which are useable on the actual game PCB, the remaining bytes not used and impossible to access as configured in hardware.
In the photo above with the test program running in MAME I've manually triggered the error display which shows the Sprite RAM address in question (in binary, reading from top to bottom) as 8800 Hex and next to that the data read back which in this case corresponds to the upper address byte 88. When running on actual hardware an error condition would be detected and displayed if the address and data values do not match at any point in the Sprite RAM Address testing routine.
Asm316.asm RAM Test Rev.6 Assembly listing
Prom5_diags6.4p RAM Test Rev.6 Hex file
For Shuttle Invader which is an earlier game using an 8080 CPU with a limited instruction set and only bitmap graphics ability achieving the same goal was more challenging. Compared to the z80 instruction set, the 8080 has no extended instructions for data fill or individual bit operations. The original EPROMs on the Shuttle Invader PCB are 2708s with only 1kByte of storage so the entire program including any graphics should ideally be written to fit within a single EPROM.
For a RAM testing program there is another limitation, the RAM itself can not be relied upon for the program to run. The entire program should only make use of the CPUs internal registers and the 'boot ROM' location for the program itself. That means no subroutines can be called or any data pushed onto the stack for temporary storage as these operations require a known good area of RAM to be set aside.
The program I've written begins by filling the dynamic RAM area with data, beginning with all zeros then reading each address back and checking for errors. If all good it increments the data and repeats the process for every data value from 00 to FF. As most of the DRAM is video memory the resulting patterns should be visible on screen as the test progresses. At the beginning of each test loop a brief, low pitch tone should also be heard.
If that completes correctly it does two more passes where the address of each memory location is written as data, first using the low order address byte of each memory location then the high order byte. The purpose of this last step is to identify any addressing errors where data may be written to the wrong memory location then overwritten by other data. If there are no errors a 'DRAM: PASS." graphic message is transferred to the video memory and a similar process commences for the static RAM area.
As the static RAM is being read, each byte read is also written to an area within the video RAM so the patterns read back from static RAM can be viewed on screen. If these tests pass a "SRAM: PASS." graphic message displays that result and the program moves on to a continuous 'reading every address' loop, also writing the data read to an area within the video memory so the activity can be viewed on screen.
Shuttle Invader Test ROM, 2024 - running in MAME
At any point during the RAM testing if there is a read error a high pitch tone sounds and the program continuously rewrites and re reads that memory location, announcing the result with a low or high pitch tone each time. Repeating the write and read of that particular memory address allows the problem area to be identified in circuit using an oscilloscope or logic probe. In the latest version of the test ROM the address, data written and data read back from that location are decoded and displayed on screen as a graphic message allowing a faulty RAM IC to be identified directly.
Here is the Shuttle Invader Test ROM running in MAME; once again I've manually triggered the error display message where A is the address, D is the data written and R is the data read back. When testing actual hardware an error will be indicated if D and R are not equal.
Asm406.asm Shuttle Invader Test ROM v1.6 Assembly listing
test.13c Shuttle Invader Test ROM v1.6 Hex file
Having completed the test program for Shuttle Invader and proving its worth in a recent PCB repair it occurred to me the test routines contained within could be ported to other games of the era which employed similar hardware and had no existing diagnostic software available. The first example which came to mind was Space Fever by Nintendo.
To date I've managed to repair a number of Space Fever PCB sets without the aid of any diagnostics but may have saved a lot of time and guesswork if RAM faults could have been easily identified or eliminated. Of course the memory map and screen layout are different for the two games, requiring some parameter changes to the test program.
Although Space Fever has more RAM memory than Shuttle Invader the testing procedure is much simpler with just a single 16k bank of dynamic RAM for Space fever compared to Shuttle Invader's 8k dynamic plus 1k Byte of static RAM. That eliminates the need for a second set of RAM test routines, leaving some free space in the 1k Byte EPROM capacity so I decided to try my hand at adding a test routine for the shifter circuit in the Space Fever Hardware.
Space Fever Test ROM, 2024 - running on actual game PCB set
Many invader style games use a shifter circuit to quickly move the objects on screen by 1 - 7 pixels before they advance to the next byte of video RAM and the process then repeats. The shifter circuit is really just moving the graphics data within each byte to achieve fast scrolling rather than keeping track of the objects outright positions.
This saves processing time compared to performing the shift operations within the CPU and avoids an issue where shifting an object by multiple bits would take additional clock cycles for each extra bit shift operation.
Writing a test routine for the shifter circuit in Space Fever was a learning experience as it required a deeper understanding of the circuit to predict the correct operation and identify a fault situation. To begin with, a byte of data to be shifted is sent to a latch on the video PCB. Another latch is sent the shift value, from 0 to 7.
The data latch has two stages, the second stage will contain the byte of data which was latched in the previous shift operation. Using these two data bytes allows bits which would have overflowed from the previous shift operation to be effectively shifted into the current byte, providing a 'seamless' transition of objects as they are shifted pixel by pixel from one byte of screen RAM to the next.
For the purposes of testing, I found that a single data byte could be sent to the latch twice in succession so both stages would contain the same byte value. When the shifted value is read the bits within that byte should effectively be rotated; that is bits which overflow from bit 7 appear on bit 0.
So the test routine involves latching a byte of data (twice) with an initial shift amount of 0 and reading that back from the output of the shifter circuit. Then the shift amount is incremented, also a CPU 'rotate left' instruction is performed on the initial data so the data read back from the shifter can be compared with the predicted value.
If that is correct the process repeats for each shift value from 0 to 7 and each data value from 00 to ff. Of course if the initial data is 00 then the shifted value should always be 00 as well but every data and shift value is tested nonetheless. Should there be a discrepancy between the predicted and actual values read an error is displayed.
Space Fever Test ROM, 2024 - running in MAME
For the Space Fever test ROM, if there is an error with either the RAM or the shifter circuit the program will display an error code and then just retest the same error location repeatedly. If the error is intermittent the result will sound a 'pass' or 'fail' tone and update the display each time the same location is re tested.
For the RAM test the error message looks like Axxxx Dxx Rxx where A is the address, D is the data written and R is the data read back. If D and R are not the same there is an error.
If you see the DRAM: PASS. message and SHIFT: then an error code that is a shifter error where: A - the first two digits are the data sent to the shifter from 00 to FF and the next two digits are the shift amount from 00 to 07
D - is the calculated result using the CPU to do the shift operation and R - is the result read back from the shifter circuit. Once again, if D and R are not the same there is an error.
Asm615.asm Space fever Test ROM v1.5 Assembly listing
f1-test.bin Space fever Test ROM v1.5 Hex file
By the way, just the character graphics data for the pass / fail messages and numerals 0 to 9, letters A to F take up 256 bytes of the available 1024 so the program itself fits into the remaining 768 bytes of EPROM space. As mentioned the program should run even if the RAM is not working however a meaningful on screen display would require the video area of RAM to be working to some extent.
Even if the on screen display is garbled or the RAM completely corrupted the program should still function and output some sounds (if the sound is working). At the very least the test program should generate some repetitive activity in the area of the circuit where errors are present.
Just a little addition to my Homebrew test ROMs; here was a PCB mod and ROM hack to create a standalone RAM tester for 2114, 1k x 4 bit static RAM ICs.
These RAM chips are commonly used on arcade PCBs as well as early computers. I recently bought a batch of them online to upgrade the RAM on my Ohio Superboard II computer reproduction from 4k Bytes to a full complement of 8k Bytes, requiring another 8 ICs.
As usual the ICs received were obviously second hand reclaimed parts which had been scrubbed off and re marked, having identical part number and date code markings despite being in different packages with slight variations in the plastic mouldings such as the shape of the slot which identifies pin 1. Some still had different manufacturer codes printed on the underside of the DIP package.
That's pretty much par for the course with these obsolete components so the real challenge is to see if any or all of these components actually work. Initial results, plugging the ICs into the empty sockets on the Superboard were not promising. With a bit of swapping I found 4 of the batch of 10 which I purchased were working OK but combinations of the remaining ICs seemed to fail.
The problem with using the computer itself to check if the ICs were working is the cursory RAM test on startup doesn't shed much light on the specific ICs at fault. Being only 4 bits 'wide' the ICs are used in pairs, each pair being 1k Byte of RAM.
The on board RAM test which was simply designed to establish how much RAM is available seems to just check each byte for a result, stopping at the first error. That will identify the first pair of ICs which are not working but not which individual IC (or both) is at fault and will not proceed to check any IC pairs after that.
I guess the only sure way would be to start with however many ICs are known to work then substitute one IC at a time, to test each one individually before fully populating the remaining RAM sockets. Although that would work I am usually reluctant to swap multiple ICs, one after the other into an otherwise working PCB if a better alternative exists.
That led to the idea of a standalone RAM tester utilising a Zero Insertion Force (ZIF) socket which could test the 2114 ICs individually rather than in pairs. I do have a slightly older model TL866 EPROM programmer which can also test some static RAM ICs such as the 6116 and 62256 types but sadly not the 2114.
Meanwhile, I recently built up a Z80 CPU test PCB which was not my own design but an open source project. I was given the blank PCB along with some of the components - actually I swapped them for a spare 2708 EPROM programmer PCB which is another open source project along with a few parts for that. Details for both of those projects can be found in the links at the bottom of page.
Anyway I completed the build of the CPU tester and it worked well as intended. It tests the operation of the Z80 CPU at various clock frequencies and can also identify original type NMOS CPUs or later CMOS types by testing their response to some extended commands which are handled differently by the two types. A row of 8 LEDs serves to identify the IC type as well as confirming the function of the 8 data lines with a simple LED chaser effect.
Here's the CPU tester completed in its original form. There is no RAM on board and the entire 64k Byte address range of the Z80 CPU is directed to a 27C512 or equivalent EPROM of which only 420 bytes of code are used for the CPU test program.
To me, that immediately signalled a potential for this little PCB to perform some other useful task in addition to testing the CPU in question. Why not add some RAM and test that as well?
As it happens, I had already substituted a 27C256 EPROM as I had no 27C512s on hand, cutting the track which carried the upper address line A15 to pin 1 of the EPROM and linking that pin of the 27C256 (Vpp) to +5V instead. I had also chosen to use various coloured LEDs to make the LED chaser more colourful, these could be helpful to indicate RAM test Pass or Fail conditions.
So, I made up a little board which plugs into the EPROM socket, most of the necessary signals are on there . I didn't have an 18 pin DIP ZIF socket handy so just used a 24 pin narrow ZIF socket which I had to hand, leaving the bottom 6 contacts unused.
It's just a one off prototype built on a very small piece of Veroboard so all of the interconnections are done with wire on the track side.
- But could easily be built as a neat little add on PCB or added into the main PCB design without too much trouble...
I used a spare gate on the 74LS02 to invert A15, when high the EPROM is disabled and the RAM is selected. The other signal from the main board is the CPU /Write output.
After the original CPU test completes one pass the RAM tests run. Lucky I used various colour LEDs originally. Two green = PASS.
Two red = FAIL and orange/ yellow indicate data or address range at fault. Above is a data error. The IC below passed the data test but was found to have a fault in one of its upper address lines A8 or A9. Yellow LEDs would indicate a fault in the lower address lines A0-A3 or A4-A7.
If no RAM is present the CPU test will still run and repeat as normal but will just indicate the RAM error in between passes. The extra code for the RAM tests is only a couple hundred bytes, taking the program size from 420 up to 656 bytes!
So the upshot with the previous RAM IC order for 10 pieces was 7 working, 3 bad. It is definitely a lot easier to test them individually, when installed into the computer it was pretty confusing to work out which ones were good and which were bad.
I'll add a little video to the links below and the extra code for the RAM test mod here:
Asm700.asm cpu_ram_test v1.0 Assembly listing
cpu_ram_test.bin v1.0 Hex file
- More updates and test programs to follow in due course.
Web Resources (External Links) -
Z80 CPU tester modified to also test 2114 RAM ICs - YouTube
Z80 CPU tester PCB: djtersteegc/z80-cmos-nmos-tester - GitHub
Fluke 9010A Micro-System Troubleshooter - Centre for Computing History
All images and text on this website are Copyright.
Contact: jbtech at telstra dot com