1942 (bootleg) Repair Logs
Forum Thread: 1942 (Bootleg) PCB Repair
Sniped this 1942 bootleg board on ebay recently, sold as a faulty, the one guy I outbid was probably annoyed but they saved themselves a right pain in the rear if they were planning on fixing it.
Physically the board didn't look great, there had been quite a bit of repair work done on it, a number of TTL chips were not original, some in sockets, many soldered badly. There were a number of bodgy fixes, wires strung across the board linking things that looked like they would never be connected by the PCB itself. Finally the EPROMs were a mish mash of brands, with mismatching stickers and all looking rather tatty. The silk-screening for the CPU board and the gfx board were different styles, clearly this board pair were not born together.
The initial problem was that its was not JAMMA, nor was it Capcom classic pinout as it has a 22 pin edge connector so it wasn't the standard 1942 bootleg pinout, a quick check with the multimeter showed it also wasn't the 22 pin bootleg pinout. Right at the end of the fix when I was trying to infer the control pin layout did I actually find the 22 pin pinouts that made sense for this board. Initially I had to work it out myself, which actually is quite easy if you have an oscilloscope. The 5V and Ground rails are easy enough to work out as all the TTL chips connect back to this, and for initial troubleshooting of a board you only really need the 5V, the ground, and the video output, enough to power up the board and see what it does. On a running board with no 12V (so the amp is off) the only signals you should see coming out of the board are the 3 colour channels and video sync, the colours look like very weak noisy signals and the sync is a regular pulse. So wiring up the loom was quite easy, except which colour is which. MAME is damn handy to see what a game should look like, it literally was a case of going round with a loose wire touching each of the three outputs to see which made the sea blue during attract mode, the other two were a 50/50 guess and suddenly I had a full video output.
The game was running so I thought I was half way there, sadly planes were buzzing around happily over a pure blue sea, no sea surface graphics, no islands and no aircraft carrier - the background was totally missing. The player sprite was also a bit flickery from time to time, with lines of flickeryness extending out behind it.
Every once in a while I would get bursts of graphics scrolling past as backdrop but they were blocky and just wrong.
The title screen was also wrong, it should be a black background, but I had blue, sometimes blank and sometimes with crap all over it.
Initially I thought this was a video ram problem for the area dealing with the back plane, it was no consistent so RAM was the logical suspect. The RAM was easy to find as when interrupting the output pins I got single pixel lines scrolling past as the back drop, it was a standard 6116 SRAM chip, which tested fine when removed. Strung out above the SRAM chip were 3 27c128 eproms, one in its original socket, 2 in replaced sockets with a wire soldered across them to fix a mangled track. Hitting these with a scope showed that they were all outputting a healthyish signal and were addressed by generally healthy looking address lines. The 6116 chip was enabled and everything looked fine. The data bus was controlled by a 74LS377 that I removed for testing and sadly it passed all tests.
At this point I finally got round to dumping the ROM contents, none of the 3 ROMs by the 6116 were recognised, the main program EPROM (a 27c64) was not even seen by my tester, yet when it was told to blindly drive the chip gave a dump that was an exact match for the 1st ROM in the Capcom set. On the far side of the GFX board were 5 other 27c128 ROMS, 3 dumped fine and matched the capcom set, one had contents not recognised and one was totally dead - not detected and gave a dump full of FFs. The 3 chips that read fine still had their original stickers on them and were all Mistubishi chips, the remaining two had no stickers and were a TI and a Hitachi ROM - not original.
Looking in the MAME set and working out what the locations meant (another trouble with bootleg boards is often the chip location info is missing from the silk-screening) it was odd that only 4 of the chips should be 27c128s, one should be a 27c64, the 4th one down. EPROMs in a stack often share the same address bus, ie A0 goes to the same pin on all chips, as do all the A lines. The 4th socket had no connection to pin 1, totally correct for a 27c64 but wrong for the 27c128 EPROM that was in it. By reading the ROM contents out and diffing them in blocks to the MAME set it seems someone, for some odd reason had taken the time to consolidate the ROM contents even though the board wouldn't support it. The 128kbit EPROM in the 4th socket (which was wired to address only a 64kbit chip) contained the correct 64kbit code for that board location in its lower 64kb section, and the 1st 64kbit of the 128kb EPROM that should live in the 5th socket. The 5th EPROM was totally dead so I couldn't see what the loon who had done this had done there. It amazes me that someone has the understanding to do perform this strange act without also having the knowledge to know why it makes no sense with this board. Anyway - I erased the 27c128 from socket 4, burnt the code for chip 5 and moved it down one socket. Grabbed a 27c64 from my stash and burnt the correct contents for socket 4, flicked the power and found no bloody change whatsoever. Mildly annoying but not hugely surprising, these EPROM contain the sprite data and over half the data was correct when I got it, potentially later levels would have had mashed sprites but attract mode was the same old same old fault.
Back to the backdrop ROMs, the MAME set contains 6x 64kbit ROMs for this location on the board, but I had 3x128 kbit EPROMs, same total capacity by fewer chips. Was not surprised when the 1st chip was found to contain the data from the 1st pair of 64kbit chips from the MAME set back to back, the other 2 eproms contained mostly the same data but there were differences widespread through the data sets. Its possible that as this is a bootleg board the ROMs will be different, but as this is gfx data its less likely to have been redesigned. The second chip also had a large blank gap in the middle of it and I was wondering if the backdrop data was supposed to be where the hole was. So I took backup dumps of the 2 EPROMs, erased them, made back to back data sets from the MAME set in a hex editor and burnt the new data to the chips. Again this made not one bit of difference.
So I decided to run the board without the 74LS377 chip and got a surprising effect, the colours of the backdrop came good despite the graphics being missing, or rather a single tile due to the fact the bus was floating.
The battleship outline appeared, and despite the display flicking from dark gfx to bright gfx every once in a while..
...the islands and the sea colouring was correct.
This suggested that the system was working properly but it wasn't being told to display the backdrop, also when the 377 was back on the board interrupting the EPROMs seemed to "load" some crap into the system which would then scroll down the screen a second later. Trouble was the LS377 tested fine again and dropping in a spare didn't fix the problem.
At this point I ended up going off on a trip through the logic trying to find where things went, sadly what I took as being suspicious turned out to be totally normal, so my 3 evening voyage was a bit pointless. Basically I was trying to find a non existent fault that was causing the normal operation of a clock pin to a pair of 74LS174s. For some reason on the 3rd evening the board decided to taunt me. At the same time the colours went nuts and the backdrop graphics appeared for about 30 seconds, long enough for me to hit my suspect chips with a scope and find that nothing much had changed from when the background was missing to when it was scrolling merrily along. Probably the biggest waste of time was tracing a track on the CPU board up to the edge connector, through to the gfx board edge connector and then losing it. None of the tracks coming out from the edge connector were connected to it, the track was on the parts side of the PCB so I couldn't eyeball it either as it was under the connector. I ended up removing the 50 way connector only to find the track really didn't go anywhere, it was just a pad, another joy of bootleg boards is that they often have errors or were not designed from scratch for the game they ended up running.
Anyway, out of desperation I went around looking at all the chips on the boards, everything looked fine, eventually I found a 74LS374 chip that looked very slightly odd on the scope. If it was interrupted its outputs would crap out totally but when not interrupted they were a bit weaker than I would consider normal. So I desoldered it, found it tested OK but decided to fit a new chip. This also changed nothing but when I then went back over the nearby chips I clearly disturbed something, as soon as I hit one of the pins on an LS273 chip the backdrop flicked up on the screen. This is very suspicious, I would suspect that 273 except I had not been over it a dozen times or more with the probe before hand, its outputs look very good on the scope and the fault is consistently gone. Its been 2 days now with many many reboots of the board and not once has the backdrop failed.
The only odd issue was that the middle of the islands was a mess, as was the aircraft carrier and sometimes blocks of crap would pop up in the sea.
One thing I had undone was a bodgy solder joint joining a track to the 5V rail, the laquer had been scratched off and a big drop of solder used to bridge the gap. I had removed this earlier in my attempts to narrow down the issue as I suspected it was left over from previous troubleshooting but I decided to put it back, this fixed the aircraft carrier and the islands!!
The odd block of rubbish and sprite flicker was still popping up from time to time, thoroughly bored of scoping round the board I wondered if the problem was due to the fact that there was not a single capacitor on the board outside of the amp section, or the one that held the reset line until the board had powered up fully. Usually you see caps across the 5V and 0V to act as reservoir capacitors to smooth out any sags in the voltage. So I fitted a couple and the glitchyness of the player sprite vanished.
All that was left was to wire up the amps 12V feed and thankfully the sound was fine, after fitting the 1P control links to the loom the game plays perfectly, or it would had the PSU in my Vertical Cab not decided that today was the day to die - ho hum. It works in my horizontal cab but its not easy to play standing sideways.
When the sun finally comes out I am going to give this board a damn good wash, probably in piping hot holy water, its pretty mucky, then it can dry outside.
... which is pretty handy as I had fixed a badly corroded 1942 a while ago, and had already made up an adaptor for the same 44pin pinout as this board.
The old 1942 board lasted about a fortnight before falling over again and ended up as scrap due to all the corrosion.
... no sync!
... totally shot, the sound Z80 was just warm to the touch but this one was stinking hot, literally. So it was removed and a good Z80 soldered in.
Progress but still no signs of life. This board set had a few "usual suspects", firstly it had a fair dose of Fujitsu TTLs which are notoriously flaky in their old age, and my old favourite, Mitsubishi M5L27xxxK "ridged" EPROMs. I have now met a couple of boards with these in full health but mainly they are bad. So to avoid wasting hours looking for a hardware problem to what possibly was a software fault I had to check the EPROMs. OUt of the 16 on board 5 were bad, all of the Mitsubishis and one TMS2764 contained unrecognised data. A few I could swap for the good chips on my wrecked 1942, the rest I burnt new chips to fill the gaps.
...more life, just, but the board was still not actually running. A quick scoot round with the scope showed a few more Fujitsus with floating pins. It is common on PCBs with chips from a mix of manufacturers to find each maker supplied only a few chip types, and as I was focusing on the Fujitsus I only had to contend with 74LS74s, 74LS157s, 74ls283s, a single 74LS10, 74LS273s and 74LS245s. So I wheeled out my HP Logic Comparator.
This is a really useful test tool, you give it a known good chip of the type you want to test (usually a chip from a scrap board confirmed as good in my Wellon VP280 eprom reader that has a TTL test function), configure a set of dips to tell the tester which are the input and output pins, and then you clip the test clip onto the same sort of chip on the board. It takes the inputs from the PCB chip and feeds them to the known good chip, and compares the outputs of the two chips, if they match the LEDs for each pin stay dark, if they differ then it lights up red on the pin it detected the difference on.
It found 2x74LS157 and 5x74LS74 chips were bad on the CPU board, and 2x74ls74s on the video board, of course I could have gone round with the scope and worked out based on the inputs if the outputs were correct but this is much quicker, you don't even have to power the board down if you are careful, just move the clip to all the configured type on the board.
... a previous fix where they had cut the legs off the original chip and soldered a new chip to the stumps, electronically sound but fugly!
The 74LS273 was another Fujitsu so I replaced it but it changed nothing. My HP tester can only do chips up to 16 pins so 273s and 245s are scope work only. Once pins 2 and 3 are momentarily shorted the game will run for a while, it might freeze again and another brief short will restore it, until it sprays letters all over the screen, with the action still going on in the background.
I went over the board with the scope and found a few 74LS273s and 74LS245s that looked iffy so these too were replaced. This fixed the last of the colour issues but the game still froze the second the game demo started, just now correctly coloured.
At this point I gave up for a while, only to come back to it after dark, at which point I found the culprit. My habit is to scratch an X on a chip I want to replace while I am working on a board. With the daylight coming in from the window I had managed to miss the X on this chip...
...FIXED. Must scratch my X's harder in future!
Repair Logs converted to wiki format by Brad from Aussie Arcade.