Galaga (bootleg) was working but now won't boot

[RGP]

Yeah, couldn't have probably picked a worse board to look at than this with multi cpu - oh hang on a minute, I did a bit back - Battlezone lol - Equites has it at the moment though.

Z80 jumps to 0x0000 so that'd be easy to follow to the first EEPROM then (in theory).

I've reseated the daughter card already.

I'll lift the EEPROMs out tomorrow and verify them, if there's a duff one i'll re-burn it as that'll at least give us a healthy starting point.

I understand how address decoding works but don't understand the implementation at the IC level yet.

I really need to find a book on understanding microprocessor at the hardware level.

 

[Judder]

It's this version so that'd be a green variant

Ok, hmmm, bit embarrassing - on looking at this picture, it appears there might actually be 4 Z80's in total. So the primary would be the one near the front of the above pic and the 3 others which are tied together on the LS259 are in the middle of the board.

Ok, I need to go re-probe the board a bit

Yep - as the guys say definitely a bootleg Galag with the 4th extra CPU

Interestingly there is a custom switch wired up in the bottom top left corner of the top board, which seems to be connected to the daughter board.

Not sure what that is for but it's not standard (*is anything on these boards) as per the ones I have.

I recently repaired some Williams sound boards (repaired = swap out dead chips for good chips ) and out of 7 two had dead CPUs - so maybe one thing to test is to put each of the 4 x Z80s into a known working board one by one.

Aussie Arcade uses a Ms. Pacman

"Using my little Ms Pacman board I tested the Z80's and rams. 2 Z80s were bad but the rams were all ok even the 7489's. 3 roms were bad @ K4, J4 and E5."

 

[RGP]

You'll laugh, the switch is the rapid fire enable/disable siwtch on this board.

I'll first test the EEPROMs - no harm in doing that process anyway then i'll find a suitable Z80 board - I have a bootleg Pac-Man which has most of the RAMs and the CPU socketed on it and is known working so I can switch the CPU's in there to test them all. I was just running the logic probe around the chips directly connected to the primary CPU (now we've established it) and could see mostly nothing going on.

I wish I had a multi state analyser - I could see what's going on on a lot of pins simultaneously.

I know everyone swears by the Fluke stuff but its getting hard to get hold of now and then the pods.

I don't want to stray off topic but I was wondering if there's a way to make a more modern version of some of that test gear using some way to interface to a PC. Someone effectively built a computer to analyse a computer so it can't be that difficult.

 

[RGP]

Update:

Have tested all EEPROMs and they all check out fine and are recognised properly. Some recognise as both Galag and Galaga (Rev B) some just as Galag.

I have also tested the CPU's in my Puck-Man bootleg and the CPU's all work.

So, it's not the ROMs and not the CPUs.

I'm kind of stabbing in the dark here but I guess the next thing to check is the address bus.

What I found on my probe was that the lines were pulsing (ie, I could see both HI and LO on and the pulse light flickering). My probe is set to TTL and PULSE.

It's a £7 maplin one

 

[babalouk]

Hello,
I'm sorry to dig up such an old post, however I have the exact same problem on a Galaga card identical to the one mentioned above.
Did you have the solution to the problem?
The display is frozen full of zeros with R 002 indicated and the / reset of the 3 secondary D780s remains at 0 while the POR acts normally.
Thank you for understanding...
Jean-Michel from France

 

[babalouk]

OOOps, sorry for the police size.

Jean-Michel

 

[RGP]

Hello,
I'm sorry to dig up such an old post, however I have the exact same problem on a Galaga card identical to the one mentioned above.
Did you have the solution to the problem?
The display is frozen full of zeros with R 002 indicated and the / reset of the 3 secondary D780s remains at 0 while the POR acts normally.
Thank you for understanding...
Jean-Michel from France

I don't come on here very much these days due to a lack of time, I was checking my mail folders and spotted this alert.

If you're frozen full of zero's that likely means initial code is running enough to clear the random junk in memory at first power on - the other CPU's won't come out of reset (pin 26 goes to a 1 (HI)) until the initial code in the primary CPU executes.

Possible causes:

Bad EPROM in CPU 0 circuit

Bad work RAM in CPU 0 circuit that code relies upon.

Bad memory address logic to EPROM or RAM

Bad data bus buffer chip.

Can't remember if the exploded custom is part of CPU 0 or not but if it is that could be faulty.

There is a schematic for this green bootleg out there - I did fix the above board in the end many years later when my skillset matched the problem.

I am still doing some mail-in based repairs if you haven't resolved it, i'm not familiar with how export/import works cross border now though.