NMK Thunder Dragon Repair Log

Some repairs can be very tedious and take you months (even years) of fighting with the PCB to complete. Others on the other hand can be both easy to diagnose and to repair. This is one of the latter. And I think it is important to tell about the full spectrum of difficultness. So here we go...

This little baby by NMK has actually already been on the table once before when I bought it as defective. But a couple of months ago, I decided to bring it to a cozy get-to-together with my dear friends at MadGearArcade (a private arcade set up with some candy cabs and SuperGuns in my friends living room };-P), as they all 3 love good shmups. It was just bobble wrapped and stuffed tightly into a bag-pack together 3-4 other PCBs. I know this is of cause not the optimal way of transporting arcade PCBs, but when you don't own a car and have to bike to get to your destination, and you also know how to fix brokes PCBs, this is actually how I usually transport them to different gatherings.

When I connected it in the a wonderful Sega Aero City and flipped the on-switch, I quickly discovered that something was wrong with the music and some of the sounds. Most noticeable was, that the intro music was played in level 1 instead of the normal music for that level (this video is not from that night, but shot with my tv and SuperGun).

After a quick visual inspection, I found this

The smoothening cap right next to the sound chip had been crushed during transport. It would seem very likely, that this had something to do with the problem I was experiencing. All the other disc-caps for smoothening spread around the PCB is 0.1uF (code 104), so I removed the 2 broken-off pins, cleaned the holes, and installed a fresh one.

And now the music was in the right place again.

After playing a few games, I wasn't actually completely sure that music was completely right, but after inspecting an OST I found on youtube, I realised that I just have a bad memory. The music is ABSOLUTELY right now };-P

Psikyo Gunbird Repair Log

So, after beeing dead in the water for over a year now, Elgen is back with another one of those block rockin logs! };-P This repair was done over a year ago, but I hadn't had the time nor energy to do the write-up before now. I hope this will mark a new period of more logs to come. But please be patient here at the beginning, as I'm quite rusty };-P

<3 A Whole Lotta Love and Plz Enjoy <3

};-P E

* * * * * * * *

This story actually starts with me smashing one of my own favourite arcade PCBs... but let's start at the very beginning:

After doing this repair log about using GALs to substitute bipolar PROMs under certain circumstances, I'd really gotten interested in PLDs in general. Especially, I wanted to get enrolled in the PLD-dumping program that my dear friend porchy has going on his website JAMMArcade.net. The program is about dumping as many (mostly protected) PLDs as possible, as these are usually *not* part of the MAME ROM dumps. As the PLDs are protected, you dump them by a technique known as black-box testing: You throw all possible input at the unit under test (UUT), and record the output. While this is pretty easy for very simple logic devices like an AND-gate or similar, it's much more complex, if the UUT is able to hold internal state (i.e. FLIP-FLOPs) and/or has connection points that can be configured as both in- and outputs.
Anyway, if you build an appropriate adaptor, you can use an EPROM and "read" the PLD as a ROM. Address lines generates all the possible inputs and the data lines "record" all the output. And here we should also remember to take into account, that some of the pins can be configured as both in- or outputs. The resulting dump file can then be analyzed and we can then derive how the original equations must have been.
So I made such an adaptor, and started dumping PLDs from games in my collection that wasn't in porchys online library already. My adaptor is very quick-and-dirty and uses 2 ZIF-sockets to make it physically fit in my Needhams EMP-21, but works well. For my first dump, I started with a PAL on one of my all time favourite games: Gunbird by Psikyo.

So i popped the PAL out of its socket and dumped it in the EPROM programmer

and then inserted it into the PCB again

