This pcb booted up but with corrupt graphics. Helpfully Pacland does a self-test on startup and this one briefly printed 0 0 4 on screen (or arguably 4 0 0 as the self-test is printed upside down – to clarify the 4 is the first digit to appear). This means a RAM error and as I have a working Pacland to compare against it was quite easy to work out what error digit corresponds to what chip.
Piggy-backing a replacement chip on top fixed the corrupt text and the top scrolling layer so for sure RAM was bad. The bottom scrolling layer was now completely absent though and the self-test didn’t report any errors.
As I had a working board I swapped the custom chips and tilemap ROMs between boards just to rule them out and it made no difference. I suspected the fault was in the priority mixing circuit – this is what decides what pixel is ‘on top’ be it text, sprite or a scrolling layer.
The relevant chunk of the schematics is above, essentially the sprites and top scrolling layer are mixed by custom chip 29. The bottom scrolling layer is produced by custom chip 30 and drives the ROM at 4N. A pair of LS298 multiplexer chips then decide what takes priority – the background layer or the sprite/foreground layer. The LS298 selector is driven by an 8 input AND gate (LS30 @ 1N). This is really what determines ‘transparency’ in the sprite/top tilemap layer – if any of the 7 bits are high for a given pixel then it is ‘opaque’ – all low means ‘transparent’ and the lower layer should be shown.
On this board the LS298 chips and the LS30 are all manufactured by Fujitsu, which is known for a terrible failure rate. A logic probe showed the output of the LS30 chip was dead – so the LS298′s in turn were constantly stuck. Replacing the LS30 with one from a Dragonninja parts board fixed the problem.
I got a very clean original Double Dragon 2 pcb, but unfortunately it was completely dead. No video output at all, and a logic probe revealed almost zero activity on the TTL chips. After checking voltage, the first thing to do in this case is to check if the CPU is getting a clock signal – and indeed the clock pins were completely dead.
On both Double Dragon 1 & 2 the main CPU clock comes from a 12MHz crystal on the video board. Probing around here again showed no activity so a suspicion is the crystal itself was dead. Before replacing it though I checked the Double Dragon 1 schematics which showed a capacitor should be present and none was on my board. It seems the tiny capacitor that should be at C43 (C36 in DD1) had been snapped off so cleanly it just looked like an unpopulated pad.
A replacement was taken from a Dragonninja parts boards and amazingly that was the only fault – all sound & graphics were perfect.
Here’s an odd thing, I added a bunch of the mid-eighties Data East games to MAME around 1997-1999 – and just today realised the colors in many of them have been subtly wrong all this time. In fact I suspect this might affect quite a lot of games in MAME. The problem is a long-standing assumption that games with a palette RAM will emit a linear analog RGB signal proportional to the digital value. But on the real hardware – many don’t.
Games such as Karnov, Gondomania, Real Ghostbusters, etc, use 4 bits per color channel – these 4 digital bits then feed into a resistor network to create an analog signal for the RGB monitor, a simple DAC in other words. For these games the resistor network is a 12pin custom Data East part marked RM-C3. The values are 220 ohms (MSB), 470 ohms, 1 kohm, 2.2 kohm (LSB).
So, with those values it’s not actually a linear conversion – the high bit has slightly more weighting than you would expect, the low bits have slightly less. The picture below shows how the colors actually should look when expanded to a 24 bit PC display. Each column has the linear conversion on the left, and the corrected non-linear on the right.
Look, I said it was subtle
The in-game difference is subtle as well, but it’s there on the Gondomania gameplay ground, or the shadowed greens on the title screen. Shackled looks a little more saturated. Oscar a little more detail. Ultimately this is a tiny change, but it does reflect the original hardware a little more which is what MAME is about.
This pcb was in clean shape but sprites were corrupt. It’s not very clear on the picture but it seemed every second column on the screen was missing, so was more likely to be in the sprite processing area than the ROMs (if it were the ROMs the missing lines would move around).
I confirmed the 4 RAM chips on the top right of the board near the graphics chip involved sprites by temporarily shorting some data lines together and watching the corruption change. I was reasonably sure one of these chips was the problem, but a logic probe showed no obvious errors, so I removed them one by one and replaced with RAM from a parts boards.
The second chip from the top was the problem – replacing fixed the error!
Another 4 slot – a previous owner had installed a new battery and replaced the palette RAM. The board now reported a RAM error with the original BIOS, and the diagnostic ROM confirmed it as the upper WRAM chip (see my previous 4 slot repair).
If you don’t have a SMT desolder station then (if you dare) you can remove surface mount chips with a heat-gun and some tinfoil to protect the surrounding areas. The chips are capable of taking quite a lot of heat so the only worry is warping the board rather than damaging a chip. Because there’s very little solder holding the SMT chips on though, they come off quite easily.
With that one RAM chip replaced, everything worked!
This Neo 2 slot was stuck constantly resetting, which means the 68000 CPU is not resetting the watchdog timer, so the board continually tries to reboot itself. A previous owner had clearly changed out some faulty surface mount RAM previously so I spent some time verifying all data and address lines from RAM/ROM to the CPU were correct as some looked like they could be shorted. Turned out fine however. Without much more to go on I tried out the diagnostic ROM which surprised me by booting and showing a VRAM error. In this case both of the 6116 fast vram type chips that often go bad. Both chips desoldered, sockets added and replacements fitted. Now the diagnostic ROM reported no faults, but the board kept on resetting with the original ROM installed.
I dumped the original ROM and found it to be corrupt – no wonder the CPU kept crashing – really I should have tested that first. Some kind of internal addressing fault as in the dump you can see some ASCII text where the reset and stack vectors should be. Unibios was burned to a replacement eprom and everything worked again!
This NeoGeo 2 slot booted to a screen saying Z80 error. That doesn’t necessarily mean the CPU is at fault – it could be the program ROM, the RAM or several intermediate chips that connect the Z80 to the main 68000 CPU that prints the error. In this case though a logic probe seemed to show the Z80 was dead. Desoldered, installed a socket and Z80 pulled from an Arkanoid, and everything worked!
An original Capcom/Mitchell Buster Bros pcb booted to a solid blue-green screen. This is one of the infamous suicide battery pcb’s, where a custom Z80 CPU contains a decryption table in volatile RAM powered by a battery. When the battery dies the decryption table is lost and the program code cannot be run. This pcb was an untouched original with a 29 year old battery, so safe to say the battery was stone dead.
Full info on restoring these dead CPU’s can be found here – http://www.arcadecollecting.com/dead/pre-cps.html
One of the original tricks of this encryption is that program opcodes (instructions) are treated differently from operands (data). This means that even if you understand the decryption and have the key you can’t just burn a new ROM in place as each byte the ROM will have two values depending if the CPU accesses it as data or instruction. The solution is to decrypt the ROM for both data & instruction separately and burn to a new double size ROM with data in top half, instructions in lower half. The CPU pin that controls whether instructions or data is being fetched is then used to select the upper address line on the ROM.
So the desuicide process is fairly simple – use 27c020 and 27c512 eproms to replace the originals, and run a wire to control the top address bit. I’m pleased to say it booted up first time when I tried it.
But.. pretty obvious there was no red color channel. The palette RAM would be the first port of call in this situation, but a logic probe showed neither of the two chips had any stuck bits. I probed down stream of the RAM and there are 3 LS367 chips. One each for red, green and blue. These are the last TTL chips before the signal is converted to the analog output and they control the blanking by cutting out the signal during h-blank and v-blank events. Shorting pins 2 & 3 on the red channel chip fixed the problem and isolated the fault to that TTL chip (which is a strange type of failure but there you go).
This pcb was dirty with signs of corrosion, booted to garbage on-screen and didn’t play. First problem was very obvious – two RAM chips had been removed from the game board and a lot of traces had been pulled up and ruined. Hippodrome isn’t the greatest game, but it deserves better than that so I installed some sockets and repaired the traces via wires on the underside. I have another working Hippodrome for reference so it wasn’t too hard to figure out what was what, but schematics are available anyway. (The RAM pretty much goes directly to the custom tilemap ASIC on the game board).
I swapped the game board onto the working main-board and the game ran and played. At first there was a problem with 1 layer of tilemap graphics – an address line fault that caused tiles to appear in the wrong places, but that was just a problem with my trace repair and easily fixed.
The main board continued to boot to garbage which is usually a sign the CPU program is not running. A logic probe showing the CPU had activity on the data and address pins so was trying to execute something at least. I removed and tested the main RAM (TMM2063 which are known for going bad). One failed the test. When replaced the game booted!
But not so fast.. although the title screen was correct no sprites or background graphics were visible, just the top text layer. Usually bad RAM would be the first port of call for missing tilemaps and sprites, but one layer comes from the game-board and I’d just repaired and tested it with the working main-board so why wasn’t it showing up here?
I suspected the priority mixing circuit – this is how the game decides what pixels from the 3 tilemap layers and sprite layer are above or below each other and also how transparency between layers works. A lookup PROM is the core of this system – for every pixel on screen each of the 4 layers signals whether it contains a non-transparent pixel. The PROM then contains a set of fixed rules that determine which of the 4 layers ‘wins’. A logic probe seemed to show the inputs to the PROM were all pulsing but the outputs were stuck low (which would mean only a single layer would ever be selected – in this case the text layer).
The PROM was removed and replaced with one from a parts board, and all graphics were working again. It’s quite rare for these kinds of PROMs to fail, I assume it was physical corrosion.
Quick & easy repair – the sewer level had moving ‘dots’ that looked to be every 16 pixels up & down across the screen. In fact probably every level had these corrupt dots but the constant scrolling of the water layer in the sewer makes it more obvious.
The problem was a corrupt mask-rom for one of the tilemap layers. The ‘transparent’ tile had a corrupt bit. Burned a 27c512 eprom from the MAME data to fix it. There was no corrosion or any physical problem visible on the corrupt ROM.