On 6/11/20 10:31 AM, Mattis Lind wrote:



    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

===========

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!

Reply via email to