Another contribution from Andreas.This time he sent in the PAL dumps from a Logic Pro 2 PCB (a puzzle game released dy Deniam in 1997).Dumps have been made from three unprotected devices (two PALCE22V10 and a GAL16V8), there was also another GAL16V8 but the chip is faulty.We mark them as untested for now.Thanks again to Andreas.
J. J. Squawkers PAL dumps added
Andreas, one of our most assiduous contributor, sent us PAL dumps from a J. J. Squawkers PCB, a cute platform game from Athena. Dumps have been all made from unprotected PAL16L8A devices (PCB has also a secured GAL16V8, not dumped ) and they are assumed working for now.
Thanks to Andreas.
CPS1 PAL update
A CPS1 PAL update today but no properly a dump.This one is needed to run Daimakaimura on a ‘90629B-3’ B-BOARD so a different one compared to the original.I took only care of compiling the .JED, equations have been created by ‘aje_fr’ so all credits must go to him.You can read original thread here:
https://www.gamoover.net/Forums/index.php?topic=27862.0
The GAL16V8 programmed with this .JED must be installed in socket @1A, the other PAL needed is the one marked ‘IOB1’ @11D.Thanks again to ‘aje_fr’.
My friend Josef sent me some boards for a repair and among them there was this Vulcan Venture (export release of Gradius II – GOFER no Yabou) :
This Konami hardware ( called Twin 16) is as beautiful as complex : two 68000 CPUs, one Z80 as sound CPU (Yamaha 2151 + YM3012 DAC, UPD7759C and a 007232 Konami Custom Chip as sound chips).Specifically video board use a lot of custom chips whose functions are not really documented.With this in mind I began my troubleshooting and fired the PCB up:
Initial RAM/ROM self test reported a bad RAM @R8, this is located on video board in form of a MB81464 chip (a dynamic 64K x 4 bit RAM, there are eight of them in this section)
I was very confident that this would have been an easy repair but I was tremendously wrong because, after replacing this RAM, the board died.I couln’t get anything on screen but only some flashing lines and sometimes I could barely recognize the “RAM ROM CHECK” message.Sadly schematics of this board are not available so you have to seatlle with the Dark Adventure ones which runs on same hardware but has different ICs location.The fault was located on video board since, as I said, board properly booted but it played ‘blind’.In particular looking at Dark Adventure schematics I noticed that the custom marked ‘007782’ generates some video timing signals:
So, given the typology of my issue, I started to check this part of circuit.All signal from the custom were fine but when I piggybacked the near 74LS244 @A4 the video output was restored.I fired up my logic analyzer which gave me this result on some gates:
As you can see output signals were absent (like in gate A1/Y1) or altered.Tested out of circuit, this 74LS244 failed miserably.Replaced it, board booted and displayed properly but was stuck on “RAM ROM CHECK” message.Analysing the CPU board revealed that 68000 sub CPU has /HALT line active so something was wrong in its bus preventing the proper execution of code.Also here the old but effective piggybacking technique came in help since since when applied it to a 74LS244 @10L (which, indeed, sits in the middle of the address bus of the 68000 sub CPU and its work ram) I could enter in game:
Gameplay was fine but background graphics were constantly rolling (besides, some of the audio PCM samples were garbled).I was pretty sure this fault was in the same location of the first one (around the custom ‘007782’ area).Looking at this part of circuit I noticed a small 220 pF ceramic capacitor soldered across ground and PIN15 (input) of a 74LS244 @A10:
Usually little ceramic capacitors are used to clean signals filtering them.In this case the signal to this input of the 7LS244 came from the custom ‘007782’ and was called ‘NRAS’ on schematics while the corrispective output was connected to the RAS line (row address strobe) of the eight MB81464 DRAMs previously mentioned (they are used for tilemaps).Also here piggybacking this TTL , after removed the capacitor, cleared the issue ( actually this 74LS244 was tested as good in all my programmers but does not mean its internal junctions were fine).I was going to analyse the sound issue but board developed a new graphics issue :
Text/characters were all blocky but I could quickly pinpoint this fault in a bad 74LS86 @B11 on video board using my HP10529A logic comparator:
So, now graphics were completely restored, it remained to be fixed only the sound.Sound hardware is made of a main Z80 as CPU , a Yamaha 2151 + YM3012 DAC, UPD7759C and a 007232 Konami Custom Chip as sound chips.Music was fine but some of the PCM samples (speeches) were garbled.For example the initial speech “DESTROY THEM ALL!” was played so :
while the correct should be:
Studying a bit the hardware with the help of The Main Event schematics and doing some tracing on the PCB, I could figure out that the MASK ROM containing speech samples is addressed by the NEC D7759C chip not directly but through a 74LS273 @7B (while the ‘007232’ PCM custom chip addresses the other samples MASK ROM). Probing this ROM I found that most of its address line were stuck LOW or HIGH.I dumped it and it matched the one in the MAME ROMset.So, at this point fault had to lie in 74LS273 @7B that was in the middle of address bus.Without thinking twice I desoldered and tested it out of circuit where it failed:
Fitted a new chip restored all speech samples so board 100% fixed.The ‘Evil’ Konami has been defeated again!Well, at least until the next battle….
Just a quick note : all the TTLs and RAM replaced were from Fujitsu.
Got Muddymusic’s Time Pilot on the bench this time.
This game gave me the run around for a lot longer than I anticipated due to reasons I don’t really understand. Maybe someone can help me understand why.
So the game was meant to have two faults. The first was the RIGHT control didnt work. The second was the sound did not work.
Straight away I ran into problems. I could not get this board to sync with any of the 3 screens I have on my test rig, it also wouldnt sync properly in my Astro City cab.
I have recently bought a couple of those mini cabs and one was stripped out at the time so I used the monitor from that and the board seemed to sync up just fine.
There was that big red border around but I recall having the same thing on a Circus Charlie board I fixed so thought nothing of it.
Playing the game led me to think the background colours were missing.
I spent about 3 days going right through the schematics and running tests with the Fluke 9010 to figure out what was wrong. I couldn’t understand it. Muddy claimed that the background colours were present before he sent it off.
As I started doing more and more testing I started to get new faults with the sprites. I needed to figure out which chips were the sprite RAM’s so I reversed the ‘custom’ chip known as K526. In reality this chip is an 82s153. I dumped the chip and reversed it into equations
Pin 1 = MREQ
Pin 2 = RFSH
Pin 3 = A15
Pin 4 = A14
Pin 5 = A13
Pin 6 = A12
Pin 7 = A10
Pin 8 = F4
0xb400 (spriteram2)
/o12 = /MREQ & RFSH & A15 & /A14 & A13 & A12 & A10 & /F4
0xb000 (spriteram1)
/o13 = /MREQ & RFSH & A15 & /A14 & A13 & A12 & /A10 & /F4
0xa000 (main ram. covers color ram and video ram too)
/o14 = /MREQ & RFSH & A15 & /A14 & A13 & /A12 & /F4
0x8000 (Goes to pin 12 of 501 custom and also F3.)
/o15 = /MREQ & RFSH & A15
0x6000 (enable for unpopulated ROM socket, H5)
/o16 = /MREQ & RFSH & /A15 & A14 & A13
0x4000 (ROM H4)
/o17 = /MREQ & RFSH & /A15 & A14 & /A13
0x2000 (ROM H3)
/o18 = /MREQ & RFSH & /A15 & /A14 & A13
0x0 (ROM H2)
/o19 = /MREQ & RFSH & /A15 & /A14 & /A13
I figured out that the 4 x 2114 chips at D7 – D9 were the sprite RAM. 3 out of 4 had failed one by one so I ordered some up and replaced them when I got them.
All the sprites were back but still no background colours.
In a desperate attempt I wired the RGB-S straight into a scart connector to try a different TV. This is what I got.
The backgrounds were there all along but for some reason my other monitor wouldnt display them. I know the monitor works fine with my other games but why I did this I have no idea. If anyone knows or has any theories I would love to hear why.
On with the repair.
As you may already know this board gave me the opportunity to test Shoestring’s diagnostic ROM. After a few teething problems we got it working and I was able to test the player inputs. To my surprise they all worked fine and testing in game confirmed this. No idea why it didnt work for Muddy but it works now.
After getting the game up and running with background I noticed the main ship sprite was no longer a ship (see picture above).
Lightly flexing the boards fixed the problem but then the board stopped working. The Fluke was already plugged in and running test gave me a DCD error.
This error means there was a problem with the RAM addressing/decoding. This issue is normally missed by POST routines as they simply write a value to an address and read it back comparing it. The Fluke doesnt do this. It writes specific values to specific addresses so if there are any addressing issues it can tell. My issue ended up being caused by me. There was a tiny flake of loose solder bridging two address lines on the main RAM. Removing this made the game boot again but now I had another issue.
The graphics were now doubled up.
This was easy to find and ended up being a dodgy socket on the 082 custom chip at location F5. I replaced the socket and now everything was good again.
With that all done it was on to the sound.
I was getting a little tired of looking at this board so after a few preliminary checks I just desoldered the Z80 and fitted the Fluke.
BUS CHECK showed bit 0 and bit 1 were stuck LOW. I wrote 0x55 to a point in RAM and read it back, I got 0x50.
I then wrote 0xAA to the same point and read it back, I got 0xA0.
Looking at the schematics I pinpointed the offending RAM chip to the 2114 at B7.
Replacing this game me back the sound.
On the final test the sprites died again!!
I replaced the last 2114 RAM chip on the main board and this is now 100%