and hooked it up in my test bench for testing... But I got nothing but a BLACK SCREEN!!! };-( I immediately pulled the power again!

Now let's just revisit 2 of the previous pictures again side-by-side

You notice anything wrong? Let's just see them one more time then...

I had actually (clumsy as I am) inserted the poor PAL up-side-down into the socket. Of cause I tried to turn it around the right way and apply power again, but the damage was done, that PAL was toasted }:-(

Oh well, the whole purpose of dumping the PAL, was after all to be able to make a replacement. So I quickly derived the equations and programmed a GAL replacement. Slammed it into the socket and flipped the power switch full of hope. But alas... black screen! }:-( I tried verifying the GAL an extra time and also tried to dump it, but all checked out fine (as far as I remember, but more on that later).

Full of dispair, I parked the poor PCB on the shelf hoping to be able to fix it at later time...

Months went by, but suddenly one day while looking at the MAME source of another Psikyo I have in my collection, Sengoku Blade / Sengoku Ace Ep. 2, I noticed that it uses the same MAME driver. Usually this is a good indication that the games run on very similar hardware. I immediately fetched both PCBs and studied them side by side. Obviously the lay-out was not precisely the same, but there seemed to be a lot simmilarities; in particualar the both have a PAL-IC in roughly the same area...

Now just a word on the the difference between PLDs and ROMs. If you replace a ROM with one of the same type (but with different data) nothing serious happens with either PCB or the ROM. You just get errors, game will not start, graphic glitches etc. But you pop in the correct ROM afterwards, and everything is back to normal; no harm done. That is because the configuration of address and data lines, input and and outputs is always the same on a ROM regardsless of the data programmed onto it. On a PLD (ie GAL) on the other hand, you as a programmer of the device, have the power to (to some extent) define which pins should be inputs and outputs along with the logic that is programmed onto it. Two GALs programmed with different input and output configuration can therefore NOT just be safely interchanged.

But I took a chance... Aaaaaaaaaaand, MY GUNBIRD BOOTED! };-P

But as you might see on the photos, the game had now developed some other issues. Sometimes the graphics was glitchy and sometimes some of the letters was replaced by other letters or other characters. I was pretty sure, that this had nothing to do with using the PAL from Sengoku Blade, as I could influence the behavour of the glitches by flexing the PCB. This is often a sign, that some of the SMDs have pins broken off of the PCB and making poor contact.

Finding the culprits of such problems can be hard, cause you are not always able to see the cracks with the naked eye. But by pressing down on the SMDs one by one, and watching if it had any effect on screen, I found a good candidate near one of the corners; a large Psikyo custom IC.

After doing a close visual inspection of the suspecious IC, I still couldn't find anything fishy. So I decided to just reflow ALL the pins... 160 that is };-S And I really hate doing SMD soldering, cause I suck at it! I reflowed 1 side (40 pins) at a time testing in between. But after having reflowed all 4 sides, there was still no change, and I could still make the glitches go away by pressing on the custom IC. Having ruled out the large custom, I started investigeting the nearby SMDs pressing from both top and bottom at the same time and soon found that pressing on this IC

made the glitches go away. And that didn't happen when doing the same trick on the others. Luckily this one was larger and had a lot fewer pins that the big custom. And after a quick reflow of all the pins, the glitches were all gone, even when I flexed the board.

So now all was more or less good, but it still annoyed me, that I had to shift the PAL between the 2 games. So just to be absolutely sure, I tried to read the GAL I'd programmed at the beginning one last time. But for some reason it read as blank. That was strange? I tried again; same result! Now I am almost 100% that I had been dooing all the right steps of programming the GAL, but obviously something had gone wrong. Full of hope I tried to program it again with the devired equations, slammed it in the socket

and lo and behold: The game booted ever so happily! };-P

A long case was closed, and I was proud to contribute my first *real* and tested PAL-dump to the fast-growing repository over at porchys site JAMMArcade.net.

To this day, I still don't know what went wrong when I tried to program the GAL the first time... but I'm glad that all went well in the end, as both Gunbird, Sengoku Blade, and Psikyo games in general for that matter, are really some of my favourite shmups };-P