It's been a while since I have done a write up, mainly because they can take as long as the actual repair to put together, plus most aren't that interesting as write-ups, but this one was bit fruity - a Super Hang On PCB set from a cabinet restoration that another AAer is doing.
I got some detailed photos of the boards condition beforehand as Sega boards can be riddled with track rot and unfixable, but this one was pretty mint.
The usual suspect on Sega PCBs from this era is the big black Hitachi module in the master CPU socket, often a FD1094A, or a FD1089B in this case. These are the infamous suicide modules, a form of 1980s copy protection, to stop operators from upgrading to a newer game by burning a different set of EPROMs. While you could copy the ROMs from one game to another you'd need a decryption module with the right key in it to actually get the game to boot. Putting in a standard 68000 CPU was no better than putting in an FD1094 bock with the wrong encryption key, unless you had a way to decrypt the code.
So the only way to get the latest game was to buy the official board from Sega as even if you could get hold of a spare module you'd still need the right encryption key and a way to load it into the module. Eventually the keys were reverse engineered (in the mid 1990s), but only very recently (2018) have the modules themselves been reverse engineered, to the extent that a dead FD1089 can be revived and reprogrammed with a new key. Check out the blog post by a guy called Arcade Hacker if you want to know what's inside these blocks, its hardcore stuff.
Anyway, along with lots of photos of the boards there was also a spare 68000 CPU and a set of 4 EPROMs...
...which is a de-suicide kit for the board, EPROMs containing the unencrypted game code, and a normal 68000 CPU to replace the FD1089.
As it looked like these had never been fitted the owner swapped them into the board along with the 68000, to check if that was the only problem, but the board was still dead.
So it arrived on the bench for some TLC.
The 1089B module has a lid that's easily unclipped, unlike the FD1094 which has a metal plate glued on, but both are much the same inside, space for 3 batteries but only ever one used, and wires disappearing into the block. In this one the date code on the battery was January 1987...
… so no surprise it was dead, with volts so low that this would have died a long time ago.
A few things to note on first inspection, firstly a lone 27c256 EPROM in at location at IC56.
This doesn't belong on the board, if it did there would need to be another ROM in the empty socket to the right, at IC74. These 6 sockets are the program code for the main CPU and each of these ROMs contributes 8 bits of data towards the 16 bits on data bus, so only having one makes no sense. It does contain code that is part of the Super Hang-On ROM set, but I'm pretty sure it for another board configuration. In fact the MAME ROM set "SHANGON" is a bit of a tangle, with all sorts of files that don't make sense for this board. It wouldn't be the cause of a dead board as the program code doesn't address the space where those ROM sockets would sit in the address space.
Some good news is the board doesn't have the hugely problematic TMM2063 64KB SRAMs anywhere, instead using ASAHI brand, which gave more hope this wasn't dead due to galloping RAM failures. There were also only 3 Fujitsu TTLs on the board, again very good news from a future reliability perspective. With low numbers of Fujitsu TTLs I opt to just replace them all, dead or not.
The only other oddity was a single TTL IC in a socket at IC105, socketed TTL which is usually a sign that someone has been trying to fix the board before, but this was totally original, and a handy way to disable the watchdog circuit without resorting to desoldering one end of the zero ohm resistor R5.
With my power and video harness hooked up I flicked the switch and yes it was pretty dead, but not totally, the board would give very brief flashes of white lines on the screen on a regular basis.
(Yep the toyroom is a mess, it's always a mess)
This is the sign of a Sega board trying to reboot itself due to the watchdog circuit firing. The watchdog is a timer circuit that the game code has to constantly reset every few milliseconds or it will pull the master reset line to logic low which will reset all the CPUs on board. It's there to allow the board to recover from a game crash without needing a human to power-cycle the entire cabinet, otherwise the game sit there in a wedged state unable to slurp up players coins. For a random crash this works well, but a faulty board it will sit there constantly resetting for ever.
First step was to go over the board with the oscilloscope looking at the usual suspects, but aside from a dead 74LS109 in the road section I couldn't find anything by cruising around. There are two 74LS109 on the board and neither should break the boards ability to boot, you'd get weird faults like a static road if IC102 is bad, or a road that is totally missing if IC7 bad, but the main CPU doesn't care about either of those so that wasn't the main fault I was chasing.
Super Hang-On uses the same CPU board as Outrun, just paired with a simpler video board, as the game doesn't have as much sprite or object data. For some reason I ended up with 6 Outrun board sets last year in quick succession so I got to know the CPU board quite well. One major difference between Outrun and Super Hang-On is that Outrun actually draws two roads, as there are two carriageways on screen that merge into one 6 lane highway, and then diverge at the end of the level where you get to choose the left or right track. Super Hang-On only draws one road, so the left half of the road logic on the board is unused, which is why there only one road ROM and an empty socket where the left road ROM would be on an Outrun board.
By swapping the Super Hang-On CPU roms to the Outrun test ROMs, and plugging it into my own Outrun video board I could quickly test the CPU board, both CPU buses, all the bus transceivers and line drivers that the CPU board uses to talk to the graphics board, basically a tonne of stuff in one go. The board passed with flying colours, mostly.
The ROAD LSB and MSB errors (least and most significant bit) were just from the fault I'd already found in the road section due to the dead 74LS109, but that wasn't the fault that had downed the board. Usually you find these boards will loads of RAM errors in the Main, Sub or Palette sections, but this was all clear.
This suggested that the fault was on the video board, but converting an Outrun CPU PCB to Super Hang-On and pairing it with the Super Hang On video board got me a working Super Hang-On board set.
So I had just proved that the CPU board was OK and that the video board was also OK but putting them back together gave me a dead board set again. Weird!
I'd already eye-balled the pins in the board interconnects as squashed or missing pins can happen, but all the connector pins were there and with no signs of corrosion.
It's possible but unlikely that the Outrun code somehow doesn't touch all the areas that Super Hang-On does, especially as Outrun is much more complex, so in theory gives the hardware more of a workout. Time to wheel out the big gun, the Fluke 9010A and a 68000 pod from 1982.
This is pure overkill for a lot of board repair, but for a PCB that won't boot and gives no clues as to why it is the weapon of choice.
On any PCB the CPU can only execute the instructions that it can fetch from the ROMs via the PCB tracks, sockets and control logic ICs. These instructions are all very low level operations like fetching a byte, or a word in the case of the 68000 and doing something with it, such as moving things in and out or registers, reading and writing from RAM, or doing mathematical operations on numbers that the instructions have pulled in. If these instructions make sense and keep up with the housekeeping, like maintaining the stack, then the CPU will just keep working away. If the instructions don't make sense then the CPU will just crash, and end up in a hung state unable to do anything, often with the address and data lines doing odd things. On a faulty board you probably only have a few milliseconds before the crash, and then a few milliseconds of quiet time before the watchdog restarts it all, leaving you with a twitching system thrashing around in a mess, very hard to work on when using a scope or logic probe.
The CPU has no choice in what it will or won't do, it just ploughs blindly on, but the Fluke 9010a lets you become the CPU and have that free will. With that control you can perform all sorts of operations with no way to lock yourself out, and run a load of built in tests, if you know the memory map for the board. You can also ignore all the things which would stop a normal CPU in its tracks, like the the watchdog pulling the /RESET line low, or the other CPUs on the board asserting the /HALT line if they see a bus error. The main benefit is that you can test exactly what a real CPU would be able to do from the actual socket it would be sat in, proving everything from the socket itself all the way through the glue logic to the RAM and ROM blocks out in the memory space. On complex boards there is a tonne of logic that controls the addressing logic, read/write modes, and output enables, where any fault can easily brick a board and being able to validate all that quickly is really useful.
So I pulled out the 9010A and the 68000 CPU interface pod and ran straight into the first problem, the 315-5195 Memory Mapper IC.
The problem is that these boards are software configurable, and first thing the CPU does when the board boots is to run a short piece of code in ROM that write values into certain registers within the 315-5195 to configure the board. That sets up the board so the later stages of the program can access all the blocks of RAM and ROM that aren't connected before the mapper is programmed. So if a board is so bricked that it can't run any code then it can't configure itself to the point where you could use a Fluke 9010 to test the RAM and ROM areas that a CPU on a fully working board would see.
While this looks like another bear-trap for bootleggers I suspect it was an attempt by Sega to future-proof the platform, potentially make software development easier, but mainly to make the PCBs far cheaper to manufacture.
Basically it is an implementation of virtual memory, allowing the CPU to think it has it's full memory space available, but in fact the mapper IC is intercepting what the CPU asks for and silently diverts it off to the right hardware, leaving the CPU unaware that most of the memory space it thinks it has doesn't actually exist in hardware.
The 68000 CPU has a whopping 16MB of address space defined by the 24 pins of the address bus. Games like Outrun and SHO don't need anywhere near that amount of space, but I suspect Sega had plans to use the platform for many more titles than the four that were ever actually released for it, with future games using up more space.
On System 16B hardware the logical layout is apparently divided into multiple regions, and it is probably the same for the Outrun family of boards.
Region 0 - Program ROM
Region 1 and 2 can be used for additional program ROMs or other hardware.
Region 3 - 68000 work RAM
Region 4 - Text/tile RAM
Region 5 - Object RAM
Region 6 - Color RAM
Region 7 - I/O area
So, the memory mapper IC is hooked up to the full 24 address lines and the CPU control signals, and is used to convert it into 16 bit bus and a load of chip select lines which head off to the various slabs of RAM and ROM on the board. This seems like a lot of hard work but as a 24 bit bus needs 24 address lines, and 3 of whatever octal logic is used on the bus (e.g. transceivers, line drivers, latches) a 1/3 reduction in lines and chip count is a significant saving on PCB layout and parts costs. PCB production at the time was incredibly expensive so it would have been insane to physically layout 16MB of address space, especially for a game that used less than 2MB all up.
Production costs, and additional PCB layers were certainly avoided but it presented me with a problem. I had no way to know if the board was able to configure the memory mapper before crashing and the watchdog jumping in, which also resets the mapper IC. In retrospect, knowing the actual fault I'd say the board probably was able to do this, and I probably could have used the Fluke to run the board as if it was a normal CPU and let it crash. I could probably have manually taken over leaving the mapper registers intact, but I would have had to have disabled the watchdog circuit on the board. At the time I had set the Fluke up to ignore the watchdog, but the mapper IC would have been reset instantly, losing the board config.
I opted to go down the rabbit hole, to dig into how the mapper sets up the board. MAME would look like a logical place to start, but I'm not sure it bothers with emulating the mapper as it solves a hardware problem which doesn't exist when the whole thing is emulated in software, especially when you have a million times more RAM than a 68000 dream of in 1987, its simpler to give it 16MB of RAM and not worry about the big gaps.
Hats off to Charles Macdonald who wrote the System 16 hardware notes, cmonkey and the late Zabanitu from Italy who did document their efforts on UKVAC to understand the mapper, and what it was actually doing, their notes on UKVAC were really useful in getting my head round it.
Ultimately you can work out the bytes being written to the mapper IC (if you know where the mapper physically sits in the address space) by disassembling the 68K code and looking for the section which pumps data into the registers at the mapper location, before then branching off somewhere else, to start the actual game code.
In the case of SHO the mapper initialisation code is this, which is a for/next loop counting down from 15 to 0, pumping the byte pairs held in ROM at 00153e and upwards into increasing register addresses starting at $ffff20, which is where the mapper sits on the SHO/Outrun CPU board.
L_001000: moveq #$0, D0 ; clear D0
moveq #$f, D1 ; initialise the loop counter
lea L_00153e.l, A0 ; address of data to send to mapper registers into A0
lea $ff20.w, A1 ; address of the memory mapper configuration registers
.1: move.b (A0)+, D0 ; get a byte of data and post-increment data pointer
move.w D0, (A1)+ ; move a word of data to mapper registers
dbra D1, .1 ; loop
L_00153e: dc.b 2,0 ; map $10000 to $3ffff to main cpu EPROMs
dc.b $0d,$10 ; map $100000 to $11ffff to tile/text ram
dc.b 0,$12 ; map $120000 to $12ffff to palette ram
dc.b 0,$13 ; map $130000 to $13ffff to sprite ram
dc.b 0,$14 ; map $140000 to $14ffff to unknown??
dc.b $0f,$20 ; map sub-cpu program to $200000 to $23ffff and maps work ram
dc.b 0,0 ; does nothing
dc.b 0,0 ; does nothing
Machine code never was my thing, but working through this did give the clue I needed to break the mystery of why two working boards couldn't work together. I didn't need to set up the full memory mapper config, just to set it up enough to get access to the main system RAM. The first two passes through the loop above write h0002 to $FFFF20 and 0000 to $FFF22, which set up the board to have 128KB of ROM (at boot it only has 64KB) and it sets the base address of Region 0 to 00000. This seems to unlock the higher addressing where the RAM sits too.
After poking those values in at those locations I could then read the full 128KB of ROM space and the RAM partially appeared in the memory map at 60000-63FFE and the NVRAM at addresses 64000-67FFE. I say partially because while the Fluke has built in test scripts for exercising RAM these instantly failed when I tried to run them on the RAM space, but writing a bit pattern to the first address location and reading it back showed what the fault actually was. When the SHO CPU board and the SHO video board were connected I only had an 8 working bits on the data bus, not the full 16.
The fluke is great but the strobe on the vacuum fluorescent display makes it hard to photograph...
Writing 5555 at memory location 0x60000 should allow me to read it back out again.
But reading the data back from 0x60000 got me 5500 instead of 5555.
With the CPU board powered up solo, with no video board I had a fully working 16 bit bus, and the RAMs on the top board passed their tests, but when the boards were connected again the lower byte of the pair was unusable. Pointing the scope at the RAM chips themselves showed the /WR (write enable) signal on pin 27 of IC115 and IC114 was held high, i.e. never write enabled. I could read them fine, but I couldn't ever get them to store any data, so the CPU would have had the same issue. When reading back the lower byte would always be zeros leading to the crash.
The stuck write enable line for the lower RAMs is called LWR on the schematic, while the equivalent upper byte write signal UWR was working fine.
With the Fluke set up to continually write to address 60000 I could track the issue to the edge connector (which is referenced by the signals going to page 7/7).
The UWR on pin 13 was active...
...but LWR on pin 15 is stuck high...
... and when the boards were powered up separately the LWR was active again. Separating the boards while powered up is a great way to blow all the line driver ICs so I didn't even attempt that test.
This initially looked like a fault on the video board jamming the LWR signal high, but is actually turned out to be a line driver problem on the CPU board. All ICs have a drive capacity, in terms of how many downstream gates their output pin is able to pull low. The default logic level is high, and a drive transistor in the output stage within an IC will conduct and pull that line down to ground via current limiting resistors to prevent a dead short and magic smoke. In this case the 74LS244 at IC123 on the CPU board had a weak output drive on pin 12 and didn't have the ability to sink the enough current to drive the LWR line when it had all the gates and pull-ups on the video board connected up.
Piggy backing a new IC on top of the old one gave enough drive to the line, enabled the lower /WE line and the board could finally boot!
As to why this CPU board was happy with the Outrun PCB but not its own video board, it would come down to how many gates are hanging off the LWR line. I suspect that because Outrun has a much more complicated video board it has a buffer on this line to take over some of the load, so as far as the 74LS244 chip was concern Outrun is an easier board to drive on pin 12 than the SHO video board.
So it looks like the video output is clean, and the sprite system appears to be working perfectly, but I have no road, corruption in the background, and a lot of pink. Oh and no sound at all.
The 7th rule of board repair is to take any help the board offers, so if it has a test mode you should use it. The 8th rule is don't trust the 7th too much, as the built-in tests can be misleading and are usually far too quick to be doing any in-depth testing, but to get to this test menu I needed some inputs to mimic the accelerator pedal and some switches.
The I/O on Sega boards of this era don't share the same power supply as the rest of the PCB, so you'll find them powered down unless you pick up power from the board and feed it into the right pins on the edge connector. Word is they did this to avoid the problem of people getting free credits using a piezo clicker to shock the board as the input section is only optically connected to the actual game system. With the power plumbed in, three wires off to a potentiometer robbed from a TV chassis and two wires for Test and Start...
... I could get into the test menu. By the way, the pinout of SHO is very different to Outrun, connecting an Outrun harness to SHO will cause no end of damage.
The CRT check ruled out any issues with the video output stage as all three colour channels were there and white is white, not impacted by the pink...
and the RAM test...
...shows all passes except these 4 road SRAMs.
Not surprising really as the the dead 74LS109 I found earlier at IC7 will break the boards ability to see those. One trip to Jaycar later for a pair of 109s...
... and a piggy backed one lit up the disconnected outputs.
Piggy backing doesn't always work, but Fujitsu TTLs often lose their internal connection to their output legs, so it is as if the on-board chip isn't there. As long as it isn't shorted on its other pins a piggy backed chip will take over the work with no issue.
At nearly $5 each, Jaycar is pretty expensive per chip, as an online fake will set you back about 20cents, but you can't beat instant gratification and I still find it impressive that I can walk down the road and buy a spare part for a 1986 arcade machine.
Now it looked a lot better, the pink is gone...
the scene has the road now drawn, just very glitchy and with aspects of the road scattered around. Hard to catch on camera but you can see some pixels scattered either side of the central rider..
This quickly got worse, probably because the new 74ls109 was driving a section of the circuit that had been disabled up to this point.
Repeating the ROM and RAM test now gave the results in bright green, with a white smear down the screen, and showed only 1 RAM as bad.
But it kept changing its mind as to whether that was 21 or 39.
The question now was whether 21 or 39 are actually bad, or whether it is something in the tangle of 244s that make up the road logic. During attract mode, or when showing the test menu the road circuit should be quiet, as no road is needed, this is controlled by two signals /ROAD, which is buffered into /REN (Road Enable), which drives the /G pin on about a dozen LS245s and a signal called /SRD which controls the direction of the multiplexers, and feeds an LS138 which controls the /WE pin determining whether the 4x SRAM is in read or write mode. Between these two they control whether the road cicruit is active, and whether the RAMs are being loaded with the stage data, or whether they are in output mode streaming the road data outwards. I suspect /SRD means speed road as it seems to determine how fast the road is rolling.
When the road is deselected the whole system should be quiet, except D3 (pin 15) on IC21 there was a very rapid uniform signal...
and on IC39 a slower signal that looked much more normal for a data output pin.
As these two chips are supposed to be interleaved I'd suspect the faulty one is the noisy one i.e. IC21, and IC39 is resisting it. If the two signals clash while the board is trying to read from either then it would confuse the RAM test but it could be both or neither if that signal is coming from somewhere else, the only way to find out is to remove and test it off board.
With the chip off the board I fired it up and went into the diagnostics again. The RAM/ROM test gave me this..
IC39 shows as bad, and IC21 shows good, despite IC21 being an empty location now, so the testing code has the RAM location labels reversed, which is not that uncommon as I doubt the coders ever saw what the final PCB looked like.
The colours look much better, but unfortunately dull green was what Sega chose for the menu system, the sky blue is only temporary.
With new 6116 SRAM fitted at IC21 it looks a lot better...
...but there is still some corruption in the road. It looks minor in a still photo but this was a flickering mess in real life.
Suspecting there may be more RAM faults in the bank of four RAMs I hooked the Fluke up again and ran both the short and long tests on the road ram which is mapped between 0x68000-0x68FFF in the address space. Despite the fact the road is run by the sub CPU the memory space is shared so it is testable through the main CPU socket, and the road RAM passed even the very intensive long test.
While I had the Fluke connected I ran through all the address spaces I could find, had some issues with the Sprite RAM but I suspect that was down to the sprite custom IC's taking control and doing their thing while I was trying to run my tests. Read writes kept flipping between pass and fail, but as the sprites are perfect there isn't a real fault here. I suspect there are some registers I could poke to disable the sprite custom IC access, but if there are I don't know them.
Cool effect when long testing the text SRAM memory bank...
All the RAM tests passed but the odd tearing in the road and the column over the splash screen was starting to become a permanent fixture.
This looks suspiciously like the base road, when it inst stretched for perspective purposes, without the horizon applied and when the kerb isn't chopped up into the stripes. Especially as after the attract mode has shown a desert stage the column changes to the same colour as the sandy road.
This took a while as the fault would come and go, but it never happened when the board has just been power cycled. The first splash screen was always perfect, and the issue would appear after the first attract mode cycle. To make it more annoying the fault would sometimes just vanish as soon as I touched a certain pin on an IC. I've met faults before where the additional load of the scope probe annoys the issue but this was rather too clean, but was ultimately pure coincidence. As the RAM tests fine even when the fault is present the issue has to be on the read-out section of the road system, that takes data out of the ROMs and passes it off to the video system for inclusion in the final image.
For a while I was stepping around the road circuit waiting for the attract mode to cycle through and hoping that the fault would symptoms would be strong when it did, but I was chasing ghosts getting nowhere.
The fault then suddenly vanished, for days, with both cold and warm restarts. I'd leave the board running for hours while I was working and I'd catch the odd flicker out of the corner of my eye but nothing I could catch with the scope.
Thankfully the problem finally came back in a major way after 3 days, with the column of crap starting to appear as a few sparkly lines before gradually getting worse to the extent the stripe was nearly filled in fully.
With the fault now present all the time the issue was easier to find with the scope...
...output pin 4 on the 74LS257 multiplexer at IC46 had turned to crap.
Intermittent faults like this are pain, as when the image was fine this chip was behaving normally, and until it failed again there was no way to track it down. Shot-gunning a board this size isn't viable, plus desoldering on Sega boards is a bit of a fight sometimes, the power and ground planes are massive heat-sinks.
With all the graphics bugs finally squashed the road finally looks mint!
The last fault was the complete lack of sound.
First port of call was the Z80 work RAM, the TMM2015 at IC87...
...whose outputs looked pretty horrific on the scope.
Off it came...
..and surprisingly enough it passed an off-board test, and when fitted back to the board in a socket the sound was fine.
Suspicious that the heat treatment from desoldering had revived the IC so it was retired and one from my stock went in.
The last of the piggy-backed chips got replaced, the remaining two Fujitsu TTLs (the other 74ls109 and a 74S04 at IC85) were replaced with non-Fujitsu chips, and it spent a few days on soak test to ensure nothing else was about to die.
All up the guilty culprits were these.
With them now retired to the bin I'm calling the board fix complete!