SEGA Mega-Tech repair log #1

 PCB Repair Logs, Repair Logs  Comments Off on SEGA Mega-Tech repair log #1
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.
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

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.

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.

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!

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.

Dec 312014

today I got a couple of Oric computers.
Ive been after one of these for some time now but prices have shot up of the last 12 months.
I couldn’t resist buying these two, both of them which required repair, as the price was right.

First is red/black one.
I first started by removing the ULA and powering up to check voltages. I do this with Spectrum’s too as these early voltage regulators have a habit of going wrong with disastrous consequences.
With everything looking OK I refitted the ULA and power up. I was greeted with this screen.

Ive read enough about the Oric over the years to know that the ULA is very hardy and the RAM is very poor. Ive also read that a fried ULA will usually result in nothing on screen at all.
I opted to desolder the RAM first.
There are 8 x 4164 RAM chips and on testing two of them failed.
I socketed and replaced the faulty RAM and I now have this

The random writing is my doing as the keyboard is flat on the bench when testing.
Happy with this. I think the second unit has the same fault too.

Dec 142014

Got a Jaguar console for cheap as I originally wanted the cartridge slot but like so many of my idea’s like that I ended up repairing it and not wanting to harvest parts from it.

This was sold as not powering up. Its important to know from the start that the Jaguar will not power on without a cartridge inserted but in this case it made no difference.
Opening it up and removing the metal shield allowed me to see the problem straight away and it is apparently a relatively common fault.

The voltage regulator IC has blown.
I ordered a new one and fitted it and now it at least powers up.

I haven’t really been able to test it yet as I don’t have a Jaguar AV cable. Also this version of Jaguar didn’t have an RF modulator fitted as it was the French ‘Peritel’ version.
Ill tap the signals some day and properly test this thing out so if it doesn’t work then it looks like ill have my cartridge slot after all.

Oct 022014

To start with this game wouldn’t boot at all.
The board has had one of its big surface mount custom chips replaced in the past and apart from one lifted track that has been patched out, the swap was very neat.
First job was to desolder the sub CPU and fit the Fluke to see what was going on.
I found a broken link between the ROMs and D4 of the CPU. I patched this and did a ROM check.

The ROM address space lies between 0x0-0x3ffff.
The Fluke 9010 signature for this is 8A4F

This was correct but the game still refused to boot.
Checked the RAM. This lies between addresses 0x20C000-0x20FFFF
Both of these failed and both were replaced.
Ram checks now pass but the game still does not boot.

Next I tested the shared RAM.
This lies between 0x210000-0x21FFFF
This passed up until address 0x21FFFE where I couldn’t write to the address at all.
I haven’t figured out why but I’m starting to think this is normal as the code writes to this address space separately but never reads from it. Maybe some kind of watchdog reset or something?

As the game still did not boot I opted to desolder the main CPU and fit the Fluke there.
Found another broken track between the main CPU and one of the ROM’s (I forgot which one as this repair has taken ages).
I patched this out and the game now boots but there is a faint output on screen. Further probing with the scope revealed a dead TC0070 RGB custom chip.
I replaced this and now got a booting game but with wrong colours.


This had me stumped for a while as there are a lot of custom chips on this board and any one of them could be a suspect as they all feed into and out of each other.
I opted for a different approach to normal and made up a small converter PCB that let me use 0.6″ chips in place of 0.3″ chips. This allowed me to use an NVRAM chip in place of the palette RAM.

So with this in place I let the game boot to the title screen and powered off. With the contents stored in the NVRAM I was able to dump it and repeat the operation for the second palette RAM and interleave the dumps together. No I had this I could compare it to what MAME has at the same point. This allowed me to see if the data being written was actually correct or not.

Here is what I got on my first attempt and what I should have got.

As you can hopefully see, bits 4 and 6 are wrong here so I took a closer look at the custom chip TC0110PCR that feeds the RAM chips.

There was the smallest bridge of solder across D6 and D7. Removing this gave me the colours back.


Everything else appears to be working so I am glad this is now sorted.

Sep 212014

Another one of Ben’s boards.
Had the usual graphics issues you normally get associated with those four 2114 RAM’s only this time the RAM’s had already been replaced and all four were good.

Following the inputs and outputs from these RAM chips I found some broken traces, probably a result of desoldering them originally.
Pin 1 of the RAM at location 3H was not connected to anything. I patched this and it fixed the solider sprite on the title screen but some in-game graphics were all messed up.


After confirming all other connections were good I noticed two other 2114 RAM chips that had been worked one and socketed so I checked those too.
Initially I found pins 3 and 4 of the RAM chip at 1B. Patching these gave me this result

Getting there but not quite.
A little further inspecting these chips and I also found pin 15 of the same chip not connected to GND like it should be.
Patching this one gave me a perfectly working game.