About me

My Photo
Vanløse, Copenhagen, Denmark
Mathematician. Working programmer/system developer. Nerd. Married. Father of 3.


Bubble Bobble Lost Cave & REDUX on same bootleg PCB

About a year ago, i managed to snap up a cheap defective bootleg Bobble Bobble that I fixed and installed the REDUX ROM set on. That works fantastic, but another exciting project is Lost Cave, that originally released on December 11, 2012. It's a very ambitious fan project made by the 2 good fellows Bisboch & Aladar and consists of 100 "new" levels for the original arcade game. "New" are in quotes, as it's actually the best levels from various ports, that have been backported to the original arcade platform. Along with that, it introduces a lot of new elements for example on the graphical side. The original release from 2012 only ran on original Taito hardware (and MAME), but when the authors discovered REDUX, they got inspired to try and do a bootleg-PCB version as well; and as of Lost Cave v1.2 (December 11, 2013) it also runs on bootleg boards (the kinds without a 68705; so the same criterion as running REDUX).

I downloaded the Lost Cave (bootleg) ROM set and installed it on my board, and it worked like a charm; jawsome game! };-P Now Lost Cave is a whole new game with new levels and stuff; the original levels are not present in the game anymore. So I started thinking about how I could find an easy way to run both Lost Cave and REDUX on my board, without having the fuzz of swapping the ROMs every time.

The first thing to notice is, that all the ROMs on the board are 27256

Next thing to notice is, that EPROMs in the 27-series comes in "clusters" of form factors given by the type of DIP packages. So ie 2716 and 2732 are both DIP24, whereas 2764, 27128, 27256, 27512 are all DIP28 and so on. Now if you compare the pinouts of 27256 and 27512

you'll find, that they are almost identical with the exception of pins 1 and 22. The 27512 uses pin 1 as the extra address pin and have pin 22 double as both Output Enable (in reading mode) and Programming Voltage (in programming mode). Now pin 22 we don't have to worry about, as the EPROM will only operate in reading mode on the board. But pin 1 will allow us to switch between the upper and the lower 256K bits of the EPROM. This scheme is often referred to as bank switching (at least when it's is done runtime, anyway), as you divide the address space of the ROMs into two separate banks that you can switch between.
Now to pull this through, I first had to identify the union set of all the ROMs that has to be swapped to go from straight bootleg to either REDUX or Lost Cave. Now the REDUX are marked with bow ties and the Lost Cave are marked with fezzes

...the union set is of cause just all the marked ROMs };-P. Please note, that on other bootlegs, these ROMs might have very different numbers/id's, so it's the position that's the important thing here.

Next I started doing the plumbing for the bank switching. First of all, I would need an ON-ON switch with +5V on one pole and GND on the other; the middle will then be the "bank switcher". I just happened to have a bag of tiny ON-ON switches stocked that fits into 3 successive holes on a DIL, so as bootlegs often has a lot of unused holes, I easily found some usable ones to clean up.

and installed the switch

Next, the wires got soldered on on the solder side

The red wire is +5V, the unisolated is GND, and the blue is the bank switch-wire.
Now on the main PCB, 3 of the 4 ROMs to be swapped (the 3 ones on a line), already had pin 1 tied to a GND-rail individually, so these connections had to be cut of cause.

These are marked with 3 red arrows; I also accidentally (it was late at nite }:-S) cut the connection to pin 2 on the middle ROM (blue arrow). So that's why there is also a piece of red kynar to patch this up on the next pic showing how the pin 1's are connected to the bank switch-wire.

As you can see, the blue switch-wire ends at the ribbon cable connector

That's because the switch-signal needs to be passed on to the secondary board. And as I didn't want any extra wires (that would have to be desoldered every time the board is taken a part), I choose to hijack one of the many GND wires on the ribbon cable (notice the cut). Now that was all the plumbing needed on the primary board. The secondary board was actually easier. Here, all the pin 1's on the ROMs was already interconnected, with a GND-connection in one end, and a connection to a resistor array in the other end. So only 2 cuts on the component side needed to be made

And then of cause, the connection to the hijacked ribbon pin had to be cut and connected

The last thing needed to pull this off, was the actual ROMs. Now as I'd dumped all the ROMs during the repair, I had a full set of REDUX ROM files for my board. Also, before I even started, I'd checked that Lost Cave v1.2 would actually run on my board, so I had a full set of files for that too. So it was only a matter of combining the two sets, for each ROM that needed to be swapped. This is easily done ie in a Windows cmd prompt with the command
~> copy /b rom1 + rom2 combined_rom
for every pair of ROM files; of cause taking care, that the files from the same set were always first/last };-D

