15th May 2020
I finally got some real arcade controls hooked up to my Dirt Dash PCB (except brake which is just a 5k pot wired up so I have no brake in the
game... it's always off). Here's the full attract loop and game play run through all of the tracks. The general idea is this is a reference
video to help improve MAME emulation.
Youtube isn't the best venue for quality videos and the game runs at 15kHz interlaced which makes it not so easy to video either but I
suppose it's better than nothing. I got the frame rate right though... notice how the video is solid, not having the usual dark horizontal
band moving vertically down the screen... that's because when I set my camera to 25p for some reason it syncs perfectly. It might also
have something to do with the power frequency here which is 50Hz. My camera is a Nikon Coolpix B700 which can do up to 20MP pics and 25p, 50p, 60p and 4K video so
I may experiment with other rates later.
One thing that is not so obvious in the video is the shadow under the cars is actually multiple horizontal lines separated by a small grey
space. It is not just a flickering solid box like in MAME, although it does flicker but not all the time. It's not the easiest thing to
photograph either ;-)
In the 2nd video on the right I go through all of the screens in the test mode.
One thing that doesn't show up is a calibration screen. This can be accessed by holding 'service credit' and pressing the test button....
If you are trying to calibrate PC controls for use with MAME and your controls don't work by default or are erratic, you probably need to go
into the TAB menu then 'Analog Controls' and check to see if your controls are actually working. If not you probably need to enable them by
changing the controls in mame.ini in the 'Core Input Options' section and add 'joystick' for 'paddle_device', 'pedal_device', 'dial_device'
& 'positional_device'. By default MAME has the wheel set to 'mouse' and the analog gas and pedal controls are n/a. When 'joystick' is added
in mame.ini the analog controls will change to the joystick axes but they may not be the correct axes and it's likely they won't be properly
calibrated for the game.
You must go into the TAB menu then 'Input (This Machine)' and re-set the control axes for steering wheel and gas and brake pedals to use the
correct wheel/gas/pedal axes by selecting the item with the cursor then pressing enter and then moving the control you want to re-set. Once
that is done, go into the game and while pressing SERVICE CREDIT (i.e. 9 on keyboard) press TEST (F2 on keyboard). If you did it right you
will see the calibration screen, if not, while holding those keys also press reset (F3 on keyboard). With all controls at default positions
and untouched and with the steering wheel centered press SERVICE CREDIT and an offset bias will be applied to the controls so they are fully
calibrated. They are correct when the number on the far right (VALUE) is close to zero. Note on my real PCB the value sometimes moves
slightly up and down about 0001 but that is normal. Press F2 to set test mode off and now the controls should work.
Note my board has a small gfx glitch at the top of the high score screen that wasn't there a couple of days ago. Sadly it seems common that
these boards develop random graphic faults due to 25 year old mask ROMs going bad and the only way to fix it is to replace them with an
equivalent flash ROM. Fortunately I dumped all the Namco Super System 22 games and the ROMs are available so that's not a big problem
10th May 2020
A few weeks ago I noticed some ROMs in Namco's Dirt Dash had been flagged as bad. After re-checking my PCB it turned out my PCB had the same
fault so there wasn't much I could do since one of the ROMs was internally bad. A couple of days ago I got hold of a different version of
the same game and dumped the ROMs. After comparing, only one gfx ROM was different. As well as getting a good dump of the Dirt Dash
graphics ROMs, as a bonus we get the Japan version of Dirt Dash :-D
I was also playing around with TX1 in MAME. It has the potential to be a great game but the controls are horribly broken. While the game is
normally very hard, in MAME the game is impossible to control and the car is always spinning off the track or has a hard wheel lock to the
left or right. This is because of a tiny bug in the way the controls were configured. While both the gas and brake values go from 0x00 to
0x0F, the steering should go from 0x00 to 0xFF. Even in the manual it says the wheel movement goes from 00-FF. In MAME it was set to 0x0F so
it could only move in large steps. Simply changing the wheel to have the full 00-FF movement gives the car more turning steps (256 instead
of 16) and thus smoother animation which makes the game a lot easier. Although even with this fix, as I said it's still a very hard game but
maybe now with a real 360 degrees steering wheel it might be possible to get further than the 1st road split haha! I'm watching out for a
youtube video where someone gives it a try :-)
Anyway, both of these changes should hit MAME 0.221 at the end of this month, or you can download the src from Github and compile your own.
With some 3rd-party artwork TX1 looks fantastic and now with the controls fix it might even be playable too! ;-)
In other news recently, on the 3rd May 2020, after a long hiatus the lamer page got a small update LOL!
27th April 2020
I've been working on something completely different for a few days. Here's a quick work-in-progress demo of it in action.
Look closely at the bottom right corner of the emulation screen and you can see an arm.... :-)
This game has never been really fully playable in MAME, even now. The controls are completely broken and implimented as a dial without any
limits so it wraps, which is competely wrong. Basically the arm/motor emulation that was 'fixed' at MAME 0.104u3 is a big hack. As far as I know it was never possible to win any match... until now ;-)
To improve the emulation some info is needed from the real arcade cabinet.
If you have a working Arm Champs II arcade cab or know someone who does, go into the test mode and then to I/O Port Check and look at Arm
Volume. I need to know the range of the Arm Volume when at the left and right limit switches and the middle limit switch.
Also, I need a description of the arm movement at the motor test check when the game is powered on. Thanks!
6th April 2020
Here's a repair log for some stuff I've been working on recently.
First one is a bootleg Terra Cresta PCB that was not working. As usual it sat on the pile of non-working
crap for a few years. This is the nice YM3526 version with better sound and is virtually a 1:1 directly
copy of the original Nichibutsu version.
Initially it was dead.
Looking at the top board I noticed the 68000 pin 32 was hacked. I pulled out the 68000 and verified that pin 32 was broken. Normally I would
replace the entire socket but I did not have a proper DIP64 socket in stock (obviously the bootleggers didn't have one either hahaha!!) and
despite how hacky it looked, the existing socket was mostly ok so I just pulled out the old hacked socket pin and replaced it with a new pin
taken from another socket, then replaced the 68000 with one that has all 64 pins ^_^
That did not get the board working so I pulled the program ROMs to check them and found that all of the ROMs and sockets were rusted. I
cleaned the ROMs with some fine sandpaper but the sockets were too far gone so I replaced all of the ROM sockets on the top board. The game
now booted up. The background graphics and sounds were good but all of the sprites were partially missing, showing only random pieces of
sprites on screen.
The sprites are generated on the bottom board. The sprite ROMs tested ok. There are 8x 2148 RAMs for the sprites so of course I started
looking at the RAM but I didn't find any issues, although they were running very hot. Piggybacking another RAM on top didn't help so I
pulled and tested all the RAM but they were not faulty, so I added sockets and replaced them back on the board. The rest of the board looked
ok and there were no easy 'Dead Fujitsu' chips on the board so I decided to take a break and leave it for a day.
The next day when I powered it on the game worked perfectly!! But after a few minutes the sprites started to fade slowly and after 5 minutes
there were only random pieces of sprite showing on screen. After spending several days slowly checking every logic chip I found no problems....
very frustrating! The board seemed to have a heat-related issue so I used some freeze-spray on various chips on the board while the game was
running but it didn't make any difference.
I decided to take extreme measures and put the whole boardset into the freezer for 5 minutes. Then I plugged it into the power and to my
amazement it again worked perfectly! Note don't run the board like this for too long because the coldness will turn into water droplets on
the board as condensation takes place... so just a quick test is all that is necessary. I figured the fault was on the lower board since
that is where the sprites are generated so this time I put only the lower board in the freezer. After 5 minutes I pulled it out, plugged in
the lower board and powered on and the sprites were still bad! That means the fault must be on the top board. I tested the theory by putting
the top board in the freezer for 5 minutes then repeating the quick power up and as predicted the sprites came back to normal. I let the
board dry then ran it again for longer and after 5 minutes the sprites were flakey again. Now was the time to check every logic chip on the top
board with the freeze spray, but amazingly it made no difference. The strange thing was none of the logic chips were getting hot so the
faulty chip is going to be tricky to find because it works when cold and when it goes bad it only partially fails. This is the worst kind of
fault and is best checked using an oscilloscope. But I was impatient and didn't want to waste time scoping out potentially dozens of logic chips.
I put the board in the freezer again to 'fix' the sprites. Then plugged it in and powered up the game board, and while cold, used my heatgun to warm up the board. When I hit the
top right corner of the board the sprites started to glitch out but that was only after I had heated the board a lot.
I used my multimeter to trace the output circuit from the lower board through the 50 pin flat cable and found that it came onto the top board through
4x 74LS174 Motorola branded logic chips which just happened to be located in the top right corner of the top board :-D
On the scope the outputs didn't look bad, but to be sure I pulled all 4 chips and tested them out of circuit and they passed the test!
Urgghh! Now you would think... 'ok, just put them back and keep going'. No no. With this kind of strange fault, the chips work when they
are cold and there's actually no way to test that situation except maybe using a heatgun to warm up the chips and re-test when hot. But
there's an easier way. I learned a long time ago when faced with this problem to replace the chips with different chips ^_^
So I found some 74LS174 chips on a scrap board and replaced those chips. I powered on and got this.....
Obviously at least one of the 74LS174 chips was suspect but it's time to move on. I played the game for about 20 minutes and everything was still ok so I'm calling it fixed :-D
Second one is a quickie :-)
This is a Sega Repulse bootleg that was dead. On the top board, the Z80 reset signal was missing. I replaced a broken electrolytic capacitor in the reset
circuit and now the reset was happening but the reset was not getting to the Z80. The first chip in the line is our unfriendly enemy, the
nasty 74LS04 Fujitsu logic chip! I checked the inputs and outputs with my logic probe and of course the outputs were all dead. I replaced that chip
and then the game booted up. It had other faults in-game and the lower board was littered with nasty Fujitsu logic chips. The fix is probably as
simple as removing the Fujitsu logic chips and replacing them with good chips. At this point someone wanted the board so I gave it away and this
is now his problem ;-)
The third and final board in this log was relatively easy just tedious and time consuming.
This is a bootleg Twin Cobra that works but has big sprite problems.
Looks like it was stored in a damp place for a long time and some traces are corroded and broken under the RAM. Removing the RAMs reveals the carnage...
There were 7 broken traces. I patched the traces neatly and directly on the PCB using micro wire and then put the RAMs in sockets. The board
now works fine and from just looking at it you can't tell it was repaired :-D
12th March 2020
I've had this for a while but since a few people sent it to me, here it is.... My Google Drive Shared ROMS Link
This link is also added to my main menu under 'Guru Misc'.
As well as the previously mentioned Sonic Bros, you can also get OOParts. It is a prototype Arkanoid rip-off made by
Success that also runs on Sega C2 hardware. This is not supported in MAME and may never be due to arcade scene hoarders
not wanting their secret prototypes in MAME and having a pissing contest with the rest of the scene and desperately
trying to hold onto the crown of 'King Pisser' (and failing), but you can run it as 'tantr' and it works fine. To make
it easy I've already renamed the ROMs inside the zip and named the zip so you can see it is ooparts running as tantr.
Just download the zip and rename the file to tantr.zip and then run 'mame tantr'.... problem solved....
23rd February 2020
I picked up a fairly rare Sega System 32 ROM board called 'Soreike Kokology'. In MAME 'Soreike Kokology Vol.2' is dumped but not the original. I have dumped it and it will be added to MAME soon.
10th February 2020
Something priceless just arrived....no words needed ^_^
19th December 2019
CAPS0ff has been busy decapping some of my Semicom 87C52 MCUs and as a result the Decapping Page was updated several times over the
last few days. If this continues, there should be at least 3 more 87C52 MCUs decapped relatively soon-ish :-)
Please support CAPS0ff with funds if you can so they can work on some of the more difficult decapping jobs that are waiting in line.
10th October 2019
Continuing with the Commando repair, there were no additional issues on the bottom board and the game was fully playable after swapping out
those 5 bad logic chips I mentioned previously. The only remaining issue is no sound. There are no Fujitsu logic chips on the top board now
so it can't be that. The Z80 has the clock and reset but there is no activity on several pins of the Z80. Nor is there activity on the ROM
or RAM. The ROM was read and checked good against the MAME ROM set. The RAM was the next suspect. I swapped out the RAM and it didn't help,
but I was not able to test the RAM. Luckily I added a socket for the RAM so I tried another RAM and it still didn't work but it was slightly
different and started making some random noise. I went through about 10 different 2016/6116 RAMs and then eventually the Z80 came alive and
became active. Strange that so many RAMs did not work, but maybe this board is fussy about the brand of RAM or something. Coining up showed
additional activity on the Z80 so the sound program was now running but there was still no sound output! I touched the amp with my finger
and it made the normal 'pop' sound so the amp was ok. I also touched the input pins of the 2x YM3014 and LM324 chips with a wire connected
to ground and the speaker also popped, meaning the YM3014 and LM324 chips were also ok. I checked the output of the YM2203 chips on pins 22
and 23 and didn't see anything on my logic probe. This is normal for digital sound chips. I probed the same pins with my oscilloscope and
there was no activity. Then I tried a different working game that uses a YM2203 chip and there was activity on the oscilloscope on pin 22
and 23. So now I knew what a working chip looked like on the scope, I went back and re-checked the chip on the Commando board and
it was definitely not outputting anything. I decided to piggy-back the YM2203 and to my surprise I heard sound. I was very scratchy and
noisy but definitely sounded like the sounds from Commando. I pulled the chip and swapped over a working YM2203 chip and sound was fully
And here's a quick video of the game running and me (badly) playing it sideways on my test rig....
5th October 2019
Getting back to the Commando repair, while diagnosing the rest of the faults the entire thing just died and now displays nothing on screen.
There is no clock on the CPU. If you check the CPU page on the schematics in the previous repair log, you will see this clock comes from the
74LS367 at 8K (Ø MAIN) then to page 6/8 (Characters, also shown in previous log) through a 74LS32 at 5H which was checked as good in the last repair
log. The input on pin 4 of the 74LS32 is shown as ØB which comes from page 5/8 titled 'Synchronous' which is shown below....
The ØB signal is coming from a 74LS367 pin 9 at 3K. The input of that is pin 10 which goes to a 74LS74 at 2M and then to a 74LS04 at 2N. Look
closely and you can see the 12MHz crystal is connected to the 74LS04 and of course all of the outputs are dead. This is another bad Fujitsu
chip which needs to be replaced.
Changing it has brought back the clock on the CPU, but the board is still dead!
On the same schematic page there are 2x 74LS74 and 1x 74LS08 chips which are Fujitsu branded. I checked the inputs and outputs and they are
ok, but I changed them just to get rid of them. There was no change on screen.
At this stage it gets more difficult because the PCB is slightly different on the bottom right corner of the CPU board and that part is specific to the bootleg board so I don't have a schematic. Let's have a look at the chips there and figure it out....
In the bottom corner, the 74LS245 is connected to the CPU and the PAL. On the 74LS245, pin 19 is OE (Output Enable) and is active low. This
pin is high so the 74LS245 is not being enabled. At this stage I could trace out the PAL to LS245 wiring, but we have to be realistic about
spending an unknown amount of time chasing a rabbit down a hole. I have already changed many of the Fujitsu chips on the top board so more
than likely the fault is on the bottom board. I decided to swap out the lower board with another board I have here that is also faulty. To
my surprise the game now comes up! It is of course still not working 100% and has worse graphical faults than before but it does show
something on the screen so it looks like one or more Fujitsu chips that were working have now completely failed. I put the other faulty
bottom board back. Now I could go along and test the inputs and outputs of the same Fujitsu chips already identified as possibly faulty, but
I will do this a slightly different way. One technique to find a fault is to piggy-back a chip on top of a suspect chip and note if there is
any difference to the screen or the output pins on the chip. Whether it works or not depends on how the chip has failed. If it failed open
the piggy-back will usually improve it. If it failed shorted then the piggy-back usually won't help. I plugged a 74LS32 on top of the chip
at 6B and the game fired up again, back to the same faults as before. So the Fujitsu-branded 74LS32 at 6B just died.
Now I will show a technique to remove a chip without using expensive equipment like a powered desoldering gun. It is as simple as
snipping off the legs of the known faulty chip with fine-pointed side-cutters, then using a soldering iron and tweezers to remove the pins
one by one then sucking out the solder to clear the holes. Using the side-cutters, snip the legs at the top near the plastic package, and
remember NEVER do this to a chip that you think *might* be faulty if it is a custom chip, because snipping legs off a chip
destroys it beyond repair. Only do this when you know a chip is bad and it's a common off-the-shelf chip.
Here's some pics showing the tools used, some of the legs cut, then the plastic chip removed, the legs removed one by one with soldering iron
and tweezers and the holes cleared out with a manual solder sucker (i.e. the ghetto way to remove a bad chip). Notice how the PCB
looks like new because none of the solder-mask was scratched like when using a powered desoldering gun. One tip to improve the solder sucker
is to spray some light oil (WD40 etc) inside the tube then the sucker will suck faster creating more suction and improving the efficiency of
the manual solder sucker.
The last pic shows the game working but all sprites are missing. Now you can see how having a multi-stack board with cables joined only on
one side is a good thing. To access any board just flip up the board :-)
At this stage there's no point going over the lower board and showing checking the same 74LS00/04/08/32 Fujitsu chips that have already been
identified as bad since that info was shown in the first repair log. I will do that myself and come back when it is done.
In the next repair session I will continue with the remaining sound-related faults and if anything unusual happens on the lower board chip
swap I will document it here.
However I will leave you with a very large pic of 5 chips piggy-backed (marked with a red dot) and the effect it has on-screen ;-)
These chips are all Fujitsu branded. Locations are....
74LS04 at 9A and 1F
74LS32 at 8C and 9C
74LS00 at 8B
12th August 2019
I recently dumped an alternative bootleg version of Commando (a classic game by Capcom released in 1985). It uses a mix of ROMs from the
original PCB and other bootlegs, but one ROM was different. It was added to MAME yesterday as 'commandob3'. The PCB was sitting around on a
pile of junk for about 15 years in a non-working state but is actually in pretty good condition so I thought it would be interesting to fix
it. It should be relatively easy for a few reasons... it has no custom chips, the boards are joined with a single cable (you will see why
this is important later) and also because it uses several logic chips made by Fujitsu with date codes that are known to have failed. For a
change, I will make this into a basic repair tutorial for someone wanting to look into repairing an arcade PCB and has no experience. But
with a difference. Rather than just say I scoped this and that and replaced this and that like other people do, we will look in some detail
at how the chips work and use some inexpensive tools to help diagnose it. That way you might actually learn something and be able to repair
your own PCB or at least pique your interest to do so later. This is probably going to be quite long so sit back with a hot or cold drink
and read on....
Here's a pic of the board.....
Yes this is a bootleg and generally considered to be not worth much, but it's in great condition. If you just want to play some classic 80's
games in an arcade cabinet this is what you want. Well, hehe!! Actually for classic 80's and 90's games an X-in-1 is what you want or a MAME
PC, but if you want something that resembles the original hardware, a bootleg is the best way to achieve it. For example I used to have an
original Gyruss PCB but sold it while it was still working and later got a non-working bootleg PCB for nothing and fixed it relatively
easily. I doubt the original board is working now because it has several custom chips and is not easy to diagnose. More modern boards can be
a nightmare to fix due to having sometimes dozens of custom chips that may or may not have failed and you'll be tearing out your hair trying
to figure out what's wrong with it and after many wasted hours you will just give up. Bootlegs like this one use only common logic chips,
EPROMs, RAM etc so can always be fixed no matter what goes wrong with it. This bootleg is kind of unique among bootlegs because it has a
chip layout that matches exactly with the original board and doesn't use any of the plug-in daughter boards often found on bootlegs (a
common failure point is having bad connections between these plug-in boards and the socket on the main board). Even better, the original
schematics are available so we can use it to help with the repair.
The tools you will need are a soldering iron, solder, flux, side cutters, multi-meter and a logic probe (with 3 LEDs; low(green), high(red), memory/pulse/clock(yellow), and a piezo
speaker.... all of these features are required and important!). All of this stuff is available on eBay etc and this is the bare minimum if
you want to be successful at any PCB repairs. You can't fix anything electronic without these basic tools and I always laugh when I see
people on forums ask for help with an electronic problem but don't even have the basic diagnostic tools LOL! Well you may be able to do it
without the logic probe if the PCB is not a little computer like an arcade game, but as far as arcade games are concerned it will be much
more difficult without some way to 'see' the status of a chip and this is what the logic probe provides. You don't need an oscilloscope, and
in fact most people who think they need one to repair stuff don't really know how to use them anyway. We will use
the logic probe as the main diagnostic tool, together with the most important tool, our brain. Oh and a few senses too; sight, hearing and
touch... but not the other two. Sorry to disappoint but no, we are not going to be sniffing or licking any PCBs ;-)
When powering on the game it only shows a black screen. The first thing to do is check the clock and reset on the CPU. Commando uses a Z80
as the main CPU. Refer to the diagram below....
On a Z80, clock is pin 6 and reset is pin 26. Probing the clock with the logic probe shows that the yellow LED is flashing constantly. This
is the clock, so that means the 12MHz master crystal is OK and the logic that divides it is 'probably' OK. We have some kind of clock so we
are happy. To know the frequency you need a frequency counter or oscilloscope but let's assume the clock is OK. To check the reset, have the
PCB powered off, then position the logic probe on pin 26, then power on and observe what happens. The pin should be low for about 1/4 second
then go high. It does so the reset is OK. Some early CPU resets start high and go low, so be sure to check the datasheet for the proper
operation of the reset pin, but regardless there will be a clear transition from low to high or high to low. So while probing these pins I
noticed that the Z80 is very hot, almost too hot to touch. This probably happened when the game was left on for a long time in this non-working
state and high frequency rapid toggling inside the CPU destroyed it. I figured it is bad so I swapped out the CPU for a known good
chip. I also noticed a broken 10k resistor network near the main program ROMs so I changed that as well. When powering on it now shows
something on the screen....
At this stage I could just start changing out all the Fujitsu logic chips, but that would be too easy and you will learn nothing. In the
voice of Siegfried from 'Get Smart'... zis ist KAOS, zeir vill be no shotgunning here!
First let's have a look at the CPU page on the schematics.....
Thankfully this was scanned at 600DPI so it very readable. For the purposes of loading time the image has been reduced but the original pdf
is very nice and the pages are much larger. Click the thumbnail and then click the 'four-arrows' icon in the bottom corner of the image to
view it full size.
The circuit starts at the top left corner. The reset 'high' comes from the PST518. On a bootleg this is just a diode, a 4.7uF electrolytic cap and some resistors. The
signal travels through a cap which charges up then goes high after 1/4 second then to a 74LS14 at 11J and then to the Z80 pin 26. On the
right side of the Z80 there is a 74LS138 at 9J and then a 74LS08 at 9L. Looking on the PCB it can be seen that the 74LS14 and 74LS138 are
not Fujitsu chips but the 74LS08 at 9L is a Fujitsu chip! Looking at the rest of the PCB it can be seen that all of the LS00, LS04, LS08 and
LS32 chips are Fujitsu chips with date code '8502' or '8504' and there is a very high chance that all of them are bad. There are also a few
other random Fujitsu logic chips scattered across the board such as 74LS74 but these are not all exclusively made by Fujitsu and in any case
were made in 1983. I might look at those later. I think this Fujitsu issue affects most logic chips made between 1984 and 1985 at the very
least. These Fujitsu logic chips are rampant on Konami games from the mid 80's as well, in this case especially LS07 and LS253. But I have
seen failed Fujitsu chips as late as 1992 on (for example) Lethal Enforcers. So basically you can't trust any Fujitsu logic chip no matter
when it was made. I suppose that's why eventually they stopped making logic chips hehe! Thankfully these are all simple logic chips so easy
to check in-circuit. Let's start by looking at the LS08 at 9L. I have seen videos on YouTube where people probe logic chips with an
oscilloscope or logic probe on an old Commodore computer (C64 etc) and then announce that it looks OK. You can't just probe a logic chip and
know if it is good or bad, you must know what is expected on the outputs given the current inputs including which pins are inputs and which
pins are outputs, and to know that you must look at the datasheet. I like the old school 80's Texas Instruments datasheets because generally
everything I need to know is shown on the first page in a very clear and concise manner. One tip, if you plan to do a lot of logic repairs,
get hold of a real paper TI Logic Databook because it's a lot faster and nicer to look at real paper than looking at the pdf datasheet,
especially if the repair area is not near a PC. You can also access datasheets on a PC of course, or a tablet or phone. You can also
download the entire TI Logic Databook in PDF form and keep it for reference but be sure to get an older Databook as some info has been
removed from the first page for some reason. The older 80's Databooks are much nicer. Here's the datasheet for the LS08....
This is a Quadruple 2-Input Positive AND Gate. It sounds complicated but basically it just takes some inputs and ANDs them together and
outputs the result. This is known as 'Boolean Logic'. Some logic chips can be VERY complicated but this chip is very simple.
Referring to the pinout, there are four individual and separate sets of two inputs (A , B) and one output (Y). 1A & 1B pairs with 1Y, 2A &
2B pairs with 2Y and so on. The logic diagram on the datasheet shows how it looks when drawn on a schematic and if you look at the Commando
schematic you will see the same symbol for the LS08 at 9L (well it's nearly the same, there are variations on how symbols are drawn but it's
the same thing). It is shown four times because each set of 3 pins (A,B,Y) is separate. The truth table on the datasheet shows how the
outputs react based on the low or high input levels. X means 'I Don't Care' so only one low is significant or two highs. If both of the A
and B inputs is high, the output is also high. If either A or B is low then the output is low. If there is a low and a high on A,B the high
is ignored (i.e. Don't Care) and the output is low. In Boolean terms, both pins must be 1 to output a logical 1 otherwise you get a 0.
That's all there is to it for this chip. The pins are grouped together and easy to remember so now we can test the chip in-circuit and see
what the logic probe tells us about the status of this chip. With the game powered on, probing pins 1 and 2 shows nothing! The game may have
been trying to do something but has crashed instantly at power-up. If I probe the pins while powering it on, pin 1 shows low for a second
and pin 2 shows nothing. The output pin 3 (Y) shows nothing also! If the chip was working, the output should be low because pin 1 is low.
This chip connects to the ROMs CE pin (active low chip enable) so the ROMs are not being enabled and therefore the program can't run.
Probing the remaining pins on the chip shows similar inputs (high or low) and the output pins are all nothing, so all the outputs are dead,
meaning this 74LS08 at 9L is toasted and must go!
We have now positively identified one bad chip. Yes, four pages of text and one logic chip changed... well I did say it was going to be in-depth
hehe! At the top I mentioned this tutorial might be long but that might have been a massive understatement. It will get more
interesting very soon so don't get discouraged ;-)
So what does the game do now? It shows even less on the screen just some blocks of garbage and a black screen. Urgghh!
BUT!!!! It seems to be running?!?!!?!!! It is cycling between three screens that mildly resemble game screens shown in the attract mode.
When I coin up and press start it shows the in-game screen! The first black screen was probably the 'For Use In Japan' message. Wow it's
running! Well it's kind of running, perhaps more accurately it is showing signs of life but needs emergency intensive care!
At this stage I like to probe the address and data pins on the CPU and as expected there is a lot of rapid activity on the logic probe. As
the attract mode screens cycle through, the activity also changes on the data pins. This means the main program is running! For now I will
leave the CPU section alone.
The backgrounds appear to be mostly OK (with flickering) but there is no text on the screen so let's have another look at the
schematics. This is the page that deals with characters....
Checking the schematic we can see there are four chips that can possibly be bad, based on the fact they are Fujitsu chips.
These are 74LS00 at 3F, 74LS08 at 6F, 74LS32 at 5H and 74LS04 at 3E. There's no order to checking the chips but since we already know how to
check an LS08, while I have this in my memory I check it and the logic probe reveals pulsing inputs and pulsing outputs but only on pins 11,
12 and 13 so the chip is working at the moment. Most of the other pins including those that connect to the LS74 at 4H and the LS04 at 3E
are doing nothing and the outputs are low so this chip isn't dead. Since this is about not only fixing it but totally obliterating all signs
of Fujitsu chips from this board, I just removed the chip for good measure and swapped in a non-Fujitsu chip but as expected there was no
change on screen. However this has eliminated a future fault at 6F, which as you will see later can be significant in the repair
The next chip I am going to check is the 74LS32 at 5H and here's the datasheet....
This chip works in a very similar way to the LS08 but instead of AND'ing it is OR'ing. Referring to the pinout, as with the previous LS08
analysis, there are four individual and separate sets of two inputs (A , B) and one output (Y). 1A & 1B pairs with 1Y, 2A & 2B pairs with 2Y
and so on. The truth table on the datasheet shows how the outputs react based on the low or high input levels. This time only one high is
significant or two lows. If either of the A or B inputs is high, the output is also high. If both A and B are low then the output is low. If
there is a high and low on A,B the low is ignored (i.e. Don't Care) and the output is high. This is another very simple chip. The pins are
grouped together with the same style as the LS08 and also easy to remember so now we can test the chip in-circuit with the logic probe. With
the game powered on, probing pin 1 gives nothing and pin 2 gives nothing. Pin 3 (Y output) shows high. This doesn't really tell us anything
other than maybe the outputs are not dead (but they can be stuck high hehe!). Pins 1 and 2 are missing for some reason. Probably some other
Fujitsu chip triggers some other chip that provides those inputs and that chip is not outputting anything so the inputs on the LS32 are not
present. Also pins 1, 2 & 3 are not used in the character circuit so not yet relevant. But checking the other pins shows similar results,
either no inputs or just a clock signal (flashing yellow LED). But at least we now know how this chip works. Let's move on.
The next chip I will check is the 74LS04 at 3E. Check the schematic above again and you will see this connects to the LS08 at 6F, which
connects to a LS74 at 4H and then to the LS32 at 5H that we just checked! Now it's beginning to make sense. Obviously one of these connected
chips is screwing things up.
Here's the datasheet for the LS04....
This is even simpler than the other two chips we have looked at so far. This chip is a HEX Inverter. Hex meaning 6 of them in this chip and
inverter meaning it takes the input signal and outputs the opposite signal. It is basically just two pins for each circuit, in and out X6.
This time we will move in for the kill and just check the pin on the schematic in the character section. When probing pin 5 it shows a high,
but occasionally the yellow LED is pulsing so a signal is coming into the chip. The output is on pin 6, but probing it shows nothing!
Checking some of the other input pins shows activity but all of the outputs are dead! I swapped out the chip but it did not change anything
on screen... urgghh! But now all the outputs are working, with a low input coming out high and a high input coming out low, so for sure
this chip was bad.
There's one chip remaining in this section that hasn't been checked yet, the LS00 at 3F. If you look at the pic above you will see our not
so friendly Fujitsu 74LS00 chip right next to the LS04 we just changed.
Here's the LS00 datasheet....
The LS00 is a Quadruple 2-Input Positive NAND Gate. The pin layout is the same as the LS08/LS32 and it works exactly the opposite way as the
LS08. With this chip, if both A & B are high the output is low. If either A or B is low then the output is high. In Boolean terms, if both
inputs are 1 it outputs a logical 0, otherwise you get an output of 1.
Referring to the schematic you can see that the LS74 at 4H connects to the inputs of the LS00 at 3F and the output pin 3 is tied to the
character RAM at 7F to the WE pin (write enable). Probing the input pin 1 & 2 shows activity. Pin 1 has all three LEDs on (low+high+clock).
As the three attract mode screens change, the activity changes slightly, then goes back to the regular pulsing pattern before. Pin 2 shows a
low and occasionally the yellow LED pulses. Probing pin 3 shows nothing!!! Probing the other pins shows activity on the inputs and nothing
on the outputs so this chip is dead. I changed the chip and now it's starting to look like Commando!
The screens still show garbage blocks which I'm assuming are partial sprites. In-game there are no real changes from the previous in-game
pic other than the text is now visible (score etc). Notice in the 2nd pic above that the top board is folded back like a page in a book.
This board has a cable attaching all the boards but only on one side so it makes it easy to work on the individual boards while it is
powered up. With a lot of newer multi-board games, the individual boards plug into special connectors obscuring the lower boards and the
game will simply do nothing if everything is not connected. This makes it impossible to work on the board while it is running. I didn't get
a shot of it, but the start-up text 'For Use In Japan' now shows (with garbage blocks). I then went back and checked the LS32 at 5H.
Checking pin 4 shows a low with a clock pulse (solid green LED + yellow LED flashing). Pin 5 has a similar signal and pin 6 (Y output) also
has a similar signal so the inputs are being correctly OR'd together and output. Checking pins 13, 12 and 11 shows similar results. Pins 10
and 9 are low but for a few seconds pin 9 shows low+clock pulsing, then back to low. The output pin 8 also shows the same low and then
low+clock for a few seconds. As we can now see, there's something happening with the text on the screen when the yellow LED is flashing. To
test that, I powered on and I get the black screen which 'types' the 'For Use In Japan' characters on screen, and pin 8 has the same pulsing
low+clock which is in sync with the text showing on the screen. This happens when it shows the start-up text or when 'Insert Coin' is
flashing. When no text is being manipulated on screen the output pin 8 stays low. We have proven that the 74LS32 at 5H is OK. As before, I
removed this chip anyway and put in a non-Fujitsu chip to avoid a future failure.
We have made significant progress and you should have learned something along the way. This is getting very long so I will leave this
tutorial here for now and continue later.
28th July 2019
Update: It broke again hehe! Small fix at the bottom of this section.
Here's another Neogeo repair. This time we have a NEO-MVH MV1 older single slot board.
The battery has leaked but there's virtually no PCB damage. Actually on this board the battery is relatively far away from the rest of the
parts that even moderately severe leaking won't effect the operation of the game and the game will work fine without the battery. I always
laugh when I see someone ask for help with a repair on neogeo forums and there are comments from clueless people asking if the battery has
leaked then they parrot the usual things to check around the battery area and pull other solutions out of their ass to make themselves look
important LOL! For the purpose of this repair the battery leakage is extremely minor so let's assume the battery has not affected anything
The board was initially only showing garbage on screen and resetting. I had previously worked on this and found a corroded trace between the two work RAMs.
I patched it with a wire on the bottom side and now on power-up it shows an error about color RAM and when using the Neogeo diagnostic ROM
it shows basically the same fault. Note that neither of those RAMs were anywhere near the battery...
The color RAM error is very unusual because there appears to be only a 1-bit error (write 5555, read 5554). I pulled and tested the two
color RAMs as well as the three logic chips nearby.
They all tested good so I used a multimeter to beep out the connections between those RAMs and the other connected parts. The RAM is mostly
connected to two custom chips NEO-G0 and PRO-B0, a few pins on the 68000 and some adjacent logic chips. There were no connection issues. The
soldering on the custom chip PRO-B0 looked in poor condition so I re-flowed the legs and re-tested but it did not affect the issue. I went
across each of the legs on the RAMs with a logic probe looking for irregular activity and then compared it with another working board I have
here. I found that all the pins on the RAMs were the same except one, pin 2. Here's the relevant section on the schematics....
Unfortunately and as usual, this schematic was scanned by someone who was clueless to what a schematic is used for, resulting in most of the
text being very difficult to read and in some cases totally unreadable. The actual schematic is from a MV-1F board but it's mostly the same.
Luckily I have a working PCB to check the connections. The RAM pin 2 is a signal called PALBNK (hard to read) and it goes off to a 74HC259
8-Bit Addressable Latch logic chip that is on the other side of the board near the 60 pin connectors. That chip is shown on the above schem
at the top left of the page (and yes, the actual chip 74HCxxx number is totally unreadable!). The way this chip works in the simplest form is it accepts some address
inputs on pins 1,2,3, active low enable/clear inputs on pins 14,15 and a data input on pin 13 and outputs on the other pins depending on how those
inputs are set (high/low etc). The 74xx259 data sheet has a truth table which can be followed but in this case it is not necessary to study it
because the inputs come from 2 custom chips (NEO-IO and NEO-E0). When I probed the RAM pin 2 there is no activity, but on the working board
pin 2 has some activity for about 1/4 second when powering on using the diagnostic ROM. This signal comes from an output on the 74HC259 pin
12, shown on the schematics as the PALBNK signal. I pulled the 74HC259 and it passed the test on my logic IC tester so the problem has to be
one of the input signals, meaning a possibly suspect custom chip.
Just for curiosity I plugged in the Unibios ROM which has been modified to skip most of the start-up checks and to my surprise the board
boots up. It shows the Unibios menu which is normally accessed by holding buttons A+B+C on power-up (allows changing region etc). This tells
me that the buttons are stuck on, very similar to the previous MV-1F repair I did in June. I checked the resistor network packs in-circuit.
With one multimeter probe on pin 1, the resistance on the other pins should read 1k, 1.2k, 1k, 1.2k, 1k, 1.2k, 1k, 1.2k & open (or whatever
the normal resistance is on the PCB between VCC and GND if checking in-circuit). On a different board I've seen 1.3k measured too, but
those are also OK. I found a couple that had the wrong resistance on the pins so I pulled a couple from a junk board and swapped them over and
now the board shows the normal test pattern on power-up without a cart plugged in. I plugged in a game cart and the game appears to work and
the colors look OK. I guess the 1-bit color RAM error is so small that it has no visual effect on the game. This is an unusual case where a
solution is not a full fix but is enough to get around the error. In a case like this it's not worth troubleshooting further so I'm calling
this issue fixed and the Unibios ROM will stay on the PCB permanently.
So I coined up and played the game. Controls are OK but there's no sound. If I listen carefully with the volume up full I can *just* hear
the sound, or at least some kind of sound but it's not correct. I thought maybe the YM3016 DAC might be bad so I pulled it and tested it on
a different PCB but it was OK. Then I looked closer at the pic I took and realised what the issue was LOL! There's some minor corrosion on
some vias that are connected between the YM2610 and the 68000 CPU and one of the vias measured very high resistance. I scratched away the
corrosion with a fiberglass pen and the connection from the via to the YM2610 went totally open! I patched the track and re-tested and now I
can just hear the sound and it's correct.
The volume is still very, very low and almost inaudible and there was a buzz coming out as well. Moving the volume pot did not change the
volume. Here's the relevant sound section on the schematics....
Referring to the schematics, it can be seen that the outputs from the 4x 4558 op-amps go to both the headphone section on the first page and
the speaker section on the second page. I plugged in a headphone and was amazed to hear that the sound is perfect and loud and adjusting the
headphone volume pot makes the volume louder or softer as expected. This means the problem is on the second page of the sound schematic. I
suspected that some of the electrolytic caps might be bad because they are all some shitty 'TK' brand (LOL!) so I pulled all of them
and tested them and as expected many were bad. All of the 470uF caps were totally out of specification and one cap even thought it was a
resistor LOL! I changed all the caps in the speaker section but it didn't fix the volume issue but it must have improved it slightly. Even
if I couldn't hear it, a cap acting as a resistor can't be a good thing for the audio quality ;-)
I also changed the main power AMP but again there was no change to the volume.
Strangely when I switched the mono/stereo switch from mono to stereo to buzz went away, but the volume was not louder. Using a multimeter I
beeped out the switch connections on my suspect board and on a working board and the results matched so the switch was OK. Referring back to
the schematic again, the only part that remains untouched is the volume pot! I measured the resistance of the pot and then moved it and
measured again and there was no change. I compared it with the working board and of course when the pot is moved the resistance changes too.
So it appeared that the pot was bad. This is not surprising really. Those pots are the cheaper type using a thin coating of some kind of
carbon-based material. If you check the specification of a standard 3-pin carbon-wiper pot you will see that they have a lifespan of 50 full
turns which isn't much! Now in this case, the volume pot is a custom part and the only place to get another is from another identical
board. However the headphone volume pot is the exact same 1kohm pot and being that it's the headphone pot has probably never been used. I pulled
both pots off the board and swapped them over and that restored the volume :-D
It isn't shown, but later I put the dead volume pot in the headphone pot position as it will never be used and won't affect anything. There
is a valuable lesson learned here. Don't randomly play with these special volume pots because they *will* go open eventually causing loss of
volume as I experienced. Then you will have to remove it and replace it with a pot taken from another board or swap over the headphone pot
to fix it. This also backs up the theory that the last part you change is always the one that fixes it, so to save time be sure to change the last part first! ;-)
Update: The sound broke again. It would work for a while then either the sound would go silent or it would play the wrong sounds. The test
mode sound test played the correct beeps so the Z80 communication was ok. It was another one of the vias connecting the YM2610 to the 68000,
the via just above the one I already patched. Between the track and the via there was some resistance instead of a direct connection. I
patched the track and sound is working again :-)
13th July 2019
Along with the trackball boards mentioned in the previous post, I've been busy making several other PCBs.....
The 2nd one off the production line is a cost reduced TC0070RGB. This one now costs $3 to build, complete with parts.
Most of the other PCBs are enhancements for Commodore computers....
- A3640/A3660 68040/68060 Accelerator card for Amiga computers (reversed by "Chucky". No changes, I just made some)
- Custom hard-card style XT-IDE to suit Amiga 1000 with A1060 XT Sidecar (in the style of the A2091 SCSI controller)
- Custom and enhanced Gotek drive containing all hardware modifications (OLED display, SD card, piezo, rotary dial etc) all built into the PCB and designed to directly
replace the floppy drive in an Amiga 500 using the existing FDD mounting points so it doesn't require a bracket or case modifications.
I will showcase all of these here later when I have built and tested them :-)
There are also 4 items for the Commodore 64....
- Another run of my joystick port switcher PCB (switch one joystick between port 1 and port 2 with the press of a button)
- Custom and enhanced Easy Flash 3 cart modified with a built-in dual ATMega1284-based SD2IEC with OLED display support. All on a cart PCB
the same size as the original. Will possibly be about the same price as the stock EasyFlash 3 to build plus of course it is even more
complicated to build than the original stock Easy Flash 3 cart. Again, it will be showcased here when I have built and tested it.
- PLA replacement chip which I call the "Open PLA", programmable for use with any of the computers that use it including C64, Plus/4, A1060 Sidecar, Commodore P600-series etc.
Again a cost-reduced design ($5) and using a proper 5V-rated part so no added B.S. to drop the voltage and no more having to pay $30-$50 for a C64 PLA ;-)
The 4th item is very special. It's an exact 1:1 reproduction of the Commodore 1581 3 1/2" floppy drive controller PCB that sits inside the case below the floppy drive.
The 1581 is unique among Commodore floppy drives for a few reasons. It is a 3 1/2" floppy drive for the C64. It came a bit late in the C64's life (around 1986) so it didn't catch on and is now difficult and expensive to buy. It also works with C128, Plus/4 and any
other Commodore computer that uses the IEC serial interface. It is also the only Commdodore floppy drive that is using all common off-the-shelf
parts other than a MOS8520 CIA.... also used in Amiga computers. The floppy drive is also a fairly common type used in Amiga
computers, but certain models of PC floppy drives will also work with small modifications.
This means unlike the older Commodore floppy drives, the 1581 can (in theory) last forever and be fixed no matter what is wrong with it :-)
This is not just a replacement PCB, it has the *exact* same look as the original too, including the quirky silkscreen, quirky footprints and
quirky PCB trace layout together with all the same texts and logos. Absolutely everything is in exactly the same place within 0.1mm.
Side by side the PCB is identical, other than being a better quality PCB. It's basically the exact same PCB design, just made 33 years later :-)
Here's a few pics of the first one I built. The first 2 pics show what the original looks like, the other pics are my 1:1 reproduction.
On first power-up it worked perfectly :-D
Here's the board installed in the original case..... it's a perfect fit :-D
6th July 2019
For those waiting, and for those who may be interested, I now have a new batch of Trackball I/O boards. This new board can control up to 3
trackballs and is designed to fit onto all the boards that use this interface..... System 16, System 18 and System 32, including of course Sonic The Hedgehog :-)
If you are interested, contact me.
11th June 2019
Something unusual just happened today. I fixed something purely by accident that I had no intention of fixing :-D
A local friend contacted me about a repair on his Neo Geo MV1C board. Someone had converted it to use a CR2032 coin battery and the battery
was being drained quickly. Obviously a poor decision because a CR2032 isn't up to the job. He wanted to replace the missing parts on the
bottom side of the board and put it back to the way it was originally and use a rechargeable battery or supercap. He asked if I could supply
the missing parts, which are all surface mounted.... one cap, one resistor and one diode.
These pics show how it looks now and what it should look like, and a simplified diagram of the circuit.....
A few years ago I bought a bulk lot of 6x MV1FZSB-2 boards.
I fixed three of them quickly as they just had RAM errors (Work RAM or Backup RAM), one had a broken track from the motherboard to the cart
slot (damaged via caused by corrosion) and the other two were worked on at the time but remained faulty and were put in my PCB storage area
for about 10 years. One of those is missing the upright cart slot PCB so that one will never work even if I fix the board.
Today I pulled out one of the faulty boards with the intention of taking the needed parts from the backup section to repair my friends
board. This board has a backup RAM error. I had previously replaced the RAM and checked all the connections. I found one bad via (again
caused by corrosion) and patched that track but it still had the backup RAM error.
The needed cap value is unknown so I started by removing the cap and testing it and found it measured 150nF. The resistor has markings on it
'221' which means it's a 220 Ohm resistor (for those who don't know how SMD resistor codes work, take the 22 and tack on 1 zero = 220). I have plenty
of caps and resistors in stock so I can just take those from my parts stock.
I removed one of the diodes and tested it on my little component tester and it said it was bad. I removed the other diode and it fell apart!
BTW, this little tester (model# MG328) is the best type to get because it uses a rechargeable 3.7v lithium-ion battery (type 14500) rather than the usual
9V batteries which are expensive and don't last very long. If you need to repair something with lots of transistors, resistors, caps etc,
simply remove each part one by one and test it with this nice thing. When the battery gets low just plug into a USB port on computer or USB
charger and the battery will charge up to 4.2V which is the full charge level of a 3.7V lithium-ion battery.
I didn't have the exact same diodes in stock but I figured a common 4148 would do the job near enough so I found some on a junk old laptop
motherboard in the same size surface mounted SOD-323 package (2mm x 1mm) and mounted it onto the MVS board. I powered up and now the board
is working. No backup RAM error :-)
So the backup RAM error was caused by the bad diodes! The battery is charging just fine as well so the diodes are working.
The 4148 diode is the same thing as the original 1SS352 (Silicon Epitaxial Planar Small Signal Fast Switching Diode). I don't know if the battery
will last as long as before but I don't care as long as it works.
Here's a pic showing the board with the original 1SS352 diodes replaced with 4148 diodes.....
I plugged in a cart and it coined up immediately, which is not correct. I went to the test mode and saw that coin 1 was stuck on which means
it is permanently tied to ground.....
On this board, coin goes from the JAMMA connector through a custom resistor network and then directly to a SNK custom chip 'NEO-FO'.
Hopefully the custom chip is ok and the problem is only a bad resistor network. I desoldered it and measured it. On the board pin 1 is
connected to VCC and pin 10 is connected to ground. On this suspect resistor network, measuring between pin 1 and each of the other pins (in
ohms) reads 1k, 1.2k, 1k, 1.2k, 1k, 1.2k, 1k, 1.2k and lastly pin 10 reads 1.2k. I desoldered another one from the 2-player control section
on the same board and measured it. Everything was the same except between pin 1 and pin 10 there was no connection, which is correct as
there should be no connection between VCC and GND. Bingo!
I soldered the good resistor network into the position where coin 1 connects and powered on. Now it doesn't coin up automatically. I tested
the coin-up and it works.
It isn't shown here, but later I found another correct and working resistor network on another junk MVS board and
soldered that on to replace the missing part and fully fix it. Problem solved :-)
4th June 2019
Several months ago I got a faulty Simpsons Bowling PCB from a friend as a gift. This was just the bare PCB stack in a metal frame and is a
standard Konami GV999 main board with an add-on top board that holds some flash ROMs and associated logic and the trackball controller
I wanted to test it so I pulled a SCSI CDROM drive from one of my other Konami GV games (Hyper Athlete) and connected it, burned the CD
image from MAME and powered it on. It passed all the tests but came up with a security error and then did nothing else.
I pulled the eeprom (which was curiously in a non-factory socket) and read it then compared it to the dump in MAME and it matched exactly.
This was a bit unusual because MAME eeproms are factory defaulted and so was this one on the PCB, but I assumed it was working at some point
and would have different high score names in the eeprom. At this point I had no other ideas about how to get it going so I put it aside.
Recently I've been doing some repairs to playstation-based Namco System 11 PCBs (repair log coming soon). While repairing them I have been
searching for IC's from other junk boards of the era to fix the System 11 boards. Back in November 2007, I got hold of a bunch of things to
dump. One of them was Tokimeki Memorial Oshiete Your Heart (complete with metal box and CDROM drive), which runs on Konami GV hardware.
While this is playstation-based, it didn't have the correct Sony chips I needed for Namco System 11 but I figured since this game is pretty
useless in it's current form, I would convert it to something more interesting. Maybe even use this board to run the Simpsons Bowling game
if the main board was the problem with it. I used the CD drive and disc from my Hyper Athlete to test the Tokimeki board. To swap games only
requires the CDROM disc and eeprom on the main board to be changed. I didn't have the eeprom dump from Hyper Athlete handy so I downloaded
the one from MAME and programmed it to a 93C46 eeprom. I powered on and it said 'ERROR 25C MBAD', which means the eeprom is bad. I then got
my Hyper Athlete PCB, desoldered the eeprom and read it and was astounded by what I saw. The dump in MAME has had a 16-bit byte swap applied
to it LOL!! No wonder it didn't work! Obviously this has happened sometime during all the (mostly unnecessary) code-playing & shuffling that is happening
nowadays with MAME because I know for sure my eeprom dump from this exact board was correct and that was what was in MAME for years. I re-programmed
the eeprom with a dump read from my working Hyper Athlete PCB and of course it worked just fine, so I know that the Tokimeki PCB
was working. To verify the MAME dump, I loaded it into my eprom programmer software, did a 16-bit byte-swap and it matched my defaulted real
eeprom dump.... SNAP!
Then I started thinking about the error on the Simpsons board. Hmmmm.... it just said there was a 'Security Error'. If you have read my
Konami GV readme in the MAME source (konamigv.cpp)
you will know the eeprom on GV was a mild form of security to stop operators swapping games. The security error suggests the eeprom is bad.
Hmmm I wonder..... I read the Simpsons Bowling eeprom and of course it matched the factory-defaulted dump in MAME... which as I've just
discovered is wrong LOL! Obviously someone has been playing around with something they know nothing about on this board and wrote the EEPROM
from the current MAME dump to the 93C46 EEPROM on the board thinking that would fix the problem LOL! I read the eeprom again, applied a 16-bit
byte swap and then re-programmed that back to the eeprom. Powered on and got this.....
Some progress! Now we are getting closer to discovering the *real* problem. It's telling me the flash ROMs at location 3A, 3B, 7A & 7B are bad. 25C (the eeprom) tests ok now :-)
I powered off and booted up with test and service held in and got this screen.....
After a few minutes the flashing completed then it showed this screen.....
I switched the test switch off and it went directly to test mode. I selected 'Game Mode' and this came up....
It's working! Awesome!
Since it is so rare, here's a large pic of the daughterboard from Simpsons Bowling so you can check it out.
As I have a proper GV metal box (from Tokimeki) I put the whole working board into the box to make it complete :-)
I went back and checked several of the MAME Konami GV eeprom dumps and yep! they are all bad, with an incorrect 16-bit byte swap! Now I'm
wondering what else has been screwed up. Obviously someone who is playing with the dumps doesn't understand the massive effort and expense
that it took to get access to these boards and dump them. In this case no serious and unrecoverable damage has been done. I've informed smf (MAME's psx man)
and hopefully this problem gets fixed quickly.
Regarding repairs to PCBs, just be aware if you are trying to fix a real PCB, you can't always trust the MAME dump of an eeprom, especially
if it was hand-crafted. Just because it works in MAME does not mean it works on real hardware since in MAME the code can be forced to do
whatever the emulation dev wants. A similar issue happened with the dumps of Amiga kickstart ROMs in the past where the dumps were bit-swapped
to keep emulators happy. Obviously this is the wrong way to think... the dump should be kept in its original form and the emulation
changed to suit it. Thankfully the Amiga kickstart ROMs in MAME are good because I pointed out this issue years ago and they were all fixed,
although I don't think WinUAE (the source of the bad dumps & bit-swapping) uses these correct dumps :-/
To those emulation devs playing with dumps, please don't. These dumps took a great deal of time, effort and LOTS of money to acquire and dump
over the last 20-something years. I certainly won't be re-buying things, but it would be a real shame if other people had to find these rare
boards again to re-dump them just because of silly things like unnecessary bit-swapping to keep emulators happy. Think before you bit-swap.
24th May 2019
Following on from the previous repair below, here is the repair log of the other Dodonpachi Dai Ou Jou PCB that came in for repair.
This one was not in bad condition but someone had also removed all of the surface-mounted ROMs (urggh!) and then put them back using little to no skill or technique.
On power-up the screen showed an error 'Trap 13' with some memory registers and other things. Sometimes it would show 'Address Error' but still with the same numbers.
The first thing I did was remove all of the surface-mounted ROMs and check for PCB damage. There was a bit of corrosion around the ROM legs,
and like last time, some surface-mounted pads were lifted by the previous owner and one pad was missing. Fortunately the missing pad is not
used so that didn't affect anything. I cleaned up the board so it was ready for mounting the ROMs back onto the PCB.
The ROMs were read and matched the known good set in MAME so I mounted the ROMs back onto the PCB. I also read both EPROMs and they also matched the ROMs in MAME.
After testing the board again the same error came up on screen but at least now I know the ROMs are good.
The 'trap 13' or 'address error' problem seems to be memory-related. The obvious choice here is to look at the main RAM. I removed the four
256kb surface-mounted RAMs and tested them and found that three tested ok but one tested as bad! I got a new RAM from my stock of ICs and
replaced all four RAMs back onto the PCB.
I powered up and got this.....
Success! It's working!!!
I played a game but noticed immediately there was no sound. I wet my finger and wiped over the back of the board where the power amp IC is and got crackling so the amp chip was ok.
I inspected the board closer and noticed some cowboy has been here before and messed with the 78L05.
This IC in a TO92 package looks like a transistor but is a voltage regulator. It takes 12 volts from the JAMMA connector and outputs clean
5V power for the NEC uPC844C op-amp IC. I measured the voltages and both input and output measured the same. While
this is not surprising in itself if the in/out are shorted, the voltage was very unusual.... it measured -3.5 volts!! Yeah... MINUS!
I removed the voltage regulator and checked it closely and noticed that it was the wrong part!!
It is a 79L05, which is a -5V regulator LOL!!! WOW! What a turkey!
I found a replacement 78L05 voltage regulator in my parts stock and soldered it onto the PCB.
I powered on and got the correct sound.
Luckily the negative voltage didn't damage anything else so the game is now fully working :-D
Here is a very large high quality pic of the whole PCB in its final repaired state. Click the thumbnail then click the arrows at the bottom right corner to expand the pic to full
size. Then you can scroll around and look at the PCB using the mouse by left clicking and holding then moving the mouse.
There are a few important things to take from this repair log.....
A fault on a PCB can sometimes be caused by a relatively simple and common part and easily changed out for a new working part in just a few minutes.
Do not mess with *very* expensive and complicated PCBs if you have no knowledge or skill with surface-mounted repairs. If you want to learn, practice on a junk PCB that is worth nothing so that if something bad happens it doesn't matter.
If you remove a faulty part, be sure you replace it with an identical or functionally equivalent working part!
If you have something like this that needs repair and you don't know how to repair it, don't just hack it up blindly hoping that your
'hammer-approach' will fix it. I can tell you now you can't fix an arcade PCB with a hammer. If you want it fixed, instead of butchering it,
get help from a local friend who has PCB repair experience, or send it to someone who knows how to repair PCBs so that the board will not end up scrap..... especially if it's something nice like a Cave shoot-em-up :-)
15th December 2018
A few months ago a couple of Dodonpachi Dai Ou Jou PCBs came in for repair. They had been purchased as non-working boards. One had major damage and
corrosion on the large video chip. To make it worse, someone had also removed all of the SOP44 ROMs and seemingly tried to put them back with
their eyes shut, or in the dark or something O_o
Here's a few pics of the worst one which I'll try to repair now.... OMG what a nightmare!!
and here's what it looks like after removing the video chip.... looks like a bomb went off under the chip!
This kind of serious chip and pad damage does not just happen by itself. Someone with no brains, no skill and no equipment tried to repair it and
basically scrapped it as soon as they touched it. Several of the tiny 0.5mm pads have been lifted and were just hanging on by a few microns.
WOW! Talk about the biggest loser... this guy must have won the competition!
It is going to be a big challenge to get this thing going and stretch my Guru-Skills to the limit!
First thing to do is clean up the board and fix the pads. After a few hours of delicate work it was done. I scraped the corrosion off the pads,
straightened the bent/lifted pads then patched the one missing pad with the thinnest piece of wire I could find (~0.15mm). Hopefully it would
stay there when remounting the chip. It's not perfectly clean but several pads were loose so I could not clean the area too much otherwise those
pads would fall off. If that happened the repair job would become even more difficult. It's a miracle only one pad was missing!
The board was ready to accept the chip but now there's a dilemma. Should I put back the original chip... did I want to spend hours straigtening
all those tiny legs on that really bad looking old chip and was it blown up? Experience tells me it was probably dead and I doubt the PCB pads
could take the removal and re-mounting of another chip if it didn't work the first time. So an executive decision was made. A good working chip
must be sourced from some other PCB. Fortunately there are several other non-Cave games using that chip so the owner promptly bought a donor PCB
and had it shipped to me.
The good chip was removed and mounted onto the PCB. This was a very tedious, delicate job. It required several hours of intense concentration and is
an experience I would like to forget ever happened, so I'm going to skip the details and just show the re-mounted good chip....
I suppose it came out ok in the end, but we're not done yet. The SOP44 ROMs had to be removed and read to make sure they were ok. They had to be
removed anyway because of the previous poor hack job done to them so I figured I would read them anyway while they were off the board. Luckily all
the ROMs were ok. However after removing the ROMs and cleaning up the PCB pads it was clear there was more damage and nearly every ROM had at least
one lifted pad! Arrgghh!! Fortunately only one pad was missing and it was an unused pad. The remaining pads were hanging on by their fingernails so
I just straigtened them, rolled my eyes in disgust and imagined I didn't see it.
After remounting all the ROMs it was now ready for the first power-up.
Would it work or was it still dead? Would it just blow up?.....
3...2...1.... power-on... hold breath!!!
Sigh!! It works!!
Next I had to test it to make sure it fully works. I coined it up and hit start and it appeared to be working. I started playing it and I'm
thinking 'wow this is great' but then I noticed I couldn't move backwards! Damn! I went into the test mode and checked the controls and sure
enough the down movement didn't work. First I suspected the I/O chip (IGS026) because it was also in bad condition but fortunately had not been
touched by our Biggest Loser winner. It appeared to have been effected by the battery. In case you didn't realise, these boards have a Ni-CD
barrel battery on them. If you have been following my previous work and repairs, you will know that is bad news for any PCB. If you own one of
these boards you should immediately get that battery off the board before it kills it if you haven't already done it. On this particular board
the battery had already been removed but there were remnants of corrosion around the area where it once was. So I removed the I/O chip, cleaned
it up and remounted it onto the PCB. Tested again but still no go with back movement. I traced the down signal from the JAMMA connector to a few
resistor networks but they checked out ok on the multimeter resistance test. I looked more closely at the edge connector and noticed the green
solder mask was slightly darker at the place where it meets the JAMMA pad so I suspected a broken track caused by the leaking battery and doing a
continuity test with multimeter confirmed a break in the trace. I scraped off the old solder mask and then the break was visible. For some reason
the JAMMA pads had some of the gold plating flaking off too so I scraped that a bit and ran some old solder wick over it to clean it up. Using
old solder wick and rubbing and pushing down while heating with soldering iron allows the solder to stick to the pads and re-coats it so tiny
imperfections are filled in. I patched the track with a small piece of wire and re-tested. Success, now down was working.
I went back to test mode and checked everything again and noticed button 3 was not working. I checked the edge connector again looking for
another broken track and sure enough found that the trace at the button 3 JAMMA pad was broken. I patched that like the previous one, but this
time instead of running the patch wire back to the via I simply patched the trace directly. This looks MUCH neater. If you have to patch a break
in a track or a bad via do it right there where the break is, don't run ugly long wires across the PCB!
I went back to test mode and verified all controls were now working. Job done!
Here's a few pics of the game fully working and the final pic showing the PCB fully repaired. The last pic is very large. First click the arrows
at the bottom right corner to expand the pic to full size, then you can scroll around and look at the PCB using the mouse by left clicking and
holding then moving the mouse.
Another successful Guru-Repair! Fortunately it was sent to me otherwise it would definitely have been scrapped.
2nd December 2018
Well well, seems it was added and then removed.... like the hoarders (Shoutime and Co.) own the IP or something and have the power to stop
distribution LOL! I don't think so... in other words, I've put the src + ROMs online here in.... My Google Drive
Small update: Also add OOParts to My Google Drive, a prototype Arkanoid rip-off made by Success that also runs on
Sega C2 hardware. This is not supported in MAME and may never be due to arcade scene hoarders not wanting their stuff in
MAME but you can run it as 'tantr' and it works fine. Just rename the zip to tandr.zip and then run 'mame tantr'.... problem solved....
If Sega were concerned they would also not be happy about the other 1000 Sega games in MAME including several other
'Sonic' games. Of course they are not worried and don't care. The game is 28 years old and is a pretty poor effort which
is why it failed at the test location.
You guys are funny. Better luck next time losers. Oh and thanks for an excuse to direct an inordinate amount of traffic
to my site, it's great for publicity... thanks guys! :-D
So.... to get it going, in your MAME source tree, simply replace the original segac2.cpp file with the file in the zip,
re-compile MAME then put the ROMs in your MAME ROMs dir.
Result..... instant Sonic Bros. LOL!!
Since it's an unprotected set, I'm sure the ROMs could be used to convert a C2 arcade PCB too....
Get it while it's hot because in a week or two this will be just another shitty arcade game 'Columns' rip-off and will be totally forgotten.
26th November 2018
A couple of years ago an unreleased Sega C2 game surfaced. It was shown on the net and at some arcade shows and hoarded
by the usual people so no ROMs have become available..... until now ;-)
One of the hoarders even tried to scare anyone else with the ROMs to keep them secret by spreading rumours that the men
in black would come looking for them if they leaked the ROMs! LOL!
The Bottom line is this is another game rescued from the clutches of hoarders and will be coming to MAME very soon.....
While I'm on the subject of arcade PCBs, a large box of PCBs arrived from Korea recently. Some are to re-dump ROMs of games that had bad ROMs and
some are totally undumped games. As for what they are, you'll just have to wait ;-)
In other news, the Sega Sonic System 32 trackball interface PCB was so popular that I completely sold out of stock so I have got another batch of
PCBs made. If you missed out on the first batch today is your lucky day ;-)
I have also been working on a few PCB projects. There are a few NVRAM boards available for use in pinball machines that normally use a 5101 or 6116
static RAM to hold settings and high scores and a nasty NiCad battery to keep the RAM powered. Unfortunately they are priced out of reach of most
people even though there is very little to it, just a PCB and a RAM LOL!
A buddy asked if I could make some so I made my own budget design and it works very well :-)
The 2nd pic shows the 6116 NVRAM installed in my 6803-based pinball machine (Eight Ball Champ). This series of machines needs around 50 settings
correctly set or the machine doesn't work at all. The little adapter is almost invisible but it's the tiny thing just above the red push button.
This allows highscore and settings to be saved so a back-up battery is no longer needed so I removed the back-up battery from my PCB completely :-)
6th October 2018
I've been busy doing mostly non-arcade repairs to some Amigas (one rare and special Amiga took 3 months to be documented here soon!) and
other unrelated things for the last few months and making some PCB designs. I was recently given a fancy but dead PC monitor.
But this is no ordinary monitor, it's a LG 34" UltraWide Curved Gaming Monitor, model 34UC79G. Seems to be
still a current product and is listed on the LG web site at AU$1349. This kind of thing is really only for serious gamers that have plenty
of money to throw around, the average Joe will never see something like this except at a large computer or electronics chain store.
Since this is such a rare beast I'm going to document my repair and I guarantee the end repair will surprise you ;-) The problem with it
is it's dead. It's pretty sad that something that is only just 2 years old and was incredibly expensive is now dead. It's also pretty sad to
see even Korean stuff is now made in China. To make it worse I didn't have the power supply and it's a strange connector... great! :-/
After some research I discovered the power supply and connector is almost identical to the PSU used by some Sony VAIO laptop models, namely
the P-series. By luck I have a Sony VAIO P here so I plugged in the power supply and tested it. The LED on the PSU came on for 1 second then
went off. This is a sign of a short on the main power input. I opened the case to discover there's only 1 board inside.
If you check the PCB pic you'll see there's not much on the PCB. Even better there's no BGA chips... WOW! this might even be easy to fix.
After checking some parts with my multimeter set on continuity I confirmed there was a short between ground and the input voltage (19VDC).
When diagnosing a power short fault, the usual thing to do is to hook up a bench-top power supply and give it a small voltage with very low
current like 0.05A or 0.1A and see if anything gets hot. Normally by spraying freeze spray on it before and watching to see where the freeze
spray warms up. It's a fairly stock technique used by a lot of professional repairers and there's a lot of videos on youtube showing the
technique. Unfortunately I don't have a bench top power supply so I had to do it the ghetto way. So not knowing anything about this monitor
and finding no repair logs online (likely because it is rare and expensive and few 'gamers' would own one and be skilled enough to repair
it), I proceeded to remove a few parts like surface mounted capacitors (known to short in iPhones etc) to see if the short went away... it
didn't. But worse every part was seriously difficult to remove, even tiny surface mounted capacitors were held on with a tarzan grip!
Obviously this PCB has at least 4 layers, but possibly 6 or 8 layers would not be surprising on such a new product. After removing over 20
parts I wasn't getting anywhere :-/
So what to do now?..... Obviously start looking up parts on Google and find out what they do! Fortunately there are not many parts on the
PCB. After checking out a few parts I was getting bored with research and I wanted to just fix it! I looked over the board a bit more and
noticed a chip package I had seen before in several repair videos of Apple Macbook laptop repairs by Louis Rossman. This guy seriously knows
his stuff and routinely repairs Macbooks that no one else can handle (check Youtube if you want to know more). The chip I remember being
replaced often is usually one that takes a higher DC voltage and drops it to a lower DC voltage. This is called a Buck Regulator. The chip
on the board is very small (5mm x 5mm) and has a very strange number, probably re-badge by some manufacturer to hide it's identity. The
number was 'SN1302001', but fortunately Google knows what it is.... it's a Texas Instruments TPS65286 Switching Buck Regulator (Google it
for datasheet etc). So I figured I'll just remove it and see if the short goes away.... and it did! I discovered this chip is used to create
the power for the USB hub on the rear of the monitor. Amazingly this tiny chip can provide 6 amps which explains the large heatsink pad in
the middle of the chip on the bottom side and why it was very, very difficult to remove. I suspect this chip is not really up to the task
given to it which is why it failed. Basically it's just too small to output 6 Amps and survive for any long period of time.
Now it gets interesting because I don't keep spares of this part in stock and I have never seen one on any junk board I have lying around
here. Rather than order one off the net and wait 4 weeks for it to arrive from China I just decided to power it on and see what happens...
after-all the short is now gone. To my amazement it powered up straight away and works. Well kind of anyway. The LED on the power supply
stayed on and the LED on the monitor also came on, but nothing on screen except the backlight. Then I realised I had not put back a bunch of
parts I removed earlier hehehe! So I put them back and re-tested. It works! I couldn't believe it! In case you were wondering, the message
on screen is telling me there's no signal input.
So I re-assembled it and to confirm it was fully operational, I plugged it into my Toshiba C665 i5 laptop which has a HDMI output. The
Windows desktop came up and shows fine, although the resolution of the monitor is so high (2560 x 1080) this laptop will never be able to
show it full screen and I don't have any other device I can try that outputs a higher resolution. LG provide a driver for Windows 10 but I
am sticking with Windows 7 so I can't get the higher resolution. But I can get 1920x1080 just fine. Obviously the USB ports won't work but
I was never a fan of those stupid USB hubs on the rear of TVs/monitors anyway so no big deal that it doesn't work and I won't miss them!
And here's a later update with some pics running in Windows 10 with the full 2560 x 1080 resolution :-D
The last pic shows a directory thumbnail view of a compact flash memory card from my camera, showing all 159 pics as large thumbnails all on
screen at the same time!
So now I have a working 34" UltraWide Gaming Monitor for $0, fixed by simply removing one chip. Not a bad score and it's now minus one nasty
chip that will never cause this monitor to die again since it's not on the PCB. Even better the previous owner left the protective clear
tape on the bezel edges of the monitor so after removing it the monitor looks like new :-D
Score: Guru 1, LG 0
Anyway.... Life's Good (LG-related pun intended) ;-)
9th June 2018
Well here it is, sooner than expected.... The System 32 Trackball Interface is now a reality! It turned out I was upgraded to the express
service for free. I quickly assembled one using the minimum number of parts.... 5 IC's and the bottom connector. I used an original
press-fit bottom connector taken from a System 32 driving interface board, but don't worry there is a common alternative available that will
do the same job. I plugged it in and screwed it down using stand-offs taken from some old Sega board. Those holes are specifically designed
to take the original Sega stand-offs but I don't have them so I used some black ones I had lying around and the height is perfect. I'm
guessing they probably came off a dead Hikaru board. Common board spacers can also be used and fit just fine. I checked the three trackballs in the test mode and they all test GOOD. SUCCESS! :-
Note the Sonic PCB shown in these pics is sold. I am selling the trackball PCBs to recover my costs. I have sold 7 of the trackball
PCB's (so far). I have 13 PCB's total but I have no use for these now that the job is done since the Sonic PCB is sold
and I have no plans to get more S32 main boards and/or convert them. That can now be done by _YOU_ using my System 32 Conversion Info Page
here. I will keep one fully assembled trackball board for myself, so I currently have 5 PCB's
available. If you are interested to buy one (or more) contact me. If more than 5 are wanted I can re-order another batch so don't worry if
you missed out getting one of the available boards, just tell me how many you want :-)
Update: Now only 4 in stock.
Update: Now only 3 in stock.
Update: Now only 2 in stock.
Update: Now only 1 in stock (as of 1st November 2018).
Update: Sold Out ! Another batch has been made, see news above....
Here's some more pics of it fully assembled (I'm still waiting for some more parts to arrive to compete the partially assembled ones).....
Update: They are now all assembled and tested working.
2nd June 2018
The System 32 Trackball Interface PCBs have finally been shipped and should arrive within the next 3 weeks.
While I'm waiting, I made another small Eagle project and assembled it today. Tested and it worked first time :-D
Anyone who owns a Commodore 64 will know of the constant joystick swapping that is required because some programmers did not know the difference
between Port 1 and Port 2 (LOL!!) and games use any random port regardless of the number of players it supports. Great! :-/
But fear not the solution is here! Now no more pissing around swapping joysticks to the other port.... I simply press the little button on
top and it switches them instantly so the joystick works no matter which port it is plugged into :-D
There are some other similar things out there already but this one has been made as small and unobtrusive as possible on purpose.
This one also supports the mouse and switches the analog pins too, so a joystick and mouse can be left connected permanently!
Total build price was about $10 :-D
14th May 2018
My System 32 Trackball Interface is finally complete and PCBs have been ordered....
8th April 2018 (Updated 26th September 2018 with pic #5 of actual part assembed)
While I'm on the subject of Taito PCB repairs, here's the next project 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 get some
PCB's made themselves and fix their own boards 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?
UPDATE: Yep, there's an extra board in the DX cab. Got dumps of it and documented it. Should be in MAME by the time you read this.
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 effected
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 effected 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.