Two pcbs with a fair amount of corrosion on the chips, probably stored in a humid warehouse for decades.
Showed quickly scrolling lines, so clearly video sync wasn’t correct. Sync mainly comes from two LS123 chips – a logic probe showed one of them was getting an input but had a stuck output. A corroded Fujitsu chip. Piggybacked a replacement on top and video worked – screen of garbage characters!
So random garbage on each boot generally means the CPU isn’t running (consistent garbage usually means it is). Logic probe showed the main Z80 cpu had pulsing address lines and reset was working ok, but all data lines were stuck low. The program eproms, which tested good off board, also had pulsing address lines and pulsing output enable lines. So that means something is telling the eprom to output data – but if it is then why are all the data lines low? Something on the data bus had to be grounding all the lines and stopping activity. There’s not much on the data bus – the CPU itself, the Z80-DMA chip, the RAM, the ROM and a LS245 latch that isolates the video board data bus.
The LS245 was removed and tested good, the Z80-DMA was removed and suddenly the data bus was active. With a replacement fitted all data and address lines were now pulsing – but still random garbage characters on screen. So the Z80-DMA had failed in a way that pulled all lines low.
The LS245 was next the clue – this latch allows reading and writing from the video board – but the direction pin appeared to be stuck low. The schematics show this line is buffered by a driver chip – in this case a Fujitsu at 6A which had failed. When replaced the game worked albeit without sound!
No garbage display on this one – instead some consistent moving long blue lines across the screen. So that’s a hint the CPU is probably doing something and the initial problems are on the video board.
Because of the ‘stretched’ look to the lines I examined the horizontal and vertical timing part of the circuit first. In the schematics things like 4H refer to every 4 horizontal pixel, and V to the vertical line. In the picture you can see some references to the low 3 bits of V and H. 3 bits gives you a value 0-7 – and this game has 8 pixel wide tiles, so you can see those parts are dealing with the pixels inside a tile.
The video board came together bit by bit – the lines became solid tiles, then the inside of tiles, then sprites. Faults were all Fujitsu chips, or just badly corroded chips.
At this point it was pretty clear the CPU board was fine and sound worked on it so the working video board 1 was combined with CPU board 2 to make a fully working game. 1 worker from 2 corroded trashed boards is a good result.
But I’ll get back to fixing CPU board 1 and video board 2 at a later date – the video board only has 1 fault left – sprites are sometimes duplicated vertically – I suspect some kind of vertical comparison fault somewhere, but not found it yet. The lack of sound on the CPU board I suspect the audio CPU itself has failed.