crackedMagnet’s

Sega Model 3 Step 2.0

Repair Guide

Video Board

JTAG Bus Order

This order was worked out from tracing tracks to and from the video ICs (both frame buffer and depth memory).  Then I captured the JTAG bus on bootup.  The datasheet for the non BGA ICs indicates that they start in bypass mode for the JTAG as they have no ID Code, meaning they will just show up as a single bit with the value 0.  

Here is a table of the ICs on the video board JTAG bus in order from TDO (output) to TDI (input).  So these bits are in the order they flow out of the TDO.  Not sure if the ID codes need to be reversed to get their proper values.  I should also note that the order of IC76, IC77 and IC90 might be wrong, as they are BGA’s and its difficult to trace the tracks between them.

Boot up

If there is a fault with the JTAG bus, like one of the registers being stuck high or low, the system will not boot.  If I recall correctly two of the “frame” leds flash, thought I had a photo of that but can’t find it.  On startup there it seems to go through a partial scan of ICs then a full scan.  I suspect it's trying to detect if there is one or two video processor sets connected.  

Boundary Scan

The boundary scan is a jtag function that allows the pins on an IC to be read or set from the jtag bus.  The idea is you can set a pin on one IC high and read it from the IC it should be connected to in order to see if its connected.  It’s particularly important with BGAs as you can’t access the contacts so testing them directly isn’t very practical.

The boundary scan option is not available on all model 3 step 2 games.  Sega Rally 2 doesn’t have this option (or any ram tests by the looks).  Daytona 2 Power Edition does and I believe Ambulance Call also does.  There may be many others that have the boundary scan option, I just haven’t found out which.  If there is a game that has the boundary scan option and doesn’t require a security board let me know and I’ll add that to this guide as it might allow people to download and program roms that could help them diagnose their boards.

Don’t assume boundary scan errors mean there is a problem! 

For some reason which I haven’t worked out yet video boards can have 10,000 or so boundary scan errors when they seem to be working perfectly.  I’ve also got at least one video board that comes up with no errors.  I suspect this might be some difference between the step 2.0 and step 2.1 boards.  At some point I should probably get ID codes for each of the ICs from working boards with and without the boundary scan errors and see if there are any differences.

Where I’ve found the boundary scan most useful is when I’ve replaced one of the ram ICs and its still comes up as failing.  Given I’m expecting a problem with that IC (ie my soldering), it can point to a pin or two, which I can confirm with a meter is not connected.

Boundary scan results to IC mapping

This table was reverse engineered from recording the jtag bus while the boundary scan occured (well at least the start of it).  I had already worked out the order the ICs were placed in the JTAG chain and the fact the video memory has 88 boundary scan registers (from the datasheet).  From there it was a case of recognising the repeated 88 bit patterns from the scan to establish the number of bits in the Sega BGA ICs.

Boundary Scan Bit Position

The following table can be used to identify the pin on the video ICs that the boundary scan is theoretically referring to.  Don’t assume that if you have one of these bit positions come up that there is a fault with that IC, however its a good place to work out which pins to look at.

Memory Test Faults

The video board memory test gives a range of faults.  It does seem however that it normally fails an entire group of ram ICs when only one of them is actually faulty.  Another interesting fact is the IC numbers the memory test will give you often don’t exist on the video board.  That’s because it seems to be reporting IC numbers from the step 1.5 board.  On the step 1.5 board you can see the ICs that are reported to have failed next to empty pads marked with the IC number that needs to be replaced.

Polygon memory

This memory is reported as IC70 and IC71:

The IC it’s actually referring to is IC12.

Here is a shot of a Step 1.5 board showing you why:

You can see they empty socket for IC12 next to IC70 and IC71.  The step 2.0 boards use a single IC in IC12 instead of 2 ICs in IC70 and IC71.

So the IC you need to replace (or fix joints) is IC12 which is a NEC D4811650GF-A12.  Given the -A12 version is the slowest one you should be able to use any NEC D4811650GF (I’ve used the -A10 instead with no issues).

This ram IC is connected to the video rom bus and is likely used as a cache for polygon shapes.  This is why a fault in this IC produces symptoms that look similar to when there is a rom board fault.  

Here’s a photo of what things look like when this IC is not working properly:

You see polygons of distorted shapes firing off in strange directions.  You’ll also note that all of the 2D image is rendered fine as it ends up getting overlayed on top of the whatever is coming out of the 6 frame buffer ICs.

As an interesting side note, its actually surprising how well the system runs with this IC completely removed, a few polygon problems but a lot less then I’d expect.  And if I recall correctly it was more a case of missing polygons rather than distorted ones.

Culling memory

The memory test reports the culling memory as faults with IC68, IC69, IC72 and IC73:

As with the polygon memory these IC numbers refer to the step 1.5 board IC numbers:

So it appears IC68, IC72 refer to IC10 and IC69,IC73 refer to IC11.

One note I will add about replacing these is that if some of the solder joints aren’t connected the stack won’t boot.  In my case it was some of pins in the corners.  So if you replace one and it won’t boot afterward, check your joints.

