13th April 2018
My System 32 Trackball Interface is finally complete and PCBs are currently being manufactured....
8th April 2018
While I'm on the subject of Taito PCB repairs, here's the next project which I've just completed....
This is a reproduction of the Taito TC0070 RGB Module used on many, many Taito PCBs from the 80's and 90's. These were originally made on a
ceramic substrate and then covered in black ceramic and often break off or are damaged, or just fail internally. They are the very same
things pictured in my Chase HQ repair log Part 3.
Some time ago (~2013) 'JROK' reverse-engineered the TC0070RGB module and provided a schematic here. There was a re-made version using PALs which re-produced
the logic exactly but it was a bit ugly. Someone else came along and took the JROK design and copied it 1:1, called it their own
and sold it for US$65, which is just highway robbery. Need proof? Google has all the answers. eBay has answers too LOL!!
Instead of paying through the nose, this can now be made by anyone familiar with the hot end of a soldering iron for $5. The
simplified design presented here replicates the same logic and works 100% the same way. This design uses less chips (all common off-the-shelf
parts available on eBay etc) and the final result is the same..... 5-bit digital R+G+B input (15-bits total) and standard analog RGB output.
The design is based on JROK's reverse-engineered design and the Bubble Bobble bootleg PCB which uses the same kind of 15-bit RGB DAC on the
PCB but instead of a flimsy ceramic module, they made the circuit with common logic chips etc and put it on the main PCB. Bryan McPhail
helped to trace out the bootleg circuit and I laid out the PCB and routed the tracks using Eagle PCB CAD.
You might be thinking (or some leech who sells the US$65 one might be trying to convince you) "it isn't a 1:1 from the original so it can't be good".
FYI, all logic chips contain circuits made from resistors, transistors, diodes etc. Any circuit can be made from a number of different chips. There's
no hard rule about how things can be done. It's called 'innovation'.
Regardless, it works and is free so it doesn't matter whether there are non-believers or not. The smart people will see the light and make
it themself. Yes that's right, it's free. I have no plans to sell this, this is purely so people who want to fix their boards can do so
cheaply. I have some other future repairs to do to almost-worthless Taito PCBs that would otherwise be scrapped due to the cost of buying a
pre-made TC0070 module. Now these can be fixed very, very cheaply using this module, which is 2" x 0.9" (i.e. smaller than the original).
The PCB costs $3 (quote from Osh Park... probably $1 from most Chinese PCB manufacturers) and the parts are (depending on where you buy
them) around $2 total.
Design files (gerbers) are available free on my "Guru's Useful Eagle PCB Designs" page. You make your own at any PCB manufacturer such as
Osh Park then solder on $2 in parts and you have your own.
Don't get shafted and pay US$40 for a blank PCB or US$65 for an assembled version from somewhere else LOL!!!
You will learn something and feel better when you build your own TC0070 module for $5 :-D
2nd April 2018
Let's continue with the Chase HQ repairs, Part 4.
If you have not read the previous repair logs, read Part 1 and Part 2 and Part 3 so you can catch up with the current situation.
The remaining final issue is there's no sound. Fortunately with this game the sound section isn't too complicated as far as the actual
circuit. Most of the complexity lies within the custom Taito TC0140SYT and the YM2610 chips. The first thing I need to do is find a good
TC0140SYT and mount that onto the board, since it was blown and I had removed it in Part 1. I have already verified all of the pads on the
PCB join to the correct places. I found a chip among a pile of other chips of unknown origin....
While not in the best condition, I've seen a LOT worse so as long as none of the legs are broken or break off when I straighten them, and
it's not blown up (hehe!), it should be usable. After about 1 hour of prodding with tweezers and pushing with a stanley knife, and pressing
the chip down on a flat surface, then prodding and tweezing and pushing again several times all the legs are straight....
This isn't the actual chip (note the date code is different hehehe!!), I had already re-mounted it on the PCB and forgot to take a pic, but
this gives you an idea what it's supposed to look like ;-)
Ok so now I just need to put it back on the PCB. There's not a lot to say about this, I just solder it on then clean up with isopropyl alcohol...
I powered on and I got this screen....
Great! The sound error is gone! But does it make any sound? Well..... it's trying. On first boot there's the normal speaker click, but it's
crackling a bit where it should be silent. When the Chase H.Q. title appears and drops the shadow down, it should make a clunk sound then
the music should play. Unfortunately, there's just some bad screeching instead of any kind of correct sound, but it seems to be kind of in
time with the correct sounds. The TC0140SYT receives the reset signal and is active on all address/data pins so I suppose that means the
TC0140SYT I just re-mounted is ok. The Z80 and EPROM and RAM are active and so is the YM2610. When I coin up the screeching changes to
different screeches and some of the pins on the Z80 change so the sound program is definitely running. Maybe the ROMs are suspect? I need to
read them, should be a simple two minute job to read four ROMs, right?
On the PCB is printed '23C4001E'. I don't know the brand of these ROMs, but the info on the net tells me it's equivalent to a 27C4001 or
27C040. So I read them as that type and got no output, just 00's! I removed another ROM and read it and got the same result. So I repeated
with the last two and got the same result. Hmmmm, surely all four ROMs couldn't be bad? I'm not going to worry about that right now, just
replace with EPROMs of type 27C4000/27C4001/27C040. I have plenty in stock so I grabbed a handful, erased them and re-programmed them with
the correct data. On power-on I still got the same crackling and screeches! The address and data lines on the ROMs are active so for now
I'll move on.
The next chip to check is the YM2610. It seems to be active, but all of those active pins are inputs coming from either the Z80, the ROMs,
the sound RAM or the TC0140SYT custom chip. The only audio output on this chip is the digital audio outputs (SH1 and SH2, the analog output
on pin 27 is not connected and unused) and a clock that drives the YM3016-F DAC. The input clock is correct (8MHz) and the output clock is
also correct (2.666666MHz). I probed the two digital audio output pins with my logic probe but all I see is a regular high/low flash no
matter what sounds are being made. Is it working or not? I got out the scope and probed those two pins again. This is the output of SH1
while in attract mode where it is supposed to be playing music (it's a bit hard to get a clean shot of it)....
There's mainly no change in the waveform except a little 'wiggle' at the top. When the sound isn't playing the waveform looks exactly like
SH2. On SH2 the waveform has no change at all even when sound and speech is playing in game. Is it good or is it bad? I don't know what it's
supposed to look like since I have no reference waveform. I would have thought the waveform should be a bit more irregular and span the full
0v to 5v range as different sounds are output but only the top wiggles hehe! That little wiggle might be the noise and crackle I'm hearing.
Or maybe not. I think I'll try the 'Louis Rossman Repair Method' (search youtube for more info) and just change stuff that looks corroded
The YM2610 certainly looks bad and rusty. But this theory might be on shaky grounds already here in arcade land because if I were to fully
apply it, then everything would need to be changed because everything looks bad heheh! Anyway let's pull this sucker and change it and see
Those little pieces left in the holes are not legs, they are the remains of the plating on the legs, the corrosion lifted the plating and it
fell off. After cleaning it all up it looks like this....
While the chip is off the board, I went along every pin hole and beeped out all the connections to where they go. They were all joined so
everything is ok. I replaced the chip with another one taken from a junk board, powered on and got exactly the same output, crackling and
screeches. Oh well, so much for the 'replace bad looking stuff theory'. That doesn't apply in arcade land, sorry!
So moving onto the next chip in line, maybe this is a digital to analog problem. The schem shows the complete path of the audio....
YM2610 --> SH1/SH2 pins 29 & 30
--> YM3016-F pins 7 & 8 --> pins 10 & 11
--> TL074 @IC64 pins 10 & 12 --> pins 8 & 14
--> TL074 @IC65 pins 5 & 12 --> pins 1 & 8
--> Taito TC0060DCA custom pins 2 & 5 --> pins 3 & 4
--> two resistors --> one line output
--> volume pot
--> MB3735 pin 1 --> pin 8 (+) & pin 5 (-)
--> 28-way edge connector pins 10 & 11
Here's the relevant circuit on the schems....
I know from past repairs I can probe the TL074 outputs and 'hear' the sound on my logic probe through it's built-in piezo speaker. I probed
the TL074 output pins and heard nothing. Probing the YM3016-F outputs also gave no sound on the probe and this is the next chip in line
after the YM2610. There should be something coming out of the YM3016-F when music is playing, but there's nothing. Maybe that's it! I
removed it, cleaned the pads and replaced it with another YM3016-F from a junk board.
I anxiously powered on and waited for the start-up tests. There was silence, no crackling. The title showed then the shadow dropped and
'CLUNK!' then the music started playing! Yay!! It's finally fixed!!! I coined up, started a game and Nancy announced we have an
emergency(!), so I grounded the accelerator pin on the edge connector and the car took off. It's perfect :-D
But we're not done yet! I went back and tested the YM2610 digital outputs with the oscilloscope again and got the same readings, so the
waveform above is what the digital out on a working YM2610 looks like.
I'm still curious about those ROMs. I removed the EPROMs and put back the original mask ROMs expecting to hear bad sounds, but the sound was
still perfect! Hmmm, what's going on with those ROMs? I must investigate, we *still* have an emergency Nancy! I read the ROMs again but
still got bad reads. Some research is needed. Here's the relevant datasheet pages for 23C4001 and 27C4001 and my original mask ROM pinout
shown on the schem...
There's no difference between the first two pinouts, but the original ROM has pin 1 tied to ground. That pin 1 is a no connection on the
23C4001 mask ROM and VPP on the 27C4001 EPROM. On my programmer it pulls pin 1 high by itself when reading it. The datasheet
specification for 27C4001 says pin 1 on the EPROM is 'don't care', which means either low or high it will still read it just fine. Whereas
the original mask ROM must have that pin tied low to be in read mode, otherwise it goes into power-save mode. I put the original ROM in a
socket and read it with pin 1 lifted....
Here's a tip! When doing this do not just put the ROM directly into the EPROM reader and bend pin 1 out at 90 degrees or more because you'll
break the leg off the ROM! Put it in a socket and then you can bend it about 20 degrees and the height of the socket allows the pin to clear
the EPROM programmer zif socket, then gently bend it back afterwards and the ROM leg will survive. I did another read as 27C4001 and to my
surprise the read came back ok and the CRC32 matches the known good ROM dumps in MAME. So it looks like my EPROM programmer just pulls that
pin high because there's no hard rule about it and the manufacturer chose to pull it high to 5V. Heheh! You learn something every day
Here's a summary of what was actually bad:
Replaced 10x Toshiba TMM2063 8k x8-bit Static RAMs (bad) with good RAMs, including adding sockets so if they go again it will be easy to fix.
Replaced 1x 256k x16-bit mask ROM (bad internal CE or OE) with 27C400 EPROM (IC27)
Replaced 1x Taito TC0140SYT custom chip (blown/cooked) with good chip
Replaced 1x Yamaha YM3016-F DAC (blown) with good chip
Repaired broken/corroded track from PAL at IC52 pin 21 to via with a patch-wire
Not In The Log: Re-programmed 1x 27C512 EPROM (IC51).... the dump of the original sound program EPROM didn't match the known good dump in
MAME so I re-programmed it.
So you're probably wondering how this board got in such bad condition and had so many faults. Did you notice this board-set was a
Frankenstein one? The sticker on the top board says "CHASE HQ UP", meaning it's an upright board. The sticker on the bottom board says
"CHASE HQ CP" meaning it's for a cockpit board-set. The actual PCBs for any of the different cabs are exactly the same, just the program
EPROMs differ. So it looks like some loser had several boards and swapped them around to get one going then sold the remaining non-working
boards on ebay as 'untested'. However that's not all bad. Losers like that are part of the lowest end of the food chain, just as a spider
needs bugs and other nasties to survive, PCB owners/repairers need PCBs that come from dubious locations with dubious faults sold by
untrustworthy losers trying to sell stuff that they know is tested and doesn't work. All pretty common and predictable behaviour LOL!
Bonus Log Event: Pissed off the loser ebay seller who sold this as 'untested' hehehe!!
BTW, to all the Chase HQ owners out there, if you happen to have a Chase H.Q cockpit or deluxe cab, please dump the EPROMs on the top board
and send them to me so they can be preserved in MAME because they are currently not dumped. Or at least it looks like they are not dumped.
Maybe there's some additional hardware in the cockpit/deluxe?
Anyway, all problems solved, now we can go catch some criminals!
1st April 2018
Ok, continuing on with the Chase HQ repairs, Part 3.
If you have not read Part 1 and Part 2, click here for part 1 and here for part 2 so you can
catch up with the current situation.
The blurred video issue is the main problem right now. I think if that is solved the game will be fully working other than missing sound
(which I'll fix last). Here's some pics of the blur effect. Notice the in-game pic is almost perfect except a blur at the far right side of
The first thing I noticed was the RGB custom was a bit dodgy, hacked up by some loser who doesn't know how to use a soldering iron.
Underneath the PCB was some dirty flux crap and it was really nasty. I think now I know what grizzly bear shit looks like.... urgghh! So I
removed the RGB custom and some legs fell off. This is a pretty common issue with these ceramic custom SIL packages. I assume it works
because the colors are ok, but just in case I'll swap it over with another one I have, which is also missing legs but not as many.
Basically just remove the old one and solder in the good one.
Before putting the new part in, check ALL the connections to the source and ensure they are all joined. It's *much* easier to check
connections while the part is off the board than do it when the new part has been put back. That way if there is a connection issue it can
be fixed directly at the track or via without having to add bodge-wires ;-)
All the connections from the RGB custom to the color RAM and TC0110PCR custom were ok so I soldered in the exchange part.
To replace the missing legs, first just solder in the good legs, taking care to make sure the holes with missing legs stay clean. Ensure the
body of the RGB custom is as high as possible to allow working space underneath it. Then get a new resistor or capacitor and cut off the
legs about 3/4" long. Tin the pin on the custom with solder and add some flux there too, then poke the wire through the hole from underneath
the PCB. While holding it in place, solder it to the remaining RGB custom pin. Repeat for the other legs, then turn the board over and add
solder to the hole. Don't put too much heat there otherwise the leg may come unsoldered from the RGB custom. When all the legs are soldered
in place, trim off the new legs, clean up with isopropyl alcohol and job done!
Did that fix the problem? Unfortunately not, but it's exactly the same so I know the RGB custom is ok. At least now I know the connections
are solid :-)
The next part in line is the TC0110PCR custom chip. This takes the pixel data from all video sources, merges it and sends it to the RGB
custom. So let's change it. There's not much to say about this really, simply remove *the correct way*, clean-up the pads and re-mount
another identical known good part. Just check the pics, a picture paints a thousand words, and the picture caption tells the rest ;-)
So did that fix the problem? Nope! It's still exactly the same. Anyway, the chip was a bit corroded and the pads looked bad so at least now
it's clean and tidy :-)
Time to get serious. I first beeped out all the connections from the PCR to where they went. Lots of stuff, but all ok.
Then I beeped out all the connections from the next chip in line (the TC0100SCN custom) to where they went. Also lots of stuff, but all ok.
Then I went around the PCR and SCN chips with my logic probe looking for suspect signals, but they all looked ok.
I unplugged the video board and to my surprise, the CPU board actually starts to boot up. It shows some of the RAM tests then resets. But more
importantly, the blur is there even without the video board. That means the fault is definitely on the CPU board.
I'm thinking, it looks like the pixels are too bright. Like some voltage is shorting the RGB lines, but all the colors are correct, it's
weird! I'll just check the harness to make sure nothing is out of place....
D'oh! I found it. I had originally made a harness for Operation Thunderbolt and fixed that one first last week. I have re-used the harness
since the wiring is mainly the same for Chase HQ except the video which comes off a 5 pin connector and I'm not concerned about inputs yet
so I don't care where the other wires are. So I left the RGBS wires in place on the 28-way connector and added extra RGBS wires to the 5 pin
connector coming off the existing wires on the 28 way connector where the RGBS is for Operation Thunderbolt. I just piggybacked the wires
and fed them to a 5 pin connector which plugs into connector V. Obviously a mistake!! I did that mainly so I could leave the harness the
same and use it to run both boards to see that they powered up and worked without having to re-wire the harness. I was thinking it wouldn't
matter because those pins were just inputs/unused but obviously one of them has some voltage or ground there and was screwing with the video
heheh!! OK so I removed those extra wires on the harness and the video is back to normal! :-D
WOW! It's April 1st. I think I may have April-Fooled myself! hehe!
Note to self: When re-using an old harness, remove all the unused wires hehe!
Note the purple Taito logo is actually blue on screen (i.e. correct). For some reason the camera makes it look purple.
So now there's just the sound issue to fix and then the Chase HQ board should be fully working.
31st March 2018
Let's continue with the Chase HQ repairs, Part 2.
If you have not read Part 1, click here to read that first (posted March 30th 2018) so you can catch up with the
I'll look at the sprite issue now. The problem seems to be that the transparent (outer) section of the sprite isn't fully transparent,
there are lines through it. That means data is missing.
It's definitely not ROM related since I checked the ROMs and they are all ok. Incidentally, one thing I discovered about the ROMs.... there
are some that have an indented line running the full length of the chip, a tell-tale sign they are made by Fujitsu. On the PCB is screened
'MB834100'. I couldn't find the datasheet for this chip but I figured it was like 23C4100 so I read them as 27C4100 with my EPROM programmer
and got a bad read so I figured they were bad and replaced them with 27C400 EPROMs. That didn't help and made it much worse! The datasheet
for the Fujitsu MB834100 is not easy to find but there is a good quality datasheet in the 1989 Fujitsu MOS Memory Products Databook
available at bitsavers.org. After checking it I realised the MB834100 mask ROM is pin-compatible with a 27C4096 EPROM! So I read the mask
ROMs again as 27C4096 and got good reads :-)
Note to self: MB834100 = 27C4096
I got a quick tip-off from Bryan McPhail... yes, the same very talented MAME
developer who emulated many games in MAME years ago. The suggestion was to look in the area surrounding IC173/IC174 because that has
something to do with the transparency of the sprites, or check the video RAM.
This is the relevant section of the schematic....
Personally I didn't think it was the RAM because piggy-backing the RAM has no effect except to make it worse and put wide vertical stripes
across the entire screen, but the tip-off was close! I probed about with my logic probe and pin 8 of IC174 (LS260) sounds strange. My logic
probe has a piezo speaker inside so I can 'hear' the 1's and 0's... it's very nice.... good data sounds pleasant and rhythmic, but this
didn't sound good at all. When I shorted pins 8 and 9 of the LS260 together with my logic probe, by pure luck it fixed the sprite problem
100%!!! Obviously that's not the solution but it shows I'm close. What that actually did was inject the signal from pin 9 into pin 8 because
pin 8 has something missing. The actual suspect signal is on pin 8 of the LS260 at IC174. The schems show it as a signal on the FRD BUS
called FPO10 or something like that (the schem is the usual poor quality crappy hard to read scan... arrgghh!).
Here's a close-up of some of the circuit with the relevant signal highlighted in red....
The schematic shows FPO10 connects to several places..... 74LS260 at IC174 pin 8 (input), 74LS166 at IC153 pin 12 (input), 74LS244 pin 9 at
IC130 (output only, all inputs on this chip are grounded), pin 11 (D0) of the 256k VRAM at IC85 and a PAL at IC52 pin 21. All inputs can be
ignored because they have no effect on the signal. We need to find some chip that 'creates/outputs' this signal. The schem show the source
of the signal is the PAL at IC52 pin 21. There is a bank of eight PALs together in the top left corner of the video board and out of those
chips, there's only two different types. Checking PALs with MAME as a reference is not the easiest or quickest thing to do. The PALs in MAME
must be converted to .jed files using the JEDUTIL program provided with the MAME distribution. Then the actual PAL is read using an EPROM
programmer and compared manually with the MAME-converted .jed file. The reason it has to be manually compared is because the MAME-converted
.jed file only shows lines in the fusemap that contain 1's. Any line with all 0's is omitted, so the CRC32 of a MAME-converted PAL .jed and
the real read from an EPROM programmer will always be different. Even looking at both of the actual fusemap files will show they are very
different, except those lines that contain the same bits. Knowing several of the PALs are the same, rather than go through the hassle of all
of that converting and comparing B.S., I simply read the PALs and checked the CRC32 against the other identical PALs. They all matched so
the PALs must be ok. There is another way too.... I could swap the PALs to the other location where the same PAL is, but IMO that would not
tell me whether the PALs are good or not, especially if there was no difference on the screen. The better way is to just read the PALs
and compare them against one of the other identical PALs :-)
When I probed the RAM on pin 11 it shows the same strange signal. Luckily on this board the data lines are not connected across multiple
RAMs. When data lines are connected across multiple RAMs (for example to create a 16-bit data path from two 8-bit RAMs) it's a nightmare to
find the suspect RAM because when probing the RAM you are actually probing two or more pins on multiple RAMs. This why it's very difficult
to repair faults on later arcade games that have 16 or more 8-bit video RAMs tied together to create a large 32-bit chunk of RAM. A classic
example is Namco's Point Blank, where sixteen 32k x8-bit static RAMs are tied together on their data lines and address lines. It's a
nightmare to find a sprite fault on that board. In that case the only way to find the bad RAM is either remove all of the connected RAMs and
test separately or use an oscilloscope and hope something looks different. But even an oscilloscope won't fully help, although it can allow
you to narrow it down to less possibly-bad RAMs. I have a nice 80MHz quad-trace dual time-base scope but I'm no expert with it so I skipped
that part. Personally I think scopes are over-rated. They have their uses, but not in this case. I already know there's a bad signal but the
scope isn't going to help me find it and even if it did show an abnormal waveform, it can't tell me exactly which chip it comes from. That's
where the schematics come in handy and why schematics should be scanned at a minimum of 300 DPI, or better 600 DPI. Without a schematic the
only way to trace signals is by having a known good reference board or removing parts and using a multi-meter to beep out the connections by
visually locating the connections on the board. It's a huge job. The schem pages for Chase HQ were scanned at a measly 72 DPI!! The moron
who did it probably looked at the page on a 14" CRT back in about 1992 and saw lines so he thought it was good. He obviously never viewed it
full size and tried to read the text. OH MY GOD! It's just barely readable ggggrrrrr!!!! Imagine if I couldn't read the schematic signal
labels, it would be useless and the scanning would have been a complete waste of time. It's a big nightmare to find the actual connections when
it's unreadable, especially on a bus where all the signals are on the single bus line and they only fan out at the IC pins. Here's a tip for
future schematic scanners out there.... scan at 300 DPI or 600 DPI so that your good work becomes useful for repair work rather than a
burden. If only everyone had scanned schems at 300/600 DPI, MAME could be even better.... yes that's right, in some cases MAME suffers from
lack of info because schems were scanned at a very low resolution and were useless! Anyway, my rant about schem quality is finished.
When I short pins 11 and 12 of the VRAM at IC85 (D0+D1) it also fixes the sprite problem. Again, not the solution but shows I'm looking at
the right signals. Since D0 is a bi-directional data pin, it can either be input or output. There's no real way to know for sure if the RAM
is bad except to remove it and test it either in an external testing device like an EPROM programmer with RAM testing capability, or plug it
into another PCB. In my case I keep a set of working PCBs with various parts socketed so I can test parts on the PCB. So I removed the RAM.
I plugged it into my test PCB and it was fine, so the RAM isn't bad. I also noticed when there's no sprites on screen that specific pin on
the RAM (D0) is still active (regular pulsing) on my logic probe even though all the other data pins on that RAM and all the other VRAMs are
quiet, so I guess it's floating or something.
There's definitely some signal missing so it's time to get beeping! I know where the D0 signal connects so I probed the FPO10 pins of the
connected chips with my logic probe and found the same regular pulsing signal on all of the chips no matter what was on screen. All EXCEPT
the PAL. On the PAL (IC52 pin 21) I got a LOT of activity when sprites were on the screen and no activity when no sprites were showing.
BINGO!! That PAL was about 12 inches away from the initial bad signal I found so without the schems that fault would never have been
I set my multimeter to continuity and checked the actual connections on the PCB. All of the chips were connected except the PAL pin 21. I
hooked up a mini-clip to pin 21 of the PAL and touched the other end of the cable to the nearest chip with the same FPO10 signal (the
74LS244 pin 9) and that fixed the sprite problem 100%! I looked on the bottom of the video board and the trace from the PAL goes to a via
but between them it has 'The Curse Of The Taito Green Mask Turning Black And Rotting The Trace' problem which plagues many Taito PCBs :-
( I don't think there's much point patching the PCB trace with a micro-wire because the track is shot, so I added a wire to join the PAL
pin 21 to the via and that restored the sprites back to normal :-D
Sprite problem solved!
Obviously we're not done yet since there's still more problems so the repair will continue later....
30th March 2018
Chase HQ repair, Part 1.
A couple of Taito PCBs came in for repair a few days ago. The games are Operation Thunderbolt and Chase HQ. Neither PCB was in great
condition but they HAD to be saved from the junk pile so I put in an extra special Guru-Effort to make sure they came back to life
One of the main issues with late 80's and early 90's Taito boards is the RAMs made by Toshiba have failed. Taito PCBs are loaded with them
usually. The specific chip is Toshiba TMM2063 (8kx8 Static RAM), and also TMM2018 (2kx8 Static RAM) is another one that fails often.
Here's a pic of the nasty TMM2063 culprits....
The Chase HQ board has 10 of these chips on the CPU board and if any of them fail the board will have major problems, most of the time just
killing the board dead. In some cases the road or colors will be bad but if it's any of the 68000 program RAMs or the shared RAM the board
This Chase HQ board showed only a wavey pattern on screen and was resetting very quickly so with this RAM type in mind
and knowing they would probably all be bad, I decided to pull and replace the TMM2063 RAMs for the Master 68000 CPU and Shared RAM hoping it
would at least boot up to some sort of screen. After doing the main CPU RAM (Taito call this the LOCAL RAM, IC28 & IC35) it was still
resetting quickly so I also changed the Shared RAM (Taito call this the COMMON RAM, IC43 & IC44). A change! It was resetting very slowly,
about once every 4 seconds, but there was still nothing on the screen. I checked the data and address lines on the 1st 68000 and there was
some activity, so the master 68000 was alive! But only for 4 seconds. At this stage I checked the 2nd 68000 reset line to see if it was
active and it wasn't.... the reset pin on the 2nd 68000 was still low. I was thinking the 1st 68000 was waiting for the 2nd 68000 to reset,
but because it didn't, the 1st 68000 just kept resetting. In reality the 2nd 68000 doesn't reset automatically, it only resets after some of
the RAM tests pass then the 1st 68000 sends a command to reset the 2nd 68000. Essentially the reset for the 2nd 68000 is CPU-controlled.
Before realising that I started tracing out where the reset for the 2nd 68000 was coming from and thinking maybe I had a logic problem
somewhere but when checking the schematics I found a complicated path leading back to the 1st 68000 and a dead end to the theory that the
1st 68000 was waiting for the 2nd 68000 to reset :-/
Time to change tactics! I had previously checked the ROMs and found a bad mask ROM which was connected to the TC0100SCN custom chip, but at
that point I had not changed it. Mainly because I figured it wasn't important at this stage since it's not program-related. The mask ROM had
absolutely no activity on any data pins and reading it with an EPROM programmer only gave a 0xFF output (i.e. nothing), so it looks like the
CE pin (chip enable) or OE pin (output enable) has failed internally. On a whim I took out the bad ROM and put in a random 40 pin EPROM I
had lying around and the data pins were active! The screen showed some strange block graphics on screen like perhaps a potential text
So I grabbed an EPROM from my stock of parts and of course found it wasn't blank! I popped it into my UV eraser and painstakingly waited
about 10 minutes for it to erase. Eventually it was blank so I programmed the AM27C400 EPROM (pinout-compatible with the original 234000 mask
ROM) with the correct data, plugged that in and got this screen!
It turns out the ROM at IC27 holds the text characters. This message tells me the local RAM (main 68000) and common RAM (shared between
both 68000's) is ok and the color RAM is bad. So I replaced the color RAM (IC2 & IC3) and got this screen....
Still something not quite right but it kept going and booted up!!! WHOA!!!
The next thing to do is fix the "ROOT MPU RAM ERROR". That's the RAM connected to the 2nd 68000 CPU which is currently not running, just
resetting. It should actually be called the 'SUB MPU' but I'm guessing the Japanese person programming it at that time back in 1988 didn't
quite understand English properly and put ROOT instead heheh! Anyway, I replaced that RAM (Taito call this the ROOT MPU RAM, IC38 & IC54)
and that got rid of the ROOT MPU RAM error and improved the graphics a lot! I also heard the speaker pop and a hum is coming from it now.
That suggests the Z80 (sound) program is running because one of the tasks of the 2nd 68000 is to talk to the Z80 and issue sound
commands.... one of them is probably a 'wake-up!' command.
Still lots of graphical issues! The next step is to replace the road RAM since the road is missing too. That's the RAM at IC22 and IC23. After changing them the road now shows!
There's still has some graphical issues relating to sprites and a weird horizontal blur but I'll sort that out later because a quick check
of the video board didn't reveal anything obvious. There's a lot of RAM on the video board and it's a time-consuming job to find the
(possible) bad RAMs and strangely, piggy-backing the RAMs didn't help, it just made the display much worse. There's also a lot of PROMs and
PALs on the video board and all of them run hot. Fortunately all of them are dumped and they are preserved in MAME :-D
I checked all the graphic ROMs and they are ok so it looks like it's not going to be so simple to fix the banding and sprite issues. Some
more research and schematic reading is needed first.
In the meantime, let's move on. I want to address the sound fault and show a technique for removing a dead/blown-up custom quad-flat-pack
chip without over-heating the board and damaging or warping it like some idiots do when using a heat gun (check my news 7th January 2017 for
a typical example).
The sound fault shown on the boot-up screen that still remains could be caused by several things..... bad sound RAM (yet another of those
nasty Toshiba RAMs), or bad Z80, or bad Z80 program ROM, or missing clock/reset signals or a multitude of other things including one or more
broken connections. However the Z80, sound RAM and sound ROM are active so I doubt any of those are bad. As I was looking in the sound area
for a possible fault, I happened to touch the Taito custom chip marked 'TC0140SYT' and I burned my finger! S.O.B!! So that chip is blown and
has to go! Normally I would remove a custom chip cleanly using a special temperature-controlled hot air tool without damaging the chip in
case it is actually good and then it can be kept and re-used. But in this case I knew the chip was toasted (literally!) so there's no need to
save the chip, just get it off without damaging the board.
The NUMBER ONE concern in any repair is DO NOT DAMAGE THE PCB!!!! In this case, the PCB isn't in great condition anyway, so we don't want to
make it worse.
To remove it, start by adding some flux to the chip, then run some fresh solder across all of the legs with a soldering iron using the 'drag
soldering' method. There's no need to be neat or worry about solder bridges since the chip is coming off and going into the bin after
anyway. Now heat each leg with the soldering iron and lift the legs **ONE AT A TIME, CAREFULLY** using tweezers. Start from the edge and
work your way to the other edge. Lift the legs high enough so you can get the tweezers in underneath the next leg then lift it up slowly,
making sure the solder is melted BEFORE you lift the leg up. Again, do it slowly and carefully one leg at a time. Here's a pic showing one
Go all the way around the chip and eventually it will come off without damaging the PCB pads. When there's about 10-15 legs remaining, heat
all of them by putting the soldering iron sideways to heat all of them together (the newly added solder will help with this) then slide the
chip away off the pads. If you don't do that, as you lift the last remaining legs the chip will move and could tear the remaining pads off
the board. You could put a weight on top of the chip to hold it but it's just easier to heat the last 10-15 legs in one go and then slide
the chip off while the solder is molten.
Just remember, when you do it this way the chip is scrap, so only do it like this if you know the chip is dead!
Now clean up the PCB pads with some wick and isopropyl alcohol and it will look pretty good.
But it's not quite Guru-Worthy yet.... notice around pins 60 and 90 there's some corrosion on the pads. As I said, the board wasn't in great
condition and there's some corrosion crap on the pads. That can be fixed easily. Scrape off the crap with a small flat-bladed screwdriver or
a knife **CAREFULLY** to expose the copper trace underneath. We're not mining for iron ore here, do it very very gently and carefully!
Problem solved right? No, the pads need to be re-tinned. There's a really easy way to do that. Add flux and then use old wick containing old
solder and with the soldering iron, rub the wick on the copper pads. The solder will come off the wick and stick to the pads. After cleaning up
with isopropyl alcohol again, now it's Guru-Worthy!
The next step is to simply find another TC0140SYT chip on a junk Taito PCB and transplant it and hopefully that fixes the sound fault. But
it's late now so that's a job for another day :-)
Here's a summary of the various RAMs and their locations.....
Note the 'Road RAM' and the 'Sound RAM' isn't tested.
On the video board, the Object RAM is the two 2018 static RAMs at IC185 and IC186. The large bank of 256k static RAMs isn't tested either.
They are for the sprites.
29th March 2017
Some more of my To-Be-Decapped chips have been decapped by CAPS0ff. The Mega Blast C-Chip was dumped, so now all of the Taito C-Chips have been successfully dumped!
It has also been marked green on my Decapping Status Page
Please support CAPS0ff with funds if you can so more chips can be decapped.
12th March 2017
Some more of my To-Be-Decapped chips have been decapped by CAPS0ff. This time we have almost all of the Taito C-Chips (#73, #189, #232 & #236).
I'm not sure what happened to the C-Chip for Megablast (#231), which is also listed in my decap list as 'sent', but there is no mention of it by CAPS0ff.
The Megablast C-Chip is a special case because the game only checks for the chip being plugged into the board and after that ignores it, so a decap of it isn't so important.... it's more of a curiosity thing ;-)
Anyway, these new dumps will help with MAME's emulation of various nice Taito games from the late 80's and will be available in the next MAME release at the end of this month. In
case you didn't realize there is a new MAME released at the end of every month. Those newly decapped chips have also been marked green on my
Decapping Status Page
There's more news and pics of the decapped chips on the CAPS0ff blog.
Please support CAPS0ff with funds if you can so more chips can be decapped.
27th January 2018
A few months ago I added a page here with info about converting any Sega System 32 board to run Sonic The Hedgehog. I did not announce it here but many people noticed it ;-)
That page has been updated with decrypted ROMs for ALL of the System 32 games that use a FD1149 so now all System 32 games can live once again!
Click here to jump to the page, or click on the top menu 'Guru Misc' and select the Sega System 32 link.
26th January 2018
If you have been following MAME progress you will have seen a recent addition of the TV Boy II. This is a rip-off of the Atari 2600 and not
to be confused with the Japanese TV Boy made by Gakken.
I happen to have an original boxed Japanese TV Boy here. Although not related to the recent MAME addition I thought since it is quite rare
this would be a good time to showcase what's inside since that information is mostly guessed or unknown.
Unfortunately there are no dumpable parts inside.
Inside is 6 logic chips, a 7805 voltage regulator, a MC6847 video controller, a 6116 (2kx8 SRAM), a MC1372 modulator chip and a 3.579545MHz XTAL.
So now you know why it has not been dumped..... there's nothing in there to dump.
I don't have any carts, but I assume it contains a 6801 which has 2k ROM and 128 bytes of RAM. It was common to see a micro-controller in a
cart with the game code built-in in some other early game consoles of that era too.
The 6801 datasheet says it's pin and electrically compatible with the 68701 microcontroller so there may be hope to dump the 6801 as a 68701 if carts were available....
Anyway, here's some pics of the PCB....
1st December 2017
Some more of my To-Be-Decapped chips have been decapped by CAPS0ff. This time we have all of the Sega Model 2 chips (#211-#218)
While you may think that this will help MAME's emulation the answer is "probably not". While true emulation is now possible, emulating an
additional 4 or 5 DSP's in MAME's Model 2 driver will kill the speed to nearly zero and a snail will travel faster. It would be nice if
ElSemi re-surfaces and updates his great Model 2 Emulator to support the DSPs with true fast emulation, although that's probably unlikely to
Anyway, those chips have also been marked green on my Decapping Status Page
There's more news and pics of the decapped chips on the CAPS0ff blog.
Please support CAPS0ff with funds if you can so more chips can be decapped.
17th November 2017
I've dumped Golgo 13 Part 3 which runs on Namco System 10 hardware. The official title is "Golgo-13 Juusei no Chinkonka". The English translation is "Golgo 13 The Requiem for Gunshots".
This is also crossed off as dumped on my Namco System 10/11/12 Status page
Here's some pics of the game. The last pic shows the position of the PCB in the large batch that arrived 15th July 2016....
I have put the ROM dump online here. Note this will be available for a limited time until it hits MAME then you'll be able
to get it from the 'usual' places'. You can't play this in MAME and you can't use this to convert or fix your PCB. The dump is actually
useless. Due to the extreme level of encryption and protection, sadly this game and all other System 10 games will not be working in MAME
anytime soon or maybe never. Anyway, now it's officially dumped and publicly available.
5th October 2017
While repairing things over the years, I've noticed an increasing trend for arcade boards to develop faults with the mask ROMs. This problem
is getting worse and is not going to go away.
A while ago I got hold of a fairly uncommon Jaleco Megasys 1 game called P-47.
The game was working but the player and enemy sprites were missing. After a
quick analysis with a logic probe I realised the only issue was one of the mask
ROMs was dead. Normally any issue with ROMs can easily be fixed using dumps from
MAME and programmed to a common EPROM, but in this case the mask ROM was an
uncommon non-JEDEC Hitachi HN62312 mask ROM where none of the pins matched
anything else or were even close. Even power and ground were in different
places! There's virtually nothing on Google about it either.
Let's change that.... Here's the pinout.....
If you know anything about EPROM pinouts you will immediately see it's a pretty whacky ROM pinout!
Since this is just one ROM, rather than jerk around making up a custom adapter, I decided to just get this thing fixed and modify the board
to accept a common 27C020 EPROM and move on. Then the data can be easily programmed to a common EPROM and in the event that it fails again
the EPROM can simply be changed for a new one.
The first step was to remove the socket and trace the tracks connected to the ROM. After that was recorded I cut all the tracks tied to the
ROM very neatly, soldered in a new socket and programmed the EPROM with the data from MAME. Well almost. These larger 2M-bit mask ROMs
contain data that is identical to the already dumped 1M-bit version EPROMs. The 2M-bit mask ROMs were dumped some time ago but unfortunately
someone didn't think it was important enough to document it in the source code so the 2M-bit mask ROM dumps don't exist. Considering MAME's
main goal is to document the history of arcade games, the fact that this anomaly has not been documented is somewhat disturbing! Makes me
wonder what other valuable info has been brushed aside as unwanted by some dev who knows nothing about real hardware and PCB repairs.
Anyway, the next step was to carefully wire each pin to the circuit. In the end it was actually pretty easy. Almost all of the tracks are
common with a 27C010 EPROM next to it. The highest address line A17 goes off to the connector 'POST#7' directly (A17 is not on 27C010) and
CE goes to a logic chip. OE was just hard-wired to ground. So I got to work wiring it and after about 1 hour it was done. Conveniently the
power and ground pins were close to normal power and ground locations so I just jumped them using a wire jumper and solder. Now it works
great! Apart from a sticker on the top of the EPROM, from the top it looks all original and is now a lot more reliable with common EPROMs
instead of crappy old mask ROMs :-) It may look a bit rough from the bottom side but it is not seen when assembled and the main point is
it was fixed quickly and now works 100%, rather than being just another broken piece of crap piled up in my garage ;-)
This board has been added to my Items For Sale page which now has 3 racks :-)
26th June 2017
Occasionally something comes along that is so incredibly rare and obscure that no one has a clue what it is and it gets passed by totally
unnoticed by everyone. Everyone except me, of course ;-)
That happened last year when I picked up a rare Namco game called "Abnormal Check".
The basic hardware is Namco ND-1, but with an extra daughter-board on top that controls a printer which dispenses a print-out at the end of the
game. I had to tie a few printer status signals high/low to get it to boot up but after that the printer is ignored so it's playable. The game is
entirely in Japanese but can be played by randomly hitting buttons when responding to the questions (or you can learn Japanese hehe!)
In a multi-player game, there's some hilarious effects when the player dies, including the head getting cut off and flying into the air, stomach
opening up and bullets coming out shooting the losing player, lightning bolts frying the losing player, turning old and grey etc.
At the end of the game the winner is put into the spotlight and grows 2X bigger.
Here's a few pics from the game, including some hardware shots at the end. The last hardware pic is from the previous post showing the placement
of this item in the pic. The thermal printer is sitting on top of the metal box to the left.
And here's a shot of the title screen from the emulation, thanks to R. Belmont.
There's no additional pics to show of the emulation because in general the ND-1 driver in MAME isn't complete enough to allow it to just run.
The original ND-1 driver in MAME is very hacky and minimalistic and there are some serious graphical issues due to incorrect/incomplete emulation
of the Yamaha YGV608 graphics chip. Abnormal Check is using the chip in different ways and exposes a bit more about how the chip
works so hopefully it gets fixed in time. As a result of that, Namco Classics 1 and Namco Classics 2 should also improve :-)
15th June 2017
Some more undumped PCBs from Japan arrived a couple of days ago....
All these are extremely rare and not dumped. One is another Konami Viper/PC server with 12 CDs/DVDs (there was a similar but not identical one
in a previous shipment), a small Konami PCB which is super ultra rare, and an ultra ultra super ultra rare Namco game running on Namco ND-1 hardware
that was previously thought to be just a myth.
There were also two free PCBs. One is a Taito Mini Vaders PCB which is working fine.
The other is a Tetris The Grand Master PCB (already dumped version JAPAN 980710) that was not working. There were some loose chips on the lower
ZN2 PCB and a broken track which seems to have been caused by some other PCB being pushed hard against the chips on the lower PCB. That would be
impossible while the top PCB was plugged in so at some point it died and was dissassembled and then not stored well after. The actual real fault
was loose legs on the large Sony chips but the additional broken track done at a later time meant that even if the original fault was fixed it
still would not have worked. Regardless of the damage, the actual PCB is in very nice condition with only minor scratches on the top of a few
large chips. The under-side of the PCB is like new. I repaired the faults in about half an hour and now it works just fine :-)
I also recently did some Namco System 246 dongle cart conversions and one of the supplied carts was an alternative version of Tekken 5 Dark Ressurrection which is not
dumped so I dumped it.
8th May 2017
Anyone with a Konami PCB from the early to mid 90's will know about the dreaded KONAMI 054986A black ceramic module that develops issues and
causes the board to either fail to boot-up or the sound is missing completely. The module is used on Lethal Enforcers, GI Joe, Violent Storm and many others. Usually it can be resolved by
changing all of the capacitors, but sometimes the leaking caps cause damage to the fragile circuit. In the past there have been some fairly weak
efforts to draw that circuit, but in all cases it was limited to the simple parts on the top side of the module.
If you saw those poor diagrams and thought it would be nice to have a full schematic of the entire module, today is your lucky day.
1st May 2017
It's time the non-working Apple Macintosh IICi moved onto a new home. If you are looking for bits and pieces for a IICi I am stripping it and selling
off the parts, or you can buy the whole thing as-is if you want.
Check my For Sale page here for pics and info of what is on offer.
In other news, another chip just got decapped and dumped by CAPS0ff. This time #145
7th April 2017
Another Commodore repair job came in today. This time we have an Amiga 600. There is an Individual Computers ACA620EC 68EC020 accelerator card
fitted over the top of the PLCC 68000 CPU which seems to be flakey. Sometimes it works, sometimes not. Most of the time it starts to boot then
gives some checksum errors then crashes. Re-seating it several times helped but even then sometimes it still crashed randomly.
After a closer inspection I noticed the card isn't sitting fully down on one side and looking closer reveals the 68EC020 is fouling on top of
the 28.375MHz oscillator on the motherboard. Maybe just on the very edge of the radius on top of the oscillator tin can.
This is a bit unusual because this card is specifically designed to clear and fit properly within the constraints of the A600 motherboard and I
found no reports of this problem with a quick google search.
I figured I'd start by removing the PLCC socket and have a closer look. I was thinking maybe I could lift up the PCB slightly and then it would
clear (it would have an air gap under the socket) then re-solder it in place and it would clear. With the socket removed, I fully pushed the PLCC
socket down onto the 68000 CPU and it went down all the way with a 'crack' sound... meaning it's now on very tight. I don't think the socket has ever been on that tight.
So then I put the PCB back on top of the PLCC socket, just sitting there loosely and noticed the 68EC020 CPU was no longer hitting the top of the
oscillator! There is some movement between the pins of the socket and the holes on the PCB and I can take advantage of that. When pushed up (away
from the oscillator) the 68EC020 clears and the board is fully seated. So I tacked it in place on two pins to test the theory and sure enough it
no longer fouls on the top of the oscillator. So all that's left to do is simply solder it back in place. Basically it just needed to be
re-positioned about 1mm so it cleared. I did a quick test after and now it's working perfectly :-)
I'm still looking for other random Amiga power supplies to make schematics and some parts from a not-working 1084S monitor as per the post below.
If anyone wants to assist please contact me. See the post below for the details.
13th March 2017
I've been busy over the last 3-4 weeks doing a lot of Commodore repairs that came in.
Here's a quick run down of the problems and what was done.
Commodore 64 faulty power switch repair
Very common problem, the switch works sometimes and sometimes not. Easy to fix, just replace the switch. Problem is we're about 30 years too late
to buy the parts now. I found a similar switch online and bought it hoping it would be a simple drop-in replacement. It almost is, but the plastic rocker
was too big. Luckily the design is similar and the plastic rocker can be swapped with the original one and fits ok. So I swapped
everything over, inserted the switch into the PCB then errr, it didn't push down fully. I got out my trusty hacksaw and chopped off the bottom part
of the bracket which isn't needed anyway and now it fits perfect. Soldered it in and it's working fine.
Commodore 1084S-P monitor repair
It was just making a whining sound and the power light was off. That's a classic sign of an internally shorted flyback. Luckily, replacement
reverse-engineered flybacks for *some* monitors are still available from a company called HRDiemen. I pulled the flyback out, ordered a new
one from a local distributer, soldered it back in, adjusted all the various potentiometers etc and it's working just fine now. One word of
caution regarding these replacement flybacks, I have bought many of them over the years and every one has been shipped with the screen
control pot turned up full. That basically over-volts the neck board and tube RGB guns by 2 to 3 times and can blow up the neck board or
tube or both. If you fit one of these new flybacks, be sure to turn the screen control pot all the way down (maximum turn counter-clockwise)
then adjust it as required.
Commodore Amiga 600 repair (and rant about caps)
This had a fault where it would take about 10 minutes to power on. After that it would work fine until powered off, where it would then take
another 10 minutes to boot-up again. That usually means bad capacitors. Sure enough when looking around there was leaky caps in the reset
section and some corrosion. When it did work the sound was strange too. If you check the first photo (below) you can see the crud build-up on
the SMD op-amp chip, which explains at least part of the sound issue (more on that later). First thing to do is remove all the affected
parts, then clean up the PCB, check for track damage (there wasn't any) then replace all the parts with new parts. The owner had previously
bought a cap kit from a popular Amiga part supplier in UK (ending in 'kit') but was not confident enough to do the job himself so he
provided that to me so I could swap over all the caps. I replaced the first two bad caps in the affected area and the other things such as
SMD resistors/caps/transistors etc and the op-amp IC, powered on but that didn't fix the booting issue. The sound issue appeared to be
slightly better but still not right. I then consulted the schematic and found that the section that was damaged is actually the
amplification circuit. Well at least that should be fixed now hehe! The reset IC (LM555) is tied to a smaller electrolytic 10uf cap so I
changed that and it vastly improved the power-on time from 10 minutes to about 1 minute. An improvement sure, but not good enough! The Amiga
should of course power on instantly. When it was working, I also noticed the sound on the left side of the monitor was lower in volume than
the other side. That is generally a cap problem too with the caps connected to the outputs near the RCA jacks. So then I proceeded to
replace the remaining caps on the board since I had the cap kit anyway. After replacing all the electrolytic caps I noticed the sound
problem was solved but the computer was still not booting up immediately like it should be doing. It also sometimes would not see the HDD. I
checked the 44-pin HDD connector and found a couple of loose pins. The connector was damaged so I have ordered one to replace it (currently
waiting for it to arrive). With my logic probe I could see the output on the reset chip was not firing. I checked the schematic again and
noted there are a number of SMD parts in the reset section connected to the 555 timer, located on the top side and bottom side of the
I pulled each part and tested them and they were all OK. The only part I had not checked was the "new" 10uf electrolytic cap at
location C612 that I had replaced from the cap kit. So I pulled the cap and tested it and found it to have an ESR reading of 4.2ohms. That
is WAY too high for a cap in the reset section, about 3-4 times out-of-spec for the 10uf 35v cap which was supplied. I grabbed a quality
Matsushita/Panasonic high temp low ESR "FR" range cap from my spare parts stock (which is basically the highest specification cap available
from that company), swapped that over then powered on and BAM! it powered on immediately. Problem solved! So the moral of this story is use
only low ESR caps in the reset section and beware of companies/people who sell cheap cap kits. Cheap as in "cheap caps", not cheap as in
"cheap price". The cap kit provided was certainly not a cheap price but the caps are definitely cheap Chinese crap caps. Always buy quality
Japanese electrolytic caps when working on repairs of expensive or uncommon electronics, otherwise you'll be sorry. There are really only a
few that are guaranteed for 10+ years and they are all made in Japan. Most of them will last 30+ years. They are made by Nichicon, United
Chemi-con, Matsushita/Panasonic, Rubycon and a few others. If you are interested, you can google 'bad caps' and read all about cheap
rubbishy caps that have become famous on sites like badcaps.net so you can avoid them! Unfortunately that site now requires an account to
view forum posts so I can't recommend it. There is another site that has a full list of every brand with photos and info at
http://capacitor.web.fc2.com. This site allows you to identify the brand of any cap (including cheap caps). The site is in Japanese but you
can use google translate or the Chrome browser to auto-translate it. The site is *very* informative so it is worth the effort to do some
Do yourself a favor, when buying electrolytic caps for quality electronic equipment, only get them from official channels like Mouser,
Digikey, Element14, RS etc and choose the quality Japanese brands (they usually sell several other brands too). You will also save money
because other companies and sellers just buy them from places like that (usually selecting the cheapest brand they can get away with), mark
them up and re-sell them for a profit. Otherwise you're probably buying cheap Chinese caps that will fail in a year or two and possibly
damage your rare collectable equipment. Those companies and individuals are only there to make money and will do whatever it takes to save a
few bucks. To give you an idea, a cheap cap costs 10c, the good quality version costs 65c. That's a difference of 55c. That may not sound
like much to you and me, but in quantites of 1000 it's an extra $550, and of course they are there to make money so they cheap out and use
crappy caps. Don't buy them from eBay either because the Chinese cap companies have copied all of the brands and sell them as genuine good
caps when in fact they are cheap copies with the same branding marks!
If you do want to buy a cap kit ask the seller what brand caps it has. If they are reluctant to tell you or they don't know or they just say
they are using the best quality caps available, it's almost certain they are using cheap caps. If you have caps already and want to know if
your cap is good use an ESR meter to test it (available on ebay for a small price), then refer to the standard ESR charts floating around
the net to see if the cap is good or bad. The uF reading should be within +-5% of the number printed on the capacitor and the ESR should be
within the specification on the chart. The actual ESR depends on the voltage rating of the capactitor and the uF so you need to refer to the
chart to know if it's good or bad. Only use caps within specification and toss out-of-spec caps in the bin where they belong. The Amiga
deserves only the best and only Amiga makes it possible!
Commodore CBM 4016 repair
This one took a few weeks to figure out. It would boot up and work, but then lock up at some random time. Sometimes it would run for 3
minutes, or 30 minutes, or 3 hours. If I powered off then on it would work again perfectly for some random amount of time. Sometimes when it
crashed it would drop out to the built-in machine code monitor. Other times while running a simple basic program it would stop with a
"syntax error" and just one character had been changed to a 4x4 checkerboard pattern symbol. After fixing the error in the program it would run again until
it crashed again later. It was crazy! When it ran long enough to run a software RAM test, it didn't find any errors. The voltages were ok so
it wasn't a power supply issue. The board was really gross too. Some idiot had sprayed silicon spray all over the board and it was a really
nasty slippery slimy thing to work on. The first thing to do was clean it up so I removed all of the socketed chips and gave it a bath
in soapy water, rinsed in clean water then dried it off outside in the sun for 1 whole day. After that I replaced all of the old MOS mask
ROMs with EPROMs (2532 are directly 1:1 compatible) and changed all of the 37 year old single-wipe sockets for new dual wipe sockets
including all of the larger 40 pin sockets. Removing the sockets also meant I could clean the crud off the board under the socket too.
Changing the ROMs & sockets didn't help but one of the ROMs was unknown and undumped!! It was the editor ROM for a 50Hz, graphic keyboard,
80 column type PET which is not available on the net. I promptly sent that to the master PET ROM archive at zimmers.net for safe keeping :-)
Next step was to change all of the 4116 DRAMs. They are also 37 years old and I figured at least one of them was bad or soon will go bad so I
ordered 16 new (old stock) DRAMs and new dual-wipe sockets and just replaced everything. I wanted it to be stable and reliable for many
years to come so there's really not much point trying to diagnose if one or two RAMs are bad, better to just change it all and be done with
it. While doing that I realized that this machine was a 16k, 80 column board which had been upgraded to 32k by someone who was not very good with desoldering
parts and had damaged the board under the chips. That explains the amateurish patch wire the size of fence wire on the bottom side of the board under
the RAMs! With all of the RAM removed I traced all of the RAM tracks and found no other track damage. Even after changing all of the RAMs it
still wasn't working properly but with all of that changed at least now I knew the problem was not ROM or RAM related.
I powered it on the next day and it was totally dead! After testing some things I realised the syncs on the 6845 were missing. The input
clock was there but no syncs, and since they are outputs it had to be a bad 6845. I changed it and the computer sprung back to life with the same
fault as before. So the 6845 just died on me in the middle of the repair!
All of the caps were 37 years old too, so the next thing was to replace all of the caps. Still no improvement on the actual lock-up issue so
I figured I had a logic problem. Over the course of about another week I slowly checked each chip but it wasn't an easy task because most of
the time it was working and when it locked up everything would stop. Powering off/on would make it work again perfectly for some random
amount of time. In the end I consulted the schems and started just changing all the logic in the memory control section since that too was
all 37 years old. In reality it needed all of the logic replacing but that was a huge job. After replacing about 1/2 of the logic the whole
thing just died again and this time it was permanent. There were no clocks anywhere (not even on the CPU) but the main crystal was ok. Most
of the time it wouldn't boot at all but when it did (once in dozens of power-ups) it locked-up within 1 second and the monitor would make really
bad noises like it was out of sync and receiving the wrong frequency. That allowed me to narrow down the search to the clock generation
circuit. I eventually found the bad chip, a 74LS164 at location UE3. I tested it in my IC tester and it failed. After
replacing that chip it fired up immediately and continued to work for the rest of the day without any issues so I knew it was fixed 100% :-
I wanted to see if the PET experience could be better so I looked around on the net and found a replacement ROM that has been reverse
engineered from the original ROM with additional features. These include Escape key sequences, a soft reset (like CTRL-ALT-DEL on a pc), a
DOS Wedge and a 40/80 column soft switch mode. I burned a new EPROM, fitted it and it had some issues so I contacted the maintainer and he promptly fixed the
problems and sent me a new binary and it worked great! If you have a PET and are interested in adding more features like I mentioned above
check out the site here
Commodore Amiga Power Supply 391029-05 Repair
This is one of the myriad of Amiga power supplies made by Commodore, model 391029-05 and is one of the light switch-mode power supplies.
When powered on it appeared to be working but when powered off it would make a whining sound that would get lower in tone over about 5
seconds before stopping completely. I suspected the caps so I opened it up and found several bad caps that had bulged and leaked. They had
also leaked through to the bottom side of the PCB causing some corrosion. I removed all of the caps, cleaned up the board and replaced all
of them with good new caps. The noise issue was still there but for only 1/4 of a second so I figured it was normal. I believe the noise is
the switching transistor trying to run but because the AC has been turned off, the large filter cap drains quickly and makes some noise via
the transformer winding. I don't know if that was by design or not, but it's actually a good thing because the big filter cap is totally
discharged. I measured it after running it for a while then powering off and the big filter cap had no charge in it. In any case the tiny
1/4 second noise is not a fault. I've heard a similar sound when turning off some electrical appliances. I tested the output voltages and
found there were none! After about 2 minutes the voltages measured ok! So there was a delay in the power supply starting up. But it couldn't
be caps because I just changed them all with exactly the same values that were in there. Or could it? I checked an identical Amiga power
supply and found that some of the caps were a different value! I changed them for the other type and it fired up immediately. I checked the
caps I removed and they measured OK so they were just the wrong value and likely changed by some amateur years ago. At that point I was
curious what the caps did so I went looking for a schematic of this power supply on the net and found nothing. So then I looked for *any*
Amiga power supply schematic and found nothing! That just isn't right so I decided to reverse this one and make a schematic of it to see how
it works. After a few days it was done. Below is the schematic for this power supply (391029-05) which I am making available for the benefit
of the Amiga community. The schematic might look a little bit strange but that is by design. The PCB has no component locations or markings
so it makes it difficult to reference components between the schematic and PCB. The schematic is drawn using the same track layout as the
PCB, but viewed from above. Think of the PCB as being transparent and you can see the tracks below. That way you can look at the components
on the PCB and immediately know where to find them on the schematic. It is also drawn on an A0 sheet because I really hate multi-page
schematics. If you have ever tried to fault-find an Amiga motherboard using the available Commodore schematics you will know how much of a
pain it is to look through 18 pages trying to find a signal only to find it then goes off somewhere else and then you have to find that
signal, then off somewhere else etc etc etc. Drawing it on one very large sheet solves that problem. In today's computing world, multi-page
schematics are really a thing of the past in my opinion. For those who are curious, the schematic was drawn using Altium Designer version
It would be good to continue to make more Amiga power supply schematics but the other versions are not available to me here. If you are
reading this and want to help, you can. If you have any of the other versions of the Amiga power supplies (heavy or light versions, dead or
alive) or any other Amiga hardware that doesn't have any schematics available and you would like to see them reverse-engineered so a
schematic can be created and made publicly available, contact me. Even if you can't help directly, you could
help by informing other Amiga users on any of the Amiga forums and similar places so that my request gets out there. You can also help by
simply donating via Paypal or donating any other unwanted Amiga or Commodore hardware. Hopefully I will be able to get hold of more Amiga
power supplies (or other hardware without schematics) and make schematics for all of them. That will benefit everyone who owns a real Amiga
so they can continue to live on! :-)
I'm also looking for a yoke from a 1084 or 1084S or 1084S-P or 1084S-P1 monitor (or possibly a 1081 may also fit). Basically any of the
models made by Philips should work ok.
I was given a dead and rusted 1084S-P1 a while ago. The chassis repair took a long time to fix because of all the corrosion but now works
fine. The repair will be shown in a future news post. Unfortunately the yoke is shorted and corroded so it's currently still unusable. If you
have any faulty/not-working Commodore monitors and you want to part out some pieces please contact me.
21st February 2017
Some more decapping news! My Sega Model 1 DSP's were decapped and the ROMs have been successfully extracted. More news on the CAPS0ff blog. Please support CAPS0ff with funds if you can so more chips can be decapped.
Those chips have also been marked green on my Decapping Status Page
16th February 2017
I redumped Gallop Racer 2 and now it's working in MAME. Here's a few screenshots....
This next pic shows the PCB in the Mother-Load that is shown on 15th July 2016.....
26th January 2017
At my request, CAPSoff has decided to consider decapping chips that are still sitting here in my Guru Lair or other chips that may be
acquired in the future.
Because of the costs involved with decapping and processing chips, to do all of the current chips and any future ones that come along, they would
like to get some support from the emulation community in order to keep the project moving forward. You can
read about it on their blog here.
They also recently did some decapping work on some PIC16C57 chips and you can see their blog entry about that here.
7th January 2017
A few years ago around the middle of 2009 I received some items for decapping. Technically they were not really needed but they were sent anyway.
However this was an extreme case of severe butcherism because the chips were received like this.....
The PCB was also sent, minus most of it's chips!
Clearly this was scrap, or so I initially thought, so I basically tossed it on my pile of junk and it sat there for several years.
We all now know that the chips were not really needed for decapping because the emulation is working fine thanks to fantastic reverse-engineering
work by Bryan McPhail. It always disturbed me that this PCB was treated so badly and was scrapped for no good reason. Recently I came across it
while looking for some other stuff and I decided to make an attempt to resurrect it to it's former glory.
The first thing was to determine if all the chips I needed were available. After a bit of searching I found all of the custom chips except
the HuC6280, but I had a couple of spare chips lying around so I had that missing chip in stock. There were several other chips missing including
several SMD logic chips, a YM2151 sound chip, a few SMD capacitors, an electrolytic capacitor that feeds the reset circuit and a DIP8 EEPROM.
And of course all of the ROMs were also missing. I had all of those parts either in my parts bin or on some scrap PCBs and the ROMs can
easily be replaced with EPROMs so the re-assembly work could begin!
The next step was to clean all the old solder off the PCB pads where the missing chips were. It was a pure miracle that the fragile solder
pads were not broken or ripped off the board by the idiot who did all this damage. It's an easy job to remove solder so after an hour that
part was done.
Now came the really tedious and boring part.... I had to bend all of the legs on every custom chip back to where they
were supposed to be *very carefully*, hoping the legs were (a) all present and (b) didn't break off as I manipulated them. After many hours
(about 1 hour per chip) the job was done and everything looked as good as it could get... not perfect but very close.
Now to start mounting the chips. I started with the logic chips, capacitors and other smaller parts then moved onto the custom chips. One by
one they were soldered into place. Because the chips were not perfectly straight and flat within 0.1mm (the normal tolerance) I had to mount
each leg one by one (close to 800 legs!). I couldn't do the usual drag soldering method and mount the chip quickly. Every leg had to be held
in place carefully in line with the PCB pad and then heated with the soldering iron to make it stay there. Because I worked in
engineering for 30 years I have developed special tools to help with that kind of task so it went fairly smoothly. After many many hours
(maybe 24 hours across about 3-4 days) everything was in place and it was time to power on and see if it was alive.
The first screen I saw was full of garbage tiles so I thought it was not working, but looking closely at the screen I could see some white
text among the pink, blue, white and purple mess that read..... "WARNING GAME MODE SETTING ERROR"
By luck probing around, I accidentally shorted two pins on a logic chip near the CPU and to my amazement it booted into the game! The
backgrounds were scrambled but it was running! The title screen graphic "Fighter's History" was there but the "Copyright Data East 1993"
text was also scrambled, mostly just random dots. Most of the initial Data East logo first boot screen was also OK but some sections were
out of position. All of the sprites were OK. The game was playable (i.e. controls were working so I assumed the custom I/O chip was OK) and
sound was working too. Things were starting to look very promising!
I figured some legs on the custom chips were loose so I went around every chip and checked them and found a couple of loose legs. The
graphics were improved slightly but it was still not fixed so I started looking closer at the bottom of the PCB. Because this board had been
attacked with a heatgun there were many solder blobs on the board where the solder in the vias had come out of the hole (because it was
boiled) and was sitting on the PCB surface as a little solder ball. You can see some of the little balls in the 11th pic shown above (the
PCB pic with the blue resitor array pack). There were dozens and dozens of those little balls all over the PCB top and bottom. This
particular PCB has vias that are *really* close together and some of the solder balls were causing shorts. I cleared most of them before I started
soldering the custom chips on but missed a few. After clearing some more blobs it improved a bit more. The corruption seemed to change
slightly with each re-boot. I checked a few logic chips connected to the 56 and 74 chips (used for generating the backgrounds) and found a
74F373 SMD logic chip that was a bit random. I pulled the chip and tested it and found it passed the test only about 50% of the time so it
was faulty. This was probably the original fault as I'm guessing this board came off ebay. After changing it the graphics were no better but
at least now the corruption was consistent.
The pic above shows the backgrounds are now partly correct.
At this point I needed to get some confirmation about a few things so I contacted Bryan to get his opinion. MAME is really great for playing
games but there's very little real world repair info in MAME (aside from my Guru-Readme's hehe!) to help with problems like this. At least
not for the average person who doesn't understand the deep down guts of the code and how it works. He told me the bootup warning error means there is a
problem with the 93C45 EEPROM and the graphics fault was likely shorted or loose pins on the background graphics chips. In this case that's
chip 56 and/or 74.
On a regular board a bad line will usually give a solid bad line/jailbar on the graphics. But on Fighter's History the graphics chip uses
a form of encryption that mixes up all the bits within a 4K block or something so they aren't stored linearly. This means that a bad line
can cause the addressing to go completely wrong over the whole block so everything appears completely scrambled. So it could just be 1 bad
line causing the problems.
I had a look at the EEPROM problem first. After checking I realized what was wrong. Urgghh! I had used a 93C46 EEPROM and it should be a 93C45
EEPROM. They are sometimes compatible depending on how they are configured. In this case the 93C45 EEPROM is fixed at 64 bits x 16-bit and a 93C46
can be configured to either 128 bits x 8-bit or 64 bits x 16-bit when a specific pin is held high or low. That pin was not set because the 93C45
doesn't have that option so it was the wrong chip. After finding a 93C45 EEPROM in my parts bin and changing it the fault went away and the game booted
up fine. Of course that didn't fix my graphic problems.
I went around the graphics chips again even more carefully than last time and found a micro-hair of solder shorting 2 pins together. I
cleared that which improved the colors slightly. Then realizing there was nothing else to look at (all chips were mounted 100%), I double checked
the bottom side just in case there was another solder blob causing a short. Sure enough I found one. After clearing that it booted up and was 100% fixed!
Success at last!!
All cleaned up and ready to go. WOW! What an amazing transformation! :-)
So after reading all of this you're probably wondering who the butcher is, right? Well, normally I would not mention that because this was
sent for a useful purpose. But of course if you have been reading these pages for some time you will know I take great pleasure in giving
assholes who have screwed me over in the past their just desserts. This is no exception. The funny part is he can't even deny it. It's
documented ALL over the internet and a simple
google search will reveal the truth of who this horrendous butcher is. Hahahahah!!!
All I can say is if you value your undumped board DO NOT send it to him for dumping!
At least this ended well because it was sent to someone who could properly take care of it (i.e. me!) and now I can sell this board on my
Items For Sale page :-)
So now with all the excitement over I can use the working PCB to discover something useful for MAME..... I noticed recently a small change
to MAME relating to the volume chip used on these Data East boards. Unfortunately no one has documented exactly what chip is used for the
electronic volume control so the change is just guess work. The real PCB does not have a volume pot on it and volume is
adjusted in the test mode electronically. So I had a look, did a bit of research and identified the chip pretty quickly.
The Fighter's History PCB (and others like Night Slashers etc) use a Mitsubishi M5222FP Voltage Controlled Amplifier (VCA) in a tiny SOIC8
package which is used for the electronic volume control. You can see that in the above pic just near the group of larger electrolytic
capacitors. For those curious about the chip the datasheet is here.