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
3 Responses to “Breywood repair log”
Sorry, the comment form is closed at this time.
it might be caused by the ROM chip latency speed. it maybe not original one (the type). i found such trouble in one game, but it’s not ROM, but RAM.
definately possible but the EPROM was the same as all the others. In the end I just pout it down to age but it could be a number of things.
It also might just be some oxidisation on some legs. My reader may not have had an issue with it but the socket on the board may not have liked it.
Who knows. Ill try erasing this EPROM and try programming it again.
hallo, would it be possible to have the exact EPROMs labels and location?
It would be helpfull to improve MAME rom names and documentation.
TIA