Turbo OutRun PCB Repair Log

dj_yt

Active member
Feedback
3 (100%)
Credits
787CR
Purchased this OutRun boardset from the states. It was sold as faulty. The seller included some free food, which kept me happy whilst I stared at the black screen it presented me with on boot.

to_repair1.jpg


First thing I did was to verify an EPROM with RomIdent. This showed this was actually an OutRun boardset converted to Turbo OutRun.

I then tested the 2 boards against a known good set, and found the lower video PCB to completely working. Fantastic! This saved me building the interconnects that ColinD kindly sent me this time round.

to_repair2.jpg


I swapped the security FD1094 processor with a vanilla 68000. I programmed some decrypted ROMs.

I was greeted with the following screen.

to_repair3.jpg


Progress, but this was a bit of a red herring. It crashed immediately after this screen. In fact, this screen was an addition of the Japanese decrypted roms I'd happened to use. It's possible that the security processor was still working, but I'll go back and check that later.

I dug out the schematics and found an LS244 with dead outputs @ IC83. This was part of the sub CPU memory addressing. I socketed it and swapped it out, but it didn't make the game boot, although the logic probe showed its pins were doing something at least.

At this point I decided I wasn't going to change any more components without better diagnostic information. I'm slow at desoldering, so shotgunning stuff wasn't a good idea.

I used the OutRun SDK, created by Alex, to code a test tool for OutRun. Alex had already started work on the tool and I made some further modifications. My theory was that I needed a minimal piece of software to test as much of the hardware as possible. The problem with the on-board tests on OutRun, is that they require most of the PCB to already be working in order to use them. So they are mostly useless.

I spent a couple of nights changing the tool so that it would test the 4 Main CPU SRAMS, the 4 Sub CPU SRAMs, Tile RAM, Text RAM, Palette RAM and Sprite RAM.

The tests that Alex had included were far more rigorous than OutRun's onboard tests, with separate address bus and data bus tests.

Screenshot from MAME below, excuse the horrible palette (it's really setup for OutRun not Turbo OutRun)

to_repair_tool.png


I programmed this to the boardset and got the following:

to_repair4.jpg


The program reported the Sub CPU RAM @ IC 73 was bad.

I also verified that the ICs reported by the program were correct by glitching some of the SRAMs whilst it ran.

After hours of swearing and desoldering (mostly due to the ground plane) I'd removed the offending SRAM and socketed the IC.

to_repair5.jpg


Personally, I find these boards an arse to work with. I have a lot of respect for Mark at Retroclinic now.

At this point, the test gave me a different error because the SRAM was completely missing. Promising!

to_repair6.jpg


Inserted a replacement SRAM and BOOM - all OK!

to_repair7.jpg


Change the EPROMs back to the game and we have attract mode with sound:

to_repair8.jpg


Next steps:

- Hook up my controls and check the game itself

- Verify whether the security processor is still good and change the battery if so

- Rewrite the test program in assembler to not use any SRAM at all! This will mean it even runs on massively crippled PCBs.

I made this sound easy. I didn't find it that easy!
 

dj_yt

Active member
Feedback
3 (100%)
Credits
787CR
Thanks for the comments! There is still plenty to do in terms of improving the quality of the test tooling. This is just an early version.

Rewriting it in assembler will be a big win, but require a bit of time. I've also been discussing with Alex some ideas to successfully test Road RAM. Both OutRun's onboard tests and our own don't cover it at present.

I have a lot of broken Sega boards to fix, so no doubt I'll keep working on the tooling when I can and share updates with everyone here.

dj_yt2017-05-10 14:10:07
 

BarrySlisk

Active member
Feedback
1 (100%)
Credits
162CR
I am a programmer myself but must admit I would not know where to start doing something like this. Massive respect. Especially If you release the test code :)
 

dj_yt

Active member
Feedback
3 (100%)
Credits
787CR
I'll definitely release the test ROMs. I'd like to get them to a better place first though.

The existing work by Alex towards the outrun SDK made the job quicker than expected so far.
 

dj_yt

Active member
Feedback
3 (100%)
Credits
787CR
Should I be keeping my old FD processors?

I tried changing the battery on the original one and somehow failed. Before I fitted the new battery the voltage was a solid 3.2v. After the procedure it dropped to 2.8v, and the processor had lost its security key. I'm not sure if I overheated the battery with my soldering iron or what exactly went wrong. The small wires in the processor weren't in great condition, so there's always the possibility the backup battery lost the connection.

In other news Alex has made great progress rewriting the test ROM into asm. I was going to do it myself, but he has taken the lead there! I'll probably aim to port to Super Hang On boardsets or X-Board next.dj_yt2017-05-12 15:45:28
 

RGP

Meeter & Greeter
Feedback
5 (100%)
Credits
2,039CR
I love a good repair log.

I love how SEGA made such crappy tests and that the board needs to be pretty much 100% before you can get into a test - not well designed.

If one had a board interrogator like a Fluke with 68000 pod you could attack the ROM/RAM from that perspective? Even with the encrypted ROMs in place - although who really wants those with the much better enhanced version around.
 

stevebm1

Active member
Feedback
36 (100%)
Credits
1,164CR
tb2000 said:
Nice work! Be great when we can reprogramme the security on the FD chips as well - hopefully it won't be too long before that happens!

I thought a guy in europe was working on that,and had made progress?,perhaps porchy is the man to ask
 
Top