So I replaced all the 27256-ROMs to be swapped with the just programmed 27512-ROMs and fired up the board full of excitement };-P

Now that's just puuuure awesomeness, ain't it? };-P

As a last thing in this post, I wish to mention, that I've recently created a Facebook page, that'll make it a bit easier to follow the blog. Here I'll post every time I make a new blog post, but also make minor posts about progress of current projects etc. I welcome you to visit, and 'like' if you wish to be updated on the stuff I do.

A whole lotta love from Yours Truly };-P


Using GALs to replace small, sparse and/or redundant bipolar PROMs (Galaga bootleg)

If you've done repairs on some of the earlier arcade games (Galaga, Donkey Kong, Pac-Land etc.), you're likely to have encountered the type of components known as bipolar PROMs. These are PROMs based on TTL technology and are one-time-programmable (OTP), as you literally burn fuses when you program them. They are often pretty small in capacity but very fast, and on many boards, they are used for things like address decoding, sprite selection, pallets etc.
Now this whole project started out with me repairing an original Namco/Bally Midway Galaga for my friend Muerto. During this, I found, that a bipolar PROM used for selecting sprites from the sprite-ROMs (i think?!) had a dead pin. Luckily, I had a bootleg Galaga containing the same PROM sitting on the shelf, and replacing with that solved the problem. But now I just a non-working bootleg.
Now as bipolar PROMs are pretty old technology, blank ones are not easy and also a bit expensive to acquire; they will easily cost you $10 (or more) a piece + P&P on eBay. Also because of the technology being old, most new (even high end) programmers doesn't support programming them either; many doesn't even support reading them. So that means that you'll have to get some expensive hard-to-get vintage programmer and also expensive parts to get you PCB with broken bipolar PROMs up'n'running again. As I was not willing to spend that much green on a bootleg (that I btw had gotten for free at some point), I started thinking about alternatives to bipolar PROMs.
The first thing the pops into mind, is trying to use some kind of EPROM. But when you try to look at the specs side by side, you'll quickly realize, that most EPROMs are much bigger in capacity (and while that is not a direct problem, it seems like a bit of a waste), but more seriously, the speeds of EPROMs are often about a factor 10 slower than the bipolar PROMs! So EPROMs were out...
Next I started looking at different PLDs and found, that the speeds of standard PALs and GALs are often comparable to that of bipolar PROMs or a bit faster. Moreover, almost any cheap ass modern universal programmer supports programming GALs, you can get new GALs for about $1 a piece on eBay, and you can erase them electronically and reprogram them.

I actually had 2 defective bipolar PROMs on the bootleg Galaga, that needed replacing. That was because when I realized how easy it was to read these in my Top2005+ using my own software u2pa, I wanted to

on the Galaga PCB. But when I tried to get the one labeled "5" at position 5N out, I accidentally broke off the GND-pin. The break was so near the plastic, that a normal pin transplant wasn't an option, so enter Mr. Dremel. I managed to cut the plastic down so I could solder a bit of wire on the broken pin; it was good enough for dumping

but not at all durable enough to put back in the socket. This PROM must be involved in the final stages of the picture generation, cause when it's not in it's socket, all you get is a blank screen. I decided to start with that one, as it's a TI TBP18S030 (equivalent to the better known Philips N82S123),

that only holds 32 bytes (= 256 bits).
Now in order to get started, I needed some way to generate the equivalent equations, so I wrote a little QAD method that generated the Boolean equations in the format of WinCUPL, and hooked it up to the u2pa CLI

If we start by looking at the raw dump

we'll see, that the 2 lines of bytes, are actually pretty redundant, and that's good, as we want to fit then into a logic unit. Next we take the raw WinCUPL equations generated by u2pa

cut them out, and make them into a real WinCUPL project. And I have to admit, that I was a bit surprised to find, that it compiled to a GAL16V8 right away };-P

At this point, the observant reader should already have noticed, that all the outputs of the GAL are on the "wrong" side, compared to the data pins on the bipolar PROM. Some kind of adaptor had to be made in order to make it fit onto the Galaga PCB. I choose this configuration of pins

Again the observant reader might have discovered, that if you turn the GAL 180 degrees, you can get all but one pin to match the PROM (not including the Vcc and Gnd of cause).
When I dumped the GAL using u2pa with the above configuration and compared it to the original

it was a perfect match };-P
So I started soldering up a small adaptor

Actually pretty easy, as almost all the pins match up };-P I dumped it as per the original PROM and still got the same correct result. So I cut it up

installed it in the socket

and BAM! had picture back on screen };-P

