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