27th April 2024
Over the years I've had many junker PCBs given to me for parts to fix other boards. Here's one specific example that has been laying around
here for probably 10 years. If you're a Simpsons fan you might want to look away as there's a high possibility you may become violently sick
and eject noxious liquids and semi-solids from all orifices at both ends....
Yes that's a Simpsons board!! This is a good example of just how many really stupid, clueless and brain-dead people are in the arcade scene.
This was hacked to hell and back by the king of all loser cowboys thinking he could fix it with a hammer LOL! It needs to be saved and
luckily it came to me so it has a chance. Of course a board in such bad condition will require weeks of work and might remain dead after
all that work but I will try my best to bring it back from the dead.
I worked on the board about 1 year ago for a few weeks. The reason for not putting the log here is because it still wasn't working at that
point and I didn't want to spend several days writing up the repair log. Now it's time to write the repair log but I'm not going to detail
every little thing here. It really just needs all the missing parts replaced and all the Fujitsu logic chips replaced with good chips (all
removed/tested and several were found to be bad). Then the *actual* faults need to be fixed (which I'll detail here) but I really don't want
to write a book here and it's not easy to remember everything, especially in the same order that it was done. Let's just skip all the
part-replacing b.s. and show some pics of the re-assembled board in its current state along with a few work-in-progress pics. Or at least
the pics I took (and just found) from a year ago. Click on the pics and read the pic descriptions to see what was done....
There were also numerous broken traces created by the king cowboy loser and those were also patched. That was done by removing parts and
physically tracing the copper trace on the board from end to end. I had all except one custom chip from this same board in a box and those
were simply put back onto the board. After everything was replaced and the damage fixed, the backgrounds were still missing. It turns out
that the Konami custom chip 051962 was bad. I replaced that chip with one taken off a different board (Punk Shot) and that fixed the
backgrounds. THAT was the actual fault on this board, a bad 051962 custom chip.
As of about May 2023 this is what I currently have and it's been sitting there on a shelf waiting for parts....
The right side of the board (butchered part) has not been touched yet because without that (missing) custom chip there's not much point. The
missing custom chip is part of the sprite circuit so without it there are no sprites. On the ROM check screen the red errors are the four ROMs
on the right side. Additionally the sound is working fine.
Forward almost 1 year and another Simpsons board came in for repair. This had the usual Fujitsu logic faults. After the Fujitsu logic chips
were replaced the board booted to this screen....
.... and this is what it should show....
The bad graphics are caused by either bad ROMs (two bottom ROMs) or a bad custom chip, either 051962 or 052109. The two red errors are the
sound ROM and sound RAM. That's because the Z80 that runs the sound program isn't running. I went over the entire sound circuit and
removed/replaced all the Fujitsu chips and also replaced the sound RAM, sound ROM and Z80 CPU, as well as pretty much every other chip in
the sound circuit including the custom sound chip at the top which was taken off another working board. I even removed and tested every
other non-Fujitsu logic chip in the sound section in case any of them were bad but everything tested ok. I did a thorough trace of the
entire sound section using the schematics as reference (many hours of work) but everything was connected like it should be as per the
schematic. The last two (bottom) errors refused to go away and the Z80 refused to run. I was almost getting ready to give up. I checked the
graphic ROMs and they were ok so the final executive decision on this board is it looks like one of the custom chips is bad. I don't think
the sound problem is impossible to fix, just that it needs a lot more time. The board is definitely not scrap and I can always go back and
look at it later. Now I have another dilemma. A little voice in my head is telling me to take that gfx chip from another board and try my
luck with spending more hours attempting to fix the no-boot sound fault. Another little voice is telling me to take the other chip I need
from this board and move it to the working board. The latter is what was done. The board with the gfx and sound fault is now missing Konami
custom chip 053247. If I ever get another junk Konami board containing that 053247 chip (or someone sends me any Konami junk board with that
chip on it) I can move it over and continue looking at the remaining faults on that board. For now the sprite chip was removed and mounted
onto the working board. Of course just moving a chip over didn't help anything and there were still no sprites hehe! That's obviously
because of all the damage on the right side of the board. Now if you know anything about The Simpsons PCB you will know there is a manual
with schematics but the two video pages for backgrounds and sprites was purposely omitted from the manual. I'm not really sure why as there
are some games around the same time that do have full schematics and the chips used on Simpsons are also on those other schematics. Meaning
the pinout is known and their basic functions are known. While not absolutely required to fix this I figured why the hell not, so I made
schematic pages for the video section. But with a special twist. The pages are not only re-drawn but done using the same Konami style from
1991. In order to do that I had to create a lot of custom schematic symbols. I also copied the logo and the title block and sheet border and
added signal names and across-sheet references for those signals. Additionally, Konami schematics show the custom chips as very long
rectangles but in order for it to be more useful as a repair aid I drew the custom chips as they are presented in real life, as squares and
with in-order pin numbers. After about 2 weeks it was completed. The pages are named VRAM, which is the background page, and OBJECT which is
the sprite page.
With the video schematic pages in hand I checked the entire circuit finding several broken traces. As I patched each trace the
MASK ROM test slowly got better (then worse hehe!) then better again until only 1 ROM was showing as bad (actual ROMs are tested good)....
This is the really funny part. That king cowboy loser pulled all the 74LS374 logic chips on the right side, added sockets with soldering
skills at the level of a retarded ant and put them back into the board, breaking a dozen traces in the process but also putting back BAD
CHIPS!!!! LOL!!! Additionally he left all the Fujitsu logic chips untouched, not even making any attempt to find the real fault! Wow, what a
triple f**king LOSER. I would have added 'brain-dead' too but that guy doesn't have one LOL! I knew exactly which chips were causing the
issue from my schematic but it actually doesn't take more than a normal brain to figure it out due to the pattern of how the ROMs are
connected to the logic. Data pins D0-D15 of MASKROM 16L (the bad ROM shown in red) is connected to the 2x 74LS374 logic chips at 10K and
12K. I manually beeped out all the pins on both chips for continuity and they were all connected. I pulled both chips and one failed....
These 8x 74LS374 logic chips were not all the same brand so it appears some of them were changed. It's highly possible the original chips
were not Fujitsu brand and were ok. Or maybe they were all Fujitsu and these chips are the replacements. It's highly likely there was
actually nothing wrong with the sprite section and the only fault was some bad Fujitsu logic chips and a bad custom 051962 chip. Either way,
with the bad logic chip replaced and all the damage repaired the board is finally fully working :-D
Now I know what you are thinking... the schematic above doesn't have a link and I didn't make the full schematic available publicly. Yes I
know, I'm just screwing with you ;-)
Since you have stayed with it and read to the very end of the repair log I'll reward you with the actual PDF schematic. For a hard copy it
should be printed on A3 paper with each page on the same piece of paper using both sides to print both schematic pages. Then fold in half
and insert into a Simpsons manual along with the other schematic pages. This should be complete and I have no plans to re-check this and
make corrections, but if I do find any other errors or omissions it will be updated and the version changed on the schematic. The current
version is dated April 9, 2024 and is available on my Reverse-Engineered Parts and Documents page. Enjoy it and be sure to let other
Simpsons fans know about it while pointing out where you found this holy grail ^_^
23rd April 2024
If you have been following along with previous repairs you will remember some Police Trainer PCBs that I worked on around July 2023. They
seem to have a common issue where the reset chip (Dallas DS1233 Econoreset) just dies and then the board doesn't boot. I wanted to try to
replace that special and not-common DS1233 with a common capacitor-resistor reset circuit but it didn't work. This board requires something
different timing-wise. After doing research and some Spice Simulations an electronic engineer friend and I came up with a circuit that does
what the DS1233 does but using only 3 common and cheap components. To test the theory I built the circuit with loose through-hole components
and wired it up point-to-point. It was very ugly but it worked. In a recent PCB order I made up a small PCB (10mm x 5mm) using
surface-mounted parts, ordered the one part I didn't have in stock and built the first one today. It works perfect and the Police Trainer
board boots up without any issues. Here's a quick pic of the circuit in-situ and the schematic.
It uses the familiar cap-resistor components (values selected to give the correct timing) but also goes through a 74HCT14 Schmitt-Trigger
Inverter which is the key to making it work. The 7414 is also available in a single gate 74HCT1G14 which is the part I used on the little
PCB. It's designed in such a way so that the VCC and GND pins fit across a SMD capacitor. The Police Trainer board has several not-populated
capacitors so that makes for a nice clean mounting. Since it's at 90 degrees to the reset pad on the board I just soldered a short wire from
the IC output to the reset input point but the PCB I designed also has a dedicated reset output pad so it can be mounted flat on the PCB or
some header pins can be added and it can be built like a TO220 or TO92 package. Additionally there is no copper or vias on the bottom side
of the little board so it can be mounted directly onto the PCB (as shown above) without any risk of shorting anything :-)
21st April 2024
A Namco Final Furlong came in for repair from one of the big Australian arcade distributors. Like most companies nowadays who need people to
deal with the general public, it looks like they don't employ any real tech people and just take any random clueless dog off the street who
will accept minimum wage lol! They only sell stuff from a warehouse so if anything needs to be tested they send it out to someone who can
test it. That was not me but it ended up coming to me via someone local hehe! The board worked fine after just cleaning the connectors and
re-seating the boards so that was a waste of time LOL! However while I'm in this mode I figured it was a good time to look at some of the
other junk Final Furlong boards that have been laying around here for over 15 years. Many years ago several were purchased trying to get a
full system to dump (they were all partial junk lots). The first one arrived on October 28, 2008 (Wow 16 years ago!). Another one arrived
August 15, 2009. I didn't see any others in my arrival logs but there were some others too. At one point I had 6 or 7 of them here and only
1 worked. Eventually a full dump was done and then they were put on my shelf. Here's a quick pic of the first (partial) board that arrived
in 2008 and a pic of the main board without the ROM board on top....
Now it's time to try to figure out some of them. Well actually over the years I fixed a couple of them but I didn't document it
here heh! One board that came in for repair about 1 year ago was a non-working Japanese Final Furlong FF1 board. It was being operated so
it looked like new and had no physical damage. The boards are bolted into a metal rack so they generally don't have loose legs on custom
chips or random loser PCB damage. That means some random chip has failed. I couldn't fix it so I just swapped one of my working FF2
(English) boards and I kept the Japanese version board which will be dumped later. If Final Furlong was to suddenly start working in MAME
that might persuade me to dump it sooner, rather than later ;-)
These boards are incredibly flimsy and complicated so it's important to first understand what the board is supposed to do when booting. At
power on there are 8 LEDs that light up. They are connected to the outputs of a 74HC374 logic chip with all the 74HC374 inputs tied to the
backup RAM databus D0-D7 and also the C361 custom chip. BTW, this is also how the LEDs are connected on Namco System 23 (Time Crisis II
etc). If the backup RAM is bad, no boot, no LEDs. If the C361 custom is bad, no boot, no LEDs. If the top ROM board isn't plugged in, no
boot, no LEDs. If literally *anything* in the CPU section is bad, yup you guessed it.... no boot, no LEDs ;-)
So with all the LEDs lit up (meaning some quick checks and security pass) they slowly turn off one at a time until all are off. I believe
during this time the main program is being uploaded to the program RAM (2x 1M x16-bit SDRAM) which is configured as 1M x32-bit. That data
passes through more than a dozen logic chips then into the C413 custom chip then into the SDRAM. Then the main program starts running. At
this point the LEDs flash left/right like KITT (from Knight Rider TV series). After moving left/right about 12 times an IC check screen
shows briefly. This is a really quick 'life' check of several RAMs and custom chips. If everything on that screen passes it changes to
another check screen and does some deeper tests (not shown) with the result shown as OK. After everything on that screen passes the game
shows the Namco logo and then the title screen.
This board I'm currently looking at does the LED count down and the LEDs move sideways but nothing happens after that and nothing shows on
the screen. The LEDs just keep moving left/right forever. That's actually a good sign and means the board is still running. If the LEDs stop
moving it means the board has locked up and crashed, and of course there will be no clues given by the hardware about what or where the
fault is. I'm guessing this is why Namco added more extensive start-up checks to System 23 to aid with factory testing and that also helps
when repairing too but no such luxuries with Gorgon. Due to the ROM board being on top there's almost nothing that can be checked except the
area on the left side....
By pure luck when I pressed on that area I saw the first 'life check' screen!
I'm guessing there are some loose legs on the custom chips there so I went over them and sure enough found several loose legs and resoldered
them. I powered on again and now that check screen shows without having to press on the board but it's the same. There are a couple of
errors shown on the C417 custom chip RAM at 12R. I've been slowly working on all these boards over the years and noticed that RAM has
already been changed. I checked the C417 custom chip and found some loose legs so I resoldered them. Now the first test screen has no errors
and the next check screen shows....
Now I'll give you a brief explanation of this screen based on what I know (which isn't a lot lol)....
MEMORY is likely to be the main SDRAM. This is kind of stupid because if it was bad the game would be dead ;-)
TEXT is the custom C361 chip or RAM connected to it. FYI the C361 has RAM inside too (shown on the first start-up screen as location 10B). If
C361 is dead or missing the board does nothing and is dead.
PALETTE is the custom C404 Palette/Gamma chip (which btw, has RAM inside it ^_^) or the 3 RAMs connected to it.
SPRITE is the sprite chips or the RAM connected to them. I'm not exactly sure what it's checking here. There's at least 5 sprite-related
custom chips, several with RAM connected so best I can say is it's one of more of those custom chips C300, C374, C379, C381, C397 or
connected RAMs.... with most of them covered by the top board so good luck trying to figure out any sprite custom chip faults or sprite RAM faults ;-)
POLYGON is the C417 custom chip or any other 3D chip including C435 or the RAM connected to it/them.
This is where the error is but I actually already know why it stops here LOL.....
Yup! I took those 2 custom chips when repairing something else years before. I suppose it's time to put them back with some others taken off
another junk board. In this case a totally butchered Time Crisis II board where some f**king idiot cowboy loser tore off the R4650 CPU
taking half of the PCB pads with it LOL!
With the 2x C435 custom chips replaced it now shows this WAIT message....
I believe this is a non-fatal error simply because the backup RAM is not powered with a battery. I put a CR2032 battery into the holder and
power-cycled the board. All the tests on that screen say OK and the game booted. However the screen is really whacked....
I left the board for a day and had a think about what the problem could be. It was definitely a pretty serious failure of something
since there was a LOT of missing data. The next day I decided to get my 8X magnifier and go over the board looking for anything unusual. It
didn't take long to remember that these boards were junk, tossed around by losers years earlier and all damaged slightly on the bottom.
There were a lot of scratches and all looked ok until I found this....
Oooff! It looks really bad but there was actually only 1 broken trace. I patched it with some micro wire and powered on....
Wow it's A LOT better now. The 3D looks ok but the textures are bad.
There's a large number of RAMs on the right side of the board used for the textures and none of them are tested. I pushed on that area
by squeezing a finger between the main and top boards and pushing down and some of the textures looked good! I first soldered the 6 RAMs
closest to the corner. It fixed the issue but only on the right side of the screen....
I pushed on all the other RAMs but it didn't change anything. I thought about trying to manually solder the other RAM there but they are all
very close together and SOJ RAMs are annoying to solder by hand so I decided to do a full hot air reflow of all of the texture RAMs. That
fixed it!
Well almost lol! Now the area on the right side is bad again and the rest of the screen looks perfect hehe!! I reflowed those same 6 RAMs on
the corner and that fully fixed the graphics....
Now it's time to relax a bit and play it :-)
Well it's pretty hard to play it with two 5k-ohm pots lol! This is kind of a kiddie ride really. I doubt anyone can actually win. Plus they
also cheat and bump into you so you lose energy. I had it set on easy and the best I could get was 5th.
On to the next board. I previously worked on this one around June 2023 and I don't remember what I did to get it to this point but it was
probably just soldering a bunch of loose legs on custom chips or maybe changing some faulty RAMs. I found a couple of old pics showing the
board hooked up to my test harness and a cut trace I repaired near some resistors. Those resistors are on the bottom side of the board in
the video output section under the Sony CXD1178Q 8-bit 3-channel RGB video DAC. It currently shows jumbled garbage on the start-up screens
with the text shifted up about half a screen, then it hangs on the 2nd test screen (with totally unreadable text) but if I press test then
release it the game starts. On the title screen there's a lot of O's on top of everything. In game the 3D and textures are bad. ...
I'll skip the part where I waste a couple of weeks pissing with this and show what was actually wrong with it....
Yup! Another damaged trace caused by a cowboy loser. I patched that with a micro wire and that fixed everything hehe!! I won't bother
showing an in-game pic as it's exactly like the working one above. The broken trace joins to the C361 (pin 75) which generates the text
layer (and of course several other things like h-sync and v-sync). I checked my schematic and the actual signal on that previously broken
trace is A10 on the backup RAM, so while that RAM is used to save high scores it's also used for *LOTS* of other things :-)
Here's another quick log for a repair that was done around the same time (June 2023). Again I don't remember exactly what was done other
than what these old pics show. One of the PST575 reset chips is missing and a resistor on the bottom was knocked off (the green wire is a
factory bodge wire which is on all Gorgon boards). I replaced the missing parts and it booted but with lots of in-game graphical faults. The
actual fix for this was changing two RAMs at 4P and 4N, and probably also re-soldering a bunch of loose legs on the custom chips. This was
done when the Japanese board came in for repair. The one board I had that I thought was working actually didn't work so I had to go through
the junk and find one and fix it. This board was the one that got fixed and went back to the owner/operator. He got a nice 'upgrade' to the
English version :-)
Later at the same time I fixed another one so I could have one here working for testing purposes. I currently have 3 fully working Final
Furlong boards sitting on my PCB rack. There's 2 more that don't work. One is the Japanese version mentioned above which not only has a bad
main board but also a faulty ROM board showing bad graphics. Those are totally dead where the LEDs light up and start to move sideways but
stop moving and lock up without displaying anything on the screen. It seems to be sort of common as I've seen several that do this. I
haven't figured out what's causing that so far but if/when I do I'll make a log about it here.... although it's very low priority given I
already have 3 working boards :-)
15th April 2024
I went through my boards and found another Subsino game that was dumped years ago (Last Fighting, a Bomberman rip-off) with a dirty
little secret DS2430 which is now dumped and should be added to MAME soon :-)
This board is not working because the H8/3044 MCU was sent off for decapping many years ago. Unfortunately it was not done but now that I
know a bit more about these boards I realised I probably have several of the same chips on the recently dumped Subsino mahjong boards.
This is the chip from my Decap List, chip #108....
It is marked "SS9689" which matches the MCU on the mahjong boards. I took the chip off and mounted it onto the Last Fighting
board, powered on and it works. Wow! I never thought I would see this board working again hehe!
Now if the person who still has the MCU (I believe it is CAPS0ff) can decap and/or dump it, the MCU dump can be added to all the games that
use this same hardware. Alternatively I can look into dumping the chip here as it seems like it can be wired up like an EPROM and dumped
non-destructively using a similar method I used to dump the SH2 CPUs back in July 2023. I'll probably make up a special custom Guru dumping
adapter board to make the job easier, but first some research is required.
In other news, a couple of months ago I noticed an unknown Namco System 147 board on the bay, but of course it is known to me hehe! It is the last remaining
and *interesting* S147 board that is not dumped..... Pacman Battle Royale. It's a modern 4-player Pacman with enhancements played on a 16:9
large LCD screen cocktail cab. Thanks to long time MAME contributors ekorz and rtw it was promptly bought and shipped over. I powered it up
using the same I/O board that came with Pacman's Arcade Party and it actually works fine. So the seller was basically completely clueless
with no idea what the game was or how to make it work lol! This board also requires an additional A.I. PCB I/O board that is used to control
all 4 player directions so without that board it won't boot into the game but hopefully it can be made to work in the emulation when that is
eventually done.
12th April 2024
If you have been following along with recent dumps and MAME progress you will know the graphic ROM from Xiaoao Jianghu hasn't been dumped
yet. That's because it's a very unusual 32-bit ROM in a SSOP70 package. It's possibly the first and the only 32-bit ROM ever found on
any arcade PCB. After some PCB reversing and research I got the pinout and tried to dump it manually but all those wires (70 of them!) were
frying my brain. Having worked in engineering for ~30 years I came up with an idea pretty quickly so I got to work designing a custom
adapter and added it into a recent PCB order which arrived a couple of days ago. This should allow the ROM to be hooked up more easily
without having to deal with 70 loose wires. The arcade board can use 4x 1MBx8-bit EPROMs (D0-D7 on each ROM) or it can use this strange ROM
that is 1MB x 32-bit (D0-D31).... which also equals 4MB x8-bit... which by pure coincidence is the same capacity as the 4x 1MB EPROMs
:-)
My reversing revealed when the SSOP70 ROM is used 8 bits (in order, x4) go to each of the positions where the EPROM data pins D0-D7 were. So
ROM0 (D0-D7), ROM1 (D8-D15), ROM2 (D16-D23) and ROM3 (D24-D31).
Since there is absolutely no support for any 32-bit ROMs in any EPROM programmer I figured the logical way to dump it was to hook up the
first 8 data pins D0-D7 and dump it, then hook up the next 8 data pins (D8-D15) then dump it again, repeating for the other remaining data
pins D16-D23 and D24-D31. At the end there should be a full 4MB dump once the 4 separate dumps are joined together.
Here's a pic showing the custom adapter I made with it hooked up to D0-D7. The theory was I just had to move the 8
wires to each header near the ROM and dump it as a 27C080 with 4 reads to get the full dump.
As to whether it worked or not, thanks to quick work by Osso hooking it up, I'll just let the resulting emulation speak for itself ;-)
27th March 2024
The Golden Axe board that was fixed February 21st 2024 is back again hehe! When cold there are white vertical stripes across the screen and
when it warms up the whole screen turns white but the graphics are visible behind it because the screen has horizontal lines missing.
There's also some minor glitching on the sprites (missing dots/lines)
Running the test mode 'memory check' shows all RAMs are good. But when it gets to checking the color RAM the screen *almost* fixes itself!
Now it looks ok but there are tiny horizontal lines across the screen....
So it's the color RAM, right? I swapped them but it didn't change anything LOL! This is another one of those bizarre faults that is likely
to be very difficult to find. I swapped over a working ROM board but the fault remained although the sprites looked slightly better. The
fault is definitely on the main board but the ROMs have issues too. I checked the ROMs and found one of the black mask ROMs at B7 was
actually bad, giving pin contact errors on pin 10 when I read it and multiple reads gave a different CRC32 so this ROM is definitely bad.
This is a known thing now... mask ROMs are dropping like flies and it's only going to get worse as time passes. I swapped that out for an
EPROM programmed with the correct data and it seems to have made the sprites look better but it didn't fix the white screen problem. I
plugged the ROM board into a different working Golden Axe main board and it looks perfect so the ROM board is 100% ok. It is important to
narrow down the fault to a specific board because you don't want to be working on a board that isn't faulty as that just wastes time and can
create more problems by messing with something that doesn't need to be messed with.
As they say, if it ain't broke don't fix it ;-)
System 16B has 3 big custom chips that do almost everything.
315-5195 - CPU related functions, memory controller, main glue logic etc. If this is bad the board will be dead.
315-5196 - Sprite Generator
315-5197 - Tile Generator
There's also a few logic chips (74LS244/245/374) that separate the various buses. Since the RAM passes it looks like they are ok but the
actual RAM test is likely to be very simple because it's fast (meaning it does/checks almost nothing) so it doesn't reveal a RAM that could
be marginal. These boards are also annoying because the top ROM board has to be in place otherwise it only shows a black screen so probing
has to be done on the back side of the main board. I probed around and eventually came across the 6116 (2kB x8-bit) RAMs at G2, G3, G4 and
G5 which appear to have a stuck pin 22 which is A9. I suppose it would be a good idea to consult with the schematics to see what those RAMs
are doing....
The schematic shows they connect to the custom sprite generator chip 315-5196 and pin 22 is actually grounded so that's normal. These RAMs
are connected in pairs. When shorting various adjacent pins together I noticed when pin 22 was shorted to pin 21 on RAM G4 or G5 the white
lines completely disappeared!! The sprites were of course fully glitched with horizontal lines because pin 21 is the RAM write enable
pin....
At this stage it looks like either RAM G4 and/or G5 is bad or the custom chip 315-5196 is bad. I don't see anything else involved but just
for a test I piggybacked all of the logic chips and all of the RAMs one by one (extremely annoying having to remove and replace the ROM
board 50 times) but piggybacking didn't make any difference. I pulled and tested the two RAMs. The RAM is tested in my chip tester by
writing (binary) 00000000, 01010101, 10101010, 11111111. In hexadecimal that's 00, 55, AA and FF. Then it goes onto more exhaustive checks
including count+/-, RND(256) and March U and March Y tests. If all of the tests pass you can be 1000% certain the RAM is good. The RAM at G4
failed but not immediately. It passed the 00 write but failed on the 55 write. I replaced both RAMs for known good chips and powered
on....
It works!!! This is another lucky board that lives to play again. Game NOT over heh! So there's something to learn from this, never trust the
built-in RAM test because it is almost always very basic ^_^
Now we can use this to check something in MAME. MAME ROM set goldnaxe3 has a comment in the source saying the ROM check fails on two ROMs.
This board is the same version so I checked it in the test screen memory check and it says "GOOD" for all ROMs. I read the ROMs and they
match MAME. So that likely means the decryption key for that set using 317-0120 FD1094 CPU module has to be bad and someone needs to check
the decryption key file.
25th March 2024
A Sega System 16A Shinobi board came in for repair.
The game is running with correct sprites but the background graphics are messed up. This board has a lot of Fujitsu logic chips. I went into
the test screen and ran the memory test and all RAMs passed. Unless you're very familair with this hardware (I'm not) there's no easy way to
find this problem but I figured it was probably on the bottom board. I probed around and found the background RAMs by shorting data lines.
This is the general area to look. I used my logic probe to check many chips (mostly focussing on the Fujitsu chips) and when I got to IC82
(74LS244) I found a totally dead no-signal on pin 15. I piggybacked it and that brought most of the graphics back so I pulled and swapped the
chip for a known working chip....
I powered on again and it was exacttly the same as before! I tested the old Fujitsu chip in my chip tester and it passed. I probed the chip again and
when shorting pin 15 to pin 14 it brought up the same almost-fixed screen. Pin 15 was still dead with a completely missing signal so it had
to be a broken trace. I had a quick look at the System 16A schematics. It's the usual poor quality crap done by the usual clueless cowboy but maybe
I'll be lucky.
The schematic shows pin 15 is an input (AD8). Checking the other pages doesn't show where these lines go because the other page is
chopped off on the left side! Yeah good work buddy! I manually traced it and found it went to a via just above the logic chip. I traced that
and it went no where so this is definitely the bad trace. This area of the board is a bit weathered. Scratching off the mask revealed a tiny
break in the trace. Tracing the other side shows it goes to 315-5012 pin 8 and all the other inputs from the 74LS244 at IC82 also go to
the same Sega custom (pins 4-10). I patched the trace, powered on and it's working ok now. That was a lucky one as it could have been a lot
worse.
21st March 2024
Some more Mahjong work-in-progress thanks to quick work by Osso....
Shizhan Sanguo Ji, GMS, 1998
20th March 2024 .....it's sleuthin' time!
While working on the last mahjong board dump I noticed a comment in the MAME driver (subsino2.cpp) that there's supposed to be a small
(unknown) EEPROM on the board but it's not dumped. The comment says it's used for protection and uses a 1-wire circuit to read it. I pulled
out my Bishou Jan board and compared it to the Xiao Ao Jiang Hu board....
They appear to be *identical* other than these minor differences...
- The teft board has a surface-mounted SSOP70 ROM, right board has 4 EPROMs. Under those EPROMs is the SMD pads so either can be used. I'll dump the SSOP70 ROM later after I figure out the pinout.
- The left board has a JAMMA connector and (earlier) 18-way Mahjong connectors and the right board only has the 28-way Mahjong connector
(JAMMA is present but masked off/unused).
The bottom right side of these boards has a bunch of parts that are not populated and they are both the same so that's normal. There's also
a Hitachi H8/3044 microcontroller (has 32kB internal ROM) but there's an EPROM on the board for it. If there is internal ROM it's not
important since the emulation is working as-is without it. Checking over the entire board didn't reveal any other obvious visible EEPROM so
where could it be???? After some extensive searching I found something hiding in the sound section with the surface scratched off!!!! Now
that looks suspect LOL!
It's masquerading as a transistor hehe!! The PCB even identifies it as Q3. I don't think so, bud ;-) The driver comment says the program
sends an identify command and when that passes (Device ID=14h) it reads out 64 bits of data. Experience tells me it might be a DS2430 and I
have previously dumped these devices. The datasheet says with the flat side of the TO92 IC facing me, pin 1 (ground) is on the left.
Checking the pins on the PCB shows pin 1 is tied to ground, pin 3 is tied to a resistor (removed by me in the above photo) and pin 2 is tied
to the 2SC945 transistor behind it. After looking through some Dallas 1-wire databooks I found the Family Code for the DS2430 is 14h. I
suppose the Family Code and Device ID is the same thing so that's a match. It's time to test the theory.
I first checked to make sure I'm barking up the right tree. I removed the 10K resistors (which connect the IC to a Subsino custom chip) and
powered on. With R4 removed the game still works but with R5 removed it now only shows the following screen....
This means the protection check has failed.... looks like I'm on the right path hehe!
I pulled the IC and plugged it into a random socket into pins 1 and 2 as instructed by the info that my EPROM programmer gives. It gave a
good read so I repeated the process with the other board....
btw, the same DS2430 IC is inside some Konami DIN5 dongle plugs used for protection and can be dumped the same way.
I tested Bishou Jan in MAME using my new dump and the game works so that proves the dump is good.
So the secret IC is just a DS2430.
Anyway, job done and mystery solved :-D
In other news, these just came in thanks to quick work by Osso....
San Se Cai Shen (Three Color Plutus). GMS, 1999
19th March 2024
Here's some more mahjong work-in-progress thanks to quick work by Osso.
Jin Xiu Zhong Hua (BMC 1996) (dumped. preliminary, not working yet)
Update: The remaining Mahjong boards have been dumped.
Check the PCB Arrival pic below (in the news 18th March) to see the boards identified.
WIP pics here soon, maybe....
18th March 2024
A bunch of Mahjong boards arrived, thanks to Dyq and little0.
A lot of these are on very unusual hardware. They will be dumped over the next few days although one of them might take a week or two to
figure out. I dumped one quickly that looked like it might be an easy addition; Being an IGS game there's the usual protection causing issues but here's a couple of early work-in-progress pics
thanks to quick work by Osso....
Chaoji Da Man Guan 2 Plus, IGS, 2000
Update: I just dumped another one of the Mahjong boards for a game named "Tong Zi Maque". It's the small yellow PCB on the bottom left of
the pic above. The main program ROM doesn't contain any valid Z80 code and there's no plain text in the ROM. The ROM and Z80 databus are
connected to a CPLD so it's highly likely it's encrypted and emulation is not possible. At least not anytime soon. Just a FYI ;-)
I also wired up the board but it's not working, just showing a bunch of garbage on screen. There's not much to the board, 2 big square PLD
chips, some ROMs and 2 RAMs. The RAMs had a bit of corrosion on them from a leaky nicad battery (one RAM is battery-backed) so I pulled both
RAMs and they tested bad so I replaced them hoping that it would start working but it's still dead. There doesn't sppear to be anything
else wrong with the board so highly likely this died due to losing the battery-backed decryption key which likely was inside the DS12887 RTC
module.
10th March 2024
Firstly some dumping-related news. In that large pile of Namco System 147/148 boards was a System 147(B) version of Animal Kaiser which I
dumped a couple of days ago. It was quickly hooked up in the Play! emulator and appears to be working ok. The dump was Version 1 (shown on
the title screen as just 'Animal Kaiser') but it appears with a simple ROM byte change all 6 versions can be made to show. The other
versions would have been enabled with a special card scanned in the card reader and then a byte in battery-backed NVRAM would have been
written there to configure the version that runs. So basically Namco designed this game complete with 6 versions already done so that they
would be able to sell numerous nearly identical versions of the same game with zero effort to maximize profits LOL!
I've also dumped Pacman's Arcade Party but that hasn't been looked at yet by the Play! emulator guys. Hopefully soon I'll have some work-in-progress pics of it.
Now onto a not-so-random repair. Since I now have a working Zero Point board for reference it would be a good idea to try to fix a
dead Zero Point board that's been laying around here for over 10 years. This one is dead and shows a screen full of garbage. It's missing
the audio amp and another 24 pin chip (Yamaha YM3812) which I replaced before taking the folowing pic....
But before I do that I wanted to point out a small modification that needs to be done on this game when being used in a JAMMA cabinet.
Check the following pic...
The speaker hook-up on this board is non-standard. It is able to output to two speakers. As far as I know it's just dual mono, not a stereo
output. The original amp has two inputs and two outputs but both signals appear to be identical. Anyway, when connecting a standard JAMMA
cab to the board I previously fixed, the sound was muffled/distored slightly. I thought it was a side effect of using the alternative
amplifier IC but it's an actual fault. According to the manual the JAMMA speaker+ pin is the same but the speaker- pin is NOT ground, it's
speaker2+!!! A ground has to be connected separately to each speaker from a proper ground location. If not the sound is distorted due to the
speaker- not being ground. I can bet a lot of operators back in the day didn't realise that and just used it as-is and just thought the
sound was crap on this game or didn't even notice the distortion hehe! To fix that permanently I cut the trace to the JAMMA speaker- pin and
joined the other end to ground so now the sound is clear and loud :-)
The 68000 clock and reset signals are present. Most of the logic is dead so this is a very difficult problem to find. I'll omit the part
about randomly probing around for half a day and getting no-where and skip to how I found the issue. There are 4x 74LS245 chips located just
above the 68000....
The chip on the right (closest to the 28 pin RAM) is directly connected to the 68000 and that chip connects to the 74LS245 to the left of
it. Those 3x 74LS245 chips on the left side are all disabled due to the signal on pin 19 being completely missing. It's not high or low it's
just not there. That is of course an obvious fault since that pin should be either high or low or pulsing high/low. Pin 19 is the active low
enable so it has to be low otherwise the chip does nothing. I traced pin 19 and it connected to a 24 pin PAL labelled "04". PALs generally
have inputs on one side (in this case pins 1-11 & 13) and outputs on the other side. Probing the PAL shows the input side is active but all
the outputs pins are dead. I pulled the same PAL off the other working Zero Point, fitted a socket, plugged it in and powered on. The
display was slightly different but not by much so that didn't fix it. However the PAL was now active on the output side. I was randomly
probing around and touched the PAL near the (previously missing) YM3812 labelled "02" and the graphics on the screen changed. Inspecting
that PAL revealed someone had been playing around in that area and desoldered the PAL, but then just put the PAL back into the holes and
didn't solder it in. It was just sitting there floating LOL! I soldered the PAL in, powered on and this came up....
Wow! The graphics are messed up but it's working!! Ok well I guess I'll have to try to backup that PAL at some point but for now I'll leave
the good PAL in there and try to fix the remaining faults. This board has a bunch of square CPLD chips that are used to generate the
graphics. I pushed on the chips and sometimes the graphics showed on screen. This is of course a common issue with large square chips in
sockets so I removed all the chips, cleaned the legs and socket and put the chips back. That appears to have fixed 99% of the
faults....
I swapped all the square chips from the working board to the faulty board and it didn't make any difference so I put them back. The sprites
are good so the problem is on the backgrounds only. Sometimes when it booted there were vertical lines on the screen across all the
backgrounds but sometimes most of the vertical lines were gone and it was 99.99% good with only a few random pixels out of place. Pushing on
the board sometimes partially fixed it but sometimes made it worse. When lightly touching the square chip above ROM 5 the lines almost went
away completely. This means the problem is not a chip but more likely a bad connection or partially open via, likely due to corrosion. The
lower right side of the board is not in great condition and the bottom side looks even worse with a lot of potential track rot. The square
CPLD chips previously had a bit of water damage on them so there might be some corrosion either under the square chips or under the ROMs.
Like usual that probably happened after the board died from the bad PAL and was thrown in a damp shed by the usual cowboy loser. I suppose
I'll have to remove all of that stuff and take a look. I'm definitely not going to spend days/months on this but I'll give it a few hours
and see what happens. I started by removing the square chip above ROM 5....
There's no damage under the chip. Some of the nearby vias look slightly corroded but they all connect to the square chip. I traced all the
pins on the background ROMs. It looks like a single square chip doesn't have enough pins to handle all 4 ROMs so two chips have been used.
The top two ROMs 5 and 6 connect to the top square chip and the two bottom ROMs 7 and 8 connect to the square chip immediately to the left
of those ROMs. These ROMs are equivalent to 27C160 EPROMs. Check the pinout below. Roughly they are connected like this...
To diagnose it roughly it's not necessary to know where the connections go, only that those pins for each ROM connect to those square chips.
With all the data pins traced, everything was connected except ONE pin... ROM 6 pin 20 which is D3. This would be much more difficult
without another working board but since I do have another working board I checked the ROM missing signal on my good board and found it is
supposed to connect to the top square chip on pin 47. The first pic below shows that signal routed to ROM 6 pin 20. The via just above
ROM 5 pin 23 is connected on both sides and is tied to the square chip so the trace on top that runs under the ROM sockets is broken somewhere.
I'm not going to remove the ROM and patch the trace so I just added a wire on the bottom side of the board joined to the via and the ROM 6 pin
20 then powered on....
WOW!! That fixed it and now everything is perfect. It was really just luck that the damage was isolated to only one pin.
I found a uPC1241H amp chip, soldered that in and sound is perfect too so now I have two fully working Zero Point boards :-D
3rd March 2024
A few more Namco System 147/148 boards arrived.
2 more junker Animal Kaiser boards and (FINALLY!!) one of the good games on this system.... Pacman's Arcade Party, which is basically PS2
Namco Museum 50th Anniversary. The owner asked me to look into repairing the Pacman board so there should be a future repair about
it.
Of course they're all non-working due to having crap blown over the board from the fan.
Remember to keep your boards clean, people!
I'm still looking to get hold of the last remaining known good game on this system.... Pacman Battle Royale. It's a cocktail type cabinet
with 4 players on a 16:9 screen with modern and enhanced graphics. There are extra power-ups including one that lets the player eat the
other players hehe! Looking at vids on youtube shows it's a really fun game so we need to get hold of it before they become extinct.
If you can help with that, contact me.
A Zero Point (Unico 1998) board came in for repair. The game is mostly working but the graphics are totally screwed up and there's no sound...
There are 2x DIP28 62256 SRAMs near the bottom of the board which are for the foreground and background layer tiles. Piggybacking both RAMs almost
fixed the graphics so I changed out both RAMs....
I tested them later and as expected they were both bad.
Now the foreground and background graphics are good but the sprites have horizontal lines through them....
It's a bit difficult to see in the pic but the bottom of the P should be solid whereas it looks partially transparent now showing the green
background through the P. The horizontal lines likely means some logic is bad because horizontal lines through sprites is unusual. The
normal fault is vertical lines which means a sprite ROM related fault or logic connected to the sprite ROMs. I probed around and piggybacked
a few chips and the only chip that affected the horizontal lines on the sprites was a 74LS374 at the top of the board near a bank of
SRAMs....
But piggybacking all of those chips (including the RAMs) did nothing. The bank of 6116 SRAMs at the top are for the sprite screen display RAM.
There is another bank of 6116 SRAMs just above PAL 09 (check the larger board pic at the top for that PAL location) and those are sprite tile
generator RAMs. If the sprites are scrambled then those RAMs could be bad. In this case the sprites look ok just with lines through
them so it has to be related to the bank of SRAMs at the top. Probing those RAMs showed the top two RAMs had a nasty/dirty sounding signal
on pin 22 (both RAMs are tied together). The datasheet shows that pin is A9. I traced the pin and it was tied to pin 11 of a nearby
74LS161..... GS-branded (Goldstar crap!). I noticed that the same signal was also on the same chip on pin 10! I checked the
resistance between pin 10 and pin 11 and it was around 3.7 ohms. It looks like the two pins are shorted together. I pulled the chip and it
tested bad on pin 11 (stuck low) so I replaced it :-)
To my surprise it didn't change anything and the fault remained! At this stage I can't trust any of the shitty Goldstar chips so I pulled
and replaced the remaining 5x 74LS161 chips. One of the 161 chips tested bad on pin 13 but all chips were replaced. Never put GS chips back
on a board even if they test good!
So with the sprite problem fixed it's time to look at the sound. There is a LM324 op amp chip located near the audio capacitors. Probing the
4 outer pins (1, 7, 8, 14) gave some audio on my logic probe piezo speaker. This means the sound is working correctly. Touching a wet finger
to the pins on the main power amp IC did not make any pop sounds. I checked the main power amp and it was burning hot so it's probably
blown. This is an unusual amp type and I didn't have a spare in stock (SEC KA22065 with PCB silkscreen KIA8207 which is likely a compatible
part). I removed the amp IC and underneath there were alternative holes silkscreened 1241. This is likely to be a NEC uPC1241H amp IC which
I had plenty of spares in stock. I soldered a new one into the board and that fixed the sound :-)
21st February 2024
A Sega Golden Axe board came in for repair from a local friend....
The game is working but the colors are screwed up. The test mode CRT check shows it better VS MAME....
The graphics look ok so the issue appears to be at the final output color mixing stage. Let's check the schematics...
This page shows the RGB output section. The way to diagnose this is to find the RGB outputs and trace backwards, checking each part until
something bad is found. There's not a lot going on here. The outputs connect through a resistor DAC, then to 2x 74HC273 logic chips, then to
the color RAM then to 2x 74LS245 logic chips that connect to the main program data bus (which is working fine). I have previously gone into
the test mode and run the memory test and all RAMs pass so it's not the color RAM. These boards are a bit annoying because the ROM board has
to be on top to test it so it's difficult to probe stuff while the power is on so I just skipped all of that. I piggybacked the 2x 74HC273
chips and powered on and it almost fixed the issue so I removed them and swapped in some new 74HCT273 chips. The original chips are branded
NEC and both tested bad with some outputs stuck which is not unusual but interesting in this case as both are bad and these are the only NEC
chips on the board. Maybe a bad batch of chips so something to watch out for in future when repairing System 16 boards....
I re-tested the board and everything is good....
9th February 2024
While I'm playing with Midway Y-Unit hardware I decided to attempt the resurrection of a dead Smash TV board that was in really bad
condition. Looks to have been left outside in a damp shed which (like usual) probably happened after the board stopped working....
Basically every socket is rusted and the legs of all the socketed chips are rusted.
The really funny thing is I've probably seen it before, about 23 years ago. This board was likely to have been present and sold while I was
working part time (between 1999-2005) at Filtek Australia because there's a card attached to the board...
Well actually I wouldn't say 'working'. It was more like playing with stuff and getting access to anything I could lay my hands on and
dumping it, and occasionally fixing some stuff. A lot of the arcade games in MAME came from boards I dumped at this same place from the
massive pile of crap they had stored over the years. After years on a long journey with an abusive nasty old mean and clueless owner it has
finally returned to its rightful home LOL!
I first removed all the socketed chips and washed the board in the sink using a small paintbrush to scrub off the dirt then I rinsed it with
clean water and left the board outside to dry in the sun for a few hours....
The result was a spectacular transformation from a piece of crap into an actual good looking arcade board. I removed and replaced
several sockets, cleaned the chips with fine sandpaper then plugged in the chips and I was surprised to see that it works hehe!!
Wow talk about lucky!! I played a game and some sounds were missing. The title screen has a Smash TV logo that drops down from the top and
makes a boom sound then it slides out to the right and makes a whoosh sound. The whoosh sound was there but the boom sound was missing and
also the power-on self test 'bong' sound was missing. In the test mode when moving up/down on the menu items the 'clang' sound was also
missing. I ran the game in MAME and pressed the tilde (~) key. This brings up a menu that has selections for adjustment of various things
including volume of each sound chip. I reduced the volume of each listed chip to zero until it sounded the same as the real board. It ended
up being the MC1408 DAC. These boards are all very simple and are actually the very same sound board used on Williams System 11B/C pinball
games with what appears to be little or no changes. The sound at power-on is the same classic 'bong' sound heard when powering on all Williams and
Bally pinball machines from around 1989 onwards. This is the board I have that came with the Smash TV main board....
The board number is 5766-12130-00 REV. - D
I have another sound board here from a High Impact. It's nearly identical....
This is board number 5766-12702-00 REV. B
I swapped that over together with the ROMs. I first had to replace the amp IC because I had taken both of them when fixing some other games
years ago (pic above shows it after adding the amp IC). I didn't have a TDA2002 but I found one TDA2003. Checking the datasheet shows it's
the same pinout as the TDA2002 with a higher wattage rating so it's compatible. One is enough for testing since the wiring harness only has
one audio volume pot wiring connector plugged in.... these boards need the volume pot connected otherwise there's no sound at all (same as
Mortal Kombat, NBA Jam etc). I soldered the amp IC into the board, powered on and it was opposite.... the power-on bong and title screen
bang sounds were present but the whoosh sound was missing. I checked the board. It looks clean but the axial electrolytic cap at C11 is
missing! The schematic shows C11 is connected to the C1-55536 IC on pin 3 which is the output pin so the whoosh sound is generated by that
chip. The only other visible changes are the ROM sockets which have 32 pins to allow for larger ROMs but the original Smash TV 27C512 EPROMs work
fine (note the orientation and position!). Some of the white jumpers are also in slightly different positions but nothing needs to be
changed. I found another new cap and soldered that in and the sound board works perfect! I could just leave it there but I want to know what
chip is causing the fault on the other board. There's a fairly easy way to check all the sound amplification-related chips and find the bad
chip. With a wet finger simply touch the bottom pins on the MC1408, C1-55536, 1458 (x4) and the YM3012 (and if all sound is missing also
touch the TDA2002 main power amp). A faint pop sound should be heard. I got the pop sound on all chips except the MC1408. This chip requires
negative voltage on pin 3. It measured -5V so that was ok. The output on this chip is pin 4. I had previously measured the voltage on that
pin on the working board and it was around -0.637V and drops slightly when audio is playing. On the suspected faulty chip the voltage was
around -0.78V and didn't move when audio was playing. I swapped out the MC1408 taken from the working board...
I powered on and I heard the bong sound and figured it was fixed. But after about 30 seconds I heard the bong sound again. It continued to
repeat about every 30 seconds! Maybe I screwed something up somewhere or maybe something else has gone bad. It seems like the board is
resetting. I checked the reset pin on the 68B09E (pin 37) and sure enough it went low then high just before the bong sound, meaning it's
watch-dogging. I need to check where the reset comes from on this board. Unfortunately there are no Midway Y-Unit manuals with
readable sound board schematics. Since this board is used on Williams System 11 I googled and found a System 11 schematic which just
happened to be for Banzai Run. The board layout diagram shows the part number as "5766-12130-00 Bare P.C. Board". So this is a perfect match
for my board. Niiiiice! The part number on the schematic is "D-11581". The schematic is 100% readable. Many years ago when working at Filtek
I scanned a LOT of pinball manuals (probably over 100 including a near-full set of Gottlieb manuals ^_^) and Banzai Run was one of them so
this might actually be one of my schematics. I'm pretty sure it is because it's a 600DPI greyscale scan and that's the same settings I use
hehe!
Anyway, the schematic shows the reset comes from the main board on pin 18 of the data connector J4. That means the main board can't 'see'
the sound board. The bong sound is automatically generated by the sound board only so that explains why that sound is heard and no other
sounds are generated. I was just about to go in deeper and look for the cause when I noticed the red stripe on the flat data cable didn't
line up with pin 1 marked on the board. OOPS!!! I quickly swapped the cable around before anyone noticed LOL!
Ok I'm dumb. So with the cable around the right way everything is working perfect. So the only thing I found bad on this game was the MC1408
DAC on the sound board? That's wierd! It looks like this board was fully working and just abandoned at some point in the past by the
previous owner and was actually working fine until it got wet LOL! Not to worry, now it's in good hands and I will take good care of it :-)
A bit later I was checking the game in MAME and I noticed something. While doing the sound board repair I have been going into the sound
test to check it so I'm very familiar with how it looks. In MAME in the sound board test a screen shows with some text "SOUND BOARD TEST".
Comparing that with the real board shows....
It's different!!! WOW!! The real hardware shows additional text with the name of the sound that is being played. Could this be a bug in
MAME? I checked all the versions and none of them show the sound names. So yeah looks like I found a bug with MAME vs the real board and for
20+ years no-one noticed it hehe!
While playing the game I came across another wierd thing. The real cab uses two joysticks with firing on the 2nd joystick so firing opposite
directions simultaneously is impossible since it's a joystick. However with the real board plugged into any JAMMA cab the firing
up/down/left maps to buttons 1-3. While playing I accidentally pressed buttons 1 and 2 together.... that's an impossible up and down firing.
The screen blanked out grey and eventually reset itself back to the title screen. I tried it again and this time when the screen was grey I
pressed the on-board reset button. A screen showed and I had a WTF moment hehe! I googled and found by pressing reset while in a game it
activates the cheat warp #3 stage skip.
It's documented on the net, search "WARP #3 ACTIVATED = SECRET KEY".
You can trigger it in MAME simply by starting a game, wait until the enemies start coming at you then press F3. The game checks something in
the NVRAM and sees it's an in-game crash so gives the player a skip and bonuses then continues from the next level. However in an arcade
that would never happen since the PCB reset button isn't accessible so this cheat will never happen in operation. The game will simply reset
after about 5 seconds back to the title screen. It also seems to remember it happened and doesn't crash again even when multiple fire
buttons are pressed together at the same time. Since holding buttons 1 & 2 (fire up + fire down) doesn't crash the game in MAME and the
screen doesn't blank out it means that something isn't emulated correctly. So that's another thing that no one noticed for 20+ years ;-)
Another FYI thing, I tested out trying to convert any of these Y-Unit boards to a different game. Unfortunately it's not possible. I
discovered that there are several revisions of the main boards. Normally it would not be a major issue but the revisions are located around
the various game-specific PLD (i.e. protection) chips. As well as that there are some additional wire mods on the bottom of some of the
boards. I suspect that the PLDs that are game specific have been programmed based on those game-specific board revisions and wire mods. This
means swapping in a different game is nearly impossible unless the board modifications are studied in detail and documented for EACH game
and EACH board revision. Basically it's too much work so it's not going to happen. So if you are going to try to replace a board with one
that is damaged and unrepairable be sure you replace it with exactly the same board revision and apply the same wire mods otherwise it's not
going to work. In my case I was trying to get Mortal Kombat working on a High Impact board. The best I could get was I had the game
working but all of the 8Mbit mask ROMs tested bad on the power-on test. In-game graphics were scrambled and there was no way to know exactly
what was causing it despite adjusting some of the wire mods to suit the traces on my working Mortal Kombat board (which actually had no wire
mods). So be kind to your boards and don't leave them in a leaky shed for ~20 years and if you are lucky they will stay working for many
years.
February 3rd 2024
After repairing the previous Mortal Kombat I figured I could try to fix a totally dead Mortal Kombat board I've had lying around for
possibly 10-15+ years. Now that I have a working board for reference I was hoping it could be helpful for repairing my board. It's not
totally dead-dead, it shows the start-up 'rug' pattern but it looks very strange and then the screen goes black. This looks like a
protection check failure. I swapped over all of the socketed chips. To my surprise it came up....
Wow it's mostly working!! After pressing any button the game screen came up and the game is running with huge graphical issues....
I swapped back the chips one by one and eventually found the bad chip. Unfortunately it was the 40 pin protection chip
"5346-40025-8".
I looked through my boxes of random old chips and found another similar chip without a label. This was an Altera EP910
whereas the original chip was an Intel P5C090-50. These two chips are compatible. I swapped in the chip and powered on and got the
same test error screen so it looks like the chip is good. That was super lucky!
I will keep the bad chip for test and practice purposes for a future decapping effort. The chips are EPROM-based with a separate protection
fuse, very similar to an i8751 MCU so deprotecting these and dumping them might be similar.... decap, mask off the EPROM with paint (except the
protection bit area), UV erase it and then read out the EPROM. We need to get hold of all of those protection chips on Midway Y-Unit boards
because they are at risk and need to be decapped so they can be re-programmed to a new chip for repair purposes (and to improve emulation)
otherwise when they die it's game over permanently.
Getting back to the repair, now to fix the other errors. The red chips are RAMs. They are a very strange type of multiport RAM with a parallel access mode and a serial
access mode. The exact chip on this board is V53C261 which I previously had not seen.
Here's a list of compatible RAMs that can be used on these Midway Y-Unit boards....
Hitachi HM53461
Fujitsu MB81461
Texas Instruments TMS4461
Micron MT42C4064
NEC uPD41264
Vitelic V53C261
I swapped the 3 bad RAM chips for known good chips and that fully fixed the main board. I plugged in the Mortal Kombat sound board
I repaired back in October 2022 and everything works perfect so that's another board rescued from the junk pile :-D
28th January 2024
A couple of boards came in for repair....
Mortal Kombat
The game works but colors are messed up. The obvious place to start is the color RAMs which are located at U5 and U23. I piggybacked U5 and this showed on screen....
Look like the RAM at U5 is bad. Nothing showed up as bad before because Midway used red text for the errors. They should have used a color
that wasn't red, green or blue so that error text always shows heh! Anyway, I swapped it with a good chip and that fixed the
problem.
Blood Bros.
The game works but the music is missing. To diagnose this I first scoped the YM3014 DAC on pin 2. This is the analog output. There was activity on the scope so the DAC appears to be working. The issue is going to be the HB-41 hybrid module. To test that I bypassed it by jumpering pin 2 of the DAC directly to the main audio amp....
The music was audible, but obviously it's going to be distorted because the signal level is wrong (too hot), but this proves the digital
audio section is working correctly. Checking the pinout on my HB-41 schematic
(available on my Reverse Engineering Page) shows the audio from the DAC goes into pin 17 of the
HB-41, through an op amp, out on pin 16 of the module to the PCB and back into the HB-41 on pin 5. I jumpered a wire from module pin 17 to pin 5
(or DAC pin 2 to module pin 5) and music was also audible and even didn't have any distortion heh! This proves the 1st op amp on the HB-41 is bad, and of course I already knew that
because that's the part that most often fails on the HB-41 ;-)
The quick fix is to simply jump a wire from the module pin 17 to pin 5 and that should be more than good enough to fix it. It depends on
which part of the 1st op amp fails. For this particular module half of the 1st op amp was ok (OKI M6295 sound effects) and only the music
was missing, but it might require joining module pins 13 and 16 together if the whole 1st op amp was dead (I need more dead boards/modules
to experiment with hehe!). In my case I replaced the module with my re-production HB-41 and that fixed it :-)
26th January 2024
A few weeks ago when repairing several Space Invaders boards I mentioned the L-board I have would be a good candidate to reproduce. That has
now been completed. As per my usual stance on these things the board is 100% 1:1 identical to the original without any signs of being a
reproduction, although obviously it looks new so can't be mistaken for an original board ;-)
The trace layout was initially based on an original Midway PCB schematic and a scan of the board was used as a guide to trace over the
copper. PCB softwares are very good now and have lots of ways to verify things. The schematic and PCB trace layout are synced, and with the
additional PCB scan as reference I quickly discovered that the actual PCB had several changes vs the schematic. So I updated the schematic
to match the PCB. That means now there's a proper Midway Space Invaders schematic that matches the real PCB for the version using 8x 74LS151
chips for the shifter circuit. All parts are common off-the-shelf parts so it's 100% fixable no matter what happens :-)
The PCB image is very large (approximately 11MP) so view it full size and browse around to see the detail :-)
I might do some minor cosmetic tweaks to this just for my own satisfaction but as-is currently this can be considered 99.99999% complete.
Obviously I can not actually test the PCB yet since it hasn't been made but the gerber files will be made available here soon (most likely
in the next post) if you want to play with it yourself :-)
The schematic will be held for a few more days until I triple verify PCB vs schematic just in case I missed something non-obvious, but then
it will be made available. Update - Schematic is verified 100% and schematic pic/link above is active. Hopefully someone familiar with MAME and discrete circuits can fix MAME's terrible Midway Space Invaders sound
for the fire circuit which currently sounds like it might do when squeezing a duck's nuts hehe!
10th January 2024
A couple of items arrived for dumping....
- Black Rose Rapid Fire Grand Prix QLD (Konami Endeavour). The EPROMs were already dumped
and in MAME. The flash ROMs are now dumped and should be added to MAME soon.
- Aristocrat MK7 main board. The BIOS EEPROM can be dumped but this is basically useless and
will never work in MAME since it uses an Intel Celeron M 440 (launched 2006, SL9LF, 1.86GHz / 1M / 533),
Intel 82945GME Graphics/Memory Controller and a bunch of protection chips including a SIM
card slot and Altera Cyclone II FPGA. In the PCIe-x16 slot was a dual DVI card with a couple of Silicon Image
SiL1364ACNU chips but no dumpable parts. The video is generated by the Intel SLA9H Video
Controller and sent to the DVI outputs via the PCIe-x16 card.
Update: Here's a couple of screenshots from MAME thanks to quick work by Osso....
The remaining undumped Konami Endeavour games are Russian releases and unlikely to be dumped so
this is probably the last Endeavour game that will be dumped by me unless some other
Australian versions are found. Additionally, no one seems interested or has 10 minutes to fix the last
remaining issue of getting past the cabinet door switches so all Konami Endeavour games
are still unplayable :-/
13th December 2023
Here's a vid showing some emulation progress of the Namco System 148 Animal Kaiser board I dumped a while back.
Now it's playable with sound and is looking pretty good! The other System 147/148 boards I
have secured are not very exciting, just some more Animal Kaiser and a coin pusher called
Sea Story. What we really need is Pacman Battle Royale and/or Pacman's Arcade Party
boards. If anyone has one of these game boards or any other Namco System 147/148 boards
(working or not working) and wants to loan or donate it so it can be dumped, contact me.
Update: The version info has been figured out. It just needs a few bytes changed. Since Evo 8 is dumped and previous Evo versions were
simple software updates, it means all previous Evo versions are also dumped. Here's a pic showing all Evo versions from 1 to 8....
Basically it's just a scam and all versions are near identical LOL!
12th December 2023
Update to previous news.... and here's the new design with 16 banks of 16 games (16 x 16 x 4kB)
allowing selection of 256 games using 2x 16-position hexadecimal switches and a TSOP48 1MB
flash ROM....
I also removed the (silly and mostly unused) 74LS04 chip and replaced it with a single
gate 74LVC1G04 since there's only 1 inverter gate being used (for chip select). No point
having a full 4-gate 74LS04 on there and I have the single gate part in stock. There's
also a lot of routing clean-up too, no more spaghetti wiring ;-)
Of course this design is technically not new. There are some open-source nearly identical
designs already out there that use larger DIP32 EPROMs and similar hexadecimal switches.
This design just makes it cleaner and is using all SMD parts.
10th December 2023
I recently picked up one of the new Atari 2600+ consoles.
It comes with a 10-in-1 pack-in cart. Here's a pic of it running on my 55" 4K TV.... pretty nice...
But wait a minute!! I don't remember the 10-in-1 cart including Space Invaders??? And
what's that little yellow thing on the cart??? Hehe! Well I hope you don't expect me
to run this as-is? The 10-in-1 has some 'ok' games but a few of them are just crap and there
are only 10 games. Of course this has been Guru-fied.
To make sure I understand how this thing works I first removed all the parts and
re-created the board 1:1 in Eagle PCB.
There are plenty of open-source Atari 2600 carts out there and some are basically the same
as this cart using a DIP switch or jumpers. While not strictly necessary this
gives me a working base design which can be modified so more carts with more games (up to
256) can be done later using a larger TSOP48 flash ROM. The 2600+ is an Arm-based
emulation box very similar to those cheap Android TV boxes. It is a 'cart dumper' so when
the cart is inserted it tries to dump the ROM to the internal RAM running on the ARM-based
board and runs it from there. This has the main issue being that it can't handle any
special carts like Pitfall II (for example, but there are many others). It's also a little
bit too anxious to dump the cart as sometimes loading the game fails although it does
retry automatically (but only once) then it loads fine.... although sometimes it just
crashes the unit. I don't mean a bad read due to a dirty edge connector. I mean it's
continually polling the slot for a cart with zero delay and can sometimes be trying to
read the cart whilst in the middle of selecting a game LOL! This is very noticeable when
swapping carts.... games can be hot-swapped on the fly which saves having to power-cycle
the unit. People who own real Atari 2600 units will find this a strange and forbidden
concept but that's how you're supposed to swap games, otherwise you're continually
power-cycling the unit which takes more than a few seconds to boot up. But they screwed it
up slightly. There really needs to be a 2 second delay after cart insertion before trying
to dump the cart. A firmware update will fix that but it depends on Atari seeing this and
caring about it as well as fixing other issues like allowing multi-carts like the Harmony
to work. Time will tell if they fix that in a future firmware update. Anyway, the stock
way they allow the user to swap games is with a 4-position DIP switch since the 2600+
isn't compatible with carts that use a game select menu or special multi-carts like the
Harmony cart. They simply 'hardwire' the game (limited to 4kB without any bankswitching
methods) and then it dumps it and runs it. This is done by grounding one or more of the 4
upper address lines on the ROM. There is a 10k pullup resistor pack on those same address
lines which pulls all the lines high by default. The DIP switches can be toggled while the
power is on and pulls those lines low and if it's a valid combination it will re-read the
cart automatically. Here's a pic of the board with a very simple modification which makes
game selection MUCH simpler and quicker....
This is a hexadecimal 16-position rotary switch. You can easily buy one for a few cents,
remove the 4-position DIP switch and solder on the rotary switch yourself. There are
several types so be sure to get the correct one that drops in without any modifications.
The switch has 5 pins. 4 of them go to the upper address lines and the single pin on the
other side of the switch goes to the ground side of the DIP8 footprint. The rotary switch
protrudes through the cart case just like the DIP switch did and it's very easy to change
games without having to remove the cart, unlike the DIP switches where likely most people
will remove the cart and change the switches by hand. Here's a pic of the back showing the
mounting/orientation...
Of course being a Guru of all things ROM-related I'm not going to just let this go and be
done with it. No no no. I want games on this cart that I like. So that's what I did. The
cart uses a TSOP32 14mm x 8mm flash ROM that is only 64kB in size (SST39VF512). This
allows a maximum of 16x 4kB games. Unfortunately Atari only actually put 10 games on the
ROM (40kB) and the remaining space (24kB) is 00-filled (no hidden games hehe!). So I got a bunch of 4kB games and
then erased and re-programmed the flash. This isn't so simple to do as I don't have the
TSOP32 14mm x 8mm adapter here since there are zero arcade games using that type of ROM,
hence no previous reason to buy it. The quick solution is to simply wire up the cart pins
to a DIP socket and plug that into the EPROM programmer....
However there's a few issues. First, the pull-up resistors and most of the other parts
need to be removed otherwise it will interfere with dumping/writing it. Not a problem for
me as all parts were removed anyway hehe!
The next issue is a trace must be cut since pin 32 is hardwired to ground and that's the
OE pin which must go high in programming mode. Not a problem though, just cut the trace
and re-join it with a tiny wire later. Note pin 32 is wired to ground in 2 places so BOTH
traces must be cut....
The next issue is whoever made the cart doesn't fully understand the original cart pinout
numbering. The silkscreening on the pins is actually wrong with numbers for pins 1 & 12
and 13 & 24 printed on the wrong side of the board. I realised that pretty early on while
reversing it hehe! Here's a pic showing it....
There are resistor packs on the address lines because the flash ROM is a 3.3V device but
is connected to the cart slot which is designed to take old carts that run on 5V. Those
resistor packs limit the current so the flash ROM doesn't get damaged by the incoming
logic levels which range from 0-5V. If you check the official cart pinout pin 1 is A7. On
the 10-in-1 cart pin 13 is shown connected to A7. The cart is fine just the silkscreen is
wrong. But oops!! Hehehe!
The next issue is due to lack of the TSOP adapter so I manually wired up the board
correctly and it was a simple process to dump (for backup) then erase and re-program the
flash with my set of games, which includes....
Game Hex# Binary#
---------------------------------
Tennis F 1111
Chopper Command E 1110
Defender D 1101
Dragster C 1100
Berzerk B 1011
Frogger A 1010
Keystone Kapers 9 1001
Space Invaders 8 1000
Missile Command 7 0111
Enduro 6 0110
Carnival 5 0101
Q-Bert 4 0100
River Raid 3 0011
Yar's Revenge 2 0010
Bowling 1 0001
Dodge-Em 0 0000
These were all selected because they are good games but also have a lot of replayability.
For this cart design it is limited to 4kB ROMs. There are many games that are better than
this selection but unfortunately they are larger than 4kB. Also be sure to select the PAL
or NTSC version for your region otherwise the colors will be wrong. Note in the list above
the 2nd column shows the ACTUAL order that the games are selected. The 1st column shows my
ROM programming order but it's not the same as the game selection order. This is because
the hexadecimal switch pulls address lines A12-A15 high/low in a different order. In my
case it's fine as I don't care but I can simply rotate the switch in the other direction
F-0 and I will get the same order as the ROM order :-)
If you want the games in alphabetical order or some other order be sure to create the ROM
so the order follows the hex numbers 0-F. To create the 64kB ROM image just use the command line with the following command....
COPY /B ROM1.BIN + ROM2.BIN + ROM3.BIN ROM4.BIN + ROM5.BIN + ROM6.BIN + ROM7.BIN +
ROM8.BIN + ROM9.BIN + ROM10.BIN + ROM11.BIN + ROM12.BIN + ROM13.BIN + ROM14.BIN +
ROM15.BIN + ROM16.BIN 64KROM.BIN
With the cart inserted into the 2600+ it is a simple matter of rotating the hexadecimal
switch to the game you want and it will be auto-loaded. But remember due to not having a
load delay sometimes the ROM won't load or just crashes the unit because the ROM wasn't
dumped correctly. In this case you need to power-cycle the unit.
1st December 2023
Here's a quick update to the Midway 8080 main board 80-900C. Making it run the 2716 Space Invaders roms is a bit
more work with more wires. Additionally all the sockets are screwed so I would have to change at least 4 sockets
too. There's a MUCH easier way to convert it to use a larger EPROM and it only needs 5 wires. The 74LS42 or the
original 74LS138/Intel D3205 can even be removed and/or the chip select mod completely skipped. Simply use a 2764
EPROM and put the entire Space Invaders code inside one single chip. There are some 2764/27128 mod infos on the net
but it can be simplified even further as EPROM pins DON'T need to be bent out. This mod is for a 80-900C board
but it can also be applied to later boards too.
Get a 2764 EPROM and program it with the Space Invaders code. To join all the ROMs using the MAME 'invaders' ROM
set, unpack the ROMs into a directory then bring up a command prompt in that dir.
Type....
copy /b invaders.h + invaders.g + invaders.f + invaders.e invaders2764.bin
This creates a new file that is 8kB in size.
You can download the pre-merged ROM file here.
Burn the 8kB file to a 2764 EPROM and put it into the socket at position H with the top 4 pins
overhanging the socket. Leave all pins 3-26 in the socket, no need to bend any legs out.
WIRE #1
Solder a bare wire from pin 26 to 27 and 28 and 1 on the EPROM. That joins all those pins to +5V with 1 wire :-)
WIRE #2
Solder a wire from EPROM pin 2 to pin 4 of the D3205/74LS138 at E2. This is AD12.
Alternative location is 74LS08 at F3 pin 3
WIRE #3
Solder a wire from jumper S2 to pin 3 of the D3205/74LS138 at E2. This is AD11.
Alternative location is 74LS08 at F2 pin 11
WIRE #4
Solder a wire from jumper S3 to pin 2 of the D3205/74LS138 at E2. This is AD10.
Alternative location is 74LS08 at F2 pin 8
WIRE #5
On the bottom of the board solder a wire from pin 12 of the H socket to pin 20 of the H socket. This grounds the
EPROM pin 22 (OE). Also jumper S5 to ground as shown in the pic below. This grounds pin 20 of the EPROM (CE).
Thus both CE and OE are grounded. This works because there is only 1 EPROM so the ROM is enabled permanently.
Break off or remove all the capacitors between the original ROM sockets because they will interfere
with the address signals when using the 2764 EPROM.
That's all. Power on and it runs Space Invaders using one 2764 EPROM :-D
30th November 2023
Well that didn't last long. The Space Invaders test ROM now fails again LOL!
It seems to be the same bit 6 but not as bad. The game runs and looks perfect with no visible issues.
Here's a better look at how the shifter-related bits are laid out on the board....
I pulled the chip I just replaced and tested it in my chip tester and it failed....
But not immediately. It runs 18 passes to fully test input pins d0-d7 and it fails on pass 17.
Here is the full vector test...
0101LH1G1010101V
1010LH1G0101010V
1110LH0G0001111V
0001HL0G0000000V
1101LH0G0011111V
0010HL0G0010000V
1011LH0G0101111V
0100HL0G0100000V
0111LH0G0111111V
1000HL0G0110000V
1111LH0G1001110V
0000HL0G1000001V
1111LH0G1011101V
0000HL0G1010010V
1111LH0G1101011V
0000HL0G1100100V
1111LH0G1110111V
0000HL0G1111000V
pass 17 does the following...
> 3210YWg CBA7654
> 1111LH0G1110111V
All inputs, except D7 = H
/G is L (enabled)
ABC are H (d7 selected)
Y is L
W is H (=/Y)
So it seems that when d7 (the pin, not the bit) is selected it returns the wrong result. It must be a very minor fault
because as I said the game runs fine and looks perfect. Anyway, with the chip changed for another one the 'SHIFTERS=OK'
message shows when running the Space Invaders test ROM so the issue is fixed.
With the first board fully working now it's time to look at four more Midway 8080 main boards that have been lying
around here for many years using the working Space Invaders L-Board.
The 2nd Midway 8080 Main Board. I set the jumpers for 2716 EPROMs, plugged in the test ROM and powered on. The error
shows RAM G is bad...
The RAM positions are documented but the image is low quality. We can do better....
It looks like someone (clueless) was here before because there are some big X marks on several RAMs. I piggybacked the
RAM at position G and all tests pass. I plugged in the Space Invaders EPROMs, powered on and it works 100% hehe! This
was a lucky one, just one bad RAM. When changing any chip on these boards be extra careful about the removal because the
traces are fragile (read that as 'rubbish'). Also be careful about using too much solder because there are traces
between the pins and they do not have PCB solder mask paint on top of them so it's very easy to make a short to an
adjacent pin.
The 3rd Midway 8080 Main Board. This one has a few issues. A chip is missing, the crystal is broken, the CPU is
missing and written on the board is 'short 12v'.
A 12V short can be a common issue on these boards because there's a few (usually blue or green) tantalum capacitors next
to the RAMs. I checked them and one cap had legs that were shorted together. I unshorted the legs but the 12V short
didn't go away. On the bottom where the cap is there's a tiny trace going between the cap and a thicker trace. That
trace was broken and touching the thicker trace. I resoldered the trace in the correct location and the short went away
heh! The broken crystal appears to have been pulled out on both legs. These Midway 80-900K boards have what looks like
socket holes for the crystal. The top tin-can part of the crystal has been pulled off the bottom part and is just
sitting there. I pulled on the top part and it came off. I will replace it later but I want to see if it works.
Checking the other working main boards show the missing chip is a 9310. That's a fairly rare chip now. Fortunately the
93-series chips are simply Fairchild versions of common logic chips. Here's a few that are on these 8080 boards and the
more common 74-series equivalent....
9310 = 74160
9316 = 74161
9321 = 74139
9322 = 74157
I replaced the missing chip with a 74LS160 from my parts box. These are also not so common on arcade PCBs but luckily I
had a spare. I also put a good 8080 CPU into the socket. Powering on the board shows that the crystal and test ROM is
working. It came up with a RAM error at location 7....
I pulled the RAM at position 7 and it looks a bit strange underneath, like all the pads have been ripped off the board?
All the other RAMs are like that too so it must be normal for this board and only has pads on top where those pins have
traces joined to them. Either that or some clueless cowboy changed all the RAMs and pulled off all the PCB pads LOL! I
powered on the board and the test ROM passes so I put the Space Invaders ROMs on the board and everything is working
perfect... another lucky board that wasn't abused and a simple fix :-)
The 4th Midway 8080 Main Board is a bootleg....
It appears to be a 100% knock-off of the Midway 80-900K board (edit: no it's probably based on an earlier rev). It was
missing all the ROMs, the 8080 CPU, the same 74LS160/9310 logic chip and all the DRAMs (which luckily have sockets). I
replaced the missing parts and jumpered the board for 2716 EPROMs. The three jumpers at 'S6' had to be cut and re-wired
as they were wired straight-through for 2708 EPROMs (the normal Midway 2716 jumpering is at an angle as shown in earlier
repair logs). I went to plug in my harness and saw it didn't fit because the bootleggers made it a 22-way connector LOL!
Those bootleggers had some nerve trying to make a new standard.... I don't think so bud! The extra 4 pins are just more
grounds on the top side and 5V on the bottom side so not required anyway. Goodbye! LOL!
With the edge connector now using the standard 18-pin Midway 8080 L-board pinout I powered on and it showed a black
screen / dead board. These boards usually show a pattern of vertical lines even without any EPROMs so a black screen means a
missing clock near the beginning of the clock circuit. The schematic shows the clock circuit with the green area being
the main clock-gen circuit and the red lines are video clocks coming out of a couple of 74LS74 logic chips....
In this situation the easiest way to troubleshoot it is to use a logic probe and just probe the output pins on the chips
in the green area and the red output lines on the 74LS74 chips, basically just looking for a bad or missing clock. The
74LS74 chip at A5 (shown on the schematic in two places since it's a dual flip-flop) had a signal on input pins 3 and 11
but all the other pins were dead. I changed that chip and now it shows something on screen...
Without the EPROM plugged in the vertical lines are almost correct. The minor horizontal line garbage means there's
something wrong with the address lines according to the Midway 8080 Test Procedure Manual. This is where the repair blew
out to 2 days hehe! I went over the board many times looking for any chip that was suspect but I couldn't find anything
wrong. It turns out that the first socket was missing the ground trace to pin 18!! LOL!! It might have been there years
ago and fell off as there were soldering remnants on that pin. I changed the crappy socket to a new dual-wipe socket and
added a wire to pin 18 which is CE (chip enable) which needs to be tied low to enable the ROM. Strangely only the H
socket was missing the trace and all the other sockets had the trace connected to pin 18. Powering on now shows a
different screen...
Now it is kind of running code but has large horizontal bands across the screen sometimes filled with garbage. When
resetting the board many times I could get the test program to partially show (the RAMs are known good so no RAM errors)
but it would lock up after a couple of seconds. Probing the EPROM shows perfect signals on all pins EXCEPT A10. Pin 19
is A10 which is the additional address line present on a 2716 EPROM vs a 2708 EPROM which doesn't have A10. Checking the
schematic shows A10 is tied to a 74LS08 at F2 and that signal is equally screwed. Swapping the LS08 logic chip and the
CPU didn't help. There's clearly something wrong with A10 but I have no idea what. (edit: ummm, next time check the caps
between the ROMs and remove them!!!). I was nearly ready to give up but I decided to re-jumper the board for 2708 EPROMs
and give it a try. Being a Guru of all things ROM-related I can program 2708 EPROMs so I took the 2716 test ROM, split
it into two pieces and programmed it to two 2708 EPROMs and plugged them in at position H and G then powered on.
Initially I got clean and correct vertical lines on screen without any garbage which means the program is not running. I
realised I had to swap the S6 jumpers back to being straight-through and with that done it runs the test program and
shows 'SHIFTERS = OK' which means it's working hehe!!
So it works but only with 2708 EPROMS urgghh! Ok so I got the original 4x 2716 EPROM dump from MAME (set 'invaders') and
split those ROMs in half and programmed them to eight 2708 EPROMs fitted into positions A-H. Actually it doesn't need D
or E EPROMs because the memory map has a hole in it and the D and E ROMs (when split) contain only 0x00h so they can be
omitted. So with six 2708 EPROMs the game runs and is playable! Just because they are 2708 EPROMs doesn't mean they will
be unreliable. These are newly re-programmed so they should hold the data for at least 30 years :-)
Update (a few days later): I figured out why this board only works with 2708 EPROMs. On later 8080 boards (i.e. 80-900K)
ROM pin 18 is a separate CS pin for each ROM and pin 20 is tied to ground on all sockets. This is normal for 2716
EPROMs. But for 2708 or 3604 PROMs pin 18 is tied to ground on ALL ROMs and pin 20 is the separate CS pin for each ROM.
So this board has all of the ROM pin 18's tied together and must be based on an earlier revision after rev C (it's not
based on rev C, read on). That explains why it only works with 2708 EPROMs and not 2716 EPROMs where the function of pin
18 and 20 are swapped hehe!! (edit: additionally the caps between the ROMs MUST be removed because those caps are tied to
address line A10 when 2716 ROMs are used!). I might convert this to use 2716 later. That will require cutting all of the ROM
pin 18 traces that are all tied together to make them separate then running wires from CS (pin 18) on sockets H, G, F
and E to the CS output pins on the 74LS42 chip at E2 on pins 1, 2, 3 and 4. This also applies to the next board but
unfortunately I only discovered that while working on the 5th board several days later.
The 5th Midway 8080 Main Board is (or was) a Gun Fight (the second Midway 8080 game, first was Sea Wolf), using an early
Midway 80-900C board from 1975!
It's missing the same 9310 chip because apparently lots of people don't realise it's just a reasonably common 74LS160
hehe! It has a bunch of Intel D3604 512 byte x8-bit PROMs so I need to remove them and jumper the board for the 2716
test ROM. The sockets are also garbage including the very unusual blue screw-type CPU socket. However it's not so simple
to convert it because the jumper info for this rev C board is not widely (or at least not legibly) documented and as I
discovered later is incomplete too.
The jumpers are:
S1 - ROM pin 22 = A9
S2 - ROM pin 21 = -5V
S3 - ROM pin 19 = +12V
S5 - ROM pin 18 = PROGRAM, needs to be low/grounded for read-mode
Those are easy to work out for a 2708 EPROM since these signals are all available in the jumper section. I had some
success last time with 2708's so I will try the same trick again to avoid having to deal with the extra A10 signal. This
shows the jumpers for 2708. If I can eventually convert it to use 2716 I will document it later (edit: it was converted to 2716, read on).
The only ROM pin not accounted for is pin 20 (Chip Select or CS). This particular board uses a rare Intel 3205 for the
ROM chip select signals at position E2 instead of the usual 74LS42 chip on the later Midway 8080 boards. The Intel 3205
is the same as a 74LS138 so the board traces are a bit different vs a LS42. To make it more complicated this rev C board
also doesn't have the three S6 jumpers and instead only has a single S4 jumper. The Intel D3604 PROMs have four chip
select signals of which three can easily be changed with the jumpers S5 (pin 18), S3 (pin 19) and S2 (pin 21).
Additionally there's no schematic for this rev C board. The (really poor quality) Gun Fight schematic online is using a
74LS42 for the ROM select so it's actually a later rev board, meaning it's useless. Another very old web site shows Sea
Wolf jumper info (the first 8080 game) but it's running on a 80-900K later rev board with the common 2716 jumpers, so
also misleading/useless. Extra additionally, some butcherous cowboy loser has previously worked on this board and
screwed with at least half the chips and in the process has torn up many traces/pads so there's likely to be a dozen or
more broken traces. It's going to be an up-hill battle to beat this one into submission. Expect this rabbit hole to go
very deep and probably end up with a non-working board LOL! However there will be plenty to learn here even if the board
ends up not being fully fixed.
The first thing to fix are two broken 1k resistors. These are the video and sync outputs....
I wired the video and sync wires to those resistors, powered on and the board shows nothing on screen. Probing around in
the clock-gen section shows nearly everything is alive except the Intel 3245 Clock Driver chip at position C5. This chip
generates two 1.9968MHz out-of-phase clocks for the 8080 CPU and two clocks for DRAM bank 0 (chips 1-8) and bank 1
(chips A-H). All those clocks are missing. Looking at the 3245 chip I'm not surprised why it's not working. I pushed on
the chip and I saw a flash of something on screen. This chip needs to be removed and some investigation done.
LOL! That damn cowboy again! Half of the traces are torn off. Wow what a f*cking mess. The 2nd pic above shows it after
I cleaned up everything and added a few wires to patch some broken traces. I re-soldered the chip making sure
everything was correctly connected, including soldering the chip not only on the bottom side of the PCB but also on the
top side since there were missing vias. This means the chip pins become the vias so the chip has to be soldered on both
sides to make proper contact. This also means a socket can't be used. It still looks like crap but it's 100% correct and
now the screen shows something....
This is WAY wrong so something very serious is going on. Probing the 74LS153 chips revealed one chip with a dead pin 15.
This chip has been screwed with by our clueless cowboy. I pulled the chip and it tested good. I found one trace from pin
1 was broken that also connects to pin 15 so I patched the trace with a micro wire and put the chip back....
I powered on and it shows a different screen but it's still not working. The A9 address bus doesn't look right on my
logic probe. I pulled the 74LS08 at F2 and the 74LS157 chip at F7 both of which connect to A9 but they both tested ok.
ROM pin 22 (A9) still looks and sounds really bad on the logic probe. The socket at position G was still the old socket
so I turned the board over and was going to change it then I noticed something....
WOW there's a cap tied between pin 22 (A9) and ground on half the ROMs!! It's probably a leftover from the previous
PROMs. Let's check the datasheet for the D3604 PROM....
The pinout shows pin 22 is VCC2. Since this is now being used as A9 that pin is getting screwed up by the cap. I removed
all the caps that are connected to pin 22 and powered on. There was no change on screen but now A9 on the logic probe
looks and sounds normal. The Midway 8080 Test Procedure manual says horizontal lines means an issue with the address bus
but unfortunately doesn't offer any further info because back in 1975 this section of the board was reliable LOL! The
schematic shows the address bus connects to four 74LS08 logic chips at H3, G3, F3 and F2 and also four 74LS157 logic
chips at F7, F6, F5 and F4. I pulled all eight chips and found a bad 74LS157 at F5.... finally I'm getting somewhere! I
powered on and now it's trying to do something but mostly it just shows garbage. Occasionally it does the normal
start-up test pattern and shows a RAM error but on ALL the RAMs which is highly unlikely. I forgot to take a photo so
I'll highlight the areas in red.
Probing the ROMs shows that the CS pin is very nasty. This signal comes from the Intel D3205. Since this is a very old
chip I pulled and tested it but it passes when tested as a 74138. I replaced it with a known good 74LS138 but it didn't
change anything. The wiring on this chip is very different compared to the later boards that use a 74LS42. Here's a
quick schematic of the ROM chip select section....
The output for ROM H CS is on this logic chip on pin 15 and ROM G CS comes out on pin 14. There is a single S4 jumper
connected to pin 1 of the 3205 and the other inputs are fixed. This shows the S4 jumper and the 74LS138 datasheet....
This is a 3-line to 8-line decoder. Pins 1-6 are inputs. Pins 1-3 select which output is active (see truth table) and
pins 4, 5 and 6 enable the chip. Pin 6 must be high and the combination of pins 4 and 5 must be low to enable the chip.
The only adjustable pin is pin 1. As per my schematic pin 1 is tied to the S4 jumper. One position is ground and the
straight-through jumper position (the default factory position for S4) is tied to ROM pin 22 (A9). I think this is where
the problem is because previously with the Intel D3604 PROMs pin 22 on the ROM was VCC2 (+5V / high). Now that signal is
A9 so it can't be always high. Basically re-assigning pin 22 on the ROM sockets as A9 has broken the chip selection
logic. My schematic shows pins 1-5 are tied to A9, A10, A11, A12, A13 and pin 6 is tied to a 1k pull-up resistor tied to
VCC. The circuit appears to be connected correctly and the chips in this circuit are also tested good. The later rev
board uses a 74LS42 for ROM chip selects and the chip select lines are triggered by A11, A12 and A14 as per the official
Midway schematic. Meaning none of those address lines are affected by the ROM type which was generally limited to 2708
or 9316/2716 EPROMs on later boards since even with a 2716 it only has A0-A10. It looks like Space Invaders just won't
run on this rev C board with the current chip select logic and 2708 (or 2716) EPROMs. I did try the poorly documented
rev C re-jumpering where some lines are cut and re-wired but it simply doesn't work, primarily because the info is
incomplete and the pics were taken by someone who has absolutely no clue how to use a camera LOL! I think the only
option now is to hack in the standard chip select logic using a 74LS42 and hope that it either just works or leads me
forward to a solution and if not then the board will be scrapped for parts to fix other Space Invaders boards in future
repairs. Or I could convert it back to Gun Fight. I still have the original Intel D3604 PROMs and they all read ok and
are good. Now that the main board is (probably fully) working it should be possible to get the original game Gun Fight
working on this board. Of course the Gun Fight L-board is likely faulty so assuming Space Invaders can't be made to run
on this board there will likely be a Gun Fight follow-up repair soon-ish. I might just do it anyway because like the cat
I'm curious. Anyway, after some time the 74LS42 was hacked into the circuit. Also note the jumper S1, S2, S3 and S5
positions. S5 is open and while I'm doing this I went with 2716 EPROMs so S3 is ROM socket pin 19 (A10)....
The last pic above shows the basic logic symbol with pin assignments. This isn't that complicated. As per the later rev
schematic the LS42 has inputs on pins 12, 13, 14 and 15 (grounded/unused, A14, A12, A11 respectively) and the chip
select outputs are on pins 1, 2, 3, 4, 5, 6, 7 and 9 (ROMs H, G, F, E, D, C, B and A respectively, pins 10 and 11 are
also outputs but not used). Pins 15 and 14 are tied to the outputs of two 74LS08 logic chips which connect to the CPU
A11 and A12 and pin 13 of the LS42 is tied directly to the CPU A14 pin 39. That's all there is to it. Here's the pin
wiring. Pins 8 and 16 connect to the PCB directly and all the other pins are lifted out straight so they don't touch the PCB....
74LS42 pin 1 > ROM H pin 18 to via near socket H. The trace that connects to the S5 jumper MUST be cut in multiple
places to separate all the chip select signals for **EACH** ROM. Basically use the same vias that
connect to each ROM pin 18 AND cut the trace on **BOTH** sides of the via. Note it can be left
connected if using only 1 EPROM (for example the test ROM or if hacked to use a 2764 EPROM).
74LS42 pin 2 > ROM G pin 18 (note for pin 1 applies here too)
74LS42 pin 3 > ROM F pin 18 (note for pin 1 applies here too)
74LS42 pin 4 > ROM E pin 18 (note for pin 1 applies here too)
74LS42 pin 5 > ROM D pin 18 (not used for 2716 so leave unconnected)
74LS42 pin 6 > ROM C pin 18 (not used for 2716 so leave unconnected)
74LS42 pin 7 > ROM B pin 18 (not used for 2716 so leave unconnected)
74LS42 pin 8 > GROUND
74LS42 pin 9 > ROM A pin 18 (not used for 2716 so leave unconnected)
74LS42 pin 10 > NO CONNECTION
74LS42 pin 11 > NO CONNECTION
74LS42 pin 12 > GROUND. A convenient location is pin 8 of chip D2.
74LS42 pin 13 > CPU PIN 39 (A14). A convenient location is one of the vias above the CPU socket near S3. See
pic above for the exact location or use a multimeter on continuity to find it.
74LS42 pin 14 > 74LS08 at F3 pin 3 (AD12). A convenient location is the via between chips F3 and E3.
74LS42 pin 15 > 74LS08 at F2 pin 11 (AD11)
74LS42 pin 16 > VCC
Jumper S3 > Jumper S3 must be tied with a wire to the 74LS08 at F2 pin 8. A convenient location is the via
just near pin 15 of the same chip at F2 (check pic above).
Reminder: The rev C board has pin 18 on all ROMs tied together so all those traces need to be cut otherwise all the chip
selects on all the ROMs will be connected together (which is obviously not correct). That might be the major difference
between the early and later rev main boards that was (up to now) unknown hehe! However for just one ROM (like the test
ROM) I didn't do it (yet). I powered on and....
Now it's worse LOL! But also better since the vertical bars are present now. I went over my connections and it all looks
good. Checking A10 on the ROM with my logic probe shows it's completely screwed. Hmmmm, I'm getting a déjà vu feeling
like I've seen this before. I physically checked the traces on the bottom of the board and noticed that pin 19 on every
2nd ROM is tied to something....
Damn caps again! These are tantalum caps on the factory D3604 PROM chip selects for pin 19 previously tied to +5V
then through the cap to ground. So that explains why A10 is screwed up on my logic probe hehe! I removed all those
stupid caps and powered on....
Oh sh!t! The horizontal bars are gone and the test program is running and shows RAM errors. RAMs 1, 3 and 7 seem to be
ok but all the others are bad. I cycled power a few times and it is the same consistent error. Ok so looks like a bunch
of RAMs are bad. This can happen on triple voltage RAMs and is actually mentioned in the Midway repair manual. Basically
if the 12V or -5V rails are missing for an extended period of time all the RAMs can burn up. I'll be back when I pull
the RAMs and test the flagged chips. Err, hang on a sec.... I noticed the voltage was about 4.85V so I increased it
to 5.0V and now I get errors only on RAM F. I piggybacked RAM F and reset it and got an error on RAM H. I piggybacked
RAM H and I got this....
Holy sh!t it runs and repeats the test and passes every time hehe! Ok I won't bore you with the RAM swapping. Basically
it's working. I need to wrap this up and move on as some stuff just arrived to be dumped. So yeah, I got all 5 Midway
8080 main boards running eventually but the last one took a week to figure out hehe!!
19th November 2023
A Midway Space Invaders came in for repair. I have a bunch of dead Midway 8080 games so this is a good opportunitly to fix all of them (later, after this repair).
Before starting any Midway 8080 board repair a bit of prep work must be done. This has the usual 9316 ROMs all rusted to hell so I removed
them and some of the legs were torn off hehe! The sockets on these boards are all garbage and need to be replaced. Some
broken ROM legs were stuck in the holes. In order to speed up the repair I decided to try using the original sockets first and
see how it goes. I used a levering tool to lift up the black sockets exposing the pins. The pins all looked good so I
removed the small pieces of ROM leg and carefully pushed the black sockets back on top. Ideally the sockets need to be
changed but for now I'm moving on. The board needs to be jumpered to take 2716 EPROMs. That's very easy. In this case
most of the jumpers were correct but S2 needed to be moved. The pics below show how the jumpers should be set when using 2716
EPROMs. Note the 3 jumpers together at S6 are traces on the PCB on later boards. Earlier boards have jumper wires at
that position....
With the board jumpered for 2716 EPROMs I burned a Space Invaders test ROM and plugged it into the socket at position H.
Next is the wiring harness. The video and sync on these boards goes through a couple of 1k resistors on the edge of the
board near the L-board slot. Sync is on the end of the left resistor and video is on the right resistor. Note earlier
boards have these signals reversed. The video is also tied to pin 18 of the edge connector so that pin can be used for
the video. At the other JAMMA fingerboard end tie the video wire to red, green and blue so that it will display white.
Power is on the 18-way connector. For testing purposes only a few wires are required. First 2 pins are 5V, next 2 pins
are 12V, next pin is -5V and the 4 pins near the end that are all connected together are grounds. Make sure -5V is
hooked up otherwise you'll burn out ALL of the DRAMs if that voltage is missing hehe!
Powering on just shows a screen full of garbage...
Of course it's not going to work yet because the prep work isn't complete. Any arcade board requires a reset signal but
on these Midway 8080 boards that signal comes from the power supply. Since I don't have the original power supply the
reset is missing. On an i8080 CPU reset is on pin 12 and is active high. Meaning reset has to be toggled high at power
on then held low after that which is the complete opposite to most CPUs. For example a Z80 or 68000 CPU has an active
low reset where the board pulls the reset pin high permanently through a pull-up resistor and the reset circuit toggles
the reset line low for a 1/4 second at power-on or the reset circuit does everything and toggles low then high and stays
there. There's no such luxury on these Midway 8080 boards. There is another way to do it which I will get to later but
for now the quick fix is to tie a jumper wire to the 8080 on pin 12 and touch any 5V source such as a bypass capacitor
and then put the jumper on the other side of that same capacitor and leave it there on the ground side. So I did but it
didn't boot up. The CPU has no activity. It can be a bad socket as that's a common issue but first, the 8080 CPU has 2
clocks on pins 15 and 22. They measured good at 1.9968MHz. These 8080 CPUs can often go bad because they run on three
voltages (+5V, -5V and +12V). I swapped out the 8080 CPU and it boots and kind of works but the end of the test shows a
table full of numbers. If the shifter test is good it should display 'SHIFTERS = OK' and not show this table so there
must be an issue somewhere in the shifter circuit. In fact this table shows that the shifter circuit is totally dead and
not working at all because nothing is being shifted. As far as I know the shifter test is supposed to XOR each number
with itself so that the result is 00. When all table values are 00 it shows the ok message and does not show the
table.
As a side note, if you are paying attention you will have noticed that the table is darker and not washed-out/grey hehe! I took this
photo a bit later so all later pics will be darker and all earlier pics are grey/washed out. A little trick to get a
better picture (for testing on a standard color monitor) is to tie the end of both resistors together with a wire.
Without this wire the picture will be grey/dull and washed-out. With the wire added to short both resistors the
picture will have a dark black background and bright white graphics. That probably won't play nicely with the original b/w
monitor so don't forget to remove the wire after testing it.
So amazingly the board works. My guess is this board has been dead for many years and hasn't been abused otherwise there
would have been a whole bunch of logic and RAM faults since all the chips are 45 years old. Things were just made better
back then and shows how reliable this old stuff is... whereas your 2 year old TV or laptop (especially anti-repair
crApple devices) is already dead and was replaced with a new one hehe!
I decided to burn a set of 2716 EPROMs with the proper Space Invaders code and test on the board as it appears the
sockets are good enough and contact the test EPROM. The correct Space Invaders ROMs for this board are as
follows....
9316b-0869_m739h.h1 CRC32 = 734f5ad8
9316b-0856_m739g.g1 CRC32 = 6bfaca4a
9316b-0855_m739f.f1 CRC32 = 0ccead96
9316b-0854_m739e.e1 CRC32 = 14e538b0
In MAME this is ROM-set 'invaders' and these ROM names above are the newly updated (by me) correct names that are printed on the ROMs.
At power-on it almost goes into the game but gets stuck...
I removed the game board (the L-board) and cleaned the 72 pin edge connector and put it back in and powered on....
Hmmm ok so it's nearly working but the invaders are missing. I assume it has something to do with the logic on the L-board.
I randomly probed a few chips looking for anything unusual and I noticed several pins with no signal on them.
One is a 74LS175 at position B5 and pin 1 has no signal at all. Let's check the datasheet....
The datasheet says pin 1 is CLEAR and the truth table says it should be high. I jumpered that pin to the nearest VCC pin and powered on...
Wow it works and now the invaders show hehe! I traced that pin and it goes to many chips (all inputs). It is also tied
to a 74LS04 logic chip at F3 pin 10 which is an output (i.e. the source of that signal on pin 1 of the 74LS175 at B5).
The input is pin 11 and would be low as the 7404 inverts the signal. We already know pin 10 needs to be high so pin 11
must be low. The Space Invaders schematic for this exact board is not available as far as I can see. This board is
A084-90700-D739 which google says is the cocktail version. The ROMs are the same as the upright version. The available
schematic has the AM25S10 shifter chips but looks like it's the same for the rest of the circuit. This board doesn't use
any of those hard to get AM25S10 shifter ICs and instead just has a bunch of normal 74LS151 logic chips. I suppose that
makes it a prime candidate for copying it but more on that later hehe! I have several Midway 8080 motherboards but the
L-boards are not very exciting games (repairs on those will follow soon) so it would be good to convert one to Space
Invaders. The cocktail manual available is only a parts manual but has a board layout showing all the chips. The
schematic shows chip F3 is a 7404 and pin 11 has a Power Supply Reset signal there....
From previous Space Invaders repairs I know that the L-board requires a reset signal on one of the connectors but this
board isn't well documented. I traced F3 pin 11 and it is tied to pin 6 on one of the connectors. I jumped that pin to
ground and powered on without the 8080 reset jumper wire and the game boots all by itself after about an 8 second delay....
So it looks like there are no more faults (unlikely but maybe). The next step is to wire up the controls and audio and test play it to make
sure it's all working. With the game running I grounded out each of the connector pins to see what effect it had. After a few minutes I had all the info and wired it to my JAMMA adapter....
The pins are numbered very strangely so I will document exactly what the connectors do....
I played a game and noticed that the shields have a line through them and shooting it doesn't remove it. Also the
invaders are all missing a section near the top of each invader so it looks like the top and bottom invaders are wearing
a hat heh!
Let's go back to the test ROM again now that the board is properly wired up....
When the shifters are working this table will result in all 00 and it won't show it and instead show a message on the
first test screen 'SHIFTERS = OK'. I don't have a 100% understanding of every table error display but I can understand
this table. It shows 40 in each row. The bits are supposed to be shifted then XOR'd with that same number so the end
result is 00. Since it's 40 and all the others are 00 it means only a single bit is bad so it is easy to work out which bit is
not correct. If you check a simple 8-bit binary number it is read from right to left and consists of 8 bits of data
where each bit can be 0 (low/off) or 1 (high/on). The decimal and hex equivalents are shown below....
7 6 5 4 3 2 1 0 = bit number position (read from right to left)
0 1 0 0 0 0 0 0 = 01000000 in binary = decimal 64 or hexadecimal 40
128 64 32 16 8 4 2 1 = decimal equivalent
80 40 20 10 8 4 2 1 = hexadecimal equivalent
Read the numbers above in vertical columns; i.e. bit 7 = decimal 128 = hex 80. The table on the test screen lists
hexadecimal numbers and we have a 40 showing. Checking the table above shows bit 6 is bad. Now let's check the schematic
to see if I can find where bit 6 is in the shifter circuit....
Data bits D0-D7 enter the shifter circuit into chips B5, C5 and D5 (highlighted in red). Chip D5 (74LS174) has D6 on
pin 6. The output of pin 6 (3D) shown on the same 74LS174/74LS175 datasheet above is pin 7 (3Q). My board doesn't have the AM25S10 chips and instead has 8x 74LS151
chips. I traced the 74LS174 at D5 pin 7 and it's tied to two 74LS151 chips... chip D4 pin 4 and chip D-E4 pin 3. Let's
check the 74LS151 datasheet....
The datasheet shows pin 3 and pin 4 are inputs so not important. The outputs on this chip are pins 5 and
6. I probed those pins with my logic probe and they are stuck high & low. I pulled the chip and it tested bad in
my chip tester so I replaced it....
I ran the test ROM again...
Now the test shows 'SHIFTERS = OK'. I put back the game ROMs and played a few games and everything seems to be working fine
including all of the sounds. So yeah this board must have been dead for a very long time otherwise at least some
LM3900 op amps would have failed and caused missing sounds.
10th November 2023
Back in July I showed a repair on one of my Commodore 64's. Today I decided to test one of my SD2IEC devices on the same
Commodore 64 and it didn't work.
This SD2IEC is made to look like a 1541 floppy drive. It plugs into the user port to get power (pin 1 ground, pin 2 +5V)
and the output cable is a 3-pin audio jack with a DIN5 plug on the other end that plugs into the DIN5 serial port on the
C64. The cable contains only 3 wires; data (IEC pin 5), clock (IEC pin 4) and ATN (IEC pin 3). This SD2IEC also has a
reset button and that joins to the user port reset signal (pin 3) and is used to reset the C64. This SD2IEC is really
nice because it can also be used with the Commodore Plus/4, unlike other SD2IEC versions designed to take the power from
the cassette port edge connector which is not present on the Plus/4 computer. When attempting to load something an error
message shows 'DEVICE NOT FOUND'. If the load command is given again the C64 locks up! Now the really strange thing is I
tested it with a 1541 Ultimate II cart and everything works fine. I also tested with a real 1541 floppy drive and that
also works fine. I have another C64 with the same version main board (250425) and the SD2IEC works fine there. This is a
really unusual fault that is isolated to only a SD2IEC. I swapped the 6526 I/O chip at U2 but that didn't make any
difference. I'm guessing this is something related to the signals on the DIN5 IEC serial port. Checking the resistance
of each pin to ground and comparing it to my other C64 shows pin 3 is open. The resistance to ground on my working C64
is around 4k-ohms. Let's check the schematic...
I highlighted the path of pin 3. Basically it's tied to a 1k-ohm pull-up resistor and the output of the 74LS06 logic
chip. I pulled and tested the 74LS06 logic chip but it passed in my chip tester. I replaced it anyway but it didn't make
any difference. The only remaining part is the resistor at R28. Surely a resistor can't be the issue? I measured the
resistor in-circuit and it was open! I had a closer look...
Eh? The resisitor is broken at one end!??! It appears to have been re-soldered before but the solder broke. Maybe I
bumped it when I did the RAM repair back in July? I resoldered the resistor and now the serial port pin 3 resistance to
ground measures around 4k-ohms. I tested the SD2IEC and it now works fine. Since a real 1541 floppy drive works without
that resistor it means that the SD2IEC is incorrectly using that ATN signal for something LOL! Anyway if you are using a
SD2IEC and it gives the same 'DEVICE NOT FOUND' error and then locks up the C64 when the load command is repeated, have
a look at the pull-up resistor connected to the IEC serial port pin 3 ;-)
5th November 2023
In a previous log (23rd October) I mentioned I might try to convert the War Final Assault board to Gauntlet Dark Legacy.
Today is the day.
The PIC was decapped and dumped by CAPS0ff around August 2020 and was added to MAME but it isn't tested or hooked up in
MAME. Like a lot of games in MAME the protection is faked. This is often because when the emulation was done the
protection device was not dumped and the emulation was not updated with the dumped protection device when it was dumped,
other than simply loading it with all the other ROMs. So this is also a good opportunity to test the dump to make sure
it's good. I ordered some Microchip PIC16F57 chips and they arrived a couple of days ago.
I grabbed the PIC dump from MAME archives, programmed it to a PIC16F57 and plugged it into my PCB. I also read both
EPROMs on the boards and found that only the boot ROM on the middle board needs to be changed so I also programmed a
27C4001/27C040 EPROM with the Gauntlet Dark Legacy boot ROM dump from MAME. I also got the MAME CHD for Gauntlet Dark
Legacy and unpacked it. To do that, make a dir containing the CHD and CHDMAN.EXE, open a command prompt in that
directory and at the command line type...
CHDMAN extracthd -i gauntdl.chd -o gauntdl.img
This results in a new image being created that is around 3.1GB in size.
I used Winhex to write the image to the same Quantum 5.1GB HDD that I used for War Final Assault and after a few minutes
it was done.
With the newly programmed parts plugged in I powered on and the 7-segment LED on the mainboard went through some checks
then displayed I O A S I C then reset. This means the PIC is bad. Well technically a display of E means the PIC is bad.
The IOASIC error means the contents of the PIC is wrong and/or the PIC isn't sending out the correct info when the
mainboard requests the game ID and serial number from the PIC. Incidentally the same I O A S I C error will show if the
HDD is the wrong one (for example if you try to use the War Final Assault HDD on Gauntlet Dark Legacy). It turns out
that the PIC dump that was added to MAME is wrong so it doesn't work despite the actual decapped dump from CAPS0ff being
correct. That also explains why no one has been able to convert any Vegas board to Gauntlet Dark Legacy. There are some
posts on various forums but all end with no solution hehe! The actual PIC chip EEPROM is 2kB x 12-bit but ends up being a 4kB
dump. With the correct CAPS0ff dump in hand I programmed that to the PIC. The config bits are not included in the dump
because it's a binary file but they are not difficult to set. Basically there are only four things to set. You can
ignore the USER ID since the PIC can't read or access it. The Code Protection can be on or off. The Watchdog can
be on or off as the game doesn't care. The crystal oscillator type MUST be set to HS otherwise the 4MHz crystal
ocsillator on the mainboard doesn't work. On other programmers there is only a 4-bit binary number to set and in that
case it should be 1110 or in hex it is E. Some programmers (i.e. Topmax II) don't write the config bits when programming
the ROM and therefore the PIC won't work. In this case the config bits only get written when the device is secured. On
other programmers the config bits can be set and programmed separately. Anyway the first snapshot below shows the
settings using my XGecu T56 programmer. The same software is also used with the more common TL866II-3G (XGecu T48) and
TL866II-Plus programmers. It probably also works with the Minipro TL866A and II. That programmer was copied and
reproduced without the authority of the manufacturer so the original manufacturer abandoned it. Most of the TL866 and
TL866-II programmers out there are Chinese bootlegs, but on the bright side at least now schematics are available hehe!
Anyway, a checked item means it is programmed to 0. The second snapshot shows my EETools TopMAX II settings. The
relevant section from the datasheet is also shown.
Binary bits start at 0 and read from right to left.
FOSC1, FOSC0 = Oscillator Selection. 00 = LP, 01 = XT, 10 = HS, 11 = RC. For HEX bit 1 = 0x02h or 0x00h and bit 0 = 0x01h or 0x00h
WDTE = Watch Dog Timer. 0 = DISABLED, 1 = ENABLED. For HEX, bit 2 = 0x04h or 0x00h
/CP = Code protection. 0 = ON, 1 = OFF. For HEX, bit 3 = 0x08h or 0x00h
If you check the datasheet you will see these are bits 0 to 3 for register 8-1. Some EPROM programmers require the bits
in hex so you need to check your EPROM programmer for the specifics of what it expects. The correct HEX setting is 000E
or 0x0E or just E (in HEX, 2+4+8 = E)
With the correct PIC image and config bits programmed the game now boots up and runs fine.
It's HIGHLY likely that the same PIC config settings work with all of the Midway PIC16C57 dumps out there and I will
probably test a few more on various games I have here later.
Fortunately the config bits can be included in the dump to streamline production programming. Some EPROM programmers require a
HEX file and some require a BINARY file, some can accept either. The original decapped dump doesn't include the config
bits and is not widely available yet (hopefully MAME will be updated soon). Since it's a bit confusing and to make it
easier to do the conversion I read my working PIC and saved it in .bin and .hex format using my XGecu T56 programmer.
These files include the config bits in the dumps. I've also included the original 4kB decapped binary dump (it doesn't
include pre-programmed config bits). The correct tested-working files are available below.
Happy converting :-)
Update: Link below was updated for several PIC16F57 with the correct config bits included in the dump and tested working on real
hardware. PICs were programmed using my XGecu T56 EPROM programmer.
Games included are:
Ultimate Mortal Kombat 3 (Wolf Unit hardware)
Mortal Kombat 4 (Midway Z-Plus hardware)
The Grid (Midway Athens hardware)
Cruis'n Exotica (Midway Athens hardware)
Gauntlet Dark Legacy (Midway Vegas hardware)
TESTED BAD / NOT INCLUDED = INVASION THE ABDUCTORS (Midway Z-Plus hardware) - Dump in MAME is bad.
Bonus inclusion: Strikers 1945 MAME sets s1945, s1945k, s1945a, s1945j
I saw that the PIC for Tengai (Psikyo SH404 hardware) is dumped and also not hooked up so I programmed
some Tengai EPROMs and a PIC16F57 (with the config bits set correctly) and plugged them into my Strikers 1945 (SH404)
board so I could test it. Tengai boots up and runs fine. I plugged the original Strikers 1945 EPROMs back into my board
but left the Tengai PIC in place, powered on and Strikers 1945 also boots up and works fine! I tested the game all the
way to the end and there were no issues. This proves the PIC for Strikers 1945 and Tengai is identical so the previously
undumped Strikers 1945 PIC is actually dumped :-D
Additionally, in the MAME source there's mention of a dump of a Korean Strikers 1945 PIC but it's not included in the
source. I got hold of it, programmed it to a PIC16F57 chip and that works on the board too! I compared the HEX and it's
identical to the Tengai PIC dump. I also tested the other two sets (s1945j and s1945a). They boot but reset when start
is pressed. PICs for the s1945a and s1945j sets are also included (hand crafted) and are tested working on my board.
Originally I converted and saved the hex files as binary using the XGecu T56 software but it looks like there's a bug in
the software. Every time the bin is saved (just for the selected PIC16F57) the CRC32 is different!! EPROM files save the
same each time and the PIC .hex also saves the same each time so the bug seems isolated to saving PIC binaries. So I
used software from a different EPROM programmer to convert and save the binaries and they are identical each time the
file is saved (compared by zipping and checking the CRC32).
All tested PICs are in the zip file below. Both BIN and HEX files are included for all games.
3rd November 2023
Continuing with the SCI repairs, the last CPU board has the TC0220IOC chip missing so I took a good chip from a working Taito Champion
Wrestler board and mounted it onto the SCI board. I powered on and it's dead. I swapped all the TMM2063 RAMs in the CPU
section (see previous log for locations) and the board boots. The title screen looks ok but the top half of the screen shows the road from the bottom half of the screen LOL!
WOW! Looks like I've got a rare and undumped single screen vs. SCI version!! Hehehe!! I'm guessing this is a video fault
caused by the 2nd CPU/road chip. I piggybacked all four RAMs near the 2nd 68000 but it didn't make any difference.
Probing the RAMs at IC11 and IC13 (near the road chip) revealed a couple of dead pins on the address bus. I attempted to trace them
but couldn't find a connection so I traced those pins on one of the other repaired boards and found that the RAM
address pins are tied to the road chip. I checked the road chip and found some green corrosion. Scraping away the
corrosion revealed some broken traces...
I patched the two broken traces on the road chip (pins 37 & 38) then powered on and re-tested it. It's better but still
not right....
This is the new airport runway SCI version hehe! There must still be a broken trace so I re-checked the connections and found that pin 36 was also broken so I patched it with a micro-wire then re-tested again....
That fixed the fault. It looks like this CPU board is now fully working so that's the end of this SCI repair series :-)
Here's a bonus tip. If you own a real SCI cab with the shaker motor be very sure you plug in connector D correctly.
This connector has 24V on it on pins 1 and 2 and is used to drive the shaker motor on the steering wheel. It's triggered
by the transistor at Q3 (D633, modern replacement is TIP122). The transistor is driven by the 74LS07 at IC24 located
near the main 68000 CPU. If connector D is connected incorrectly it can blow up the transistor and the 74LS07 at IC24.
Changing both parts will fix it as long as you're lucky and the 24V didn't get past the 74LS07 ;-)
1st November 2023
Continuing with the SCI repairs, I still have two top boards that are totally non-working. I tested the 1st board and it
shows a wavey screen. If I reset it manually by grounding the 68000 reset pin for 1/4 second it shows a mult-colored
garbage screen....
This usually means some loser plugged the connector in backwards. It's almost JAMMA with the video and some controls on
different pins but the power is normal JAMMA. When plugged in backwards it sends 12V through the I/O and blows the ass
off the custom Taito TC0220IOC chip. This custom chip not only buffers the reset, it controls coinage, provides a
watchdog and also connects to the CPU address and data bus so you can't just reset the 68000 CPU and expect it to work.
That's what the previous person did with this board.... there was a jumper wire on the bottom going from the MB3771
reset chip straight to the 68000 reset pin LOL!! So I replaced the custom chip with another chip taken off a working
Violence Fight board. Now at power on it shows a garbage screen that is resetting continually (the watchdog is barking).
Of course there's a bunch of Toshiba TMM2063 RAMs so they were all changed in the main CPU area (IC19, IC20, IC39,
IC36)....
Now the game boots up but most of the graphics are missing. I piggybacked the other 4 RAMs and now the graphics show....
This board has one remaining fault. Well maybe two. The sound plays but when a coin is
inserted it sounds bad and when a game is started the mission info spoken by the woman is
missing. That's held in ROM C09-15 at IC29. I read the ROM and it's bad. This is
marked on the board as 834100 and the ROM is a Fujitsu MB834100 mask ROM. You might
automatically think the equivalent EPROM replacement is a 27C4100 but you would be very
wrong and that's exactly what you will find if you google it LOL! The pinout is the same
as a 27C4096 EPROM but with one important change.... pin 1 is a BYTE selection pin
allowing the ROM data bus to switch between 8-bit (D0-D7-D15/A-1) or 16-bit (D0-D15). This
PCB has pin 1 tied to ground and according to the MB834100 datasheet that means it's set
for 8-bit mode. The problem is the 27C4096 is fixed at 16-bit and doesn't have a byte
selection pin. There is no other compatible EPROM available. Here's the relevant section
from my Guru ROM-Ref document....
The way to solve this issue is to make a PCB adapter that swaps pins around and use a AMD
AM27C400 EPROM. Since that requires switching all 40 pins it's necessary to make a PCB and
get it produced at one of the Chinese PCB companies, otherwise there's going to be a big
mess of wires. I decided to make up a proof-of-concept proto adapter using a piece of vero
board just to make sure it works. It's not difficult but it is annoying and tedious work.
Just join all 40 pins from the socket to the EPROM but match all pins BY SIGNAL NAME. For
example join socket for MB834100 pin 1 -> EPROM 27C400 pin 31 (etc x40). After what seemed
like 6 hours of headache-inducing soul-crushing wire cutting and soldering it was done. I
programmed the C09-15 data into the EPROM, plugged the whole thing into the PCB and
started a game and the mission speech plays so that has fixed the issue. I probed the data
pins on the EPROM and only data pins D0-D7 are active and A-1 toggles the upper/lower bank
so everything is working as expected. The coin sound is in ROM C09-12 at IC44 which is
also a bad ROM. It's the same type of MB834100 so I need 2 adapters. I'll design and route
a proper PCB adapter later which should only cost $1 to make. The adapter schematic is
included below.
There's still one more CPU board to fix but that's enough for today, I need to recover and rest for a couple of days
heh!
Update 1:
Here's the adapter board routed and the 834100 Adapter Gerber Files. Instead of
getting ripped off by losers on ebay (I'm way ahead of those scumbags) just send the gerbers to your favorite PCB company
and get 5 for $2 total LOL!
This adapter can be used to replace any MB834100 mask ROM on any PCB. They were common on Taito boards but it will work
for any game that requires a mask ROM with the same pinout. I recommend JLCPCB. Their price, quality and production times are excellent! When placing the order select 'Remove
Order Number > Specifiy a Location'. It won't cost any extra and their silly number will be put under the EPROM because
I added some special text to the board for that (JLCJLCJLCJLC) ;-)
Of course they will still try to rip this off and sell it for $30 but remember, you saw it here first hehe! If you're smart
you'll just make your own adapter for $2.
If you found my site by searching for info about the MB834100 adapter because you are trying to repair your Taito game, be sure to also
check out my repair logs for Chase HQ and Operation Thunderbolt which use very similar chips and have very similar faults.
Operation Thunderbolt - 28th July 2023, 23rd October 2023.
Chase HQ - 30th March 2018 to 2nd April 2018.
Update 2:
After fixing all the issues and playing it a bit I realised that the roadside scenery is
bad. Instead of being two shades of brown it's yellow and white stripes! It's actually the
same in the pic above but I didn't notice it hehe! The yellow and white stripes match the
road border so it looks like a ROM is dead and not outputting anything. That turned out
to be another bad ROM C09-07 at IC15. Fortunately it's one of the MB834000 ROMs which is
compatible with the common AM27C400 EPROM so I programmed an EPROM with the correct data,
plugged that in and that fixed the roadside scenery :-)
Update 3: (added April 11th, 2024)
Here's a pic showing my adapter board mounted onto the PCB. Very nice and very neat and compact :-D
The adapter is tested and working perfect :-D
30th October 2023
Continuing on with the SCI repairs, now that I have one fully working boardset it's very easy to individually test the
top and bottom boards from the other two boardsets. I'll start with the bottom video boards because that's probably
easier/quicker. I plugged in the 1st video board and it's mostly ok but has graphical issues.
This looks like a simple ROM fault with the sprite ROMs. That's the ROMs located at IC52, IC53, IC54 and IC55. I read
the ROMs and it turned out that C09-01 and C09-03 are bad. The original ROMs are 234000 mask ROMs. The most common
compatible EPROM is ST M27C400 or AMD AM27C400 and swapping them for EPROMs programmed with the correct data fixed the fault completely
and now I have another good video board. Wow that was easy hehe!
I plugged in the 2nd video board and tested it....
Wow this one is really screwed up hehe! Those square blocks are moving randomly all over the screen and almost
everything is missing. That's probably bad sprite ROMS but first, I can also see lines on the screen. This is most
likely the large bank of 62256 RAMs which is the sprite display RAM. I piggybacked a RAM on each chip one by one and
when I hit the chip at IC22 the lines disappeared. Here's a side-by-side comparison without and with the RAM on the
Press Start screen. It's easiest to compare/troubleshoot with this screen because it doesn't move....
The sprites are still scrambled/missing. First step is to read all the ROMs. Sprite ROMs C09-04, C09-03 and C09-01 were
all bad! I replaced them with EPROMs but that didn't fix the issue. I read the other ROMs on the video board and ROM
C09-05 was bad. That's the tilemap generator ROM that connects to custom chip TC0100SCN. With those ROMs replaced now it
looks much better but the sprites are still partially scrambled and moving all over the screen....
There's a couple of those dirty little mofo Toshiba TMM2063 RAMs there so it's highly likely at least one of them is
bad. I piggybacked those RAMs and that *nearly* fixed everything but not quite....
There's still some small lines through some of the sprites. That probably means there's still an issue with the large
bank of 62256 RAMs. I went over all the RAMs again and piggybacking them didn't fix the issue. I injected a signal into
all the data pins on every RAM. To do that just hook up a clip onto one of the data pins on one of the RAMs and
touch the end to all the other data pins one at a time. This will show lines on the screen at different places. When
hitting the data pins on the RAM I have just changed at IC22 the exact same lines changed to the different data coming
from the source RAM data pin. This is really strange because I've already changed that RAM and I know it's good. I
turned the board over and was just about to remove the RAM and re-check it and then I noticed something....
Oops! The nearby trace tied to pin 13 (D2) is shorted to pin 14 (ground) hehe! With the short removed the board appears
to be fully fixed so now I have three working SCI video boards :-)
Update: So umm, yeah, be careful about soldering the RAMs on this board because there are a LOT of traces right next to the chip
pins and it's easy to accidentally short the pins to the trace if the mask paint has been removed and copper exposed. One of the other boards I
had previously fixed years ago (but couldn't fully fix) actually had the same type of short and just removing the short fixed it :-)
29th October 2023
A local friend brought over a Taito Special Criminal Investigation board to be repaired. I have two other non-working
boards here so this is a good time to get them all out and see if I can get at least one working.
I will start with one of my boards that kind of works. I recall I got this from Filtek Australia about 20 years ago
as-is for parts to fix other games but luckily I never got around to using it so all the parts are still present heh! It
boots up sometimes and shows a RAM error, generally in the RAM region 108xxxH
With this era of Taito board the first thing to do is remove and replace all of the Toshiba TMM2063 RAM. These RAMs are
known to go bad and changing them all might fix the board completely without having to do anything else. All RAMs were
removed and tested. Some actually passed in my RAM tester but some were bad. However even after changing all the 8kB
RAMs the fault remained and would only show a random RAM location starting with 108. The RAM at location 108000H -
10BFFFH (16kB) are the two RAMs located at IC19 and IC20 next to the TC0170ABT custom chip. I know the RAM is good so I
checked the ABT chip and found several loose legs. I resoldered them and now it boots up with bad/incomplete
graphics...
The title screen graphic is made from sprites. That data is held on the bottom board in 4x 4Mbit mask ROMs. I read them
and found the ROM C09-01 at IC55 was bad. I replaced it with a ROM taken off one of the other boards and that fixed the
title screen. While doing that I noticed in the MAME source that ROMs C09-02 and C09-03 have swapped locations so those
ROM names have been fixed in the source :-)
There's still no road and no cars in the attract or in-game. It showed some off-road graphics (trees, water) but no
on-road graphics. On the other side of the top board there's another 68000 CPU (slave), some RAMs, ROMs and a custom
Taito TC0150ROD chip. This section of the board is responsible for showing the road and the car sprites...
Of course there are some TMM2063 RAMs here too. I pulled and tested them and they were actually ok heh! I probed the
68000 CPU and the reset and clock pins are correct but for some unknown reason the entire CPU is inactive on all other
pins. It's like the CPU is dead. While probing around I noticed that pin 17 is low. This is the HALT pin. It's an
active-low signal and must be high in normal operation otherwise the address and data bus are in a high-impedance state
and do nothing. When probing the address and data bus pins on the slave 68000, RAM and ROM while powering on the PCB
there's absolutely no CPU access or any attempt to access them. Something is pulling the HALT pin down. Checking pin 17
to ground with multimeter on continuity shows a dead short to ground. Pin 17 traces to a logic chip and a 3.3K pull-up
resistor. The schematics for SCI are not available but it's very similar to Chase HQ so that can be used as a rough
guide.
I pulled the 74LS07 and it tested ok. I removed the pull-up resistor and the line was still shorted to ground. I
couldn't find any other connections tied to pin 17. The cable connector near the slave 68000 was a bit melted. It
appears someone has been playing around there so I removed the connector since the trace that ties to the 74LS07 goes
under the cable connector but I didn't find anything unusual underneath. The only remaining part that could be bad is
the 68000 so I removed it.
I measured the resistance between pad 17 on the PCB and ground and it measures open now. The short is gone! The 68000
pinout shows that pin 17 (HALT) is next to the ground pin 16. On a good 68000 pins 16 and 17 have about 2.1M-ohms
resistance. This CPU was very different...
Wow wow!! The resistance between pins 16 and 17 is only 1.9 ohms so this CPU is bad. I replaced the CPU expecting the
board to be fully working but there was no change LOL! At least now all the address and data lines were low compared to
before where there was no signal on any of the pins. I traced the 68000 address and data bus pins and they are tied to
the nearby RAM, ROM and custom TC0150ROD chip. The only part not checked is the custom chip so I removed it and replaced
it with a spare chip that I had lying around in a parts bin. I had two chips here but both were beat-up to hell so I
picked the best one and it took about 1 hour to straighten all the legs urgghh! I painstakingly mounted it by manually
positioning and soldering every leg in place individually since the legs were not fully straight or perfectly aligned
which took another 1 hour. I powered on the board hoping for a miracle...
Looks like that fixed it hehe!! Wow! So the 68000 and custom road chip were bad. That was totally random and unexpected.
Everything else appears to be ok including sound so this game is fully working now.
23rd October 2023
Here's a few boards I repaired recently....
Operation Thunderbolt
This is the same board I fixed in my repair log 28th July 2023. It worked but there was bad sound, just a repeating
noise over and over like the sound program was stuck in a loop. The ROM verified ok against MAME archives. I pulled and
tested the sound RAM (6116) but it tested good. I swapped it anyway but nothing changed. There's not a lot else in the
sound section, a Yamaha YM2610 sound chip, Z80 CPU and the Taito custom Z80<>68000 communication chip (TC0140SYT). I
decided to pull the Z80 and plug it into one of my test boards. This test board has a Z80 as the sound CPU and to my
surprise the sound had the same noise looping! I swapped the Z80 for a good chip and that fixed the sound issue.
Midnight Resistance
This appears to be dead, just a black screen. I waited a while and the attract sound started playing. I coined up and it
appeared to be playing blind so it looked like it was working, just a black screen. This looks suspiciously like the
same fault I had on a Psycho-Nics Oscar a while ago where the priority PROM was bad. It's a bit corroded in that area so
not surprising. I probed the PROM and all the outputs were dead. While probing it I touched pin 16 (VCC) and I saw
something flash on the screen. I pushed harder with my probe and the game came up on the screen and looked good! I
pulled the PROM and then saw why it wasn't working...
The VCC pin is broken off. I checked the socket and the broken pin is not stuck inside it so some clueless idiot has been playing here LOL! I re-attached a pin taken off a random dead chip, plugged the PROM back into the socket and the problem was fixed.
Another issue is the reset chip T518A is broken off but the game resets just fine although there's no low signal on the 68000 reset pin so it's pure luck that the game boots. I don't have any spares of this part so the owner can order one and replace it if he wants to.
I also updated all the ROM names in the MAME source for this game because most of them were poorly/lazily named.
Neogeo 4-slot
The board gets stuck at the initial green screen. This looks like the last cost-reduced version. The top board has
almost no logic chips and instead has 15 custom chips. Good luck fixing that when one of those chips dies LOL! I decided
to drop in the UniBIOS ROM and the board booted up and showed the test screen. I plugged in a cart and it appears to be
working fine as-is so I'm calling this fixed ;-)
I suggest whoever owns this to get rid of it F-A-S-T before it dies and becomes worthless ;-)
War The Final Assault
This is from the previous log 12th October. It doesn't boot up. I checked the ROMs and they verified good. I pulled the
boards apart and noticed the middle board basically has 2x PCI slots on it and the outer boards just plug into those
slots. I cleaned the gold fingers, plugged the boards back in, powered on and it works hehe! It came up with an error about
missing blocks.
The HDD is missing so I found a random small capacity HDD here (Quantum Fireball 5.1AT), wrote the image of the game
from MAME archives then powered on and everything passes and the game boots up!
Unfortunately it requires a special 49-way joystick to be playable so this will just go on my storage rack. Maybe later
I'll convert it to Gauntlet Dark Legacy as this game is able to use a normal joystick.
1943 bootleg
This is not working, just shows a brown screen but powering off/on a few times got this screen (frozen), but most of the
time it didn't boot. This might not be that difficult to fix as there's a few Fujitsu logic chips on the CPU and video
boards. I first checked the ROMs. They match the MAME set 1943bj. I checked the main program RAM at 10D which is our old
friend the Toshiba TMM2063. Of course it was bad and piggybacking a good RAM on top allows the game to boot. With the
good Sony CXK5863 RAM in place it now shows the title screen but the backgrounds are the same brown screen that showed
before.
The RAM failure was a bit unusual as it didn't immediately fail the test. It passed the 0x00, 0x55, 0xAA and 0xFF
write/read tests but failed as soon as it did the count+ test. Now the game can be started but there's no sound.
Checking the sound Z80 clock shows it's missing. That traced to an adjacent Fujitsu 74LS367 logic chip at 2J and
piggybacking a good chip on top got the sound working so I swapped that for a good chip.
The backgrounds are completely missing. They are generated on the bottom video board. The ROMs for the backgrounds are
at 5F and 8K (lookup tables) and the actual graphics are held in several ROMs at the bottom of the board. On this
version those ROMs are either 27512 OTP ROMs or 28 pin 231000 1Mbit mask ROMs. I read all the ROMs but of course the
1Mbit ROMs don't match anything dumped because they contain the data from the smaller ROMs joined together. Running
ROMCMP on these vs the original ROMs shows each half matches with the smaller ROMs so all ROMs verified good against
MAME archives. The 1/4 ROM matches are the sprite 1Mbit mask ROMs as those are 27256 on the original ROM set.
There is a Fujitsu 74LS175 near the ROM at 5F which had dead outputs and piggybacking that now shows the background graphics!
The clouds look to have the wrong colors and there's no sprites. Bad sprites on an original board is often fatal because
they are generated by the custom 86S105 chip. The bootleg uses a plug-in daughterboard containing logic and 3x 6116 RAMs
so it's very easy to fix it. On bootlegs the sprite issue is often just a bad connection with the daughterboard that
replaces the custom chip so I removed the board, cleaned the connectors and plugged it back in.
That brought up the sprites but they have the usual lines through them and are also scrambled.
Lines through sprites is usually RAM but there's 6x Fujitsu 74LS257 chips near both RAMs so I pulled and checked all of
them and found one was bad. Of course all 6 were replaced with different brand chips ;-)
This almost fixed the sprites but they still have lines through them, although occasionally they look good!
I checked the two RAMs at 7D and 12D. The RAM at 12D tested bad so I
replaced it and put the other RAM back.
Now the sprites look ok. if you check the previous screenshot you'll see a row of sprites at the bottom of the screen.
During the attract they sometimes disappear or move to a different screen location. This is definitely a logic issue and
might not be so easy to find as there are no more Fujitsu logic chips on the video board. On the daughterboard there are
a couple of Fujitsu logic chips so I pulled and tested them but they tested ok. Of course I replaced them anyway with
other brand chips but no change to the sprites. It's starting to get tricky now. I will first try to sort out the cloud
color issue. It looks like part of the cloud has the wrong color but part of it is ok. Probing around and shorting out
various logic chips didn't really help to locate what controls the cloud color. The only chips that affects the cloud
colors are the two PROMs at 6L and 7L. 1943 has LOTS of PROMs and they are all documented in the MAME source. 1943 has
foreground (clouds) and background (land/sea) graphics layers and a set of lookup table and palette PROMs for each
layer. The PROMs at 6L and 7L are of course the foreground lookup and foreground palette PROMs. I removed and tested
both chips but they verified ok against MAME archives but colors are definitely missing somewhere. Let's check the PROM
datasheet. The original board uses Fujitsu MB7114 which is compatible with 82S129 and this datasheet is easier to find
online. The bootleg actually has 82S129 PROMs on it anyway :-)
These are 256 bit x4-bit PROMs and have 4 outputs on pins 9, 10, 11 and 12. Probing those pins shows all pins of 7L are
active but pins 9 and 10 of 6L are low with no activity and only pins 11 and 12 are active. This is a bit unusual but
the PROMs are tested good so this must be correct behaviour. I tried to trace pins 11 and 12 but it wasn't easy to find
the connected end points. Maybe I should look for a schematic to save some time hehe! Ah yes it's available!
The two PROMs are shown on the first page on the bottom right corner. The output pins join to A19/B19, A20/B20, A21/B21
and A22/B22. That explains why I was having trouble finding the end points because those are the ribbon cable
connectors. All PROM output pins joined to the ribbon cable connectors except pin 10 of 7L (A20). The schematic shows at
the other end it joins to a 74LS273 at 13C on the CPU board. I checked the signals on that chip and there was no signal
on pin 18! That pin is an input and traces ok to the cable connector on the CPU board and through the cable to the video
board so it looks like there's a broken trace on the video board. I was about to start tracing that signal then all of a
sudden something started burning heheh! There was smoke pouring off a chip on the video board but the game was still
running. The sprites are now bad again and have lines through them. I snapped a photo then powered off quickly and saw
that the RAM at 7D was hot as hell and the markings on the chip have been burned off LOL! Since the boards are separated
I had a piece of polystyrene sitting in the middle to prevent shorting and it got so hot that it melted the
polystyrene!
Ok, so both of those HY61C16 sprite RAMs failed and replacing the burned RAM fixed the sprites again. So getting back to
the PROM tracing, the PROM pin 10 (A20) went through several traces and vias, up and down and up and down until
eventually there was no connecion on the trace near the left ribbon cable connector. There's no continuity between both
ends of that trace. I scratched away some of the green mask to reveal a tiny break. I applied some flux and as I ran the
soldering iron over it to apply some solder the trace broke away and disappeared hehe! I attached a wire to the via and
attached it to the remaining trace then powered on and that fixed the cloud color. Last pic below shows a side-by-side
on the attract screen where the plane shows since that's also affected and more obviously wrong.
The only remaining issue is the row of sprites at the bottom of the screen as seen in the above pics. I figured the
fault could be on the sprite daugherboard. This particular bootleg is better than the 'normal' type because the sprite
daughterboard is located on the outside. I've seen several other 1943 bootlegs that had the sprite daughterboard plugged
in underneath the video board and that makes diagnosing it a lot more difficult. So I started probing all the chips
using my logic probe hoping to find a missing output somewhere. When I touched pin 9 on one of the 74LS161 chips the
garbage sprites disappeared! I remove my probe and they came back. Ok so this is an easy fix, the repaired board will
just be given back with the probe hard-wired onto the daughterboard, problem solved! Hehe! No no let's try to really fix
the issue. I can get it to do the same thing just by touching that pin with my finger. Sometimes a way to fix that is to
tie a small value capacitor to that pin and tie the other end to VCC or GND and if you look at any bootleg board you
will often see those attached to logic chips to fix this kind of random issue. I tried that but it didn't fix the issue.
I also tried adjusting the voltage but that also didn't make any difference so I traced the signal back to the source.
Pin 9 of that 74LS161 goes directly to the cable connector pin A5. That is tied to pin 10 (output) of a 74LS04 at 12F.
The input pin (11) is tied to a 74LS161 at 11L on pin 15 and a couple of other chips on the inputs.
I'm looking for the source so I'm looking for an output and pin 15 on the LS161 at 11L is the one. This chip is part of
the timing circuit. I pulled the chip and tested it but it's a Motorola brand and unsurprisingly it passes. Either the
design of the board is crap (it's basically a 1:1 direct Capcom copy) or the chip has gone out of specification on the
timing/access speed or something and is now marginal when run at the full board speed. Chip testers usually test logic
at 1MHz or similar low speeds so they often don't find marginal chips which is why you should always replace any suspect
chip even if it tests good. So I did then powered on expecting to see no change but by a pure stroke of luck the garbage
sprites are gone heheh!!! I still need to test it a bit more but it looks like all the faults have been fixed and this
board is fully working :-D
One last thing I wanted to fix is the text that shows when starting a game and after the level is completed. If you
check this in MAME on the 1943b set you will see words that don't make sense...
AN TCK TARGE
Eh? WTF is that? Swapping out the ROM at 5H on the CPU board for the 1943 Midway Kaisen ROM fixes it and shows Japanese
characters. Of course it's not readable but at least now it shows the percentage in large numbers instead of some
garbage letters and small numbers. For the purpose of getting those screens more easily these pics below are taken from
MAME, showing screwed-up text vs Japanese characters. As a side-effect of this the title screen is also changed to show
'Midway Kaisen' but that's fine.
14th October 2023
A Killer Instinct board came in for repair.
The problem is there's no sound. I went through the usual things like checking/changing the TL084 op-amp, AD1851 DAC and checking the
surrounding capacitors but everything was good. If I shorted the op-amp + and - inputs (any of the 4 pairs) for 1 second then release it
makes a click then the sound plays perfect for about 2 seconds then fades out. This proves the digital side of the audio circuit is working
ok and looks like there's a capacitor issue (cap charges then discharges, sound fades). When I put my logic probe on the tantalum capacitor
that is tied to the amp pin 2 (5V/STANDBY) the sound is also perfect and continues to play as long as I leave the logic probe there... crazy
fault! The caps were removed and tested and they are ok and the amp was replaced and is ok. I jerked around for some hours and couldn't
figure it out. It has something to do with the 5V/Standby pin on the amp, or maybe the feedback pin. Why a mono amp needs a standby or
feedback pin I don't know LOL! The amp is a TDA7240. I swapped it for another one but no change. Just for a laugh I removed the amp and
connected a TDA2003. It's got 2 less pins but has the same signals. Here's a table of the signals and the equivalents on both amps.....
To use the TDA2003, break off pin 1 and bend pins 2, 3, 4, 5 so they fit into the original hole #'s 3, 4, 7, 6.
Solder it into the board. Wire the OUTPUT- hole on the PCB to GROUND. Power on and the sound works fine :-)
I've seen a couple of these boards with this exact same fault. Why it happens I don't know but there's no schematic and I don't want to
waste hours trying to figure it out. Just swap the amp to a TDA2003 and problem solved.
Here's another quick log for a related Killer Instinct sound repair, also with no sound. It was silent on first power on and would take 5
minutes to start making sound. It got longer and eventually no sound at all. The digital data coming out of the ADSP-2105 goes into the
AD1851 DAC on pin 7. That was only high now (before it was active). I traced it back to the ADSP pin 52.... no activity. I assumed the
ADSP-2105 chip was bad so I pulled it and swapped it with another chip taken off a dead scrap Cruisin USA. I powered on and sound is perfect
hehe!!
12th October 2023
A couple of non-working boards arrived as donations....
The left board is The Grid and the right board is War The Final Assault. The previous owner told me they were both
bought as working many years ago but not tested or used. As to why, that will become obvious later ;-)
Let's start with The Grid board. I'll do a repair log on War a bit later.
According to the MAME driver this runs on Zeus/Zeus 2 hardware. Nope! The VIDEO chip on The Grid is called 'Zeus2'. The hardware is actually called ATHENS. On
my Mortal Kombat 4 board it's called Z-PLUS and the video chip is called 'Zeus'. The hardware/board names are written right there on the boards ;-)
Looking over the board it's clear someone has been messing with it. The reset button is broken, the yellow "Snaphat Timekeeper"
battery is missing, one chip on the bottom right corner is missing, one ROM on the top left corner is missing and
another ROM is in the wrong socket.... working... yeah right LOL!
I first read all the ROMs and they identified ok and matched MAME set v1.20. The ROM that was in the socket at U16 is
actually supposed to be in the U18 socket.
With all the ROMs removed somthing stuck out as not being correct....
Ummm, there's a pin missing on the U23 socket. Eh?
I pulled out the broken pin and pulled a good pin from one of the other unused sockets and replaced that pin. If only a
single pin is broken and the rest of the socket looks ok there's no need to change the entire socket. It took a couple
of tries as the first pin wouldn't go into the hole and broke. 2nd try got it hehe! Looks like new now....
With the ROMs put into the correct sockets and the missing ROM replaced the board does not power up, just shows a black
screen. All the LEDs remain on so it's not running at all (when running LEDs should flash and some turn off). Probing
the ROMs shows a tiny bit of activity on the data pins for about 1 second. I have another identical board here with no
ROMs on it that was a Cruis'n Exotica. I swapped over all the ROMs and it only shows garbage on screen. At least it's
not totally dead. Oh well, so no easy fix hehe!
I put the ROMs back onto the board. I removed the broken reset button and replaced it with a good button in case it was
stuck in the pushed-down position causing a reset condition but it didn't change anything. I also noticed some damage on the
back side but none of the traces were broken...
The FCT162245 at U64 has also been messed with. This chip connects to the CPU databus and the main program ROMs databus.
The soldering looked like crap so I removed it to make sure the PCB pads were ok. They were ok so I replaced the chip
with a good chip from my spares just in case...
No changes to boot-up. I checked some of the large square chips and noticed some legs were loose so I reflowed
the entire chip at the bottom right corner and also reflowed the CPU located just above it....
Also no changes to the screen at power-on. I was thinking that the main DRAM might be bad. That's the 2x SOJ44 chips
just above the CPU. But then I remembered that those chips can sometimes pop off the board when located near the edge of
a large board (like these are)....
Yup! Cracked solder joints on the main DRAMs hehe! I reflowed both RAMs and then powered on....
Wow! It's working!! The clock has an error and the sound has an error. The clock is an easy one, just replace the yellow
Snaphat battery taken from my Cruis'n Exotica board and that allows the Timekeeper RAM to keep time. The sound error was
also obvious, when I swapped the ROMs over I forgot to put back the ROMs at U2, U3 and U4 which are the sound ROMs heh!
With all those replaced all power-on tests pass and the board boots into the game....
But there's a 'Joystick Not Found !' error :-/
I went into the test mode and was able to select the switch test by pressing button 1 since it's the first option....
Looks like the joystick is stuck LEFT+UP, the round thing in the middle is activated and one keypad key is stuck on.
Keypad? Eh? Ok so I looked up the cab and yeah it's got a 49-way joystick, keypad and trackball. I suppose that's one
way to obsolete a product by making it have controls that are not available 20+ years later hehe! Oh well, not going to
be able to test this further. So that's why the board wasn't tested.... it's not going to be playable without the proper
cabinet. BTW, that missing chip on the bottom right has something to do with A-D inputs. Possibly the 49-way joystick or
trackball, hence why it appears stuck as those lines are floating. Doesn't really matter as I don't have the joystick or
trackball so there's no need to replace it as the board appears to boot without it. So that's the end of this repair.
Maybe I'll convert this to a Cruis'n Exotica board sometime later so I can see what it looks like as the emulation in
MAME is incomplete. Or maybe I'll try to fix my Cruis'n Exotica board sometime.
9th October 2023
I received a few more Namco System 147/148 boards. Now there's 14 heh!
I dumped one a couple of months ago and a few weeks ago preliminary emulation was added to the Play! emulator....
Note the actual board dumped was Animal Kaiser EVO8, but the game running shows EVO 01.00. That's because the NVRAM holds
some data that enables the EVO8 update. The NAND contains the original EVO1 and any other updates but they are not
enabled until an update card is read in. So even with a USB update the updated version won't activate unless you also have the
original update card. Dirty f**kers ;-)
27th September 2023
I received a bunch of mahjong PCBs from China thanks to Dyq and little0....
Man Guan Zhi Zun, IGS 2003
Man Guan Cai Shen 3, IGS, 199? / 200?
Long Hu Zheng Ba Gao Qing Ban, IGS, 199? / 200?
Long Hu Zheng Ba Te Bie Ban, IGS, 199? / 200?
Long Hu Feng Yun, IGS, 199? / 200?
Pi Li Shen Deng, BMC 1998
Feng Yun Hui, BMC, 1998
Qing Cheng Zhi Lian, Sealy, 199? / 200?
1st September 2023
A couple more Konami Endeavour flash ROM boards arrived for dumping.
BTW, this system is known as Konami ES. ES stands for 'Endeavour Series'.
One is 'Safe Money' and the other is only identified as 'Amazon S' and is currently an unknown title not listed in MAME.
Update: Looks like the unknown game might be 'Amazon Spirit'.
Update 2: First emulation screenshots of Safe Money thanks to quick work by Osso....
Update 3: First emulation screenshots of Amazon Spirit thanks again to quick work by Osso....
Unfortunately these NSW versions seem to need a different IFU2 EPROM (not available) so there's a version mismatch :-/
As with the previous Konami ES games, there's a bunch of errors but most of them can be skipped in the test mode. It
looks like only the 'Main Door Open' error is holding these back from being fully playable. The machine has a regular
microswitch on the main door but also an optical switch with an emitter on the door and receiver on the cab. This is
basically the same type of opto as used in pinball machines for the ball trough. If BOTH switches are not engaged then the 'Door
Open' error occurs. Hopefully it's not that difficult to find the memory locations where the switches are triggered and
keep them happy so that these games will become playable.
29th August 2023
I just finished fully reversing Cosmo by TDS & Mints which is a rare game that runs on a modified Taito Color Space
Invaders board. I made a full schematic which took a couple of weeks to do.
Let's see if there's anyone still around who hasn't already fallen off the edge of the planet and is capable of
understanding this mess and fixing up MAME to get Cosmo fully working ;-)
28th August 2023
This Konami Endeavour hardware Rapid Fire 5 (gambling) board arrived for dumping a few days ago. Took about 1 hour to
dump it. I'm not sure this will ever be playable in MAME but it's dumped now anyway.
Update 5 minutes later:
Or maybe it will hehe! Apparently it's just your regular video slots type of game. Here's the first emulated screenshot
of it thanks to Osso's quick work plugging it into MAME. There's a bunch of errors but most of them can be skipped in
the test mode. It looks like only the main door open error is holding this back from being fully playable.
13th August 2023
Huge thanks to Luca Elia for complete emulation of Namco Happy Planet. The game is now fully playable with a mouse or something like an
XBox360 controller. There are 37 sensors to detect coin hits. Supported languages are shown in the last 4 screenshots... Japanese, Chinese, Korean and English.
7th August 2023
Here's a quick update on Namco Happy Planet emulation....
2nd August 2023
I'm baaaaaackk! Hehehe! Looks like the dirty penny-pinching sons-of-bitches running the ISP I'm with are in serious financial trouble. Some
years ago iinet was bought by TPG for 1.56 billion dollars and since then things have been going down hill. I don't know about you, but if I
had $1.56B instead of wasting it on b.s. like the internet I'd grab a couple of hot chicks and move to the Seychelles hehe! The big CEO's
running the show most likely have their Mercs and $10M payouts each year and because of all the wastage they've basically run out of money.
As a last ditch effort they went looking for loose coins down the back of the sofa but when they didn't find anything some loser lackie
shit-kicker toilet cleaner dog-snot scumbag ass-hat work experience noob decided it was a good idea to just kill all of the hosted web sites
which happened some time in the afternoon of August 1st 2023. It has probably only affected a handful of sites as most users would be
clueless and not know enough to use their free web storage space or even know that it exists. Now those sites just re-direct to their
End-Of-Life page LOL!
Thanks to a Guru-supporter here in Australia who has a retro-related site, an offer was made to host my site so now the official Gurudumps
site can be accessed as https://gurudumps.otenko.com/. It's also a modern secure https and not
the old 30-year-old http which gets flagged as unsafe by most browsers nowadays. The old site is dead and will never be active again so be
sure to bookmark the new URL. The new URL has been submitted to google and should be searchable soon-ish. But you don't need to remember it.
Just search "gurudumps" like usual and it should come up near the top after google indexes it.
Be sure to check out the parent site modelrail.otenko.com (particularly the top
menu on that site) as there's some unusual and interesting retro stuff there.
Thanks again for coming to the rescue and hosting this mess I call a website ;-)
31st July 2023
Courtesy of Luca Elia.... here's some super super super early work-in-progress emulation of Namco's Happy Planet which uses the special SH2
CPU with internal 256kB flash ROM that I just dumped. 2nd pic shows the real game screen....
Here's a video of the game.... https://www.nicovideo.jp/watch/sm18733632
30th July 2023
A Sega 'The House of the Dead 2' NAOMI cart came in for repair....
This was completely dead and didn't do anything. There's a lot of secret (but VERY COMMON) things that specialised Sega repair people don't
want you to know about Sega stuff so pay attention and you might actually learn something LOL! The first thing to do with a HOTD2 is
plug it into a standard white box NAOMI, or alternatively put the EPR-21576 standard NAOMI BIOS EPROM onto the HOTD2 board. Now power on and
you'll be able to get into the test mode by pressing the test switch. You will notice that it says 'UNKNOWN TITLE'. Ignore that. Now run the
ROM BOARD TEST. On this board the checksums are all 0000. This is BAD.... VERY BAD. The Sega 315-6050 Lattice pLSI2032 PLCC44 CPLD chip
controls the entire ROM board. The 0000 checksums means the CPLD is dead. Unfortunately it's not dumped but is a very common chip used on
many Sega games. Ideally what we need is someone to step up and either reverse-engineer the chip and make an equivalent PLD .JED file that
works or crack the chip and dump it. Anyway, no dump is available so the chip can't be replaced with a new one. Don't mess around just
replace it with another one taken off a junk board. In my case I took it from a junk non-working Hikaru ROM board. To do the job properly
the EPROM and oscillator needs to be removed too so you can get in and resolder the PLCC more easily and do a Guru-worthy soldering job
hehe! Be sure to wick the old solder off, clean with IPA, apply flux, position the good chip 100% perfectly first then tack one corner, then
the opposite corner and then solder each pin. Don't do like some amateur youtube people do and try to use hot air to put the chip back onto
the board on top of the mound of old solder. Try doing that with a QFP240 and see what happens LOL! A better idea is just do it right first
time! Wick the goddamned solder off and mount the chip onto the PCB so it sits down flat onto the PCB pads, dammit!
After
correctly replacing the CPLD with a known good chip put back the EPROM and oscillator and re-run the ROM BOARD TEST....
Notice how there's some numbers there now, not just 0000's ;-)
Now compare it to a known good cart by running the ROM BOARD TEST in MAME. I have a working cart here so I'll just use that...
Now it gets VERY interesting!! The numbers seems to be different but checking more closely shows that everything from IC12 onwards is
CORRECT!!!! This is a major improvement. The red arrow shows it should have 'F00D' at position 11 but the bad cart is different but after
that it matches. This means the ROM board still has an issue. Now don't just think that all of those ROMs are faulty and pull them all off.
No no no!! There is no possibility on any planet that 11 ROMs can be bad. On this cart ROMs 1-11 are on the top side and ROMs 12-21 are on
the bottom side. Ignore IC21 because it's not populated on HOTD2. The EPROM is IC22 and shown at the top of the list. Since ROMs 1-11 are
testing bad and are on top it makes troubleshooting this problem a lot easier. After some probing around while continually running the ROM
BOARD TEST over and over and over I discovered that the 2x 74F245 next to the CPLD controls testing/reading either the top OR bottom ROMs.
The F245 at IC25 is enabled (active) on pin 19 when testing ROMs 12-21 and the F245 at IC23 is enabled (active) on pin 19 when testing ROMs
1-11. When those chips are not enabled pin 19 is high. I concentrated on IC23 since the problem is on the top side. Probing pins 2-9 and
11-18 on IC23 shows that pin 13 sounds nasty on my logic probe and doesn't look correct.
Here's the datasheet for the 74245...
The 245 is a bus transceiver. In simple terms it just allows data to move from the A side to the B side or vise versa (i.e. A1>B1 or B1>A1
etc etc), *when enabled*, depending on the direction pin#1. When not enabled that bus is isolated from the other bus. Think of it as being
like a drawbridge. When the bridge is down (pin 19 active/enabled) traffic can flow and when the bridge is up (pin 19 not active/disabled)
no traffic can flow. The chip has 8 inputs and 8 outputs which allows 8 bits of data to be transferred at the same time and generally all A
and B pins will be active. If a pin on side A is active then the *matching* pin on side B should also be active and have a signal that looks
very similar. The datasheet shows the pin matching pin 13 (B6) is pin 7 (A6). I pulled the chip and checked it. Pin 7 is stuck! BINGO! I
replaced it with a good chip taken off a junk board and tested it in my chip tester before mounting it onto the board...
I tested the game but it still doesn't work. The ROM BOARD TEST shows different numbers to what was showing before but they are still not
correct. The numbers also change each time the test is run. Additionally now IC23 pin 15 looks suspect! The signal level is lower and dirty
but I know IC23 is good so something is pulling it down. I traced pin 15 (see pics below with red lines) and it goes to all of the SOP44
ROMs on pin 43, to the 315-6050 CPLD and through a via to the EPROM pin 20. The via near IC23 joins to a 4.7k pullup resistor array on the
bottom side and 3 other 74FCT16xxx chips...
The EPROM pin 20 is D3 so this is the program data bus. The easiest place to start is the pullup resistors. This is a package identical to
the one used on Tekken 3 (see my Tekken 3 log on 4th February 2023 for the details) and contains 8 resistors. One pin on one side is 5V and
the other 4 pins are 4.7k resistors pulled up to that 5V pin and the same on the other side. I measured each resistor with my red probe on
the 5V pin and black probe on each of the resistor pins. Each of these resistors should measure 4.7k ohms but the red trace that is tied to
RA1S measures around 800 ohms!!! The resistor will be ok so the signal is being messed up by one of those 3 chips at either IC43S, IC36S or
IC37S. Experience tells me it's probably IC43S which is a 74FCT16245. The other two chips are 74FCT373. Basically those 74FCT16245 chips are
dog-snot. The 74FCT16245 is exactly the same as the F245 chips above but they have 16 pins on each side so they allow 16 bits of data to
move at the same time. I removed IC43S and re-measured RA1S and now the pin that was 800 ohms is measuring 4.7k!! I can smell victory is
close. I found a replacement chip on a junk NAOMI cart (Derby Owner's Club) and mounted that chip onto the HOTD2 PCB....
I re-measured the resistance on RA1S and it's still 4.7k. I re-ran the ROM BOARD TEST and now all
the checksums are correct!! I removed the standard NAOMI BIOS ROM and replaced it with the HOTD2 BIOS ROM, powered on and....
Yeah!! That fixed it and now it's working 100% hehe! Those fine-pitched 74FCT16245 chips are a very common failure point on NAOMI carts and
many other Sega PCBs from the very late 90's and early 2000's so if the faulty chip can't be found easily by logic and deduction just change
all the 74FCT16xxx and 74Fxxx logic chips and you'll probably fix your non-working cart. Another option is to buy a junker NAOMI cart of the
same type and swap over all the ROMs onto it and that will also get you a working game cart but that's a *lot* of extra work. In this case I
fixed the existing cart :-)
Btw, there were rumors spread years ago about HOTD2 only working with the specific HOTD2 early revision motherboard. I have tested HOTD2 with
several NAOMI motherboards including the early and late versions and they all work. This means you can run the HOTD2 cart on a more common
(and thus cheaper) white plastic box NAOMI if you want. They all work fine. The only thing required is the game-specific HOTD2 BIOS but
otherwise nothing special is required as far as the motherboard goes.
28th July 2023
As usual there's always something going on here. Here's a few repair jobs I've been working on recently....
Meikyuu Hunter G
This is a bootleg board that was mostly working with a small graphics issue. I was told the owner was 'playing around' probing chips trying to fix a
'sync' fault and likely slipped and shorted something. After that the board was dead. I was told it sat around for ~10 years and now the
owner wanted it fixed so it was sent to me.
I was pretty sure I knew what happened. I checked the bottom of the board and found a burned trace. This can happen if VCC and GND are
shorted. Probably some chip somewhere has 2 adjacent pins that are tied to VCC and GND and these were shorted. I patched the trace, powered
on and the game was back to the same state it was 10 years earlier hehe! Now to fix the original fault. In the attract and game there's a
pattern of very tiny white dots in a grid of 5x5 spaced apart about 20mm that shows on screen ONLY when the screen scrolls
horizontally. It's still playable but kind of annoying. There's a trick that a lot of people don't know about bootlegs. They are often
assembled with really shitty 'GS' chips. These were made by Goldstar. Their reputation was so bad they changed the company name to LG hehe!
Even so they have actually kept the name partially... LG stands for 'Lucky-Goldstar' and most of the stuff they have made since the name
change is actually pretty good. Thankfully they no longer make logic chips ;-)
Anyway, the first thing to try is simply adjust the voltage slightly +-0.1V
or +-0.2V up to about +-0.5V and see if that makes any difference. Of course being an experienced Guru I kind of knew that was the issue and
sure enough setting the voltage at 4.95V at the JAMMA instantly and magically fixed the issue. Repair done!
The bottom line is don't play with stuff because you can very easily break it and then your board will be dead ;-)
If you can find the suspect voltage-sensitive chip (maybe it gets hotter than the other chips) it can be 'fixed' by putting a small value
ceramic capacitor from that pin to GND or VCC. If you check bootleg boards you will often see caps hanging off chips and this is why. In
this case the simple and cheaper solution is to adjust the voltage because looking for a suspect chip amongst 200 others isn't fun and can
get very expensive very quickly.
I dumped the full board and found out that this game is already in MAME but was listed as a Data East Japanese alternative.... which of
course is completely wrong because this is clearly a bootleg hehe! The dump was also missing PROMs because whoever dumped it previously was
an amateur and didn't have the knowledge and equipment to dump them or even identify that the board was a bootleg. I desoldered and dumped
those too. The game in MAME was updated a few days ago to correct the version and add the PROMs so that this game is now dumped
properly.
Police Trainer
I have 3 of these boards here. One was sitting around in non-working condition for ~10 years and the other two were given to me by a local friend a few months
back and are also not working. All boards just show a wavey mess on the screen....
The first thing to check is the clock and reset. Each board has the master 48MHz clock present. Board #1 has the reset present but boards #2
and #3 don't. The reset chip on these boards is a very simple Dallas DS1233 that only pulls the reset line low for 1/4 second then releases
it. The actual reset line is pulled up by a 4.7k resistor all the time. This means it's very easy to apply the reset by simply grounding the
reset output pin on the DS1233 for 1/4 second. I touched a grounded wire to pin 1 of the DS1233 and nothing happened. I tried resetting
board #2 and it came up and worked perfect but without sound hehe!! The test start-up checks pass except the sound ROMs. Ok so that one is
basically fixed, just needs a new reset chip and the sound issue fixing. The sound issue on this one is pretty clear....
The Lattice pLSI2032 CPLD at U151 is missing because I took that off to fix another board years ago that had a dead and burning hot U151. I
programmed a good pLSI2032 taken off a junk Sega Model 2B board with the correct U151 data, re-attached it to the board and the sound plays
so board #2 is now 100% working. Board #3 also does nothing when reset. Now it's time to go in deeper. I started with board #3 and the RAM.
The board has 4x CY7C199 SRAMs for the main program RAM. I pulled all 4 chips and tested them in my chip tester and one failed. I found a
good compatible 32kB SRAM in my stock of parts and remounted all 4 RAM chips....
On power-up the board still does nothing. The board is not in the best condition and has some minor corrosion near the RAMs. I traced the
connections and found 2 nasty looking traces that should have connected to the main program EPROMs but didn't. I patched those traces.
Powering on, now the red and green LEDs flash a couple of times then stop. When the game is working the LEDs flash continually so the board
is trying to boot but is crashing after a couple of seconds. For curiosity I put the test switch on and powered on. Now the output on screen
is different?!?!?! It looks like it's doing the start-up tests but the screen is garbled....
The screen is also just mono/grey... that's a hint to the cause but at this stage I wasn't thinking about that. The screen moved in time
with the test changes and when probing the ROM and RAM it looked normal. I put test off and the LEDs flashed a couple of times and then the
game crashed. I repeated it and the result was identical. So for some reason the game kind of worked in test mode with a garbled screen but
as soon as the board boots into the game it crashes! This board was also missing the U151 CPLD so I pulled the chip off the other non-working
board and transfered it to this board. I read it first and it matched existing archives. For some reason P&P Marketing (the company who made
this game) didn't protect the CPLDs so they can be easily read which is why they are dumped. I powered on normally and it still crashed
immediately. I put the test switch on and powered on and the POLICE TRAINER VERSION 1.5 sound played hehe!! The screen is still garbled but
this proves the board is running. I put test off and the game was now resetting a few times and part of the start-up sound plays then it
crashed. I inspected the board more closely and noticed that some of the legs on the large graphics chip were not properly aligned.
Unfortunately I didn't get a photo of it but it looks like the usual clueless cowboy was messing with the chip, maybe even blowing it up in
the process. I properly re-attached the chip and re-tested but there was no change to the mess on screen. Board #1 now becomes a donor
board. I took the graphics chip off and re-mounted it onto the almost working board #3....
To my surprise the screen is still garbled!! I spent a few more hours probing around and checking things. Eventually I got tired of this one
and started looking at board #1. After many hours I eventually pulled off just about every chip and tested them in my chip tester and
eventually discovered that U109 (the other CPLD connected to the CPU) was bad. I may re-build this board later but for now it remains a
parts board. The next day I went back to board #3 and studied my full schematic for a couple of hours and came to a conclusion. Oh... did I
forget to mention I completely reverse-engineered the entire PCB and made a schematic? Ummm, yeah I basically stripped board #1 down to
nothing and traced every connection....
The schematic shows clearly where the main program address and data lines are going. A couple of address lines and D16-D31 are tied to the
video RAMDAC and could be corrupted by a faulty chip on the same bus. This chip basically takes the VRAM pixel data generated
by the graphics chip and converts it to RGB. Since there was basically no color and I have already removed and tested all the other parts on
the same data bus I guessed that this chip might be bad. I pulled the chip off the donor board and mounted it onto board #3....
Then powered on and....
Yup!! That fixed it. So the messed up screen and program crashing was caused by the video RAMDAC!! WOW hehehe!!
I plugged in my lightgun and tested both guns on boards #2 and #3 and they played perfect. As they say, 2 out of 3 ain't bad ;-)
Operation Thunderbolt
This board came in mid afternoon today from a local friend. It was showing a COLOR RAM error then rebooting...
Note this game has a permanently-mirrored display so the backwards text is normal.
This was a really dirty nasty board so I put it in the sink with some soapy water and gave it a bath then dried it off in the oven at 50C for about 1 hour. The board came out looking almost like new :-)
Checking the board showed the color RAMs were the usual Toshiba TMM2063 suspects. I piggy-backed both chips and that nearly fixed the colors and the game booted up. I pulled both chips and checked them and one failed...
The bad chip was replaced with a spare from my parts bin and the game now booted up and looked perfect.
12V Power Supply
This is a 12V power supply used to run a Namco Animal Kaiser arcade PCB and was not outputting anything. They are very common in arcade
games made by Namco, Taito and Sega. These are not too complicated because it only outputs one voltage. The specific model of this one is
'TDK-Lambda VS75B-12' rated at 12V 6.3A. I reversed the whole thing so I've got a full schematic. The circuit isn't that complicated and the
PCB is only single-sided so a schematic isn't really needed but it's nice to have it simply to give the middle finger to manufacturers who
won't provide one hehe! There are actually a lot of very similar designs from a handful of companies and they are available in standard
voltages and several current levels. I went through all my stuff and found a bunch of them so I might reverse some of the others one day.
The problem with this PSU turned out to be a bad LM431. Of course every other part was checked first and this was the very last part I
looked at so it wasn't exactly a quick repair hehe! The TL431/LM431 can be tested with a simple circuit shown below. Connect 5V and ground
using any common arcade switch-mode PSU (or even a USB 5V phone charger or whatever) and the resistor divider will create a 2.5V reference.
When the TL431 sees that the LED lights up. If the LED doesn't light the TL431 is bad.
LED Board
This came out of the same Animal Kaiser arcade cab that the previous PSU repair came from. The LEDs are supposed to light up blue. The power
connector is just 2 pins, 12V and GND and the board only contains 4 LEDs and 4 resistors and nothing else. I applied power and nothing lit
up. I checked the current-limiting resistors connected to each LED and they were all good. I put a standard LED across one of the other
non-working LEDs, powered on and it lit up so it looks like all 4 LEDs are blown hehe! I keep a stock of LEDs in various colors so I pulled
off the very unusual wacky LEDs that were on there and replaced them with standard blue 1206 SMD LEDs, powered on and it worked so I suppose
this is fixed.
Namco System 148
A stack of Namco System 148 boards arrived for dumping. They are PS2-based so not a MAME-target. These are mostly all non-working, beat-up
because they were all just put into one plastic bag allowing them to scrape against each other (grrr!), corroded to hell and back because
the fan blows crap all over the board and after 10 years rots it out completely, and are also pretty useless games. 6x Animal Kaiser and 6x
Sea Story which is a totally worthless redemption coin-pusher game. They will be dumped later. In the meantime remember to keep your boards
and fans clean, people! ;-)
Commodore 64
The C64 that I use most often decided to stuff up again. Now it just shows an error '?OUT OF MEMORY ERROR IN 0'
This is a very common issue. It probably just means one of the DRAMs is bad. The DRAMs used in early 'long board' Commodore C64's that have
8x 64kx1-bit 4164 DRAMs are often made by Micron Technology and are just garbage dog-snot. Back in the day Commodore provided a diagnostic
cart to service centers and this has been archived and the cart re-produced so anyone can do it themselves. In February 2022 I designed a
simple C64/C128 cart for a fellow Aussie on youtube that can run any 8k or 16k ROM with up to 32 ROMs available and selectable with a rotary
pot. If you watch youtube channel "The Retro Channel" you will often see this cart sticking out the back of the C64 he's repairing at that
time. With the Diagnostic ROM selected, when running the cart it will test the RAM and if found to be bad it will flash the screen x-number
of times. That flash code is then looked up in the Diagnostic Cart manual....
The screen flashed 6 times. The table shows that 6 flashes means the DRAM at U22 is suspect. Now don't think that the diagnostic program is
100% perfect because it definitely isn't! It was designed to test the Commodore MAX which actually only has 2kB of RAM and thus it only
checks 2kB of RAM. There are many times when the cart simply doesn't do anything. However in this case I was lucky and it was easy. I
piggybacked a good RAM over the top and the C64 booted up fine. I swapped out that junk RAM for a nice new one and the old C64 is back in
action. There's still 4x MT RAMs holding on by their fingernails but I'll get them all eventually hehe!
I've been testing my modern (version 1) C64 drop-in replacement power supply for the angled brick PSU common here in Australia for probably 4
years now and recently got my newest revision 1.2 PCB prototype produced. As soon as the bare PCBs arrived I built one and it works great.
This one is much nicer and has over-voltage protection, over-current protection, adjustable output voltage, adjustable over-volt-trip
voltage, resettable fuses on the AC input and DC output and LEDs to show normal operation (green) and an over-volt condition (red) when the
saver circuit trips. It's designed to drop into the existing PSU case and use the same 9VAC transformer which generally doesn't go bad. It
is also designed with minimal build cost in mind, coming in at about $8 total including the PCB and all parts. Here's a pic of it on test, working
perfectly for 24 hours straight!
I manually added a simple voltage meter just to monitor it more easily over time. The voltages can be set to whatever you feel comfortable
with. Currently it is set so the voltage at the PSU is 5.31V when C64 is off. When the load is applied (i.e. C64 is powered on) it drops to
5.26V. Measured at the C64 motherboard the voltage is 5.05V which is perfect and it stays there rock solid at 5.05V all day. This 5V PSU can
provide up to 3A so it's more than enough to handle any C64 with anything else plugged into it. The PSU remains as cool as a cucumber at the
North Pole :-D
I've already made some more (mostly cosmetic) changes and that one will likely be the final revision. I will have an update on that the next
time I do another PCB order, which based on previous history could be in 4 more years hehe!
25th July 2023
A few years ago I picked up some unknown non-JAMMA Namco boards that use a Hitachi SH2 CPU. Here's a refresher pic....
About 1 year ago I contacted one of the (now mostly retired) MAME devs and asked if he was interested in looking at these games. He replied
he was interested so I dumped them and sent the ROMs over. He replied that the code for the SH2 was missing but was able to extract the
graphics and identify all three PCBs as Galaxian Fever (PCB code Z030), Shooting Paradise (PCB code Z029) and Happy Planet (PCB code Z037).
This suggests there are more games on this system. In fact I think one of the other games is Pac'N Party. He also reminded me of a game I
dumped a few years ago called 'Hide and Seek' in the MAME source file misc/hideseek.cpp which is similar SETA-based hardware. That also
means part of the dev work is already done and adding these to MAME might not be that difficult. Missing code meant it was hiding inside one
of the chips. I checked the SH2 CPUs and it turned out these are a special type SH2 microcontroller with on-board peripherals and on-board
256kB flash ROM and of course the main program is inside. Research was done over several weeks and it looked like it would be possible to
dump the SH2 CPUs but it would not be trivial. It required a special and very complex adapter that would have been available as a
development kit directly from Hitachi back around ~2000. Fortunately there are some hints in the SH2 hardware manual so I got to work and
created a custom adapter in order to make an attempt at dumping them. Due to also having many other PCB projects as work-in-progress it took another 8-9 months to
actually place the fairly large PCB order (250 PCBs) and the PCBs arrived about 2 months ago. Now all the pieces were ready to build it.....
Over the next month several attempts were made but the data read out only garbage. More research was done and I discovered a few tricks are
required to get the SH2 to cooperate, as well as requiring some additional hardware. Today I finally succeeded in dumping the first
HD64F7045F28 microcontroller which is for Happy Planet. These games are all kind of similar to Point Blank but the gun shoots actual medals
at a mirrored screen, possibly with optical or touch or magnetic sensors to detect the medal hits. The games look pretty fun and hopefully now with the full dump
available something can be done to properly emulate these games to a playable state. I can now also dump the SH2 CPU used on Hide and Seek
too which should get us another working game. We will have to wait and see if there's anyone left who's still alive, hasn't dropped off the
side of the planet, interested and capable of getting the job done.
Here's a few snaps of selected sections of the ROM with interesting text strings....
Note: I am the only person tooled up and with the required skills and knowledge and proven methods to dump these PCBs. If you have access to
any of these Namco SH2 HD64F7045F28-based redemption / medal shooting PCBs and you want to see them added to MAME do not attempt to mess
with them because you'll just break it beyond repair and that would be bad. A better idea is to contact me, send the boards over and they
will be dumped properly.
28th June 2023
A Technos WWF Superstars came in for repair. The board is working but has vertical lines across the screen...
These lines are on the background layer. It could be caused by RAM or ROM or logic connected to that RAM/ROM. I checked the board and didn't
see any dedicated background RAM. It is easy to test what RAMs do by shorting the data pins together then watching the screen to see what
happens. Shorting program RAM will obviously crash the game. Shorting graphics RAM will affect the graphics, either the sprites or
background or text layers. In this case there were no RAMs that affected backgrounds. Checking the MAME source shows the background ROMs are
located at IC112 and IC113. Probing them with my logic probe showed IC112 was active on all the data pins but IC113 had all dead data pins.
The MAME source code shows this ROM is 256kB so the ROM would be a 27C020. I pulled the chip and read it and nothing came out so I
programmed known good data to a 27C020, added a socket, plugged it in and powered on....
The in-game graphics look ok now but the title screen is still bad and the screen showing some wrestlers is also still bad. I assumed the
ROM at IC112 was bad so I removed it and tested the game without it and the graphics turned into solid square blocks. Looks like the ROM is
ok. I tried to read it as a 27C020 but I got the same result, no data in the dump, just a bunch of 00's. Hmmm something strange is going on
here. The PCB shows the ROM type.....
Sharp LN5322. Looking that up on the net reveals nothing. Even in ROMref.txt it shows nothing but I suspect I know what's going on here.
It's a custom ROM with some pins swapped. With the 27C020 installed some data is coming out so it's close to the same pinout but some pins
are different. Looks like Technos tried to outsmart Guru, but sorry you screwed up *very* badly. The board has a bunch of sprite ROMs
nearby and most of them are the same strange Sharp mask ROMs but 2 are 234000 which has a known pinout. If you know anything about arcade
PCBs you will know that generally ROMs are connected so that all the address lines are together and sometimes the data pins too. Output
enables usually go to logic or a custom chip. Tracing the sprite ROMs reveals that all the pins between the Sharp ROMs and 234000 are common
*EXCEPT* 4 pins... BINGO! I wrote down all the pins and compared it to the standard mask ROM.
Here's the pinout of the *top-secret* Sharp LN5322....
Update: I later found the datasheet and this ROM is actually a LH532200B. OE is active low to enable reading the chip. OE1 and OE2
are mask-programmable at the factory and could be either high or low so when trying to read these ROMs you need to try all 4 combinations
L/L, L/H, H/L, H/H. Additionally, there's no guarantee that the correct OE1/OE2 settings for this ROM are the same for ROMs found on other
boards.
With this info I made up an adapter using a socket and some wires. Basically lift up the affected legs and wire them to the socket on the bottom. Once that is done push the legs down to tidy it up a bit then put that back onto the PCB. That fixed all the graphical issues and the game is now working fine :-)
Good fight Technos but sorry you lost LOL! Final Score: Guru 1, Technos 0
Update: I forgot to mention the sound issue. The crowd cheering noises were missing. Looking at the board it's pretty clear why. Some
clueless cowboy has messed with the OKI M6295 chip!! I removed the chip and remounted it properly but that didn't fix the issue so I replaced the
chip and that brought back the missing crowd noise.
7th June 2023
Getting back to the Ehrgeiz repair, the board is kind of working so I played a quick game to see if
everything was working. The controls are a bit messed up. In the test mode it shows some stuck buttons...
These 2 buttons are connected to the Namco 48-way expansion connector then go through some resistors
and caps and eventually join to one of the same logic chips I have already checked. The outputs from
that logic chip go to the CUS416 and H8/3002 sound CPU. I re-checked the LM358 and noticed another
trace coming off the pin 1 output going somewhere. Hmmm I wonder where that goes...
Hmmm now this is very interesting. It connects to C60 near the H8/3002 CPU which is just grounded
but it also connects to the H8/3002 on pin 77. The H8/3002 also takes care of inputs/controls but
the sound was working so surely the H8/3002 CPU is ok, right? I removed the small C60 cap and
checked it but the cap was ok. I decided to lift up pin 77 of the H8/3002 (VREF
input) then I removed my jumper wire, powered on and checked to see if there was any change...
Wow! The voltage is now correct, around 4.6V!! So I suppose this means the H8/3002 CPU is partially
bad and is not only pulling down the voltage but also screwing up the buttons. I pulled the H8/3002
and swapped it with another one then powered on and checked the test mode switch test....
Looks like everything is fixed! The screen is good and the controls work fine. Repair job done :-)
3rd June 2023
This cute little Namco System 148 board arrived yesterday....
I have placed a common 32 pin EPROM next to the board for size comparison. The game is "Animal Kaiser - The King of Animal". This is a card
collector battle game similar to Yu-Gi-Oh. The hardware is basically a later release slim PS2 but is a custom heavily cost-reduced arcade
board. There's the standard PS2 chips on the board, CXD9799AGP and EE+GS CXD9833. These are the same chips on a Namco System 256 board. On
the bottom is a Samsung K9K8G08U0A 8Gbit (1GB) NAND flash ROM. On top near the battery is another TSOP48 ROM that has been re-marked
"ULS1001 STSPR0A". This is a typical Namco game code. Once I figure out what that is both ROMs will be dumped. I'm not sure the effort is
worth it as this isn't going to be emulated. Anyway, the funny thing is next to the USB port there are 3 pins...that's an exposed serial
port that will likely display some debug info similar to Namco System 10 if I were to hook this up to a PC serial port hehe!
UPDATE: 20 minutes later all ROMs were identified and dumped. NEXT!
Here's a few snapshots showing some interesting text strings....
31st May 2023
I've had this faulty Ehrgeiz board laying around here for years. I decided to have a look at it today.
The board 'works' but the screen is very very dark, almost black. The sound can be heard and it plays blind. Well, it can be coined up but
resets as soon as the game is started. I had a closer look and noticed some corrosion on some logic chips near the jamma connector. These
could potentially be causing the reset problem because my schematic shows they are connected to the H8/3002 data bus so I removed them and
cleaned up the crap. I tested them in my chip tester but they were good so I replaced them and re-tested, no change to the game.
The next step was the swap over the top CPU/GPU board with a known good board but that didn't change anything. The video output section is
the next area to check. There's a Sony CXA1779 RGB output chip, a Fujitsu MB88347 video DAC, some resistors, caps, a diode, a LM358 and a
MAX734. There's some damage around the CXA1779 so that's where I will start. I removed the chip....
It looks a lot worse than it is and there's no actual damage. I tested the CXA1779 in a different working board and it works fine so I
cleaned up the area and put the chip back. The rest of this section looks fine. I checked my schematic and it shows the MB88347 outputs 6
signals that connect to the RGB brightness and RGB drive pins on the CXA1779. Brightness is my main issue so maybe that chip is bad? I
pulled it and swapped it with another chip taken off a working board but there was no change on screen. The MB88347 datasheet shows it has a
VDD pin which is used to power the analog section of the chip. I measured the VDD pin and it was around 1.3V. I have no idea what it's
supposed to be so I checked a working board and the voltage measured 4.6V! Hmmm, could this be the problem? My schematic shows this 4.6V
comes from the LM358. I removed and tested the LM358 but it was ok. I replaced it with another working chip anyway but there was no change
to the output voltage. The voltage is set by 2 nearby resistors which measured ok. I also removed and tested the diode and caps but again
they were fine. The only remaining part in this circuit is the MAX734 so I pulled it and swapped it with a known good chip taken from a
working board but again no change on screen! So everything in this section is good but the voltage is low. I wonder what would happen if I
force some voltage onto the VDD pin....
Holy crap it works heheh!!
I want to see why and fix this properly but I've run out of time today. Check back later for an update.
In other news, I was having a quick look at a Taito Psychic Force 2012 motherboard and checking the EISA connector. It's supposed to be a
stock P5TX-LA motherboard but has many parts missing because they were not required for this game. Everything on the net says the brown slot
is EISA. Sorry internet you are WRONG! LOL! I know that EISA is ISA compatible but when an ISA card is plugged in the metal bracket hits the
motherboard. The connector is in the wrong place! Then it hit me... this slot is for a riser card. The actual connector is EISA but the
wiring is not! I found an old riser laying around here and plugged it in and it fits perfect! So the top Taito board is just a PCI card
containing a DOS HDD image stored in ROMs (there's a Microsoft sticker on the top Taito board near the AT power connectors) and a Voodoo
video card. That makes sense because the sticker on the BIOS says "AWARD PCI/PNP 586 (C) 1997". Mystery solved!
29th April 2023
Over the last couple of days I've been continuing with trojan dumping the whole main DRAM on Point Blank 3 using my hacked-in TSOP48
adapter. After a couple of days and 62 trojans run I had a total of about 1MB of plain text data (62 x 16384 bytes of data). I had
previously mentioned trying to trojan-dump the data directly via one of the ports on the expansion I/O board but there wasn't much interest
due to lack of info or code examples. I had a closer look at the board. There were some unpopulated parts on the ROM board, specifically
some missing 0402 SMD capacitors, a missing J2 connector and a missing chip LT1181A. The datasheet shows it's a RS232 chip. Hmmm. I wonder
where it connects. Only TR2 (receive port 2) is connected and it joins to the ROM board connector. I traced the motherboard and it went to a
LVT245 buffer. The input of that connects to the CXD8606 CPU on pin 74 which is the serial port TXD1 pin. Wow! There'a an exposed serial
port not going through any protection. That was pretty silly to leave it there on full retail boards hehe! I checked the TR2 pad going into
the not-populated LT1181 chip with my logic probe and there was activity at power-on. This means the program is sending some data to the
serial port at boot-up. I mentioned this to Windy Fairy and suggested he could hook up the serial port in the MAME System 10 driver, log it
and see what comes out on one of the working System 10 games. It looked good, some debug info showed when capturing the data in a terminal
program. From my point of view the first step is to see if I can capture the same stock data. I sprung into action!
This is a standard ROM board showing the missing parts.....
After a few minutes it had those parts, taken from a System 10 EXIO board on one of my Taiko no Tatsujin games. I was previously a bit
overzealous with the hot glue so I had to chop part of it away to get the chip to fit in place, but it's all good now....
Then I had to haul my old laptop and EPROM programmer into my workroom bringing all the cables etc. and I precariously balanced the laptop
on a chair. I found an old USB cable, ruthlessly chopped both ends off and wired a couple of wires onto J2 on the ROM board and
hooked that to my old Toshiba Tecra A8 laptop which has the optional serial port module populated. It's just a simple DB9 null-modem cable
with pins 1+4+6 tied, 2 is receive (RX, green wire), 5 is ground (black wire), 7 and 8 are tied together. Pin 3 is transfer (TX) but the PC
is not doing any transferring and the System 10 board is not doing any receiving so that pin is not connected. This laptop runs Windows 7 so
I downloaded the old shitty Microsoft Hyper Terminal and ran it then powered on the board....
It worked great! In the meantime over a couple of hours Windy Fairy had written a serial transfer dumping program using some of the example
code Namco provided with their bootup debug thing and pre-tested it in MAME to make sure it was doing the right thing. I burned it to the
NAND and ran the test. The first time it started dumping some hex data (we did it in ASCII HEX because it's easier to just capture plain
text) but after about 2 seconds it reset and repeated again continuously every 2 seconds. He added some code to keep the watchdog happy and
I re-burned the NAND and re-tested, then I got comfortable on a milk crate and waited while all the data scrolled up the screen at a
blazingly fast 115200 baud....
After about 9 minutes it was done and I had a ~6MB text file on my HDD. Windy checked the data and confirmed everything was good and 5
minutes later these pics came back....
Job done! It hasn't been properly decrypted of course. This is just using the dumped code until the encryption is figured out. This will be
playable in MAME 0.255 which gets released at the end of May. Or you could pull the source from github and compile your own if you can't
wait :-)
26th April 2023 I've updated my Namco System 10 page with some history about what's been going on
over the last few weeks. Read that to catch up. The last 3 Namco System 10 boards were being stubborn as far as emulating them is
concerned so I ran a few trojans on the boards for Taiko no Tatsujin 3 & 5 and Point Blank 3 and that led to the decryption of TK3 and TK5.
However Point Blank 3 is being more stubborn so it requires many more trojans. Unfortunately the protection keycus prevents writing to the
whole NAND ROM so the trojan can only write to the high score area of the NAND which is only 16kB. It's EXTREMELY time consuming to pull and
remount SMD tsop48 ROMs as well as the PCB pads are not going to last so I've mounted a DIP48-TSOP48 ZIF socket onto the board. Now I can
just program and swap the NAND ROM over in 30 seconds. The main program is 4MB but hopefully all 256 trojan reads to get the fully decrypted
code won't be required. But at least now I'm prepared for it if necessary hehe!
This pic shows the board working using the original ROM to verify everything is good. It works so it's all good :-)
21st April 2023
I've added a new Namco System 10 Page to my main menu 'Guru Status'. Previously this info was
on a google spreadsheet but now that info has been transferred over permanently to this site. The spreadsheet will not receive any more
updates from me. Keep an eye out on my System 10 page at least daily because things are probably going to move very quickly ;-)
4th February 2023
An undumped Namco Tekken 3 PCB (TET2 Ver.C) arrived from long time MAME supporter Heihachi_73 (a fellow Aussie from Melbourne) which has now
been dumped and added to MAME.
Before dumping it I had to remove the battery which is located right next to the flash ROMs....
Many many years ago (probably 20) I once made the mistake of not removing the battery in order to retain the coinage/play/character-unlock
data. That was a mistake... upon heating the ROMs with hot air the battery decided to go nuclear and it literally disappeared never to be
seen again heheh! So I removed the battery first. But before doing that let's have a look at the coinage/play data....
Total coins is 6951. Total power-on time is 8395 hours. If we assume it is on 12 hours/day that's a bit less than 2 years of on-site
operation. The coin rate per hour is about 82c per hour. Not exactly a great hourly rate but I suppose the arcade operator eventually got
his money back plus a bit of profit assuming he paid less than $7k for the cabinet. The total play time is only 301 hours so this game was
clearly not very popular. 301 hours vs 8395 power on time means it was only played 3 1/2% of the time it was powered on.
The board is working but has some minor damage so for fun I will try to fix it. The top board has a surface mounted electrolytic cap
missing. This is quite common and doesn't affect anything so no need to replace it. The only time missing caps need to be replaced is when
they are connected to thin traces and are part of some circuit. When there are many caps on power planes, one cap doesn't affect much if
it's missing as there are several on the power plane already. One trick often done on laptop/phones is just to snap off a bad/shorted cap
connected between VCC and GND and that will remove the short and the device will start working which proves all of them are not required.
You could replace it if you wanted but I'm going to move on.
The bottom board has one damaged EMI filter and a missing SMD capacitor...
While EMI filters probably don't do a whole lot either, the way it is wired, the signals from the JAMMA connector go through the EMI filters
then to other components. If the EMI filter is bad the signals won't get to the right place. Look closely and you can see the EMI filter at
FL6 has a hairline crack in it. Cracking isn't that common (it's clearly had some kind of heavy blow on it) but it is common for the EMI
filters to have cracked/dry joints and re-flowing them often fixes it. In this case it has to be replaced. You could also just replace the
filter with wires if you didn't have spare parts. In my case I have a few dead/junk Namco System 12 boards lying around so I have plenty of
spare parts.
The small cap was also replaced. This is a 2.2nF 0603 SMD MLCC capacitor. This took about 10 minutes to fix including pulling the parts off
the junk board and cleaning the board with some special PCB cleaner ;-)
I powered on the board, inserted a coin and hit start. The character select screen had the selector moving automatically to the right. I
went into the test mode to check the inputs....
Looks like 'right' is stuck on. I can move the joystick in other directions but when I let go of the joystick it goes back to the right
direction by itself. With my logic probe I checked pin 5 of FL6 (the 'right' input) and there was no signal, nothing! The inputs are usually
pulled up to VCC through a pull-up resistor and moving the joystick actually grounds that same signal and causes it to go low. When the
joystick is not touched the signal automatically goes high again because of the pull-up resistor. In this case there was nothing, it was
floating. The signal first goes to some adjacent 74HC257 logic chips. The floating no-connect signal is low enough on the logic chip input
(pin 2 in this case) that it thinks right be being activated. I removed a bunch of parts along the path of the JAMMA right direction so I
could check them and the traces....
The traces are all joined. At the back is another 2.2nF SMD MLCC capacitor and a 103 (10K) resistor. These tested ok in my component tester.
The part before that is marked R102...
On first glance this looks like a common 1K resistor array.... 1, 0 and 2 extra zeros = 1000 Ohms = 1K ohm. This particular resistor array
consists of separate 0603 resistors and looks like a common off-the-shelf part. I used my multimeter to measure the resistance of each
resistor. Now this is the unusual part... the resistors are not all the same! It measures 1K, 2K, OPEN, 2K, 1K. The open resistor seems to
be the issue. I pulled another identical part off my junk board and measured it. It measures 1K, 2K, 2K, 2K, 1K. Ahh!!! I figured this was a
custom part but I found the datasheet and it's a stock part. The datasheet is available online. Below is a quick snip from it. It's the
R-Type. The R refers to the type of circuit inside which in this case is 10P8R. This is actually 8x 1K resistors. The 3 middle pins
connect 2x 1K resistors together in the middle. The 2 outer pins connect to a 1K resistor in the middle and the other end joins with a wire
to the pins (5 and 10). So that's why the middle pins measure 2K and the outer pins measure 1K. In this case if you didn't have the required
part you could simply replace all 5 positions with common SMD resistors (probably 0402 would fit... remember there's 2 butted together in
the middle...) and wire them as per the circuit (probably very tricky work for such a small SMD area) or just buy some online. I have the
part so I just replaced it....
Now it looks like new and you can't even tell it's been repaired hehe!
I powered on the board and checked the test mode controls and all are good. I played a game and it's working fine now.
In other news, I also dumped a Tekken 2 TES3 Ver.A board which was previously undumped. This was a redump because I actually dumped this
many years ago. I later found the older dump (dated December 2016!!) and the CRC32's matched exactly. For some reason either I forgot to
upload it or someone forgot to add it when I released the dump into the wild, but it's done now ;-)
For previous news back to and including 2017 check the top menu 'Old News' link.
You can find a mirror of older offline news on the Wayback Machine. Probably ;-)
<-- Please Donate :-)
.....it's sleuthin' time!
