JAMMArcade.net – Page 77

Flashgal repair log

Mar 162017

I bought this game for my collection declared perfectly working.

Flashgal runs on the very same pcb of other two games developed by Kyugo which are 99 Last War and Legend.

On the bottom pcb it is silkscreened CVG-48C which is very similar to the codes used by ORCA on their hardware

Anyway it seems that in these days I am very unlucky because the game once fired up had a sync problem

Tracing back from the SYNC pin I came to a 74LS08@2P

With the frequency counter I got very unstable readings so I proceeded to piggyback it with a good 74LS08 which restored the sync.

After changing it, it tested good out of circuit, yet with the new TTL in place I got a stable sync….

The screen looked very reddish so there was obiviously a palette problem

I checked the palette rams and they were all good so I dumped the colour proms until I found the RED component one @1J which didn’t match anything in MAME.

The prom is an 82s129 and it is almost impossible to find an empty replacement these days.

Therefore I went again for the Bprom to Gal replacement already used last year in another repair log:

Mad Gear repair log

Since the prom was the very same type I replaced for Mad Gear, I converted the prom file to the PLD equations using Elgen tool U2pa and I reused the same pin configurations which fits nicely without any major hardware mod except a jumper wire to connect GND to the correct pin on the GAL

I tested the the game but I noticed something strange:

The colours were right but there were glitches on the left and right borders and also a flickering red component across all the screen (which cannot be seen on the static image offcourse)

At first I thought it was an access time problem with my GAL , therefore I burned the fastest one I had but no luck.

I tested directly the signals of the PROMS and found out that the CE pins were not tight to GND but were controlled by another ttl.

Soon it became clear why it didn’t work: the GAL was sending datas out of sync therefore producing artifacts.

Since I am not a programmer I asked to Elgen and Caius (who asked to Porchy) an advice how to replicate on the PLD a tristate behaviour.

All of them were very kind and in few minutes they informed me how tristate works on PLD equations

I added the needed modifications to my PLD equations by declaring each data pin enabled when pins CE1 and CE2 were low.

This completely fixed the colours on the pcb with no artifacts:

Again a big thanks to Elgen from https://elgensrepairs.blogspot.it/ for the invaluable tool and to Caius and Porchy for being always very helful

Senjyo repair log

PCB Repair Logs, Repair Logs Comments Off

Mar 162017

I bought this game declared 100% working for my collection but as soon as I fired it up I noticed something strange:

One of the mountain layer looked very strange and there was also some stripes of mountains in the sky

This game has no schematics and it is a particular complex and populated hardware with lots of TTLS and rams.

The game is on a 3 layers pcb so I had to find a way to test the components in a confortable way:

The upper board with the connector has the cpu and sound section, therefore I started to test the bottom pcbs and by shorting some signals I finally found the circuit dedicated to the last parallax layer which is near eproms 19 and 20.

All the signals looked good but the 2114 srams has some dead signals coming to 4 addresses.

Tracing back I found a Texas instruments TTL 74ls157@9C whose outputs were all totally dead

Changing it fixed completely the background layer:

Big Fight and Ninja Emaki PAL dumps added

PAL Updates Comments Off

Mar 162017

Today I dumped two PALs from a Big Fight and Ninja Emaki PCBs.In the first board, device was a secured PEEL18CV8 located on daughterboard @IC56, I was able to fit equations in a GAL18V10 targeting device.In the latter board, device was a secured PAL14H4 @10F on CPU board which I successfully reversed onto a GAL16V8.Both boards had also other PLD devices but all set as registered so not dumpable.

Big Fight – Big Trouble In The Atlantic Ocean repair log

PCB Repair Logs Comments Off

Mar 162017

Got this rare Big Fight – Big Trouble In The Atlantic Ocean (this is the full title) PCB for a repair :

For the uninitiated game a beat ’em up which resembls Final Fight but it features also a versus mode.It was developed and published by the obscure Tatsumi manufacturer in 1992, it was one of their last arcade game before focusing on novelty sticker printing business.

The board was completely dead, I got only a black screen.The hardware is complex : two 68000 CPU, a large PGA sprites custom IC, many PLDs, lots of RAMs.Here is picture with the daughterboard removed:

Probing the two 68000 revealed no clock, master clock is generated by a 50MHz oscillator and then divided by 4 in order to route a signal of 12MHz to both CPUs:

The output of the oscillator was dead, stuck at 1.64V :

I removed it and the its VCC pin was stuck on PCB detached from the package due rust corrosion:

Fitted a good oscillator and board sprang to life although with bad graphics:

Doing a visual inspection I found four empy sockets, according to the MAME source PCB layout and pictures on the Net they had to accomodate four TC51832 32K x 8-bit pseudo-static RAMs besides the other four present:

Once fitted the four missing RAMs most of graphics were correctly displayed but sprites were absent :

The sprites are generated by the PGA custom ‘TZB315’ (see picture above) so I went to probe the surrounding area and found discrepancies between inputs and outputs of some 74ALS245 which are in the middle of ROMs and custom data bus:

I replaced them and, although they resulted good when tested out-of-circuit, I got sprites back although scrambled :

Sprites data are stored in eight 4Mbit 32 pin EPROMs:

I dumped them and they matched the MAME ROM set but I noticed some of them had oxidized legs:

I cleaned them and at same time replaced a device with a dodgy pin:

This fully restored sprites:

But as you can see (or better, hear..) in the above video, sound was sometimes noisy and some voice samples were missing (like helicopter when you start a game or voice of special moves and enemies).

Here a recording from a working PCB for comparison:

The background noise was due a dirty 50KOhm potentiometer, I removed and sprayed it with a contact claner :

Voice data are stored in a 2Mbit EPROM and played by an OKI MSM6295 (corean rebadged one on this PCB)

The dump of the EPROM was good, I also replaced the OKI with no luck.Probing the EPROM revealed that pin 30 (address line A17) was always LOW so the second half of the voice data could be not accessed.Doing a check with my multimeter revealed thas this pin was tied to pin 22 (/CE), this obvioulsy sounded me weird.Near the EPROM there was a jumper installed @JP4:

Looking at PCB pictures on the net I had confirm that the jumper had to be set in this configuration.But looking at its solderside I noticed a trace which connected the central pad to the left one.This obviously, along with the jumper installed in that position, caused the short between the left and right pad resulting the two signals being tied together.So, I cutted this trace:

This restored the missing voice samples.No further issues were found so board 100% working.

GameKing multicart

Projects Comments Off

Mar 122017

I seemed to be one of the first to get the ball rolling with Gameking dumping.

I had to make my own part for the cartridge connector. This allowed me to make the breakout PCB.

This worked well enough for my dumping needs but I also wanted to test the dumps on a real Gamking. This led me to the first cartridge test. It has a bunch on things on that weren’t really needed but I was just playing about with ideas at this point.

It sort of worked but would do with some refinement.

This one worked much better but after dumping some 4in1 cartridges we found they didn’t always work properly using the homebrew cartridge. This led to the analyser PCB.

I never did get hold of any 4in1 carts myself so thats as far as that project actually got, although I don’t think its required anymore.

The final product is this cartridge. I believe one of these was used to aid in dumping the internal ROM.

It works fine for single games and a few 4in1 titles.

Older Entries Newer Entries