About me

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

23.4.16

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

17.4.16

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

20.12.14

Taito Asuka & Asuka Repair Log

This original Taito Asuka & Asuka


I was lucky to grap real cheap on a Danish forum. The guy selling it didn't post a picture of the PCB, misspelled the name of the game, and stated that it might be a bootleg. So even though it was an auction, this game went under the radar of other forum users, and I got it for my initial cheap bid. As I later on discovered that this seller is a dirty rotten swindler, I don't feel bad about it.
Anyway, when I first received the game, it played well and was all working and fine. I decided to bring it with me to an SSKT-gathering in Næstved Denmark, as one of my friends there wanted to try it out. I don't have a car myself, so when I'm not able to get e lift with someone else, I travel by train with all my gaming goodies in a suitcase and/or backpack. Sadly Asuka&Asuka didn't quite survive the trip fully functioning. Some of the colours were frakked up


and I didn't have the time on-site to have a look at it. Upon returning home, it was just shelved, until I had a time to look at it.
Months later I decided to have a go at fixing it. I soon discovered, that this PCB suffers from the same Achilles Heel, as many other Taito games from the same period; the Taito SIL-RGB-module


And having a closer look, I could also see, that a reflow from the component side had been attempted earlier on. I found that pressing down on the package made the error go away


so I was pretty confident, that I was on the right track here.
Besides that, I also found a large cap on the loose


but I was rather sure, that this was not involved in the colour issue, so went straight on to the RGB-module.
Taito used these type of custom SIL-RGB-modules on a number of their games including i.e. Rainbow Island back in the day, and always mounted them perpendicular to the PCB, instead of making sufficient space on the PCB and bending it down onto the PCB surface. That way it's extremely flimsy and very sensitive to just the slightest bend or bump.
As an initial attempt, I tried doing another reflow from the component side, but without any luck. So I decided on desoldering the thing and mounting it properly. But when I started and gave it just i little yank while desolering, all the pins snapped clean off }:-O



I had a lot of 64-pin reduced size DIL sockets, that I bought as a mistake some time ago (wanted to use them for socketing 68000 CPUs, but didn't look closely enough at the pitch }:-S Luckily they were cheap };-P), and I decided to use 2 of these on top of each other top mount the module properly. The bottom would be soldered to the PCB, and the module would be mounted in the top one. That way the module would rise above the other components, making it easy to mount it flat.

But first the holes needed cleaning; all the old component pins were still sitting there. That proved to be a harder task than expected. Most of the pins came out pretty easy


but the holes for the 4 supply pins (2 x 5V and 2 x GND) had their vias connected to big supply planes inside (middle layers) the PCB making it very difficult to heat up the solder blobs. Also I think the supply pins themselves might be slightly thicker than the others, because they were just stuck! After having cleaned all the other holes and also broken a track on the solder side }:-S


I gave up on those 4 last holes; 5V and GND was no problem getting elsewhere nearby on the board. So I started working on the socket to be soldered onto the PCB. As there were other components on the board where the socket should be placed, I needed to cut some of the plastics so it would fit around them


I soldered some small wires on the supply pins of the socket, and also removed a bit of lacker from a big GND plane on the PCB with my Stanley knife, where the bend pins on the "other" side of the socket could attach.


I soldered in the socket connecting GND to the big GND plane "inside" the socket "walls", and 5V to a nearby cap. The pins on the "other" side got soldered to the PCB as well for proper fastening.


As a last preparation of the PCB, I replaced the electrolyte cap for an equivalent one with a smaller form factor


Now on to the top socket. I started by soldering pieces of uninsulated single core wires onto the pin-stumps on the module and then cutting them down to equal length. I then pressed the wires firmly down into the holes and caryfully bent the whole module down onto the socket


I then used hotglue to secure the module to the socket from the underside


I inserted the top socket into the other... a perfect fit };-P


After having fixed the broken track on the solder side with a piece on kynar


and reflowed the the loose cap


it was time for the big test. And lo and behold...


