Malfunctioning VT240 - help please

torsdag 11 juni 2020 skrev Charles via cctalk <cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>>: On 6/10/20 4:31 PM, Jon Elson wrote: On 06/10/2020 12:48 PM, Charles via cctalk wrote: That leaves the unlikely possibility that one of the octal TTL devices, or ROMs. has developed a weird internal pathway that only interferes with DAL3 & 1 on some bit patterns, but not all the time. Seems like a zebra rather than a horse. The only part that drives multiple low-order DAL lines at once besides the E19-22 ROMs is the E55 LS245. Quite possible that this could happen when a specific device is driving the bus -- or that NOBODY is driving the bus in that state. When it is stuck at the ~1V level, try a resistor of about 1 K to ground on one of those lines. If it moves several hundred mV lower, it is a TTL open circuit. If it doesn't change at all, it is a bus contention (TWO drivers driving at once). Jon After much Googling, I discovered/remembered that the RQDX3 M7555 floppy controller card in my PDP-11/23+ system has a T11 CPU on

So I pulled the card and popped the T11 into the VT240. Guess what - the terminal still doesn't work!! Craptastic. At least it's not the most expensive and rarest part on the board... but now I'm really stumped. This isn't my first rodeo - in fact back in the 80's I used to design microprocessor systems for a living, and have continued to keep my hand in repairing my video arcade games and a PDP-8 system, among other projects. Meanwhile... the T11 DAL lines are only connected to a few parts that can drive onto that local bus. Time to have a look at the glue logic for the DRAM selects. Although the ROM chip selects seem to work, maybe the DRAM or something else actually IS conflicting despite the mixed signals (pun intended) ;) Time to break out the logic analyzer, and start burning pairs of 27256 EPROMs with test programs. Maybe initially just fill them with NOP's (000240 octal) with a jump to zero at the end! 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