Malfunctioning VT240 - help please

Charles charlesmorris800 at centurytel.net
Thu Jun 11 09:14:59 CDT 2020


On 6/11/20 2:29 AM, Mattis Lind wrote:
>
>
> 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 board!
>
>     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

=========

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.

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?

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.

My fear is that one of the PALs has altered itself from tin-whisker 
migration (fuse regrowth) :(



More information about the cctech mailing list