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 AKA reproduction of a bprom to GAL

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 http://elgensrepairs.blogspot.it/ for the invaluable tool  and to Caius and Porchy for being always very helful

 

Shinobi repair log

 PCB Repair Logs  Comments Off on Shinobi repair log
Feb 092017
 

This pcb from my collection developed lately a sound problem only with the jump sound which is a sample

 

This particular sample was distorted, the others were all OK

The clock and the 7759 sound chip which is responsible for the samples I was sure they were OK otherwise

all the samples would have the issues

I dumped the sound program rom 11372 and the samples roms 11288 and 11289 expecting that one of them could be corrupted

but surprisingly everything was fine.

If you have noticed, I still the original NEC module with a suicide battery from 1987. The battery is still working after all these years but unfortunately cannot be changed since the module is one piece injected with epoxy.

I started to think that the module could have the decryption key stored in ram somewhat corrupted after all these years and this could affect of course the sounds

Therefore I proceeded to use a z80 with the decrypted program rom taken from a mame set which use the same 5358 rom board (it is currently set 5)

The jump sound was correct with decrypted rom, confirming my theory that the key in the module is corrupted.

Mar 292016
 

Sometimes it is very annoying when you have placed your arcade monitor vertically and certain games are shown upside down and  even worse they have no option to flip the screen.

It happens very often with older games but sometimes even with newer games from the 90s.

In these cases you have 2 options: reverse phisically your monitor or reverse the yoke  on the pcb of the monitor (not very safe).

Now I show you a new option available only when the games were also prepared for cocktail tables (that means they have already the circuit to flip the screen for the second player)

In this first “flip screen” hack I will take Zaxxon / Future Spy hardware as an example

 

Future Spy_2

These games have no flip screen option but they have the preparation for cocktail tables play.

The board is very big but luckily schematics are available and they are very clear to understand.

The hack is very simple: input nr.4 of 74ls367@U64  is normally LOW for first player game and HI for second player game.

We have only to force pin 4 to HI (+5V) using a wire so that the screen is always flipped as it was playing the second player even in upright mode.

Zaxxo_flip screen hack

 

FS

 

Very simple and effective!

Quartet repair log

 PCB Repair Logs, Repair Logs  Comments Off on Quartet repair log
Mar 042016
 

Here is a recently repaired Quartet running on Sega pre-system 16 hardware.

quartet1

The 3 replaced chips are highlighted in red. I will explain every step of the repair process below.

1) The game was booting to a garbled screen:

quartet2

The 74LS04 located at 1H (an inverter, manufactured by Fujitsu) had good clock signals on entry pins 11 and 13 but had floating signals on outputs pins 10 and 12. Replacing the chip changed the result on boot…

2) I then got a screen with garbled graphics but with a countdown appearing at the center.

quartet3

This is normal on pre-system 16 games. Normally, after reaching 0, the game is booting. Here, I got a black screen after the countdown.

I noticed that the reset pin on the 68000 had a square looking wave signal, which was pretty weird (it should be a linear signal at +5V). The chip that generates the reset signal is a MB3771 located at 1G (again, manufactured by Fujitsu). Probing its pins made the game sometimes booting. I replaced it by a new 3771 chip and the game was now starting normally.

quartet4

3) The game was working and playing fine except for the FM sound that was inoperative (only the voices could be hear). It was due to the YM3012 located at 1B (a DAC). It had good looking signals on its inputs but nothing seemed to get out of its outputs. After replacing it I got the FM sound back.

Now the game is fully working.

SEGA Mega-tech repair log

 PCB Repair Logs, Repair Logs  Comments Off on SEGA Mega-tech repair log
Feb 072015
 

Some weeks ago I was sent a Mega-tech board to look at with an apparently common fault. The PCB would not see any cartridges that may have been present.
As it is considered a common fault I thought it best I draw some schematics up in order to allow others to hopefully fix their own fault. What I found with this system was far from easy.
NOTE: I use a variety of different displays throughout this repair and my test bench TV displayed the colours a bit wrong but its not a PCB fault.

The visual inspection turned up something straight away on the underside around one of the factory fitted wires.
IMAG1139
I cleaned this up and tested the board. It fired up OK but I could hear a strange ‘fizzing’ sound and occasionally a ‘pop’. As luck would have it I was in a darkened room at the time and I could clearly see that resistor array RA18 next to IC37 was glowing. This was located right underneath where the burnt out wire was.
I replaced the resistor array and did some continuity checks and everything was good.
I think at some point the wire had been pierced by an IC leg and shorted out. Maybe this is something for owners to check out?

This is what I got booting up
IMAG1132

The menu has its own Z80 processor and BIOS so I thought this would be a good place to start.
The first step was to take the code apart and see exactly what it does to read the cartridge ports.
Ultimately the Z80 sees the cartridges between address &8001 – $9fff, but before we can do that we have to jump through a whole set of hoops to setup the system. It is here I found my first problem.
I used the Fluke 9010 heavily throughout this repair so I had full control of this setup.

On this board there are a couple of CXD1095Q I/O extender chips. These chips require setting up before they can be used and the BIOS does this on startup.
They have 5 ports (A to E) and the pins on each port can be set as either an input or an output. To set these up the BIOS writes the necessary values to the registers of the CXD1095 at address $6406 and $6407.

My focus originally started on the one at IC7.
IMAG1154

So ports A and B are not used on this chip so they are set as inputs.
Ports C, D and E are set as outputs.
Port C lies at address $6402
Port D lies at address $6403
Port E lies at address $6404

Reading at address $6c00 clears the /RESET line to IC7. This needs to be done before the chip operates.

The port I was most interested in at this stage was port E as this is the one that selects cartridge slot to be used.
To setup port E I simply had to write the value 0x0 to address $6407 and then whatever I write to address $6404 should appear on pins 49, 50, 52 & 53.

This was not what I had though, instead all my pics were dead.
After convincing myself this chip really was bad I hit the internet and ordered a couple of replacements from China.

A week or so later and I had these replacements.
I removed IC7 and fitted a new one.
IMAG1157

Now when I ran the same tests I got correct activity on the output pins but the board still did not see any cartridges.
Moving on from here brought me to the second CXD1095Q chip at IC24.
The registers lie at address $6806 and $6807 on this chip.
This chip is responsible for reading various signals back including the “Cartridge Present” signal.
Address $6802 is the cartridge present signals and following the same testing as before I should have been able to write 0x3f to $6806 and then be able to read back values at address $6802. Again this was not the case so I removed and replaced this chip which gave me back all my signals. Like before this did not cure the problem.

The advantage I had now was I could setup the board so I could read the cartridge starting at address $8001. When I tried to read I got slightly different results each time, kind of like if one or two of the pins were floating. None of the pins were floating however.

As the Z80 is an 8 bit CPU and we are reading from a 16 bit bus there needed to be some other logic in the way. This takes the form of a custom chip marked 315-5309 at IC66.
Using MAME I knew what values I should have been reading back from each cartridge and I could confirm these readings using a logic probe on IC53. I could infact confirm the signals from the cartridge right back at the 315-5309 chip but the signals coming out of the chip back to the Z80 were different on each read.
I already had access to a spare 315-5309 so I took the plunge and replaced it. To my surprise it worked!
IMAG1162

On paper (or screen) this appears to be a fairly straight forward fix but I assure you I was pulling my hair out for most of it.
A huge thanks to Charles MacDonald for all his assistance and providing me with a proper datasheet for the CXD-1095Q chip.

Partial schematics can be found here