Malfunctioning VT240 - help please

[Charles]

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!