In terms of what visual issues you get when these ICs aren’t working… I’m not entirely sure as I had replaced the polygon memory right before doing these ones so didn’t run it for long.  I vaguely recall it might have been missing polygons, so you can see through bits of cars etc.

Video memory

These report in the memory test as either IC85, IC91, IC99 or IC185s, IC195s, IC199s:

The purpose of this memory is to store the current video frame.  The video frame is able to be read of out the VID pins while being updated asynchronously from the video processors.  It looks like ICs are grouped in 2 sets of 3.  One set for each of the video processors.  Given the changes in video output from the faults I’ve experienced it looks like the 2 video processors process alternate lines.  And I suspect in each set of 3, one is for red, one green and one blue.  I’m not sure which is which however.

One quite odd thing about they way these are used is the fact they tied the data lines together.  PALU_DQ0 is connected to PALU_DQ15, PALU_DQ1 -> PALU_DQ16, PALU_DQ2 -> PALU_DQ17 etc.  This effectively halves the capacity of the ram chip.  There maybe some reason related to the way they read the video back of the chip that makes this necessary.

IC91 and IC199s are Mitsubishi M5M410092BRF chips, the rest are Mitsubishi M5M410092BFP.  The only difference between the two types is one has its pins clockwise and the other counter clockwise.  Well there is one other difference and that is price.

I bought my M5M410092BFP for about $5US each and M5M410092BRF for about $10US each.  I ended up having to get them off alibaba as I couldn’t find them anywhere else.

Given the price tag replacing a set of 3 would cost about $20US, so it might be worth doing a boundary scan and a quick check of the joints on any pins that show up.

I should also note the memory test doesn’t seem to detect problems with the video output on these ICs.  

Anyway here’s an example of what it can look like when one of these ICs has failed:

Note the distinct horizontal lines.

Here’s another example:

Again the horizontal lines, but also the obvious colour distortions.

It’s worth noting that a complete failure of one of these ICs would cause the stack not to boot.  In these cases it’s probably necessary to put a logic sniffer on the JTAG bus to see at which IC the ID Codes start to go wrong.

Known video memory fixes (Bad IC91):

If you have this error

The Video memory test gives you this result:

Then change IC 91 and the error is fixed :)

Depth buffer memory

This reports as IC61, IC62:

Now this one is a little odd, as there is an IC62 but no IC61.  Even on a step 1.5 board there doesn’t seem to be an IC61 (unless it’s on the bottom?).  Anyway I haven’t yet replaced this IC so will update with results of replacing IC62.

The choice of IC in this case is interesting as the depth buffer uses the same Mitsubishi M5M410092BFP as the video frame buffer, but it doesn’t use the video function.  

Anyway here’s what it looks like when this IC isn’t working properly:

Sorry about the bad photo, but notice the horizontal lines that occur on only some of the textures

Cpu Board

The only two errors I’ve encountered with CPU Boards are RTC problems and scroll memory.

The RTC problems report as low battery although i’ve seen another RTC error that is different.  Changing the battery in my case didn't fix these issues.  As it doesn’t prevent or really affect gameplay I haven’t concentrated on these issues.

Scroll memory

This error reports as IC17 and IC18 (sorry no photo)

These IC numbers are accurate and its simply a case of replacing these ICs on the cpu board.

The range of problems that faults in these ICs can cause is quite varied and includes a number of malloc errors on boot.  I’ve also seen (in Sega Rally 2) a fault in the scroll ram can cause a couple of the roms to report as bad when the same rom board on another cpu board reports them as fine.  In my case the fault cased the game to run for a few minutes then crash and it would have malloc errors on reboot.  Changing these ICs fixed these problems.

Rom Board

The rom boards are probably the easiest of the boards in the stack to diagnose.  Generally these issues will show up as bad roms on the rom check.  

If the rom board won’t boot, its likely something related with IC1-IC25.  Given that these ICs are basically directly connected to the board connectors (and each other) connection issues are quite easy to test.  For IC1-IC16, with a continuity meter go through each of the addressing pins and data pins for one of the ICs.  with one lead of the meter on the pin CAREFULLY and lightly drag the other lead of the meter along each side of connectors CN2 and CN3.  Your looking for a beep to indicate its connected.  Don’t worry about what it’s connected to in those connectors just thats its connected to something.  I’ve come across 2 corroded vias on a board just under one of the connectors, so had to run a wire around to connect them.  For IC17-IC25 do the same thing but for CN4.  I’ll probably do something more definitive for these as I’m basing a lot of this part on memory.

Now if it boots but some of the roms test as bad...

If possible swap the reported bad roms from another board.  Having said that I’ve not yet encountered a rom that was actually bad, but I’ve only been messing around with these things for about 9 months now.

Video Roms

So the key with working out what’s going on with the video roms (IC26-IC41) is mapping out the physical locations on the board so you know which ICs reading the rom is dependant on.

Here’s a general guide: