Light Outrun Restoration

  1. I had broken the RAM0 trace and didn't realize that it severed the connection to both IC115 as well as IC130, so I added a jumper.
  2. The RAM1 trace was also broken so I had soldered a jumper to IC141. After looking at the datasheet for IC141, I found that what I thought was a 9 on the schematic was actually a 7.
So for IC73, I socketed it with no damage (now that I have a desoldering gun and hot air station!). I put a known good IC in for IC73 and get the same error. I also put the suspect IC that was originally in IC73 into the IC129 socket and there was no error.

Is anyone familiar with what causes the DEV (Device?) error? Apparently, the address and data lines check out, but some other error is detected? I thought maybe a bad buffer or something, but IC73 shares all the address and data signals with IC72 and shares all the control signals with IC55, both of which are working. I guess I could check the voltage of IC73 or put a scope on the address and data lines to see if there is noise or a slow rise time on any of the signals.

In any case, I put the original ROMs back in and things are much better. I won't be able to see what sort of problems IC73 might cause until I reassemble the cabinet.

1762829240853.png1762829271796.png
 
The DEV test writes to RAM and checks it, it's possible that some area of the RAM is bad, I guess you will need to play a game to check it out. Or, change with a known good one and see if it passes.

Good job on figuring the issues out!

p
 
The DEV test writes to RAM and checks it, it's possible that some area of the RAM is bad, I guess you will need to play a game to check it out. Or, change with a known good one and see if it passes.

Good job on figuring the issues out!

p
Thanks! I did put a known good part in and it failed. Also put the suspect part in IC129 and it passed. I'm going to put a scope on it tomorrow to see if there is any noise or other unexplained behavior.

Any idea what the number is after the failure? I didnt see anything in the docs, but maybe there is something that explains it in the source code.
 
I am not sure exactly what the number in the DEV test means, but likely relating to the address the error occurred.

p
 
I am not sure exactly what the number in the DEV test means, but likely relating to the address the error occurred.

p

That makes sense. I looked things up and IC73's address space starts at 0x26000. I tried 6 different RAMs consisting of 3 different part numbers and they all failed a 0x2669B4. It's really weird that it always fails at the exact same location. Or more likely it's not weird, I just don't understand what is going on yet. :D Maybe that is just the first place in RAM that it stops the test for that IC and reports an error.

So, I took a look at the data lines on IC73. This is DDB15 on pin 19. What the hell is that sawtooth doing there?!? (The scope is grounded directly to pin14 of IC73) This was on all of the data lines of IC72 and 73. It is not on the address lines and it is not on the data lines of IC129/130. (I don't recall for sure, but I think it was on IC54/55 data lines) Any chance you have a board on your bench that you could look at the same waveform?



1762880831020.png

This is the same pin on IC130. Different time scale, but you can see there is no sawtooth.

1762882208195.png


These signals run through at least 2 EPROMs and 2 RAMs so I went upstream to the source of the signal, pin 2 of IC59. (Taken at a different time, so the pulses are not expected to be the same)

1762881233695.png

So the farthest upstream I can go is directly to the 68000.

This is pin 5. Pretty noisy... I need to overlay the 2 signals, but I think this explains the sawtooth coming out of the buffer.

1762881426323.png


I looked at the power and ground of the 68000 and there was nothing interesting, so I went for broke and swapped the two 68000s. No change, still fails at the exact same address, 0x2669B4.

I ran out of time before I had to leave for work, so I still have a lot of ideas to investigate. Maybe there is a bad decoupling cap somewhere that is bad. I see a 10 uF tantalum on the 68000 VCC. Also what looks like a ceramic in the schematic, but... I can't tell the value.

Stay tuned...
 
Well, I pulled the 10 uF cap and checked the value/ESR. Seemed ok, but I swapped it with the other 68000 cap and no change.

It was a long shot, but I thought maybe a cold solder joint on a 68000 ground or something would cause transients, but I removed and resoldered all the solder joints of the socket but no change.

I verified that the address lines on the 68000 are super clean. This is address A19 for reference. (pin 47)

1762912400457.png


It is only the data lines that have this transient. The transients seem to be highest at pins 1 and 64 and go down in amplitude as you move from the top of the chip down (top being the end with pins 1/64)

Pin 64 (D5)

1762912066809.png

Pin 1 (D4)

1762912602472.png

Pin 54 (D15)

1762912228776.png

I'm outta Schlitz for now. The frequency of the transient is ~2.4 Mhz and seem to be in almost perfect phase of the data clock. Need to walk away and think about what else might be going on.
 
I realized last night that I might be thinking about this entirely backwards. I noticed that the transients on the data lines stop very periodically. Below, the green is a data line and the red is AS (Address Strobe). AS dosen't show any correlation with the stops in the transient, so I kept poking around.

1763040282788.png

This is the same plot zoomed in and the RW* signal added. The transients stop when RW* is low, so the transients only occur when reading, therefore, the 68000 can't be driving the lines because the buffers are reversed and the memory data lines are inputs and the 68000 lines are outputs.

1763040618444.png

Therefore, the source of the noise is on the input of the buffer here.

1763040873890.png

The slew rate on the saw tooth is slow, so whatever it is driving it must have some impedance between it and the data line. Maybe one of the EPROMs or RAM isn't fully tri-stated on its data lines when it is not being read? I guess I can pull each one tonight and see if that is the case. It also could be something weird on the chip selects not holding the device in a disabled state. Or even a resistive short to some other signal that is high more often than not.

If I can't find the problem with one of the memory ICs, I also thought about putting a weak pull down on the line to see if it goes away. I need to see how much the outputs of the ICs can source so I don't blow one up with too low of a resistance value. If this works, it won't solve the problem but could validate that the sawtooth is the root cause.
 
Not much progress last night, but this looked weird. Bottom is the data line of the processor, middle is the data line going into the buffer, and the top is the CS* for one of the banks of EPROMs. None of the other CS* have than RC hump. I wish it gave me insight, but I this is only one one bank of memory and the sawtooth is on all data lines. I also don't think 4 volts would be low enough for the IC's to see a low signal on CE*.

1763124975347.png

I did pull one of the EPROMs to see if it was the source of the sawtooth, but no luck. I can't pull the other EPROM or nothing boots. There is one RAM left that I could socket but want to think this through more.

Unless it is some kind of coupling, it must be something common to all the memory on this processor because it is on all the data lines. It only affects one bank of memory, because the sawtooth amplitude is lower.
 
Back
Top Bottom