About me

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

16.5.14

Incredible Technologies Strata Bowling Repair Log

About a year a year ago, I started becoming a Wednesday night regular at Chassis Arcade on Østerbro, Copenhagen. It's located in a basement in Faksegade, and on Wednesday nights, it's THE place to be. It's always packed with lovely and friendly people, there's funny contests, people are playing, talking and having a brewsky or two, and after the arcade closes at 10 o'clock, we hit a nearby pub and have a few drinks. Ever since my first Wednesday there, a machine had been standing in the corner turned off. It was a Strata Bowling; not the one with the trackball depicted in the KLOV link, but actually the version that uses a real cue ball and IR-sensors to detect the direction and speed of the ball being thrown. The game is really cool, and behind the brand Strata actually stands Incredible Technologies that later made some very famous titles including the Golding Tee series.
The problem with this poor machine was, that it kept blowing the fuse on the logic board. Chriss and Julian (the owners of Chassis Arcade) had tried a few things, but couldn't get it to work, so they asked me if I'd have a look at it. And that's how the PCB ended up on my test bench.


The edge connector is (besides the controls) JAMMA compatible, so I didn't need to make an adaptor. I didn't have any fuses with the correct form factor (the big ones), so I started by just hooking up one the small ones using some crocodile test wires


however the game wouldn't start at all. Pretty soon I found out why


the poor board didn't get enough juice; I guess those test wires has way too much resistance in them. On the first picture I measure before the fuse, and on the second one after. So I made an alternative solution


I piggy backed the little fuse on top the big blown one. And now the game actually booted up... no blown fuse or anything!


I heard a fine start-up jingle, but the display wouldn't sync properly. I have had such problems before, due to the fact that I'm using a Commodore monitor for test instead of a real arcade monitor, so I just assumed that this was one of those cases as well; more on that later...
The board now seemed to be booting to some extend, so before I returned it to Chriss and Julian, I decided to see if it might have any other obvious errors. A cell battery should always alert a conscientious arcade repper, and this was no exception



The battery is 3V, but gave a reading of 0.27V. So it was desoldered. I didn't have a replacement at that time, so I made this rather crude solution for a start


just using 2 standard AAA batteries in series connected with wires. Now I was pretty confident, that the problems had been fixed, and that the syncing wouldn't be a problem once it got connected to a proper arcade monitor. So I proudly brought it back to the arcade...

After some time, Julian found time to connect it in the cab only to find, that the piggy backed fuse blew right away }:-( So home to me it went again.

It now sat on the shelf for a couple of weeks, while I was doing some other stuff. Amongst that, I had to hook a Q*bert Qubes, that uses positive horizontal and vertical sync instead of negative composite (as pretty much all JAMMA boards use), in my test bench. While googling on how to convert the syncing signal to composite negative sync, I learned that some PCBs actually has a dip switch setting to switch between positive and negative sync. Hmmmm, I wonder!?.... try looking at page 11 in the manual (in the paragraph "SYNC").
So I grabbed the board from the shelf, flipped SW1, made another crude "solution" to the fuse problem


(plz don't try this at home), and applied power


I couldn't get the game to actually start due to the "CUE BALL IS MISSING"-detection, but when I hit the service button, it bought up the service menu


and I was able to playback some of the in-game cut-scenes (for strikes and so on) from there



I wasn't too proud of the battery "solution" that I had come up with, so while I had the board back at the bench, I decided to make it a little bit nicer. I had this old PC-motherboard in the scrap pile. It had a battery of a different form factor, but still 3V... and it was placed in a battery holder.


This type of batteries can be purchased in any bigger supermarket for about 10DKK (~$2) a piece, so that was a perfect solution. So desoldered the holder and attached a wire because of the different form factor


and soldered it onto the board


I can see that it works perfectly, as when I take out the battery, the game boots with a message that the battery is dead. But when it's installed, it saves the settings I've made in the service menu.

The last thing to get settled, was the issue with the blowing fuse. So I tried using one of the small again, and the board booted perfectly. However, when I tried to boot it again the next day, the fuse blow right away.
And THEN it struck me! I had been using fast (in danish: flink) fuses. These are designed to blow at the moment the current gets too high. Slow blow (in danish: træg) fuses however, can withstand a much higher current than what they are rated for, for a short period of time. Very close to the fuse are a couple of rather big electrolyte capacitors. When I booted the board with the "wired" fuse, these would get charged just fine, but when trying with the fast fuse, it would blow right away, because of the high current this charging generates. I couldn't find any documentation anywhere if this fuse should be fast or slow blow, but after seeing that the board runs just fine with a fast fuse once the caps are charged, I'm not in doubt.
So on my way to the arcade that day, I bought a 10 pack of slow blows (in the right form factor), as I didn't have any, and handed them over along with the PCB. About a week later, Chriss and Julian sent me this awesome video


The 2 jolly arcade owners speaks danish in the video, but to recap they're telling, that the game now seems to work just fine, but that they are missing a ball of the right size. Should you, good reader, know anything about what ball to use, plz leave a comment.

So this ended up being more of a piece of detective work and hardly any real repairing. But that's how it is some times, and I'm just happy that it works, and I'm really looking forward too trying this game out };-P

(Don't forget to swing by my Facebook-page and like it to get more frequent updates than just following the blog.)

7.4.14

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

23.3.14

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.