No announcement yet.

Sega Rally 2 Twin Repair Log


Share any logs or helpful information you may have to repairs of arcade PCBs, Monitors etc

  • Filter
  • Time
  • Show
Clear All
new posts

  • Sega Rally 2 Twin Repair Log

    This will likely be an on going thread as there is multiple problems.

    Ok so bought this one on trade me. Description they had given was "one monitor stopped working, had someone look at it and now the other side isn't working"

    So I'm thinking, ok so their is 2 monitors to repair. I've got reasonable knowledge in electronics and had always through learning to repair CRTs would be handy (Before anyone asks, yes i'm aware of how to discharge them).

    Well turns out by "monitor" what he really meant was "side". Both monitors were working, although they can be a little fuzzy till they warm up.

    He powered it up when i went to pick it up and it was sitting on "Checking network" on one side (can't recall what the other did, probably nothing)

    So the nice thing about a twin set is you've basically got 2 of everything, so swapping parts between sides is an easy way to isolate problems down to a board level.

    The Face Palm CRT Problem
    So power up one side (I picked the two sides up on operate days). CRT powers on but the screen is black. Then every so often it would come up with these white horizontal dashes. Odd I think, it was doing at least something when I picked it up. I figured because there was some dashes every now and again there might be sync problem or something.

    So I grab my scope (its just one of those ocium ones that plugs in to an iPad) and check the sync and signal lines, nothing. Turns out they were floating.

    Heres the face palm... I flip over the seat, the cage lid was already off, and the board stack was sitting in the cage... disconnected from the filter board. turns out the board stack had been unscrewed from the cage (the stack itself was still screw together fortunately) and must have disconnected it self during transport.

    So push it back into the filter board, power it up, and bingo, "Checking network". Figured this was probably it trying to talk to the faulty side (which wasn't there anyway as I hadn't picked it up). Used the test menu to change it to "Stand Alone" and bingo, it runs.

    So it had no graphics problems and would play fine. Memory test showed 2 roms as bad but that didn't seem to affect anything (more about that later).

    But there were still some problems, there was this "dit dit dit" noise, and the force feedback wasn't working.

    Surveying The Problems
    So once I had picked up the second side I was able to do some diagnostics on it.

    Out of the gate the second side starts, but has nasty polygon issues with the 3D. But the 2D screens look fine. It normally crashes a couple of seconds after the demo starts, but interestingly would do a full race (sometimes) and the replay if you hit start before the demo started (i.e. sega logo). All the 2D stuff displayed fine during the race but the 3D was a mess of polygons. The strangest think is it still is trying to render 3D on the test screen, in fact because so much of what it was rendering was white you con't really read much of the text. Although if it was on top of any other colour it was fine, leading me to think the Test menu was overlaid on top of the 3D rendered layer.

    Ok so the basic diagnostics start. Put the entire board set in to the side that was more or less working, has the same problem in that side.

    So unscrew the two board stacks so I can exchange some boards. the Rom Board and the CPU board from the faulty side already have "Bad" written on them. So I take the rom board from the faulty side and put it on the good board stack. Run a memory test. ICs 34,35,38,39 and 41 are marked as bad, also IC 17 and 18 are marked as bad (17 and 18 were also showing bad on the good rom board). So I grab one of the roms from the good rom board and put it in the faulty one. Another ram test, still faulty. Swap the good rom board in with one of the "bad" roms from the faulty rom board. And its memory test shows it as good. Concusion: its probably not the roms but something with the board itself.

    Ok so then i swap the cpu boards between the good stack and the faulty stack. And an interesting thing occurred, on the memory test IC 17 and 18 where not good. Conclusion: the "good" cpu board has some fault which causes IC 17 and IC 18 to show as bad, but seems to run fine regardless.

    So now I swap the video boards, and problem follows. Conclusion: the video board has a fault.

    One of the interesting things I noticed while testing the faulty side was it had music where as the good side didn't. So I swaped the sound boards and now the good side has music. Conclusion: Fault in the sound board.

    So the force feedback isn't working on the good side. it would slowly shuffle the steering wheel one direction and the hardlock the opposite way until it gave up. It can move the steering wheel. The side with the video problem behaved differently, instead of going hardlock it centers. So I check the back of the side with the force feedback problem, and the segmented display is showing Er 22, which is according to the manual a VR fault. Took the force feedback controller board from the other side and the force feedback works fine. Conclusion: fault with the force feedback controller.

    Summary of Problems
    • Fault with 1 Model 3 step 2.0 video board, causing 3D rendering problems
    • Fault with 1 Model 3 step 2.0 cpu board, causing IC 17 and 18 to show bad, but no other obvious consequences.
    • Fault with 1 Model 3 step 2.0 rom board, causing ICs 34, 35, 38, 39 and 41 to show bad. This causes 3D video problems
    • Fault with 1 Sound board, causing music not to play (SFX are still fine)
    • Fault with 1 Force Feedback controller, causing Er 22 and no force feedback during gameplay.

    Fixing The Rom Board
    Ok so i've established at this point there is a problem with the rom board itself as putting the rom chips from the good rom board still shows those rom slots as bad.

    No obvious damage, aside from a 470uf cap that had been desoldered. replaced the cap with a normal 470uf cap leaving the legs on and bent up to provide an easy to access ground point.

    So at this point I start to reverse engineer the rom board, while at the same time looking for bad tracks/vias. I eventually work out that the video roms (IC26-41) are accessed in pairs, with each of the roms in a pair feeding to 16 bits of the 32 bit bus. Its also apparent they have used buffer/line drivers on the addressing lines and on the outputs of each IC and for the outputs of the bus itself.

    Putting a scope on the addressing pins of the roms shows that ICs 34, 35, 38 and 39 had at least one line that is having trouble pulling all the way to ground, or just staying high all the time. IC41 seems to have a different problem, which isn't surprising as else IC 40 would come up bad as well.

    So tracing back where the problematic address lines are being driven from I end up replacing 2 47ACT541 surface mount ICs (TSOP20). That fixed the problem with ICs 34,35,38 and 39. IC41 was coming up bad. Given IC40 wasn't having a problem its not likely to be an addressing problem. So to pickup an output problem I removed all other video roms using the same bus lines (i.e. the odd numbered ones). Then had a look at the signals that hit the final output drivers. What I found was one of the outputs was basically floating. Tracked that back to a 47ACT244 IC on the underside of the board (same function as 47ACT541 but a different pinout). Replaced that which fixed IC41.

    I should probably also mention these ICs seem to be rather sensitive, or were from a bad batch as i've had a few more of them go on me while i've been poking around trying to diagnose the video board.

    A possibly handy observation for others, the faulty ICs that I pulled off had unusually low resistance from the bad output pin to the supply pin, something like 300 or so ohms. It might be possible to detect a faulty IC by measuring the resistance between the +5V and the address pins of the rom chips (or sockets with the chips removed).

    One more think, as part of this process I drew up a partial schematic for the rom board in eagle, which I can share if anyone wants it.

    Fixing the Force Feedback Controller
    Ok so the error code (Er 22) and the behaviour seem to indicate it can't detect where the steering wheel is. To confirm this I found where the steering wheel input on the working board was and unplugged it. It came up with the same error as the faulty board and behaved the same, wheel went hard lock rather than centre.

    So I traced where that signal went. first thing it hit (aside from some signal diodes etc) was an OKI M6253 (18 pin dip). Couldn't find a data sheet for this device, making a little bit hard to confirm it was doing what it should or not. I guess I could have compared the signals with the other side but that would have probably been a two person job. So I took a punt and managed to find some on aliexpress. Once they turned up, and I changed the chip. Which was a pain to desolder, due to heat sinking caused by the ground plane on 2 of the pins (if anyone has some good tips on how to overcome easily this let me know). Put the board in and bingo, problem fixed.

    I've for 3x OKI M6253 left, so if someone has the same problem I could send one. Will probably want to keep 2 for myself, as if its happened once it could happen again.

    Attempting to Fix the Video Board
    So a little research online has basically told me Sega Model 3 Step 2/2.1 video boards seem to have a high failure rate.

    A little note here, the video board repair is a work in progress, but I thought I'd share what I've done so far and provide updates. Also if anyones got any experience with these (*cough* jomac *cough*), I wouldn't mind some tips on identifying faulty components.

    So at this point I start looking for what a replacement board is worth... turns out quite a bit (about 330 british pounds). So I flick an email to Andy Geezer (AGS) explaining the situation. He said the ram was a common point of failure for this type of board and referred me to Jomac (who i've seen on this forum so I figured i'd post everything here incase its useful to someone else in the future). So I end up thinking, well if i'm going to learn to fix these things I better get some parts, so i've ordered a pile of the texture ram (the ram for the 6060 chips, assuming its for textures) and the 3DRAM (which I think is being used for frame buffers, more about that later) from china, as its the only place I could find it.

    What I noticed from fixing the rom board is these polygon issues look very very similar to the polygon issues that occur when there are rom faults. Which is making me wonder if its having trouble accessing the roms for some reason. But one of the things that gets me, is the cpu board seems to pass the video rom bus through, but I can't see signs that the cpu board can actually access the rom board, but i guess its possible all the tracks not in the top or bottom layer of the board, but that seems unlikely. So i'm assuming at this stage the video rom check is actually done by (or via) the video board and not by the cpu board directly. So if the roms test good on the bad sideboard then it must be able to use them, right? Not necessarily...

    I had a situation while fixing the rom board where the memory test showed good but there were polygon issues with the good video board. Turned out that one of the ICs was borderline. I suspect it might have been a low enough signal to count as a 0 for one ic but not another. Also leading me to believe there is something different about how the roms are accessed by the videoboard when rendering vs checking roms.

    Anyway started to look at the rom bus on the video board and how it was hooked up. There is some ICs that seem to do bus termination, some that basically convert 5v signals to 3.3v signals (and vice versa for the addressing lines). After the data lines are knocked down to 3.3v they are connected to both the data lines for a ram IC (NEC D4811650GF-A12) and a sega bga IC (315-6058). I really should have looked into this stuff before ordering that other ram.

    Poking around with the scope (which is could probably do with being a high MHz for this stuff) I can't see anything obviously wrong, although alot of signals look strange, but comparing them to the working board seem to be the same. Although one interesting difference is the good video board doesn't access the roms while the test screen is up, the bad board does. But that could potentially just be a side effect. It also seems like the addresses being accessed are a repeated pattern or a very narrow range. Not all address lines move while its on the test screen, but they do when its rendering in game.

    So i'm wondering if the fact its rendering 3d on the test screen could have something to do with it having trouble accessing the roms. So I removed all the video roms. The test screen didn't have any 3d rendering on it, but that wasn't really surprising as it would have to data to render from. Anyway, I start adding the roms back in, once I got about 4 of them in they 3d rendering on the test screen came back, and it changed quite significantly depending on which roms were in and out. Although I managed to kill another couple of 74ACT541 chips in the process of poking around. Anyway I guess the discovery there was that which roms could be read changed what was rendered, but I guess thats not surprising and doesn't really mean that issues accessing the roms were causing it to render on the test screen.

    Ok so, I start looking at these data lines that are shared between the rom board data lines (after the 5v to 3.3v conversion), that ram IC and the Sega 6058 IC. I notice there is about a 8.3kohm resistance on these tracks to ground (if you use the positive probe on ground and the negative on the data line). And this is consistent for all the data lines... except one that has a 10.3kohm resistance. Checking the other ram chips of the same type they all have consistant resistances (more or less) across all the data line pins, although those levels do vary from chip to chip (probably depending on what else is on the data lines).

    So I have a look at with the scope and can't see anything obviously wrong... however it did dawn on me, what the 6058 is probably doing is setting the ram up for writing when its reading from the rom board, then if it gets a request for data thats cached it just gets it from that ram. So I could simply be seeing the reads from the rom board and the ram chip could still be faulty. Guess I should probably set the trigger up on the fall of the write enable on the ram chip and see what happens.

    One of the other things i've notice is that these polygons that get rendered usually have flicking edges, and it seems like they only flicker if there is green in the colour. The flickering definitely looks digital. There are 6 3DRam iCs (Mitsubishi) that I believe are used as a frame buffer. If I had to guess I'd say what they have done is split the board in half, with each side having 2x 6060 (for texture mapping?) and 1x 6059 (for polygon calculations?) and have each side render alternate frames into seperate frame buffers and then just alternate between the 2 frame buffers for output. I also suspect they are using separate frame buffers for red, green and blue. I guess its possible there is an issue with the green frame buffer. One of the reasons I suspect the frame buffers is that the flickering continues even after the board has crashed.

    Another thing that is quite interesting is that they have tied the data lines of these 3DRam chips (M5M410092) together in pairs, and I can't really understand why. I'm wondering if 1 of the data lines on one of the 3d ram chips is faulty, then 1 would report a 1 and one would report a 0. But I'd need to understand more about the video output before I could come to any reasonable conclusions about that.

    So anyway thats about as far as i've gotten so for. Keen to hear anyones thoughts theories or experiences.

    FYI can take pictures and video and scope screenshots if anyone is interested.

  • #2
    sega rally 2

    hi cracked magnet,, i know your segarally log is back in 2017 but wondered if i could pick your brains?
    i have a sr2 twin cab and having a few issues, keep getting error 20 on drive bd, now i have fitted second hand working game stack, motor drive bd, drive bd and one sound amp,, apart from the er 20 I'm also getting no sound or music nor ffb on both machines???
    to have the exact same problems on both units has baffled me a bit...i have to put both units in stand alone mode other wise they won't finish network test (could be fibre op prob)
    ive belled out a lot of the wiring looms from coin box to trannys to sound bds and drive bdsand all seems ok?
    anything obvious stricking you?


    Users Viewing Topic: 0 members and 1 (guests)