This game took me ages to fix and the fault ended up being something strange.

Anyway, the game booted to a frozen screen of garbage.
Checked the voltages, all were fine.
Checked the clock, reset and halt lines on both of the 6809 CPU’s, all were fine.
Pulled the ROM’s and checked them, all were OK.

I probed the work RAM and it looked OK but pulled it anyway just in case. No problem with that so back in it went.
Other than the fact it didn’t work, I couldn’t find anything wrong with operation. All the TTL seemed to be functioning as it should. The only thing that bothered me was the I8751 MCU in the bottom left hand corner. There is no dump of its contents available and the security bit has been set.

I did find on my probing travels that when I probed the DIRECTION pin (pin 1) of a group of 74LS245’s then the intro and music would play through as it should. Although the colours were messed up I could coin it up but the game would not start. This little find sent me on a wild goose chase for a day.

As I couldn’t find anything wrong I decided to draw up some schematics of the CPU’s. Everything seemed to be going where it should. I left it alone for a day after this because I was loosing patience with it.

So, today I started looking into the code with the view of writing some test code. The hardware is actually very easy to work with and had no problems doing some tests.
It seems the sub CPU actually does most of the work at startup. Here is what it performs:
1. Shared RAM clearing
2. VRAM clearing
3. BG data clearing
4. Sprite RAM clearing
5. Copies the Hi Score data into RAM
6. Sends the region information to the i8751 MCU
7. Stores data 0x01 into address $6 in RAM
8. Sends interrupt to main CPU

After step 8, the sub CPU continually monitors address $6 in a loop. When the main CPU sets this to 0x00 then the sub CPU will continue.
On to the main CPU then. The only thing that this does before restarting the sub CPU is set the palette RAM. Once this is done the game should start up.

I edited the sub CPU code so that it wrote 0x5050 to all the VRAM. This should will the screen with the letter “P”.
I also made the background into something to prove the BG data could be written.

In MAME I got this

On the real hardware I got this

Ignoring the colour difference I was happy with that result.

Next step was to bypass the need for the sub CPU to monitor address $6. Doing that should allow me to run the intro sequence without the main CPU fitted.
This would prove that the sub CPU is all working fine and the reason the game didn’t run was down to the main CPU playing up.

I wrote the new ROM and tested.

The intro now ran. The colours were messed up but that’s to be expected as the main CPU sets up the palette RAM and that’s been bypassed.
As the main CPU doesn’t really do a lot before the game is meant to run I came to the conclusion that it wasn’t writing address $6 with 0x00.

To cut a long story short, out of desperation I burned another program ROM for the main CPU.

All working. Despite the fact I could read the original ROM out, the hardware wasn’t happy with it.
Crazy fault nearly drove me mental

PC18 from Jamma+ forum dropped me 2 UMK3 boards around a while back in the hope we could get one of them working.
Both had sound issues.

The first board failed its self test flagging the ROM U2 as bad, when one fails none of the others are checked and the game boots.
The second board just had a feedback sound playing all the time and no game sounds were there even though all self tests pass.

I check the ROM’s out first and they were all fine
Checked the voltages on both boards and they were all fine.

Probing around at the sound ROM’s on the first board I could see that none of the chip select lines were ever being activated. I traced this back to the protected GAL22V10 chip, fortunately I had another GAL from the second board but got the very same fault. Refusing to believe that both chips were bad and in the same way I started looking elsewhere.
The ADSP-2105 chip is the sound processor on this board and could see that all the address and data lines were completely dead.
At this point I wrote the board off and focused my attention on getting the second board running.

I know that if the -5v is missing then the you will get the very noise that I was getting with this one. Only trouble is all the voltage levels were fine to all points I could trace.
These boards have A LOT of small surface mounted capacitors and resistors which makes tracing things out a huge task and as there are no schematics available I was getting a bit frustrated.

Out of frustration I decided to probe the sound processor on the board and found that on start up all the address and data lines are in fact tri-stated just like the first one so it got me thinking that the other board was maybe OK.

Looking around on the underside of the board I found this

This actual mark was tiny until I starting prodding at it and missed it on my initial inspection but there was no continuity between the 2 ends of it so it was cut all the way through. Even better news was it did go to that GAL chip so probably would affect the sound circuit.

I patched the trace with some kynar

Fired the game up and was greeted with a 1 tone sound which actually means the sound hardware is OK, previously I had 2 tones which means there is a fault.

Due to the reason mentioned above I’m not going to try fixing the other board up but I have confirmed that all the processors and stuff are working so there are spares should he need them.