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 ;-)
