Problem

Hangs during boot at ‘Running 29k diagnostics…’ phase.

Diagnosis

I purchased a non-working Microprose F-15 Strike Eagle cabinet last year as I find the game fascinating – it’s a fairly rare oddity. It was the first of three games produced by Microprose’s short-lived Microprose Games arcade division. Very loosely based on the PC game of the same name, it was reportedly an expensive failure for the company. I don’t recall ever seeing the game in an arcade but I clearly remember reading a preview of it in an issue of Computer and Video Games magazine nearly 30 years ago.  I added support for the Microprose arcade system to MAME some years back so I know the hardware fairly well!

The Microprose arcade system is a complex beast. Fortunately, schematics are available online.

The stack comprises the following PCBs:

Host

A 68000 running at 16MHz runs the game logic and handles digital and analog I/O. It also holds 1MB DRAM that is shared with the Dr. Math and VGB PCBs.

Dr. Math

This amusingly-named PCB handles all the 3D maths and drives the actual 3D hardware.

Dr. Math is based around an Am29000 running at 16MHz (the aforementioned 29K), an oddball RISC CPU that was more likely to be found in laser printers than arcade games. An Am29C323 32×32 fixed-point multiplier is used to perform the multiply-accumulate (MAC) operations that are integral to 3D maths.

VGB

Both the 2D and 3D video hardware are found on this PCB. A TMS34010 handles all the 2D graphics and generates video sync signals. The 3D hardware itself is based on 8 ASICs:

There are six identical clipping ASICs (near, far, left, right, top and bottom) that process triangles and two ‘draw’ ASICs; an edge walker (‘MPGDRAW1’) and a span walker (‘MPGDRAW2’). There’s enough 3D framebuffer memory to allow for a double-buffered, medium-resolution display of 576×400 at 12bpp (which in turn indexes colour RAM to produce a 16bpp output).

Sound

An 8031 microcontroller drives a YM-2151, UPD7759C and two filtered noise sources that are used for explosions, engine sounds etc.. Communication with the host is over serial link.

Each PCB (except for sound) has a UART that can be used to access a debug monitor program that runs on each CPU. This would prove very useful later…

My assumption was that there was an issue with the Dr. Math PCB. Most of this PCB is inaccessible for probing because it’s underneath the host board in the stack. Fortunately the Dr. Math PCB can be powered and run independently of the other PCBs (up to a point).

There are three LEDs on the Dr. Math PCB:

I noticed that the bus Error LED was always lit. It is connected to the Am29000’s MSERR pin, which, according to the Am29000 Users Manual, indicates the following:

“If there is a single processor in the system, the MSERR output indicates that a processor driver is faulty, or that there is a short-circuit in a processor output.”

Hoping for a quick fix, I swapped in a spare Am29000 but this did not fix the problem. I then realized that the MSERR signal is active high which meant that the bus error LED would be lit if there wasn’t an error condition. Oops…

I dumped all of the host and Dr. Math ROMs and verified that they worked correctly in MAME. My version is actually undumped and I will add it to MAME shortly.

Probing around the PCB with an oscilloscope revealed no activity from the Am29000; all of the control lines had gone high impedance. Checking the status pins showed that the CPU was actually in ‘pipeline hold mode’, meaning it was likely waiting on a bus access. Resetting the Am29000 produced a very brief burst of bus activity. In order to diagnose the issue further, I would need to use my logic analyzer.

The Am29000 has separate data buses for instructions and data. Both buses support burst mode accesses for faster accesses to sequential addresses. The first address of each access is placed on the address bus and then loaded into an external counter which increments to provide the following addresses. The logic analyzer showed that the first jump to $2188 was correct (I used MAME to disassemble the Am29000 program to confirm this) but the subsequent jump was not. The signal which loads the address counter, /ROMLD, appeared to either oscillate wildly, not change at all, or instead follow ROMLD:

This signal originated from the GAL22V10 at U138, a part listed in the manual as ROMADLDA. I probed some more input signals and confirmed that the  /ROMLD output was changing independently of the clock and inputs. Looks like the GAL was bad! I desoldered it and attempted to read it in my UniSite programmer but it complained about bad continuity on one or more of the pins. Fair enough. At this point, all I needed to do was to program a replacement GAL. Unfortunately I couldn’t because nobody has managed to dump any of the PLDs from this PCB 🙁

I recalled some years ago that a friend had been sent a collection of PLDs removed from a non-working/untested B.O.T.S.S. boardset in order to read/reverse-engineer them (most, if not all, were locked and cannot not be read conventionally). I asked if he still had them and miraculously, he did!

Once I had received the PLDs, I eagerly fitted the replacement GAL. While this didn’t miraculously fix the game, at least now the Am29000 was now executing hundreds of instructions as opposed to just a handful:

The Am29000 was now also writing messages to the UART:

On closer inspection, the Am29000 appeared to be waiting on a data memory access to address 0x03999800:

As far as I know, this is not a valid address and is not decoded by the DRDY/wait-state generators, which will cause execution to halt indefinitely (the Am29000 has an MMU but the game does not make use of it). At this point I wondered if RAM accesses were broken and that this address was actually a bad pointer. The Am29000 has access to 2MB of private DRAM on the Dr. Math PCB, which also allows burst mode accesses in the same manner as the instruction ROM space. Unfortunately the schematic sheet which shows the RAM control GAL and the burst access counters is missing from the PDF I found online. I did some tracing and found that the 74F169 at U68 was the burst access counter and that its load signal was wacky in much the same manner as the /ROMLD signal encountered previously. This /RAMLD signal originates from the GAL22V10 at U130, RAMADLDA. Looks like I’d have to replace another bad GAL…

Replacing the GAL was clearly a step in the right direction, as now I had access to all the Dr. Math tests, once I had reconnected the host and VGB PCBs:

I decided to run through the various 3D pipeline tests to see if further misery awaited. (I was afraid the 3D ASICs might be defective). Reassuringly, everything appear to pass:

The game would still not boot however. The error message hinted that communications between the 68000 host and Am29000 might be broken (they communicate via shared RAM and interrupts):

The host program tests the RAM shared with the Am29000 and reported no errors. I decided to check shared RAM accesses on the Am29000 side. Using the monitor, I wrote to various address and got incorrect results when I read the values back:

Probing the shared DRAM with the logic analyzer showed that the row address of each access was dodgy. Here I am attempting to write to address 0 of the shared DRAM:

I located the registers on the Dr. Math PCB which latch the row and column addresses. Their output enables are, unsurprisingly, generated by a GAL (GAL22V10 at U70):

I stuck probes on both D68RAS and 68RAS, which was annoying as I had to put them underneath the host PCB. This did however reveal that the D68RAS was utterly nonsensical:

I wasted no time in removing the third GAL and socketing its replacement…

At this point, the messages displayed by the host and Dr. Math monitors were very encouraging:

I hooked up the video output to my LCD panel and was rewarded with glorious flat shaded polygons. Woohoo!

I reassembled the boardset and put it back in the cabinet to verify its full operation. Everything seemed to work great, with the exception of the attract lamps at either side of the monitor (there’s a snapped/clipped 12V wire I need to fix). At some point I will try to reverse-engineer as many of the PLDs as possible and submit them to the PLD archive over at jammarcade.net.

Fix

Replace GAL22V10 at Dr. Math U138 (ROMADLDA).
Replace GAL22V10 at Dr. Math U130 (RAMADLDA).
Replace GAL22V10 at Dr. Math U70 (DM68K0A).

Philip Bennett