Hello and welcome back.
If you follow the channel, you already know that my HP 9825, famously used by Mr. Fancy
Pants in the HP catalog, recently died from a power supply failure that caused an over-voltage.
The 5V temporarily became 13V, with is a big ouchy if you are a TTL chip.
In the preceding episode, we hooked up the logic analyzer to help us out.
We quickly found that the processor could not read the code in the ROM.
We found and replaced some bad logic chips, but it still did not boot.
We were also mystified by our logic analyzer traces.
With so many failures, it’s hard to tell what a good signal is, or if we are even measuring
it properly.
So we brought out a working 9825 to helps us sort things out, and make sure our measurement
setup is working correctly.
So we have hooked up a second 9825 that works - we're cheating.
Okay, using the working 9825 I think I straightened it out.
We were not configured properly on the logic analyzer.
But let's take a new trace and we'll get a clean startup trace.
There we go.
So this one is working, it has started up, we got the lazy T. Turns out there were a
whole bunch of mistakes on the ROM probing.
Some lines were at the wrong place, some were inverted.
So I implemented a much cleaner probing solution at the ROM.
Plus the demux of the bus on the logic analyzer was set up improperly.
As it turns out, in HP nomenclature the slave clock has to appear before the master clock,
not the other way around.
Go figure.
Anyhow once that was all straightened out, the traces started to make a lot more sense.
So it's in timing mode, so it takes many many steps for the same thing.
We should get both data and address multiplexed on that bus.
And we see that happening.
You see the bus toggle from address to data.
It starts at 0 here, and it correctly goes to address 040.
Then this STM, which is the main signal controlling memory, goes down, and transfers the address
to the ROM right here.
Then a few steps later you see the ROM putting out the data.
Actually it ends with 041 - I only probed eight bits not 16 bits.
And then a few steps later you see the full data - the 16 bit is actually 164041 in octal
- coming back on the bus.
So we can finally see the bus multiplexing happening exactly as it should, which I explained
in the previous video.
I was also able to capture a clean boot sequence from the working machine, which confirmed
that our interpretation of the firmware was correct.
And we can see what a clean boot up looks like.
At zero it reads 164041, so that must be a jump instruction, I suppose.
And then it goes to next address 041 and it reads 10 000.
And that's the address where it should jump.
And sure enough, it jumps at 10 000, when it starts to read 177.
And once again we see that the ROM got the correct address and spat out the correct data.
So if we can have the sick machine replicate this, we're golden.
So now I’m back probing the dead machine with a setup that works, and I should be able
to take reliable data.
All right, so let's see in the listing if we got something.
Oh, wow, you can tell what's not working right away.
So it goes at address 40 and we can see that address 40 is correctly latched as the ROM
address.
Now have my wiring correctly done.
But i get no data out of the ROM!
So it reads 377, which is the octal equivalent equivalent of FF.
And then it goes to the next address and it reads 377 again, and then to the next address
and so on and so forth.
Yeah, so either the ROM zapped or the ROM is not enabled on one of its two pins.
Which we could check.
Okay, so I have an inkling that my ROM never got selected, and there's only two signals
that do it.
One is STM', but we just repaired this one, it came out of the two circuits we replaced.
So now it's good.
And the other one is the address decoder over here.
So for the ROM to be selected, they have to be zero both at the same time, at some of
the time.
So one, two, three...
And... yeah!
So how come?
It could be that the RAM output is pulling it high, it could be that the buffer input
is pulling it high, or it could be that my ROMs have been all zapped by the overvoltage.
At this point, I'm thinking it may be good just to swap this board out, see if it boots
up with a good board.
At which point we know that the damage is only in this board.
But if we swap the board and it's still not booting up, then it means that not only this
card has had multiple failures, but the other cards have had multiple failures [too].
And then it's going to be super extra difficult.
Okay, that's a little bit of a hail Mary experiment.
I swapped the ROM board and we'll see if it boots.
And no boot.
Ah!
Same failure!
It doesn't read anything out of the ROM.
So it's caused by something else.
That is quite interesting.
So I put the original board in the good 9825.
Let's make sure I haven't destroyed it.
I have not, it boots.
Okay, so putting that board in this one makes it fail to read the ROM.
Well, that's a great piece of information that we got by board swapping here.
I think there is actually good reason for something in the machine
to block access to ROM.
And to understand it, you have to must first know about the different versions of the 9825,
basically the A, the B and the T.
Although this says B, this is actually a T,
and you only know it's a T because it's written under the the door access for the paper,
or in the hardware because it has this extra board.
So he story goes like this.
At first, HP created the 9825A.
The processor inside could access an immense 16 bits of address space of 64k, but the A
had little RAM and little ROM so it was not all used.
So HP looked at it he had created and thought it was good.
But of course, HP had also to create the 9825 user, which at first loved the machine, but
then quickly complained that it did not have enough RAM.
HP then decided to create the 9825B, with more RAM and more ROM.
And actually, what a B is, is a T without this board.
I’ll talk about later, but I’ll remove it for now.
So here is a B. So it has 32k of RAM, and actually over 32k of ROM, which you cannot
use all at the same time because the total has to make 64k.
So there are some switches that allow you to swap out which ROMs are used.
And also, there is even a switch to make you use less RAM and more ROM.
And HP looked at what it had done and thought it was good.
But by that time, the HP user must have eaten a bad apple, and complained that it wanted
even more memory.
That’s when HP came up with the 9825T, with is the addition of this card here, which adds
32k of memory.
But where do you put it in the address space?
You already have maxed it out in the B version!
So at this point, HP makes a pact with the engineering devil, which has come up with
a solution that is, of course devilish: the extra RAM address space will overlap the ROM
address space of the board below.
But of course you can’t do that on a normal computer, how did the devil make this work?
So he relied on the fact that he knew every instruction the firmware was running, and
therefore was able to predict if the memory request the current instruction was issuing
was for RAM or for ROM.
And actually there's a little bit in that ROM over here that tells you what type of
instruction is currently executing, and if it's supposed to address RAM or ROM.
So in practice it's way more devilish than this, and there's a whole state machine that
takes most of the board.
So the RAM is right here.
This is the RAM.
And the rest of the space here is this devilish hack that puts RAM on top of ROM.
And the way it works is, when the devilish logic determines that it's a RAM access instead
of a ROM access, it sends a signal to the ROM board that disables the ROM entirely.
And I have an inkling that this might be what's happening here, is that my logic here is fried,
it has so many TTLs, the chances are pretty good.
And it's preventing me to access the ROM by disabling it.
And to verify that, it's not that hard.
All I have to do is to remove the board.
And then I revert back to a B machine that doesn't have the disabling of the ROM.
And see if we can regain access to the ROM.
Well you guys missed another good one.
I put the board back, the board that had failed before in the failed 9825, and it let the
magic smoke out!
This circuit burned up!
The chip that burned up is U37, which is an AND gate.
But I had changed something: I moved the switch from 64k to 32k, trying to run it without
this board, in case that was causing the disabling of the ROM.
And it turns out that this switch is connected to U37.
But man, a gate is not supposed to burn up if you change an input to it.
This is crazy!
Yeah, here we go.
Here's my blown gate.
These are the three pins where it was connected.
So obviously some TTL chips have been fragilized by the overvoltage event.
Which makes you think if we should replace them all, which would be a huge and very risky
job.
But maybe that chip was also causing us the ROM trouble, so we go back to the usual config
with all the boards, including the extended RAM board, and try it.
See if it has improved things any.
I don't think it will.
So Carl has returned, and we are going to make the experiment after we replaced the
blown circuit, and see if we still get this non-readable ROM that we don't quite understand.
So ready?
Okay.
So we see this line, the select line, it's selected, right?
Why is it at zero before POP?
It shouldn't have been asserted.
So it's still not working of course.
However, Carl spots something strange in my data.
All along we had seen the ROM properly selected and it was putting out no data, which is very
strange.
Now Carl is starting to doubt my measurement.
I don't know, static logic?
Yeah maybe that's just that.
I don't know, or I'm not measuring it correctly.
That could be.
We discovered that this was not pushed all the way in, so that would explain why it was
at zero.
So maybe it's not selected.
That would make so much more sense.
I hope it's going to go high.
Ready, set...
It's high!
Yes!
The world makes sense again!
Okay.
So my ROM chip was never selected.
Right.
And probably because of the other board, probably because of ROM enable.
I would just start moving the scope.
Phew!
All right.
Finally we have a big bad fault that's understandable: it's not selected.
And we suspect that the decoder is not selected itself.
So I'm on that, U46 pin 2.
That's that fellow.
That's the red trace, which I better enable.
And make sure it's plugged in [laughter].
And that should be low.
It should be low for this decoder to work.
Yes, all right.
Ready?
Three, two, one, go.
I'm not ready.
Three, two, one, go.
It's high!
Okay, the world still makes sense.
It's not enabled.
So now check pin 11 of 50.
So now we go back to the gates before, pin 11 of 50.
All right, and that should be high.
It should be high.
It's a pull-up by a resistor, so it better be high!
Oh, but it's the same switch that blew my other chip, so...
All right, three, two, one, and it is low!
Thus ROM is being disabled.
Yeah, so thus I have no ROM.
And that's why it also made my...
Well but it has to be low not from the switch.
It has to be low from the input from something else.
Right from off-board.
Right.
So 24.
ROM disabled.
Yeah, that's the A[2]5.
So that's the experiment I was doing.
I think that goes to - this goes to this board.
And I removed the board, and I changed the switch, which I'm not sure I should have done,
and that blew my circuit.
So we're back into - oh why don't we just get on that board and see what happens there.
After having blown my circuit, I am still a little bit weary of running the A24 ROM
board all by itself, so we decide to swap the top RAM board with the one from the good
machine instead.
So if it's a single failure from this board, then if we put the other board, it will work.
If it's a multiple failure across, then this won't even work.
Single.
Running?
Running.
One, two, three... and it booted!
No, it booted not!
But it's not FF anymore.
Right!
So, we have multiple failures.
It did not boot.
But it goes up to 10 000!
But it does the boot code.
Right.
So this was it, the top board just zapped the other board.
Okay.
Yay!
Finally, the processor reads ROM and executes code.
It starts at 40, reads 41, and jumps as it should to 10000 to the init code.
Actually, it executes a lot of code, which is comforting news - the processor is likely
functioning pretty well.
So now we must analyze the traces and try to figure out where and why it gets lost.
And as you’ll see in the next episode, it’s pretty subtle.
See you then!
So it left at 010101, it should have returned at 010102.
And surprise!
It returns at the wrong place!