The Galagas still didn't look right, but that was expected. So now on to the next PROM...
This one is a TI TBP24S10 (equivalent to the better known Philips N82S129), a 4 x 256 bit PROM. As I'd only read ROMs that had a number of outputs being 8 or 16 until now, I had to make a little adjustment to the coding of u2pa to make it work. The dump in MAME is made by just saving whole bytes padded with zeros, so I choose to do the same and use this configuration

Even though this PROM potentially contained 1024 bits of data, only the first part actually had non-zero entries

So I was still pretty confident, that this would fit onto a GAL. So ran my equation generator, and made a WinCUPL project with a GAL16V8. But when trying to compile

I got "excessive number of product terms" on all 4 outputs. Now at this point, being all new to WinCUPL, I didn't knew, that minimization was not 'on' by default, but that you have to turn it on (you should use Expresso) in the compiler options (this was something porchy told me later on)

So I started 'hand reducing' the equations. Actually now afterwards, I find it kind of cool, as you get a whole new feel for the equations, and they have a very satisfying aesthetic look (oh yeah, just go ahead and call me crazy; but being both a mathematician and a computer scientist, I can't help it };-P).
One of the first things I noticed from just looking at the raw dump in a binary editor was, that every 4th entry was F (1111). So every time A0 and A1 was 0, all 4 outputs was 1, meaning that all entries from the 4 outputs starting with 00 could be removed, and replaced by a single line for every output
 Dn = !A0 & !A1 & !(A2 &  A3 &  A4 &  A5) & !A6 & !A7
where the "!(A2 &  A3 &  A4 &  A5)" part is because, we want this to stop when we reach the point, where all entries are 0.
Next I found quite a few pairs of entries, where the only difference between the two, was that one started with 01 and the other with 10. Now these can of cause be combined into one starting with (A0 # A1) (XOR).
So now I was down to a respectable number of equations for each output, but when I compiled I still got "excessive number of product terms" for 3 of the outputs. It was actually also at this point, that I turned on minimizing, but that didn't do any difference at all }:-S
Then I got the idea of trying a bigger GAL with more available product terms per output, namely a GAL22V10. And when changing to that, it frakking compiled without errors };-P For this GAL-replacement, I'd choosen this pin configuration

That way, it could act like a drop-in replacement (with part of the IC hanging out to the back of the socket, though) if I just connected pin 8 and 12 for proper grounding.
My only problem now, was that I didn't have any of those gorram 22V10. So I ordered some on eBay and waited.... and Waited.... and WAITED!.... and FINALLY

they arrived from China };-P I rushed to program one, dump it with u2pa, and test it against the original image

A perfect match! Sweet! };-P Next up was the big test on the actual board

(using a little jumper wire for ground connection), AAAAAAAND

IT WORKED! The Galagas were now back to normal!
To finish this up nicely, I choose to desolder the old socket from the board, and install a slightly bigger one, with pin 8 and 12 interconnected

Of cause there wasn't holes on the PCB for the extra pins, so these were just removed

By the way, after I finished this project, I actually (by mere coincidence while googling... I don't know why it hadn't occurred to me to google "bipolar prom gal" before, but it hadn't) found this page by retroclinic. Here he uses a truth table instead of (as I) equations, so I decided to try that out also, as it somehow seems easier. So I made a tiny addition to my processing method, so it could output a truth table as well. But when I compiled and programmed the resulting jed-file for the first GAL16V8 and dumped again, I actually got some differences compared to original image; a few bit were flipped. First I thought, that it was my simple method to generate the truth table that had a bug, but I've been over the code several times, and I can't find any errors (if you find one, please let me know, and I'll fix it). So my theory at the moment is, that I've found a bug in the WinCUPL compiler. So I think I'll stick to equations in the future... being a mathematician, I actually also fancy them more };-P

Should you ever want to try this at home yourself, the dumps of the bipolar PROMs for games containing them, is often part of the MAME ROMs. If you want to try my equation generator, it's now a part of u2pa; the help entry can be seen with the command
~>u2pa help bdump process
Remember, that if you own a Top2005+, u2pa also has support for reading a lot of bipolar PROMs now.

WinCUPL can be downloaded here.

Last but not least, the pld's and the jed's I produced for Galaga, can be downloaded here.

I wish to thank porchy for his big help and support on this project, as I didn't knew much about GALs or WinCUPL when I started out.


Namco/Bally Midway Galaga Repair Log

My dear friend (and also active user on many UK and Danish forums) Muerto asked me to have a look at his original Namco/Bally Midway Galaga. When he bought it years ago, he tested it and found that some of the sprites were displayed twice on screen. So it was put on a shelf and have been sitting there just waiting for someone to have a go at trying to repair it. When it arrived on my bench, it looked like this

