The first two pics below are definitely in the 'not helpful, shut up' category. CPU emulator pods for the 6809, 68008, 68000 and 68010 CPUs. These work with a HP 1630G logic analyzer (and the disassemblers on disk), and I got a lot of use out of these over the years. Too bad you don't live nearby, as you could borrow them. But not going to ship overseas.
What might be helpful, is a tip for looking at digital system bus, with a simple hack that lets you see where individual bus lines are tristate and where driven.
Normally when you look at a running bus with a scope (or logic analyzer) when a line is floating where it should be driven, you can't tell. Because the intervals are so brief that the signal just drifts at approximately whatever last voltage it was driven to.
The last pic is of a couple of improvised 'does it float?' probes. Each one has two wires to the tip; one direct and one via a 1K resistor (inside the probe, next to the tip.) Yes, they are made of biro pens, and the tips are gramophone needles soldered into the brass pen point. In use you connect the direct one to a scope input, and the 'via 1K' wire to the output of a signal generator. Set the sig gen to sine or triangle output, with the p-p range between zero and 3V (for 5V TTL), and freq doesn't matter much. Say 10KHz.
When you put the probe on a bus pin, the 1K series resistor is too high to upset the correct logic drives. (Actually one of those probes has a button to select between 10K and 1K series R, for picky circuits.) But when the bus line is floating, the oscillator drives it up and down, async to the bus operation. This should not make any difference to the digital system's normal operation.
Visually on the scope, the result is that tristate intervals on the bus look 'shaded-in'. It's very obvious,and quite useful.
You can run along the address and data bus, and look for any that seem particularly different to others. Best if you can trigger the scope on some CPU action, such as reads or writes to a particular device.
This little thing is good for when looking at something for which you have zero documentation. Like your Harriet.
Btw, I checked and couldn't find any info on it in my archives.
Oh, and you can look up the data for major chips on the board, find which are their chip select lines, and use a logic probe or scope on single shot, to see which ones are ever accessed during startup before the bus fault. If you can find one that is accessed right when the bus fault occurs, that should be a good clue. Can do this with a scope: channel 1 & trigger on the CS, ch 2 on the buserr. Which might be asserted some way into accessing the chip (or address range.)
Can you tell if the ram banks have parity error checking?
I think the worst case could be that one of the many PALs has died. Something to do with address decoding or bus logic. Have you checked the usual bitsavers, etc sites to see if anyone posted data on this machine?
Edit: forgot to mention that the oscillator hack works with an analog scope, that visually averages many traces. Digital ones would need to be set to an equivalent averaging mode, if available.
Home
Help
Search
Login
Register
