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 finally understood why the ROM could not be read. It was due to a
fault in the 32k RAM extension board that disabled ROM access. After we swapped it for a known good
one, the processor regained access to the ROM on the other board and attempted to boot in earnest.
It still failed, mind you, but not after having executed a lot of code. That’s a big step. The
logic analyzer trace should give us a clue as to what is going wrong.
Our first step of course is to printout a listing of the trace, on none other than our
trusty HP 2225A, the word’s first, and arguably still one of the best, consumer inkjet printer.
So we're making progress. We finally got the processor to see its ROM
and execute some code. It still did not boot and it ended up in the loop, we can see it. But we can
sort of follow through and figure out where it gets stuck. And fortunately, another enthusiast,
Craig Ruff, disassembled the system code. The source had been published, mostly in a patent. And
so, the pattern had the code and the comments, and it's not exactly the code that's in the
real machine, but very very close. So by disassembling the code of the real machine
and looking at a patent, Craig got an almost fully commented code, and we can follow it along.
So it starts correctly at address 40, as expected, from reset. It does the jump to 10 000, perfect.
And at this point, it jumps to the first subroutine. And I can see it in the source code
right here. It hits the "jump subroutine". It should branch to 15246. And before it branches,
it stores the return address. So it stores where it is right now, which is 10101,
and it stores that in this location of memory: 77633. Everything goes fine, and the end of the
subroutine is right here. And that's the return instruction. So in order to return,
it's going to fetch the location that it came from, which we had stashed into RAM at address
77633. And surprise! It's not the number we had put there! We had put 10101, and now it's 10077!
So it adds one to this, which turns out to be
10100. It's now returning to the instruction before the jump!
So it goes back just before the jump, hits the same error again, it goes back here. So it's
stuck in a loop! I think it's a memory error: what it reads back from memory is wrong by a few bits.
All right. Fantastic. Now that we repaired ROM, we discover that RAM is not working properly,
of course. But I don’t think it means our RAM chips are dead by any means.
Since we have only a few bits wrong, I’d bet you my weekly allocation of bananas that it’s the
memory refresh that’s not working properly, and that our memory is simply loosing bits.
But before we even go there,
there seems to be something even more wrong at the very beginning of our startup trace.
I discovered that we might have an even bigger and earlier issue in the boot up sequence. At boot up,
very early on - that's like the third thing it does - it's going to read the system status.
Which is, I believe, a register in the keyboard interface. And then it's going to look for the
power-on bit, to figure out if it's a hot boot or a cold boot. So, on a cold boot, which means you
just powered it on, it's going to do an extensive initialization. But if it's a hot boot, meaning
the reset button on the keyboard was pressed, it's going to do a much shorter initialization:
not even bother to erase memory, try to keep your program and all your pointers where they were.
And when you look at the code here, it takes the wrong branch! This is a cold boot, we just powered
it up. And it reads the keyboard, and it gets the wrong bit! I thinks it's a hot boot from the reset
key, which we haven't pressed! So, instead of launching in the regular initialization, it's
going to launch in a short one. Which of course is not valid if we haven't done the proper setup.
So before we incriminate our memory here, we have to fix this.
And I think we need to add the keyboard to the list of things that don't work on our machine.
So great, the keyboard, which is another complicated thing with it's custom HP
chip on it, is also on the list of casualties now too!
[Gene Kranz from Apollo 13 scene:] So let's look at this thing from a, from a standpoint of status.
What have we got on the spacecraft that's good?
Well Gene, uh, I'd say not much... There is not much that's good.
All right, so we suspect the machine is not booting correctly because the keyboard was bad,
because it gave it a keyboard reset when it shouldn't have.
So we put the good keyboard from the good machine. We still have the good A25 memory card.
And now we are going to try to boot it.
Didn't come up.
Okay we can - we print that out and see what happened.
So, this time we get an even better trace. So now it's seeing the keyboard, it's doing
the right branch, it falls into the correct initialization. And it goes about checking memory.
And we can see that it finds - at least part of the memory is fine. So this is all
memory checking. Then we jump [to] when it stops seeing good memory.
And that's at address - where is it? - 60000. So it thinks it has
16K of good memory. It should have 64! But it's the 16 that's on the RAM/ROM board. But
that memory has been thoroughly checked: it's been written and read with alternate bit patterns. So,
that's good memory. And then it goes further! It goes up to the main loop! So
at this point, it should have booted up! But we still see nothing on the keyboard.
So what I think is that it's on the verge of booting, and if it had good
memory it probably would boot. And it also reinforces my thinking from before,
that the memory, if you do read/write just a few instructions apart,
it retains memory. But I bet you [that] if you write it, go to [a] subroutine and come back,
it will have lost it. So it looks to me like it's definitely a refresh problem.
It looks like it does - it goes all the way almost through where it goes into the main
loop. So it boots up correctly. Still don't see anything, so not having any better ideas,
I put the - I swapped out the A24 board, the RAM/ROM board that we're trying to debug,
and put a good one. So it has a good keyboard. a good A24, good A25. And if that boots,
then the processor is good. It looked very good in the traces. And it sure is good!
Uh, 13, this is Houston. Uh, we think your processor is good.
Yeah, just the processor.
The keyboard, the reset definitely is bad, and we have a bad A25, a bad A24.
Which is - except for the keyboard, the keyboard has a proprietary chip. But the memory boards,
they don't have any proprietary chips, they are just normal. So we have bad
memory somewhere. And I don't think it's bad ROM, right? So it's something in that refresh
logic that's not doing fine. SO we think it's losing its memory.
[2001 Space Odyssey scene:] Dave, my mind is going. I can feel it.
And Carl and I were just going [about] making our way through the board,
and trying to find why the refresh was not working. And all of a sudden,
it started to only do a few instructions, and quit. And we thought it was doing ROM - well,
we knew it was reading ROM, even on the bad board, and going through quite a few instructions.
And then, we looked at it on the logic analyzer. And we can see that the first fetch at address 40,
it reads 164 001 instead of 041. So it goes in the weeds right there.
On the ROM itself, we go binary.
And you will see that the "4" bit of the second digit is always zero. Zero, zero. If I put my
cursor right here, you'll see nothing but zeros. We've lost a bit in the ROM! It's always zero.
So now, not only our RAM is bad, but the ROM that we repaired has lost a bit.
So that's the problem, we have to repair it faster than it breaks! We are not fast enough!
So it seems that we have a disaster of Apollo 13 proportions on our hands, and it’s getting
worse by the minute. Will this end well or will the circuits burn up upon re-entry?
Well, as of the editing of this video, this is as far as we have gotten,
so we still don’t know. In the meantime, I’ll tell the crew to take refuge
into the processor. Because our good HP processor, you know, it still works!
So the whole thing might be fragilized, and we have to repair it faster than
it dies [laughter]. [Carl:] Or just do a mass replace of all the chips.
You know, it might come to that, right? I think, if we weren't so stubborn, that would
be the more logical thing to do. [Carl:] Or just toss it out, put in a replacement board.