The board doesn't have video connections at the edge connector; they must be drawn from a molex on the video board

I didn't have a plug to fit this molex, so I cheated a bit, and soldered 4 wires (R, G, B, and sync) directly onto the solderside of the board along with the other wires from the edge connector. I fired it up, and got this

A solid yellow-ish screen and no sound at all };-( So I started examining the main CPU (this board has 3 x Z80 CPUs) for CLOCK signal

Hmmm, looks nice and healthy. Next up was the RESET signal

The signal jumped low about 2 or 3 times a second... the watch dog was barking ever so loudly! At this point, it's always good to check the ROMs, so you can rule out any software error from the equation; So be it!

They all seemed to be in good shape and verified nicely against MAME. It was then I started to have a closer look at the custom ICs on this board

All of them, with no exception, had extremely corroded pins! And when trying to gently free the poor customs from their sockets (with my trusty flathead screwdriver), some of them lost a pin or two due to the extensive amount of corrosion

(the last two photos above are taken AFTER I've cleaned the ICs from the corrosion)
The first two ICs, I cleaned as I usually do by scraping the corrosion off using a Stanley knife. Next I patched new pins (taken from scrapped ICs) on where they had broken off and then gave all the pins a thin layer of solder.

Ready to be plugged into the socket again! };-P Now the Stanley knife-method works well, but for 10+ ICs it becomes quite cumbersome. So after the two first customs it suddenly struck me! I remembered, that my lovely Dremel (How can any man live without one? Still think that every boy should be given one at birth: Congrats Daddy, it's a healthy boy, and here's his Dremel; please keep it safe until he's old enough to use it!) actually come with a steel brush, that I didn't have had the opportunity to use yet. So fitted the brush and tried carefully and at the slowest possible speed

The result was simply fan-frakking-tastic! };-P

And each pin only took about 2-3 seconds to clean! };-O So I spend an evening cleaning ICs and patching up broken pins on the main board. With one of the ICs a broken piece of pin actually got jammed in the socket

So I had to desolder the socket

and fit a new one

When I was finished with cleaning ICs on the main board, I decided to try and hook it up in the test rig again. However, in the meantime I had gotten hold of a cheap original defective Namco/Bally Midway Pac-Land with an adaptor for some obscure standard that I haven't seen before

(properly some Belgian standard, as the seller (eBay) was from Belgium).
Now Pac-Land and Galaga uses the same pinout, and in particular the same molex for video, so I desoldered the obscure finger board, and fitted a JAMMA one.

And when I flipped the switch, there was movement on the screen... the board self test. And after the test completed, the attract mode started playing with sound and all

Now this was progress for sure! However, the screen was kind of purple-ish (doesn't show that well on the photos because of the quality of my iPhone camera and the quality of me as a photographer) and the "kidnappers" (the ones the can capture your fighter) only showed up as square red dots when hovering on the top of the screen. But when they did a dive, they looked perfectly fine.

With all the customs on the video board was also corroded, I still hoped that a clean-up there might fix the problems. So yet again I spend an whole evening Dremeling, solder coating, and patching broken pins. Also had to replace a socket here due to a jammed broken pin, MOAN! };-S
And worst of all: When I fired up the board again, it hadn't changes a flying frak! Neither the purple-ish nor the broken kidnappers were looking even the slightest bit different! MOAN! MOAN! };-(
Well on the bright side, it was now time for some REAL hardware debugging instead of just doing clean-up };-P So I dug up the schematics and started scrutinizing it. As i'd already checked all the EPROMs, my first suspect was the sprite RAMs (the 8 ones on the far back of the video board)

They are 2147 1-bit SRAM in two clusters of 4 (byte wide all in all). So I started hitting them with the scope. But when I touched the data lines with the probe, weird stuff happend on screen

This can be an indication, that something is not driving the lines properly, or the values of the pull-ups might either be too high or too low. Anyway, at this point, I suspected something wrong with the sprite RAMs themselves. I didn't have any 2147 stocked, but looking at the schematics I found, that the video board may be configured in two ways: Either (as this one) with 8 x 2147 or with 2 x 2148 (4 bit SRAMs). This was actually a quite normal thing for manufactures to do back then, as the prices on SRAM were relatively high and also fluctuating. So this way they could wait until the last minute to decide on which to use, thereby keeping the cost of components at a minimum. I did actutually have 2 x 2148 SRAMs on a scrap board, so I harvested these, cleaned the solder holes

fitted sockets and the harvested 2148s, and popped out the 2147s

