Frogger Repair Logs
Symptom: Too many frogs on screen.
I have acquired this board from a seller who wasn't saying absolutely anything about it. Sure it must have been broken somehow, yet the price was very nice; expecially considering that it's definitely an original, manufactured by Sega under license from Konami. The board required me to wire up an adapter, which I did quickly enough. While doing so, I noticed an empty socket in the bank of EPROMs for the CPU code and a torn off 8 pin IC at position U1 on the sound board. I was already fearing the worse, therefore I went looking for schematics before even turning on the board. The schematics show U1 is actually an µA741 op-amp which preamplifies the audio before feeding it through the volume pot to the power amplifier. Though, even with U1 missing (which requires -5V to be present) the 5.1k feedback resistor should allow the sound through. About the EPROM bank for the CPU code, MAME came to the rescue by highlighting the need for only three chips instead of four. Therefore the empty socket is actually meant to be empty, and maybe the torn off U1 is a factory patch. Very reliving. Anyway, once finished wiring up power, ground, video and speaker I finally powered up the board and got greeted by a swarm of frogs trying to march their way to take on the world!
As you can see from the picture, the sprite of the frog trying to cross the street was repeated over and over again on the entire column (remember that the screen is vertical). Cars, crocodiles, logs and all the rest however looked fine. The reason why they looked fine is very simple: all those are not sprites! As MAME shows when pressing F4 and navigating to the layer display, most of the elements on screen are actually part of the background. The Galaxian hardware on which this game has been based most likely has the ability to vertically scroll each background column independently, which is a very interesting feature for the time. The only sprite used on screen is actually our frog hero.
To solve this riddle I needed a deep understanding of how the sprite rendering logic works. Thankfully this is very carefully explained in the comments of MAME's video driver for Galaxian. As it can be seen on the schematic, the sprite RAM is 256 bytes only, and is read each and every line in order to render a line worth of sprite data. Through a lookup in ROM the data is then fed directly into the line buffer (256 pixels, 6 bits per pixel), where some logic mixes it with and prioritises it against the background data. The line buffer is then rendered on screen and erased at the same time, ready for the next raster line. A quite convoluted mechanism that runs at about 6MHz and wouldn't have been easy to uderstand if it wasn't for MAME's documentation.
The entire logic is highly optimized to save costs, to the point that the comparison of the vertical sprite coordinates against the raster counter isn't easy to spot. The scope showed, as expected, sprite data being drawn every line endlessly. Tracing that back brought to IC78, a quad input NAND gate 74LS20. Its output was correct but extremely low in amplitude, which caused IC97 (74LS157) to never register a high logic level on pin 5.
The attentive ones among you surely noticed that the part is marked IC73 instead of IC78. That's a mistake on the schematic, and it unfortunately isn't the only one I've found...
Replacing the 74LS20 with a new one has elegantly solved the issue. And now that the graphics were fine, completing the adapter allowed me to finally play the game. Luckily the sound was absolutely fine, which proves that U1 has been intentionally removed by the factory. Great, because this means I won't be needing -5V for this board. :) All inputs are also fine, as proved by playing a game in cocktail mode. That seems to be all, then. It has been a quite interesting evening; now let's save some frogs! :P