The MegaTech is a pretty rare system, I’m not sure it was even released in the USA. The hardware is based on the Genesis/Megadrive and there are 8 cartridge slots on the board. An extra monitor in the cabinet lets the user select between the available games. Around 60 different cartridges were released which let the operator easily switch games inside the cabinet.
This board though – was absolutely dead – black screen. The ‘master’ of this board is actually the Z80 CPU that controls the menu and 2nd monitor – the ‘slave’ is the 68000/Z80 combo from the Genesis system. This BIOS Z80 sits on a little sub-board with a parallel port, but that seems to only be used for coin statistics data, so the Z80 can be plugged directly into the main board to eliminate any problems with the sub-board.
Nothing was obviously wrong with the CPU or the board though – so I used my home-made Arduino in-circuit probe to replace the Z80. With this I could test the memory and quickly found the 6264 RAM chip was flaky – it mostly worked but would sometimes return random values. When replaced the memory test was perfect but the game was absolutely still stuck on a black screen.
I moved onto to test the Sony CXD1095 chips – these are just off the shelf port extenders and the BIOS Z80 can access two of them, to handle inputs and drive some outputs. The inputs all tested good – I could ground out various inputs, and see the result on the Arduino tester. I could also see the port that detects cartridge insertion working as the value changed as I removed and installed carts. At least one of the outputs seemed bad at IC24 though – it was attached to a pull-up resistor but the chip was unable to drive it low. I swapped this chip out with one from a Thunderblade and some progress at last – the BIOS Z80 booted and gave some video output.
However, it refused to detect any games – from examining the MAME source I knew the BIOS Z80 is able to read data from the cartridges – and it uses that data to populate the menu. The Arduino tester showed the CPU was just reading 0xff for every byte in the cartridge region. This traced back to the Sega custom 513-5309. This chip is somewhat documented as it’s used on the Megadrive/Genesis as a bridge between the 68000 and the Z80. A logic probe showed the chip wasn’t dead, so I examined more with a scope – with 1 probe on an input line and 1 probe on the output line I could see the ROM reads were working on the 68000 side of the bus, but absolutely nothing made it through to the BIOS Z80 side.
A vintage Genesis was sourced as a donor, only the early revisions contained the 513-5309 chip (must say ‘High Definition’ on the front and have a ‘long’ FCC ID number) – the chip was swapped and the rare MegaTech was perfect again. (The early Genesis has a handful of other parts useful for System 18 repairs also).
Game would boot to a corrupt screen then reset. Comparison to MAME suggested it was trying to draw the ROM check screen, so it was possible the RAM used for the screen itself was bad and the reason for the corruption.
The game has 3 TC5535P-A RAM chips on the video board – I held the 68000 CPU in reset so I could use a logic probe on the RAM without worrying about writes getting in the way. It was obvious one of the chips had a very weak data output so it was replaced and everything worked. The TC5535 actually seems to be quite a rare chip now – luckily I had a spare from a Nintendo VS board.
Initially booted with corrupt sprites – certainly drawing as the wrong width – then subsequent boots showed no sprites at all.
I went through the ROMs and PROMs to reseat everything and a problem was soon obvious – 136037-103 had previously been inserted with the power pin bent outside the socket – a weird fault but when restored everything was 100%.
Game played but with corrupted graphics most noticeable on the title screen and test mode. The graphics in Gauntlet are 4 bits per pixel, with each plane stored in a separate ROM. By removing ROMs one at a time it became clear the corruption was on plane 0 only. With the ROM at 1A removed although the title screen had wrong colors there was no more noise or corruption. My initial thought was this ROM had failed – but it tested ok off the board, and a replacement ROM showed the exact same fault. Next to check are the two custom chips next to the ROMs – these are identical and process a pair of planes each. I swapped the two chips but the fault stayed on plane 0 rather than move to plane 2.
I then used a scope on the data pins of the 1A socket and found D7 was noisy whereas D0-D6 were clean (held high by the pullup resistor pack). It seems the ROM at 1C was emitting noise onto the bus even though it wasn’t enabled – with that ROM replaced everything was good.
The dual boot process is well documented on the Gauntlet site at ionpool – http://www.ionpool.net/arcade/gauntlet/main.html
In case that site ever goes down the process is quite simple as Gauntlet 1 & 2 are essentially the same board and already share some ROMs. For the ROMs that differ – 4 graphics ROMs, alphanumeric ROM, 4 program ROMs, 2 sound ROMs and the settings eeprom – the idea is you replace each with one that is double the size. Then you put the Gauntlet 1 data in the ‘low’ half of the ROM, and Gauntlet 2 in the ‘upper’ half – now by pulling the top address line either low or high you can force one game or the other. You can install double stacked sockets to achieve this, but I went for the simpler route of just pulling the relevant pins outside the sockets and running patch wire between them.
The failed AR2 power/amp unit for this cabinet was rebuilt and tested fine but the logic board had also developed a graphics fault. The test mode gave some clues as to what was going on as the character test only displayed odd numbered characters (A C E G). This suggested the low bit of whatever selected the character was stuck. The screen full of A’s was because the space/blank character was stuck as an A also.
I used MAME to clarify the layout of the character ROM – each character is 8×8 pixels in size and each row of 8 bits is stored as a byte, then 8 sequential bytes for the 8 rows. So 8 bytes a character means 3 address lines (2 to the power 3 is 8), or A0-A2. That means that if every alternate character in the range was bad, the next highest address line or A3 is the place to look.
The addresses track back from the ROM to a LS86 at E7 – this was removed from the board and tested – and yep, it had failed in exactly 1 bit. When replaced with a new chip the game was fine.
Game ran and played but with corrupt graphics. I was able to swap the top ROM board with a known working one which made no difference which meant the fault was either on the CPU board (which puts the data into VRAM as well as the addressing of the tilemaps), or on the video board (which uses the VRAM output as well as holding the 6 VRAM chips themselves).
In fact this turned out to be a simple repair – one of the VRAM chips was bad with an address bus fault – so it was just putting out data for the wrong address over the top of everything. With new VRAM installed everything was fine.
When I saw the check screen was literally cut down the middle with garbage, I suspected an addressing problem.
First up I checked the connections between the 052109 tilemap custom and the 2 6264 RAM chips. Everything was good there. Next up I checked the addressing from the CPU to the custom – this goes through 2 LS245 latches @ E24 and F24. A logic probe showed A6 was totally dead – it had no continuity back to the CPU. A kynar wire patch was added under the board and everything was perfect again. I couldn’t actually find any scratched traces, so may have been a corroded thru-hole underneath a chip.
No boot with black screen, logic probe showed the 68000 CPU was stuck in halt mode. Piggybacking known good RAM over the TMM2063 chips next to the 68000 CPU allowed it to boot though with bad colors.
Piggybacking known good 6116 compatible RAM over the palette RAM in the middle of the board fixed the colors. These 3 RAM chips were then replaced and game was perfect.
The board was clean and very good condition but booted to a corrupted check screen and would then reset. Comparing the corrupted check screen to MAME suggested one of the palette RAMs was at fault, which certainly would explain the solid red background. With that RAM replaced the game played but unfortunately the corruption was still present along with bad audio.
I had hoped the corruption was just a bad mask ROM for the text layer – but the game’s self test reported all the graphics mask ROMs were correct (both audio ROMs did fail however). Further analysis showed that the corruption seemed to come from the sprite layer – and only on every alternate scanline. The sprite system on this game consists of a pair of custom chips – 053246 and 053247. There are no schematics available so it’s not quite clear how they work but I suspect 053246 is the frontend that parses the sprite list given by the CPU and 053247 is the backend that stores the scanline buffers. As there is no external RAM for scanlines, 053247 probably has internal RAM.
As sprites did appear to work on every other scanline I took a guess that 053247 was the one more likely to have failed and swapped it with one from an untested Overdrive board. Now I had no corruption, but no sprites either. 053246 was swapped and still no sprites – but restoring the original 053247 and keeping the Overdrive 053246 fixed everything – always a danger swapping chips from an untested board as you don’t know if there was also a fault there.
As the self test reported both mask ROMs as bad – and the audio distortion was clearly of the digital variety (harsh square waves as opposed to the ‘analog’ noise a bad amplifier or capacitor may make) I desoldered the 8 meg ROM to test off-board. And it seemed fine. Rather than desolder the other ROM I swapped the 052360 audio custom chip with the one from Overdrive. Audio then worked perfectly and both ROMs passed the self test – so clearly some kind of internal fault in the custom.
Game was absolutely dead with no video output and almost no activity detected with a logic probe. The 68000 CPU was not dead though – instead it was waiting on the ‘DTACK’ signal. DTACK is what the 68000 can use to synchronise writes to external memory where there may be contention with something else on the bus. As the 68000 is frozen you can actually use a logic probe on the data and address lines to detect what address is being written to. In this case it was VRAM – which makes sense as there is contention with the graphics board reading VRAM to draw the screen.
A look at the schematics shows DTACK is driven by, amongst other things, the N1H and 2H (horizontal clock) signals and these were dead. Those signals come from the 05292 custom chip on the video board and unfortunately it was completely dead. This chip is really the heart of the board as provides all timing so without it pretty much no element can run. A 05292 was substituted from a Salamander, and Lifeforce ran which proved the 05292 was at fault.
The Lifeforce had a couple of glitched inputs, some were down to a previous repair where one of the optocouplers had been replaced – bad solder joints on the socket. Player 1 left however remained stuck on and it seemed one channel of another optocoupler had failed. As I didn’t have any spare, I used a trick – this hardware is setup for 3 buttons per player, but the software only uses two. So I cut the trace for player 1 left to the failed optocoupler and patched it to the unused third button input, then patched the optocoupler output back to where it should be. Worked perfectly and all inputs good again.
Good condition MV2F but graphics were corrupt. As often happens with NeoGeo’s acid from the battery had leaked and destroyed a couple of traces. These were patched with Kynar wire and a fresh battery installed and everything fine again.