But alas (ear wax), when I fired up the board, the screen looked precisely the same };-/ Now it would be a very strange coincidence, if the old 8 x 2147 RAMs clustered together, should show precisely the same error on screen as the 2 x 2148. So I assumed, that sprite RAMs were ok. Hmmm, well back to reading them schematics

Also on these datalines is the Namco custom IC that generates the actual sprites by mixing the signals from the data lines placed on the far right on the picture above. However, if that was broken, I'd be frakked anyway, so I assumed, that it was ok too. The last things directly on these lines, was the 2 transceivers in the middle of the picture (marked with 2 circles). When peeking the lines on the topmost of these, I discovered, that one of them was stuck high.

The input seemed to be active, so desoldered the 298 TTL, but in my eager accidentally broke a couple of pins. However, I was determined to get it tested in the Top, so I quikly fitted some header strips as new pins. But it tested good in the Top

So fitted the pathed-up 298 again, as I was "in da zone" and just wanted to move on...

Hmmm, the signal on the input of the stuck line still looked more-or-less ok on the scope. But maybe the lows wasn't quite as low as on the other inputs?! (haven't got a picture of this, sadly). At this point, my new Logic Probe (with audio feedback) had arrived in the mail, and I decided to test it, as sometimes it can be had to see on a scope, if the signals actually reaches the logical thresholds. As one can see, the only thing connected to the inputs, are the outputs from the bipolar prom in the lower left corner of the schematics picture. So lifted the suspect pin along with one other out of the socket, and hit them with the probe. First the suspect

and then the assumed good

Now of cause, as the pins were now out of the socket, they were not pulled by the pull-ups. But as this pin was stuck HIGH (and not low), that couldn't explain what I saw. To be sure, I peeked the inputs to the PROM, and they were all active. I'd finally found a culprit! };-P However, I don't have any readers that can read/write bipolar PROMs, so what now? I then remembered, that I had a working bootleg Galaga on the shelf. So I found the corresponding place on the bootleg

and compared it to the original

It looked almost identical, and the ICs on either sides of the PROM (marked "5" on the bootleg) was the same. I googled the pinout for TBP24S10N and found it to be the same same as on the original schematics. So I slammed the bootleg PROM into the original Galaga, aaaaand... PRESTO!

The kidnappers looked normal, even when floating at the top of the screen. So I fitted a 298 harvested from a scrap board for the patched up one, to close this up nicely.

Now I was down to, that the only thing wrong with this game, was the overall purple-ish look of the screen. So I disconnected the video plug, and peeked the colour signals

From the last pictures, it was obvious that one of them was dead. Looking at the solder side, I was relieved, as I found that the trace was broken just before the solder patch (the middle one)

As the one on the rigth in the picture looked like it could snap at any time too

I patched both for good measure, and all the colours was now clear and crisp. So now the game was all good to go, PEW! };-P

Now what about the poor working bootleg that he harvested the bipolar PROM from, you might think?! Oh, well it wouldn't be Elgen, if he didn't have a crazy idea for a future project, would it? So I made some minor changes to u2pa (my own GPL sofware for the cheap Top2005+ Programmer) enabling it to read the 2 types of bipolar PROMs used on Galaga, so I would be able to test them against MAME in the future. I actually also tested the one that I used for the original, to be sure it's the same as the dump in MAME, and it is };-P I now began thinking, if I maybe could use some other programmable device that my equipment can handle in place of the PROM; even though I was now able to read the bipolar PROMs, programming them is a whole different ball game. The first thing that popped into mind, was using an EPROM, but they are far too slow; about a factor 10 slower access time than bipolar PROMs. Then I thought about using a GAL, but at this is a logical device, the PROM dump would have to fit into a truth table for it to be doable. I now contacted my dear friend porchy, who is far more experienced into the world of GALs than me. After having had a glance at the dump file and the Galaga schematics, his verdict was that it might very well be doable. Cool };-P So I made a small QAD command line tool, that generates (unreduced) equations that can be used in CUPL from a dump of a bipolar PROM; it's included in the u2pa package (if your not friendly with hg, a current snapshot of the repo can be found here, if you're interested in having a look at it). I haven't come any further at this point, as I have some other repairs queued up. But I'll definitely look into it in the future };-P

After Muerto recieved the game, he sent me these nice pictures and YouTube-links of it running in his original dedicated Bally Midway cab. Enjoy! };-P

Last but not least, Muerto was so thrilled with his Galaga now finally in working condition, that he made this totally awesome poster of me.

 It's a poster! I like posters. Posters are cool!
...just like bow ties, fezzes, and stetsons of cause };-P