11 Jun
2020
11 Jun
'20
12:44 p.m.
On 6/11/20 10:31 AM, Mattis Lind wrote:
===========
The T11 is not halted - it's looping endlessly in the first ROM. There
is a brief burst of DRAM select activity on the scope just before it
hangs in the loop.
All the glue logic and memory map adders/multiplexers seem to be grossly
working with outputs that change state. I was hoping to find a bad or
immovable line on one of them... Now this makes me even more suspicious
that there is a bad address (or block of addresses) in RAM and that's
where the test is hanging.
My 7D01 (16 channels) is hopelessly outclassed here. I looked at that HP
1661 but it does not appear to come with the probes, which are so often
discarded by surplus or scrappers. (A similar aggravation with our
classic computers, of course).
Unfortunately I only have one 27256 in the drawer, so have to order some
more before making memory test PROMs...and I also have to figure out a
simple way of outputting the RAM failure address!
Now that you know the T11 is good I think it a good idea to
attach a logic analyzer on the bus.
I would then disassemble the ROM code and match that with the
logic analyzer execution trace. Then it should be possible to
find out what is going on. If one can rely on the fault code on
the keyboard it is able to pass tests 0 to 4 successfully. Of
course I have no idea what these test really do but assuming they
do some more than advanced things I doubt that they would work if
there are severe bus contention.
If that would be the case I think the system would fail quite
soon rather than on test 5. A guess is that this is a memory
problem.
Good luck!
/Mattis
=========
Thanks for the tip. I didn't see in the manuals that the keyboard
light pattern was actually a binary code, but that makes sense! I
would have expected an error message on the screen, but as I
previously noted, the video system itself does not seem to be
working properly.
The VT100 also makes use of a binary code for the very early errors
like ROM and RAM faults so assuming the same behaviour here is not
that far fetched I think.
Unfortunately my logic analyzer is an ancient Tek 7D01, the
equivalent of stone tools rather than metal ;) It's not really
suited for doing this kind of work, but it's what I have... I
wonder if anyone has already disassembled the code?
Yes. The 7D01 was older than I expected. I thought maybe a HP1630 or
possibly 1615 which is old...
I guess that the memory depth of the 7D01 is not that much.
Assuming that the CPU does a HALT when it stops it should stop
reference memory so if you let your logic analyzer just store all
addresses until it stops you might be able to find the last (whatever
memory depth you have) instructions. Use the memory strobe to clock in
the address into the logic analyzer. Then you can do hand disassembly
of this part. Or load it into Ersatz-11 and SimH and do the disassembly.
But maybe it is a good?idea to find a slightly more modern LA? Maybe a
HP 166x (There is one 1661 on Ebay at $70) which is quite portable and
easy to use. Or HP 167x which has much better memory depth.
The 4116's are soldered to the board, too. Since the memory map is
shown in the tech manual I could write a simple memory test and
burn an EPROM.
Yes. That could be an alternative. Maybe you can figure out how to
communicate over the serial port. Perhaps you can write something
simplistic that outputs something to the serial port?
My fear is that one of the PALs has altered itself from
tin-whisker migration (fuse regrowth) :(
That could probably happen. But I have seen more cases with failed
memory chips than PALs that have self-altered.
/Mattis