1943 Repair Logs
Repairer: Womble
Forum Thread: 1943 PCB Repair
Another Womble ramble I am afraid...
Now that I have a vertical cab I need to assign it an identity artwork wise, and I have very fond memories of playing 1943 as a kid. There's something about the drone of the engines as you loop the loop that is just very 1980s-arcadey.
So I snapped up a faulty Capcom 1943 board listed on the ebay UK recently, cost more to ship than it cost to buy but still cheaper than a working board locally all up I think.
Buying borked boards is always risky as you never know how the board died, it might be fixable or it might be a total wreck. The seller of this board claimed it was a permanent fixture in his mates cabinet, and that they played it incessantly during the summer, but when powering up after a few months off all they got was a blue screen. They took the board to the other guys house and tried it in his cab and got the same deal. At this point they decided to sell it rather than fluff around with it, as they knew they wouldnt be able to do much with it - these guys deserve a medal for that way of thinking. Assuming the seller was telling the truth and that it died inside the cab, there should be no chance the board had been plugged in backwards, so I took the punt.
It turned out that getting a blue screen is a bit hit and miss and the blue screen is actually the background seascape rather than just a blank blue screen. Powering on and off gives you about 5 different screens of crap
1) Alpha-numeric crap - classic Z80 in distress.
2) Blue seascape with or without music.
3) Repeating pattern of large blocks of ocean wave graphics - assume its part of the tsunami.
4) Half a battle ship
5) Black screen with fragment of plane and explosions dotted about 6) Black screen.
Oddly enough hitting the coinup button will often cycle through the above, and or stop the music.
Certain AA members will be glad to hear I have finally sorted out my playroom and my 100Mhz Dual Channel CRO now has a permanent place of honour, after having spent the last 9 months in a cupboard coz its about twice the size I thought it was when I was bidding for it.
Having dumped and verified the ROMs, (a doubely good 1st test as it reseats every Eprom too) I moved onto the second most likely culprit (after power), the RAM. This board has 3 types of RAM, across the two boards. As is fairly standard, 1 board houses the CPUs, game code ROMs, sound system, and clock generation chippery, the other is the Video board which handles the video generation, sprites and graphicsy stuff. As the music could play I was pretty sure I could rule out the sound system and the graphics fragments I could get looked nice and clean, that just left the main system RAM at 10D. Also as they were socketed I was able to test the two Z80 chips in my Galaxians board and prove they worked.
Normally I would just work using a logic probe, in this case the right pins on the SRAM were active, the chip was not in standby and the control lines were busy. Looking at the activity with the scope it showed the control lines (WR and OE) were active and healthy. The address lines were also nice and healthy - healthy as in the voltage levels were transitioning pretty cleanly from logic 0 to logic 1. However the data lines (i.e. the output) were a mess on half of the pins, a number of the pulses were more like spikes and barely reached half way between the two logic states.
So - whipped the chip out..
.. and fitted a couple of 14pin machined pin sockets side by side to take the 28 pin slim M8464 chip which is pin for pin compatible with the original TMM2063 (cheaper than buying 28 pin sockets).
The original chip failed the RAM test on my eprom burner miserably, it detected that a number of pins were unwell before it even tried the write/read tests.
Slapped in the salvaged M8464 SRAM chip, powered up the board and it booted happily.
The only thing wrong was the sound, everything bar the chip tune was missing. I briefly heard the shot noises very very faintly but that stopped pretty quickly.
Back on the test bench and looking at the board there are two Y2203 sound generators, feeding two YM3014 DACs which feed into the amp section. Hooked up my audio probe to the output of both DACs, the one at 2B was happily pumping out the chip tune, the one at 2C was giving out silence. Probing the input signals to the DAC showed 2C was getting no inputs. Tracked back to the Y2033 and some inputs were active and others not. In the end it was simpler to desolder it, fit a 40 pin socket and drop in a spare YM2203. This brought back all the shot sounds and some of the background noises, but not the classic 1943 drone sound effect, or any of the explosion noises.
At this stage I don't know if either of the two YM2203 chips are in perfect health, the sound effects that are missing are too complicated to be generated by any of the TTL logic in the sound section I would assume so perhaps one of the YM2203s is only half well.
So I reckon that the seller's story checks out - the board could well have just died in its sleep, the YM2203 chip probably died here as I just heard its last gasps. Need to put some more time into the remaining sound issue, but have run out of weekend! It plays well tho, she's definitely a keeper.
Repair Logs converted to wiki format by Brad from Aussie Arcade.
Repairer: channelmaniac
Symptom: Garbled player/enemy sprites
Problem would come and go with tapping/flexing of the board set. Flipped set over and isolated the problem down (by light tapping) to a custom surface mount chip on the ROM board. A closer inspection revealed 3 pins on the chip that were barely soldered at the factory. The connection broke loose resulting in the corruption. Repaired 3 bad solder connections on surface mount chip to fix the game.
Repairer: Apocalypse
Forum Thread: 1943 - Capcom 1987 (repair log)
First obvious thing to notice is +5V connectors were burnt on the JAMMA edge. Never a good sign. I checked for other burnt traces or components on the board and even blown capacitors but didn't find any. So it was time to power it... Nothing came on screen. One thing I always do in that case is checking if any IC is getting hot. And the sub Z80 (for sound) was. I replaced it but saw no improvement. I then started to check the main Z80 lines and the main RAM lines and while doing so I got some music. I replaced the main RAM and the game booted but with wrong text colors:
I replaced two 273s at positions 5E and 5F and the game played fine. For 30mn...
Then it started to reset every second, indicating the protection chip (i8751) has died. Unfortunately this chip is read-protected and hasn't been dumped. I had a look at the MAME file and discovered the protection was quite simple:
MAME wrote:46 READ8_MEMBER(_1943_state::c1943_protection_r)
47 {
48 // The game crashes (through a jump to 0x8000) if the return value is not what it expects..
With an hex editor I searched for C3 00 80 (JP 0x8000) in the program ROMs and found 3 locations. The game simply compares two registers (one coming from the protection mcu) if equal the game jumps relatively 0x11 addresses forward if not it clears some registers and jump (absolute) to 0x8000 (reset?). I replaced the cp b instruction (data coming from the protection chip being stored in b) by cp a (the data calculated by the main Z80 being stored in a). This correspond in hex by replacing 0xB8 by 0xBF. Now the patched game (only 3 bytes to modify) compares a with a so it's always equal. I burnt the patched code in a 27C256 and played the game to the end just to be sure everything was fine. With this patch the protection chip can be completely removed.
[Note]The same method may be applicable to other Capcom Commando based games.[/Note]
The day after I played the game again and after 15mn clouds in the background turned grey... This time I replaced the 273 at 13B and the game was fixed. I let the game running for few hours without any new issue. Finally!
