JAMMArcade.net – Page 120

28 pin CPLD replacement

Jan 242016

Some years ago MikeJ from FPGAARCADE made a 28 pin CPLD replacement that could program to replace certain custom chips from a variety of arcade games and even the Commodore 64 PLA.
While I was waiting for Mike to get another batch of his boards ready, ColinD on the UKVAC forums contacted me telling me about his own project.
The concept is essentially the same as Mikes but his was originally geared towards replacing the SLAG chip on some Atari games. It does however have multiple links available so it can be configured into what we call ‘normal’ mode. This makes it so the power pins are in the corners like with ‘normal’ chips/EPROMS/etc. It also has space for a 3.3v regulator so a XILINX XCR3064XL CPLD can be used in place of the EPM7064 that I’m using.

20160123_115449-1

big_slags

My first project for this was to reverse the Konami 501 custom chip. Luckily I have a one of the bootleg versions of Time Pilot here courtesy of Muddymusic that has the same layout as the original board but all the customs are implemented in TTL on riser boards so reversing this was a matter of drawing out the schematic.
I eventually got something that let the game boot and work but there were some graphics faults here and there. This ended up being an issue with using a modern part to replace old parts. The propagation delay on the CPLD is a lot less that the original TTL part. This was solved by enabling the ‘Slow Slew Rate’ option in Quartus II.

So with the 501 reversed and the chip I have confirmed working I’ll set about doing the others on this board.
I’ve yet to test them on genuine hardware but I remain hopeful.

The original thread of Colin’s can be found here.
If anyone is wanting one of these then you can PM user ‘ColinD’ on the UKVAC forums.

Gryzor repair log #2

Jan 232016

A friend got a Gryzor PCB working but with problems on some of the sprites (mostly enemies and items with half of the horizontal lines missing).

The 4 GFX MASK ROMs were tested ok on another Gryzor PCB. Looking with the scope on the RAMs revealed nothing really suspicious.

I then piggybacked the RAMs around the GFX part and quickly found the faulty one.
It was the NEC 8644FU12 at location 14G. This RAM is a 4464 (64k-word x 4-bit, same type than the ones I replaced on my recently repaired Final Star Force).
Here is a picture of the PCB with the faulty chip highlighted in red:

gryzor2-1

Piggybacking it with a compatible TMS 4464-12 restored all the sprites.
In fact, the problem was so small that it was impossible to see any suspicious signal on any of the pins of that RAM with the scope (every signal looked healthy). I replaced the chip and obviously got the PCB running perfectly.

Here is a before and after picture:

gryzor2-2

Blandia PAL dumps added

PAL Updates Comments Off

Jan 172016

Yves_M, one of our members, sent in dumps of PALs from his Blandia PCB.Dumps were obtained from protected PAL16L8 and have been successfully tested back on board onto GAL16V8 targeting devices.Thanks to Yves_M for his contribution.

Truxton II/Tatsujin Oh PAL dump added

PAL Updates Comments Off

Jan 152016

Today I’ve dumped the only PAL from a Truxton II/Tatsujin Oh PCB.Original device was a registered but unsecured PALCE16V8H so I could read it straight in my programmer.Dump is not tested since the PCB is not working but should work on a PALCE16V8 target device or a GAL16V8.Any feedback is welcome.

Marchen Maze repair log

PCB Repair Logs Comments Off

Jan 132016

Had on the bench this Marchen Maze PCB (Namco System 1 hardware) :

Marchen_Maze_PCB

On the power up I was greeted by this screen:

D6_error

The RAM @D6 is a 6264 located on CPU board (fault was surely on this board since I succesfully swapped a good one) used in pair with another one @E6 , both are adressed by the near custom ’48’ which is a sprite address generator:

custom48_D6_E6_RAM

For first I went to replace both RAMs (sometimes the board booted showing an error also on the one @E6) but this didn’t cure the problem as well swapping a good known custom ’48’ had no effect.Probing these RAMs revealed some address lines stuck high.Looking at the schematics of Pac-Mania (which runs on same hardware) I figured out that adress lines from custom to RAMs are driven by two 74LS365 @H6 and @L6.

object_control_circuitry

Parts mounted on the PCB were from Fujitsu which means high chance of failure:

74LS365@H6_@L6

After a quick test with my HP10529A logic comparator (which confirmed me troubles on all outputs) I decided to remove them.They both failed in my programmer:

74LS365@H6_@L6_failed

This cleared the error on startup so board successfully booted into game but sprites were all blocky:

blocky_sprites

Judging from the kind of fault on screen, this, more than an addressing issue, had to have something to do with data.Always looking at schematics I noticed that data bits from the custom ’48’ and RAMs are routed to two 74LS377 @A3 and @A4 :

object_datal_BUS