We have all colours back again! };-P And you can tap on, wiggle with, press down on the module etc., and the colours still stays on };-P

This game is a nice little vert shmup, but I am considering parting with it, cause the very weird sidescrolling used, kind of makes me a bit seasick when playing it };-P

23.11.14

Capcom Ghost 'n Goblins Bootleg Repair Log

I snapped up this defective bootleg Ghost 'n Goblins along with some other defectives very cheap at a danish forum about a year ago. Up until now, it had just been sitting on the shelf; not even tested. It had adaptor wires soldered directly onto the edge connector.


As mentioned before I believe, that people who does these kind of things, will burn in a special level of Hell; the one they reserve for child molesters and people who talk at the theatre... The Special Hell! }:-(
Well, anyway... the fingerboard soldered to the other end of the wires wasn't JAMMA, so I made a QAD adaptor with a JAMMA fingerboard connecting only the power and video connections. The game booted, and I was greeted with the attract mode:



The backgrounds and sprites were perfect, but the layer displaying characters and the game logo was pretty messed up and the game was dead silent. The silence could, however, just be due to a dip switch setting turning off attract sound.
I did the usual visual inspection, but as nothing obvious was to find, I started doing (what I sometimes refer to as) "Playing the game of peeking and poking around". For this, I use either my scope, logic probe or both. The purpose of this, is to give me a rough idea of where the different elements of the game are generated. I usually start with the ROMs and RAMs trying to short adjacent data and address lines with the probe to see what that stirs up in the game. Also I peek a bit at the data and address signals. This time I started with the logic probe and quickly found that this ROM


and this RAM


both at the primary PCB (also containing the primary CPU, program-ROMs and the entire sound system) were definitely involved in making the character layer.
Next I went over all the data and address signal lines of the two with the scope, but didn't find anything unusual. But then these two these two guys


sort of in the middle of the ROM and RAM caugth my attention. Why just them you might ask? Well because they are Fujitsus, and Fujitsu TTLs from around the 80'es, just have a tendency to go bad at the moment. So they are all Usual Suspects when repairing PCBs from that period. In general this board is peppered with Fujitsu TTLs, but these sort of sat there in the middle of this cluster of non-Fujitsus and happen to be in the same area as the RAM and ROM. The 74LS86s are packs of 4 XOR gates. So again I tried to short some of the signal pins and found, and when I shorted pin 8 and 9 on the right of the twins


the character layer changed to this



Hmmm, all the letters displayed correctly, but upside-down. Then tried flipping the dip switch to flip the picture


and when shortening the 2 pins again got this


Perfect character layer. Ha! Haaaaa! Surely on to something now };-P I peeked the inputs and the output of that gate



and found one of the inputs floating. I traced the input to the output at pin 8 on the left Fujitsu 74LS86. I salvaged a 86 from a scrap board, piggybacked it on the left one


And got perfect character layer with both orientations };-P



So out it went.


In my eager I accidently pulled out a via with it, but luckily it isn't connected to anything on the component side, so no worries. A socket was fitted and the salvaged 86 installed.


So now the graphics was a'okay... time to clean up that edge-connector-mess! With a combo of soldering iron, desoldering iron, solder wig, a whole lotta patience, and a final rub with rubbing alcohol


it actually ended up looking pretty okay in the end. I attached my full Capcom Classic adaptor and booted her up; but alas, no sound. So I dug up my external amp. It's actually just an old PC-speaker, where I've cut the jack plug and attached a crocodile clip for GND and an old multimeter probe for signal (actually it also good for listening on signal lines as well). Anyway, I heard sound from the speaker


Followed the sound to the fingerboard and found, that this was again a game that uses SPK- for signal and SKP+ for GND. As my SuperGun uses SPK+ for signal, that was why I didn't get any sound. So I finally pulled myself together, and installed a switch to flip the polarity of the sound in my SuperGun.


...better late that never, right };-P This closes the case...

Plz take care all you lovely people out there!

<3 Whole Lotta Love <3
};-P Elgen