Sawtooth on data bus

Mojodog333

Active member

Donor 2024-2025
Joined
Nov 5, 2024
Messages
385
Reaction score
163
Location
Michigan
I have a RAM failing the memory test on an Outrun project and hit a wall so I thought I'd throw what I'm seeing out here in case anyone has some ideas.

Below is what I am seeing. The red trace is one of the data lines on the shared data bus between 2 EPROM, 2 RAM, and at least 3 bus transceivers. That sawtooth is on D0-D15, but there is no trace of it on any address lines.

1000052287.png

The green trace is on the other side of a bus transceiver going into data line of a 68000. I think the third pulse is a glitch causing the RAM failure that occurs when the sawtooth is high enough to change the state of the transceiver.

One thought i had is that one of the ICs on the bus has some leakage on its pins when it is tri-stated. But it would need to be leaking pretty heavy to drive the voltage up when another IC is driving it low. The other thought was that the chip select logic is jacked up, but it seems to check out. Could one of the ICs have a bad chip select or output enable input that is not tri-stating the data lines?

I removed any socketed chips to rule them out as the source, but I don't want to socket everything on the bus if there is a less invasive way to approach this.
 
nip a pin of your best guess and if you are wrong get it back close together and bridge it with a little solder
 
Thanks guys! I'm in Korea all.week for work but should be able to dig back in next weekend.
 
The data lines are pulled up to 5V with 4.7K resistors, so they aren't floating but it only takes ~1mA to pull them to ground.

I checked all the chip and output enables; nothing looks suspect. No devices should be in contention for the bus. I pulled everything I could find on the D15-D8 bus (ICs 60, 76, 75, 73, 72, 135, 37), but there is still something active every ~150 mS. I'd like to pull everything off and put a 200 Ohm resistor to ground and see if something still tries to fight pulling it down, then selectively add things back. @parism are you familiar with the schematic enough to know what I might have missed on that data bus?


1764175928732.png
 
Bus transceivers have enable and direction pins. Check those to see if there's any correlation to the pulses.
 
Bus transceivers have enable and direction pins. Check those to see if there's any correlation to the pulses.
Thanks! I did look at the direction pins on everything but 19. The transceivers can pull like 15mA, but the RAM and EPROM can only source 1-2mA, so it looks like one of them could be stomping on the bus lines. That might explain the waveform if the memory outputs are CMOS, the junction would heat up, the FET Rds would rise and the voltage with it. Or, I might not understand this stuff as much as I think I used to and sound like an idiot.

Also, the sawtooth is on both D0-7 and D8-15 so a component associated with a shared signal might make more sense than 2 failed transceivers.

Going to a Wings game tonight, so I'll dig back in tomorrow morning.
 
I had a little time over the holiday weekend to look at this. I took these waveforms and then got interrupted before I could thing through what is going on. Now I'm in Germany for work, so I had a little time to interpret them....

I pulled everything except IC60 and see this. Red is a data line and green is R/W* from the 68K to the bus transceiver.

1764642991889.png

I thought I had a smoking gun here with sawtooth being a result of the RW* going high... but I need to investigate more.

1764643600593.png

I *think* IC60 is the only thing installed (no RAM or EPROM), but I really need to document these traces better with the notes feature of picoscope because I am second guessing if I tested that everything pulled in this trace. If I did, pull everything, when the R/W* high, the data pins on the transceiver should be tri-stated, and that sawtooth must be the pullup resistor. If I remove the pullup and the sawtooth is gone, that is the smoking gun, and the problem is that *nothing* is driving the bus during that cycle (basically what @HudsonArcade implied). Maybe a problem with the OE* of that bank of RAM? Might have a chance to prove this out Sunday night after I get back if I don't sleep for 18 hours straight.
 
Back
Top Bottom