I dumped the only PAL from a Gunbird 2 PCB.Original device was a secured PALCE16V8H marked ‘PS5-1’ @U18.Dump has been successfully tested onto a GAL16V8 targeting device.
Some days ago I had this Truxton PCB on the bench:
Game had wrong colors on some background/foreground objects, like title screen
This part of graphics is generated by a ceramic PGA custom marked ‘NEC D65081R’ which addresses four 1Mbit MASK ROM and read/write data from/to four 62256 static RAMs:
Address bus is daisy-chained between the custom, the four MASK ROMs and the four RAMs, all was in order here.Custom receives data from MASK ROMs and transmits/receives to/from from RAMs on two different bus.When I went to check connections, I found no continuity between pin 17 (D5) of the RAM @18F and the custom.Here is where trace from pin of the RAM goes under the custom (picture taken with a USB microscope)
Infact, if I pressed the custom in this corner, the fault went away.I simply reflowed this dry joint and all came back to normality.
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:
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
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:
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.