9 Oct 2019

Turbo OutRun - Sega 1989

Turbo OutRun on the bench today (OutRun hardware). I really like to work on this hardware, I find it very easy to fix, design is made in a way different fonctions are made quite independent and neatly organised on the boards, THT custom chips are rock solid (and can be found on S16B motherboards anyway) and the only weakness is the PCM SMD chip which has been reproduced. That's maybe also because I've worked on those boards a lot and know them by rote.

I got this boardset as a gift from member kingau, many thanks to him.

Upon first inspection I immediately noticed a kit from Sega Resurection had been installed (standard 68k for main CPU and the 4 main CPU ROMs) in order to "desuicide" the game. Original CPU MODULE (FD1094) and ROMs were also included.

Once plugged game actually started, I could add coins and start a new game but image wasn't syncing and samples were buggy.

I probed the sync signal on connector H (bottom board) but it was missing. It's coming from a LS125 (IC91) and sure enough input was pulsing but output was dead. I replaced it and could finally play a psychedelic version of Turbo OutRun:

There was some more work needed...
Obviously there was something wrong with the palette circuitry, and probing in that area revealed IC98 (LS241, bottom board) driving the palette RAMs /WR and /OE signals had one of it's output stuck high (/WR signal of RAM IC92) meaning nothing was never written to that RAM. I installed a new one which revealed more problems:

Oops, forgot to take a picture!

This time it was a tile problem, again probing on the bottom board revealed all data signal for RAM IC64 were unhealthy. Piggybacking a good chip on IC60 (LS374) cleared the fault. Now all graphics were much better, however now I could clearly see road was missing:

Turned out both road ROMs (IC11 & IC47) had been replaced by 27C512 chips (64kB) when they should be 27C256 (32kB).
Of course that shouldn't be a problem if you double the file before burning it but here I didn't even check the content of the ROMs and installed fresh 27C256s instead, which restored the road:

Graphics were all good... Only for few minutes when suddenly all sprites disappeared:

Some address signals were flacky on the object RAMs. Cause was a faulty LS367 (IC49, bottom board):

Then to conclude the repair I had a look at the sample area (top board). I quickly found one of the RAMs (IC91 , top board) was faulty by piggybacking a good one.

Game fixed.

A handful of chips later...

P.S.: Out of curiosity I installed the OG CPU module and ROMs and surprisingly game booted without any issue!

27 Sep 2019

Sega System 18 romboard custom chip reversed (315-5436)

Just a short video to show the small adapter board I've designed to convert the SDIP64 package pinout to the PLCC84 package used by the CPLD I've choosen:

Works flawlessly.

7 Jul 2019

Sega PCM chip 315-5218 reproduction part #1

I can't promise to update that blog very often in the coming months but tonight I found time to write a new article!

That chip handling samples playing can be found on many Super Scaler games from the mid/late 80s:
- OutRun/Turbo Out Run
- Model X
- Model Y

And some may also know that it's unfortunately quite unreliable and no equivalent/replacement exists so only solution was to pull a working chip from a donor board (which proves expensive to the point of not making it worth it).

I started this project cause I got a Frankestein OutRun/Turbo OutRun boardset (top board from OutRun with EPROMs swapped with Turbo OutRun ones but jumpers left configured for OutRun, bottom board from Turbo OutRun) with many faults including that damn PCM chip (last hurdle in the repair).

There's little information about that chip but what's available is highly useful:
- Pinout is available in OutRun's schematics
- MAME states some earlier Sega games (Enduro Racer, Space Harrier, etc.) use an almost 100% TTL version of it
- Schematics for Enduro Racer are available!

Those were good entry points so I started by comparing schematics and identifying functions:

Pink = clock circuitry
Red = sample RAMs
Blue = sample ROMs
Grey = banking mechanism
Yellow = PCM logic

TTL version:


Then I identified signals directions and equivalence:


A0-7 = A0-7 (from Z80)
SD0-7 = PD0-7 (from 280)
!SRD = !PRD (!RD from Z80)
!SWR = !PWR (!WR from Z80)
!SRESET = !PRS (!RESET from Z80)
!EE0 = !DACS
GD0-7 = GD0-7


!SWAIT = !WAIT (!WAIT to Z80)
RS02-11 = RS02-11 (to DAC1022)
LGT = LGT (to MF6 filter for left channel)
RGT = RGT (to MF6 filter for right channel)
SA1-7 = SA1-7 (RAM)
GA0-15 = GA0-15


DD0-15 = DD0-15 (RAM)

Some other signals also have direct equivalence but don't have names in the TTL version (!WE0 & !WE1 for RAMs, etc.)

Obviously there are few differences:
- TTL version can address only 32/64k for sample ROM (A14/A15 are used for chip selection). No banking.
- Clock circuitry is all external in the TTL version.

But we'll see that in the next part...

16 Jun 2019

This blog is still active: two Sega chips reversed! (315-5436 & 315-5218)

With all the changes in my personal life I hadn't got time to update this blog in a while.

I'm still alive and still working on many different arcade projects, with two recent milestones:
- RE of the 315-5436 custom chip found on some Sega System 18 romboards in a CPLD. Not really useful for preservation since that chip is pretty reliable but a step forward in the direction of a S18 multi romboard (first prototype used a trillion GAL chips instead of one unique CPLD now)
- RE of the infamous 315-5218 PCM chip used by Sega on many Super Scaler boards (Out Run, Model X, Model Y)

Unfortunately I'll be away from the hobby for an other 3 or 4 months so don't expect much news during that time.

9 May 2019

Raiden - Seibu 1990 #2 (repair log)

