Omega Race repair help

i86time

Well-known member
Joined
Apr 3, 2011
Messages
2,257
Reaction score
410
Location
Riverside, California
I picked up an spare OR set a while back and am getting around to repairing it. It was sold as having issues. It had previously been repaired, worked for a while, then did what it is doing now. I've made some repair to it, but it is still displaying these weird vector issues and I'm spinning my wheels.




tl;dr version

When I got the board, it was displaying these issues and also had a VRAM error.

The previous repairs done had included socketing (and likely replacing) the 3 LS670 @ K4/L4/M4, the 393 @ R5 and the LS245 @ S1.

I started by switching out both of the possible RAM, no change, then both sockets, still no change. I tracked it down to a bad LS32 @ R1, switched it out and VRAM error was gone but vector issue still remained. Here's where it gets fun.

Using a scope, I saw that the errors were present @ the output of the TL082s. I wasn't sure if there was a way to test directly out of the DAC to eliminate the TL082s themselves (is there?), so I started as near there as I could.

Iterating between logic probe and comparator, at various times I found possible issues with many chips, I know that comparators can show disagreement for reasons other than bad ICs, so I had to do my best with what I was seeing. The first IC with a possible issue I found was the LS157 @ F4. I pulled it, but it tested OK w/ a TTL tester. I socketed it and put it back.

Moving back and figuring it was related to Y9/Y10/Y11 signals, I followed this back along the SDY lines, came to the LS367 @ G4 and found an issue. I pulled it, but it tested OK, so I socketed and put it back. From there I switched over to SSETA lines and came to the LS193 @ K5. I pulled it but it too tested OK, so I socketed and put it back.

So, it pretty much goes on like this, moving from chip to chip and pulling and testing when I find an issue. In total I ended up also pulling/testing/socketing:
LS273 @ E2, LS139 @ F2 & S04 @ S6 (I have no idea what led to this last one, can't find anything in my notes) and all tested OK.

At one point I checked all ROMS and all were good.

So I just said screw it and I took a working board and my comparator and tested all ICs. I noted if the chip tested OK and if not, which pins were different. I then used this info to compare the ICs on the non-working board. If any chip showed a difference to what the working board showed (even if there was a disagreement between the referenc chip) I looked at it further. This led me to pull/test/socket the following:
LS74 @ E7/8, LS20 @ G2 and LS374 @ D5

but all tested OK. The 393 @ R5 tested different, but as it is part of the RESET line, I ignored it. Also the LS374 @ A5 also showed differences but after testing the one @ D5 I didn't bother pulling it. The LS161s @ L2 and M2 showed differences, but only for the unused pins 11-15. I was unable to test the LS74 @ H9 and LS367 @ J/K9 as the clip wouldn't fit. Other than that all other chips/pins showed the same activity between my good and non-working board. Then just for fun I replaced/socketed the DACs and TL082s, still no change.

So, to double check there was nothing wrong with the TTL tester I was using, I swapped all the socketed chips on the non-working board (including ROM/RAM/CPU, DACs/TL082s and all my pulls) to my OR repro, in which all ICs are socketed, and it played fine.

So here I remain stuck. About the only thing I have not done is to cap the board (but I did replace the 10 uF @ C108 as it tested bad, all others tested OK). Any pointers are appreciated.
 
That looks digital to me, so it would be before the DACs. But seeing as the game plays fine (and I assume passes self-test) then it's beyond what the CPU can access directly, aka it's on the vector side. If all the VRAM and VROM passes, then the vector address bus, vector data bus (and S1) and VRAM/VROM chip select (F2) are probably OK. Likewise the vector state machine itself is probably OK since it's starting (to draw) and stopping (to let the game run and not watchdog). That leaves the program address bus, the counter set bus and the vector output bus.

Even though the main data bus is talking to the vector data bus correctly (VRAM and VROM tests pass) the LS157s that are in the middle might still be at fault when they try to talk to the program address bus (SEQAx). Or, next in line would be the LS193s mediating between the program address bus and the counter set bus.

Beyond that the 670s have already been replaced, and one of the 367s... what was the 'issue' with G4 (and F4 for that matter)? A comparator cannot deal with tristate or bidirectional chips like the 245 but should be fine with most others. Try power cycling with the comparator attached so it has a chance to get reset/set/loaded/etc. as the chip under test does.

The other interface to the vector output bus are the four LS273s in row 2.

Don't forget to check the timing and control chips (to the left of K4 on the schematic) that run the 193s and 670s.

I would't worry about the 161s at L2/M2/N2 since your VSM seems fine. Also the LS74 at H9 is only used by the interrupt line into the CPU. If the 367 at K/J9 were bad you'd have bigger problems.

It could also be something as minor as the 74S32 at L/M6 not putting out the SSET signal to load the 191 position counters in column 3, or the 191 at C3 not sending bit 11 (QC or pin 6) to the 157s in column 4 (or the LS04 at D1 not passing the proper over/underflow bit).

I realize you have already covered some of the chips mentioned but I thought I'd share my entire thought process. Good luck!
 
Cool, thank you for those leads. I just need a fresh perspective on this.
I figured something similar (program operating normally but the translation to drawing the vectors was failing), clearly not quite as competent and informed as your explanation though :)

G4 was disagreeing on outs 3,7 & 13 (all others seemed OK, as did all on H4). F4 I cannot find my notes on, but it must have been at least one of the outputs. In general when I found a disagreement I used the monitor function to look for stuck pins and then verified with the schematic. I didn't find any stuck pins that should have activity.

It's funny you mention the 7432 @ L/M6. I sort of suspected that one, but both my good board and this bad one showed disagreement on pins 3,6 & 11 but neither boardset showed an issue on pin 8 (SSET). Perhaps I should take another look at it. Is there any way to tell if the 191 counters are working properly in circuit or do they need to be pulled? The comparator wasn't any help.

Thanks again.
 
Finally had time to get back to this....

I'm making some progress thanks to your suggestions. I went ahead an probed all the chips you mentioned. Every pin not tied to V, Gnd or clock showed activity (i.e. no stuck pins), so I then went to pin 6 on C3. On my good board it's mainly held low with some occasional low pulses on certain parts of the attract screen. On F3, pin 6 is always low. Pin 7 on both chips is also held low. But on the bad board both pins 6 & 7 of C3 & F3 frequently pulse low and not at regular intervals. This leads me back to the SDX/SDY 10/11 lines. Since I knew E2 was OK, I pulled and tested B2 and it was also OK (as I suspected).

Sooo... I'm thinking it's something that's tied to both A/B/C3 and D/E/F3. This leads me to SSET as you mentioned, but the activity looks similar to my good board (but I may still pull and test it anyway). But I guess it could be something further back. The other option is GO(bar) or something that leads to it. The LS138 @ F5 and LS14 @ MN6 tested good with the comparator.
 
I can finally close this out.

After going back and forth with a probe on the suggested chips, I just couldn't find anything definitive. So I decided to go back to my spreadsheet of all chips that I had tested with a comparator, re-examining all chips that agreed on a good board but did not on the bad. The first was the LS74 @ E7/8, but I had already pulled and tested that. Next in line was the LS138 @ J/K6. Using the probe, I found that the pin 12 was always Hi whereas on a working board it was pulsing Hi. I pulled it, it tested bad, so I replaced and all is working again. Apparently that video is what it looks like when RDSTOP gets stuck.
 
Back
Top Bottom