Hey David,
fancy "meeting" you here, somehow I feel like I owe you a drink
.
I haven't replaced the RAM yet, as I'm still waiting for the parts. I made the mistake of getting USPS "Express" delivery to the frozen tundra of Canada-land - they might show up tomorrow, or never.
I have however sucked the old chips out, cleaned up and installed sockets, so I can swap them around and run with/without. If the RAM chips themselves are bad, this might clear up once I get new ones - though I'm still hard put to explain why it'd get wobbly when I populate one particular ROM socket.
I figure at this stage I'm debugging borked TTL-level logic, more so than a Tectronix scope, per-se, so might get useful hints from here...
I think the address buffers are fine, looking at the signals they seem quite clean and robust, and all the dowstream address decoding seems to work just fine.
The data buffers are reasonable suspects, as are perhaps the outputs from all the memory devices. I've looked across the data buffers by differentially probing their ins/outs and they look just fine. I can only really look at the read direction with the kernel tests and a regular scope. Now that you mention it, one mode of fallout due to the corrosion could have been RAM and data buffers fighting on write cycles.
Perhaps it's worth putting the logic probe on them, see whether the reverse direction is borked - or I might just switch them out. I guess a soldering iron is sometimes quicker than a logic probe
.
Assuming that e.g. a CS line has shorted to another signal with the corrosion gunk on there, then I would have had two or more memory devices, and/or RAM and data buffers waging war on the data bus.
Would the device outputs usually survive this, or would I likely be looking at burned-up outputs?
Any practical difference between the ROMS/RAMs? The NVRAM is a CMOS device, the other one is TTL, I believe - any practical difference there?
I figure if the ROMs are baked then this'll get a lot harder to debug and fix, though I might rig up something to read them and see whether they checksum OK or something. From looking at the data lines under kernel test, they do look OK, e.g. I don't see any lines wedged high/low or undriven.
It's kind of cool being able to look at the address space in the time domain - there are neat troubleshooting features in those scopes.
I have to admit that the 2430 isn't as viscerally pleasing as the 2465/2467s.
When I bought it, I was under the impression that it was dual path, e.g. a 150MHz analog path as well as the digital path. Turns out it's all digital display, although the details are still pretty fascinating to me. Using those CCDs for capture and storage, then digitizing at a much lower rate seems like a pretty scrappy thing to do.
I guess the killer feature of this scope at the time must have been pre-trigger signal display, cause there's not much else to it?
Siggi