Professional software development, amateur BMW tinkering, old arcade game stuff


Nintendo Mario Bros arcade pcb repair #3

Very strange fault on this board – two misplaced tiles on the title screen – but absolutely no fault anywhere else.



That kind of fault is very strange as usually a fault with video hardware like this would affect all sprites, or at least groups of related sprites.  Indeed when the CPU board was matched with a known working video board the fault remained – so it was on the CPU board rather than in graphics generation.  As the program EPROMs verified correct the main suspect would be the Z80-DMA chip which copies data from memory to the video board – however I found the fault with some luck by swapping the two main CPU RAM chips.  The fault went away with different RAM, and came back with the original RAM replaced.


New RAM installed to properly fix the problem but still a very strange fault – usually when RAM fails an entire an address row or the data bus is taken out – which usually means the CPU program will fail quickly.  This RAM must just have a handful of bad bits that happened to correspond to work area for the title screen.



Taito Sky Shark arcade pcb repair

No video output from this Sky Shark, aka Flying Shark but the main CPU and RAM did show activity via logic probe.  There are no schematics available so I traced out where the RGB lines on the jamma edge connector go.


And they go to the resistor network at the right side of the board, so the digital palette is converted to analog video signal as expected.  The resistor network is fed by the two LS273 latches in the N row and I presume those two latches are clocked by the pixel clock to output each pixel as supplied by the palette RAM.  No clock was present though – so I traced the clock signal back to the LS08 on the M row.  This seems to be how the game handles the horizontal and vertical blanking – so the pixel output is turned off when needed.

The MAME source indicates the CPU can also turn the screen on & off – and it’s this signal that also goes to the LS08 – by (temporarily) bridging the input pins I forced the screen on – and got a screen full of garbage!


So that’s actually a good thing – confirmation the pixel clock is working, palette RAM works, tilemap RAM works, etc, and likely confirmation the CPU program was not running long enough to turn on the screen.

Piggybacking the main CPU RAM with known good RAM had no effect, and the program ROM’s seemed fine, so I used the MAME debugger to trace the program a bit – and it seems the program is very delicate – any RAM or DSP error leads to a crash rather than any on-screen indication (so although the game reports ROM:  GOOD  RAM:  GOOD on successful bootup – it will generally never report something bad – just crash!).


Now after all that, I examined the board in more detail and found 3 gouged traces on the underside – when repaired the game worked 100%.  So I went down the wrong path for a while but fixed in the end.






Nintendo Mario Bros arcade pcb repair #2

Two pcbs with a fair amount of corrosion on the chips, probably stored in a humid warehouse for decades.


Board 1

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!



Board 2

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.