Game was dead, no main or sub CPU activity, however sound section was alive since adding a coin would make the associated jingle play.

This was the first revision of the hardware used by Seibu for Raiden, a real nightmare for repairers:
- 18 CPLD (most undumped, few dumps I've found turned out to be incorrect due to most devices being registered)
- 12 SMD custom chips
- 6 SIL custom chips
- few others DIP/SDIP custom chips (e.g. YM3931, etc.)
- many custom SDIP mask ROMs
Seibu probably went this route to discourage piracy, at the price of an overly complicated design, a much more simpler hardware could have done the job perfectly.

I probed main and sub CPU and found there was activity on buses for a fraction of second only then nothing. I was a bit stuck since few signals made no sense: some LS245 had their /OE signal stuck high, putting all outputs in high impedance, although their DIR signal was toggling, Altera chip for sub CPU had 2 floating inputs (pins 5 and 9) coming from the PEEL18CV8 stamped RD016, etc.
I put the board aside for a couple of days, time to elaborate a plan. Having a fully working Raiden I though I'd make few experiences with it. Pulling sub CPU ROMs revealed main CPU was still able to start and maintain its activity. Thus first problem to solve was to get main CPU to run. I continued probing on the main CPU, associated ROMs and RAMs, and nearby PLDs when I found one input (pin 11) of RD002 (U0172, PEELCV8) was floating. This was interesting since that chip generates the /CE signals for ROMs and RAMs and I had found before ROMs 3 & 4 were permanently selected (always low) and the other pair of ROMS (1 & 2) so as RAMs were never selected (always high). I followed the trace and found a point of corrosion on a via near the JAMMA edge. I clean the rust and exposed copper and for sure connection was low on half a millimetre between the via and the trace:

Once patched game then booted and was almost fully working! Except sprites were "cut":

Swapping the daughterboard (OBJ1) with a known working one informed me it was the culprit. Upon close inspection I found several lifted pins on several SMD customs chips:

I reflowed all of them and sprites fully reappeared:

Game fixed.

P.S.: I had used the UEC-52 (SIL22) custom chip from that board to repair an other Raiden board but in the meantime I'd also ordered a replacement part from Caius from jammarcade:

I decided to install the replacement on that board and can confirm it works per fectly. Thanks Caius, good job!

2 May 2019

Vapor Trail - Data East 1989 (repair log)

As often board was dead. Upon inspection I discovered someone previously worked on the board and reflowed the custom chips (in a weird way, by this I mean with a lot of solder but surprisingly there didn't seem to be any short). Also the sample ROM on the top board was in the wrong socket and jumpers weren't set properly but this shouldn't prevent the board from booting. Last thing I noticed was a sticker on the top board saying "NO SOUND".

1) Getting the board to boot

One of the work RAM had its data bit 7 stuck low. I pulled it and it was reported faulty by my programmer. Once replaced I saw no improvement. Main CPU being 16 bit (68k) work RAMs are paired (LSB/MSB) and often when one is faulty the other one is too. So I pulled the second one (again reported bad) and game booted with many graphic faults and no sound:

2) Fixing the sound

I went straight to the audio RAM and again data signals were incoherent. Once pulled it tested bad, as expected. Replacing it brought back sound.

3) Fixing the graphics

3.1) Jailbars
Probing the top board revealed data signal D6 was absent from LS373 @A6. Probing were D7 was coming from gave me the information that D6 was linked with D6 on the LS373 next to it (@A7). I restored the connection with a piece of kynar wire and jailbars disappeared:

3.2) Sprites
I probed the mask ROMs on the top board and found the one named MAA-04 had weak signals on its data pins. I desoldered it and tried to read it with my programmer: it was full of $0E and $0F repeated at infinitum... I programmed a new one (27C400) and graphics were much better, sprites being perfect now:

3.3) Background
Still, there was an issue with one of the background layer.
It's generated by one of the custom chip named '55'. At first I thought it was faulty cause I had the exact same issue before with an other Data East game and the '55' custom chip was the cause.
Anyway, I probed the 2 RAMs associated with that chip and again one of them had weak signals on its data pin. They are directlty connected to the custom chip so not 100% sure they were the RAM was the problem but I took the chance of replacing it after having found 3 other bad RAMs on this board. And it was a lucky bet, the background was much better after replacement but not perfect.
Some tiles were corrupted:

But sometimes background was perfect:

I was pretty sure problem was around the custom '55' @D19, it had been reflowed before so I probed each pin when pin 82 would give me connection with two traces going to the custom chip. In fact pins 81 (ground) and 82 (data signal) were bridged by an almost invisible solder bridge. I removed it and could finally enjoy the game:

Game fixed.

24 Apr 2019

Wonder Boy - Sega 1986 (repair log)

Game was a conversion but not sure if official or not:
- game has 2 Sega daughterboards
- labels are handwritten
- program ROMs match the encrypted wboy romset

Anyway, sprites had horizontal bars over them:

I dumped the sprite ROMs but they checked ok, then reseated the associated daughterboard with no result.
So I followed the sprite generation circuit from IC to IC finding nothing obvioulsy wrong.
This is where I reached the 6 DRAMs used for sprites. They were AM2148 devices, known to generate a lot of heat, however two of them remained cold (IC13/IC33): to me that indicated those two chips were doing nothing.
I pulled them and installed fresh ones (much faster though being 35ns were original ones were 70ns) and sprite issue was cleared:

Lisenced... Clearly asking for a legal loophole.

I ended the repair by testing all inputs and sound and confirmed there wasn't any other problem with the board.
Game fixed.