Malfunctioning VT240 - help please
Doug Jackson
doug at doughq.com
Mon Jun 15 06:29:59 CDT 2020
I remember testing memory chips with a thumb. The one that took yoir
fingerprint ofd was always faulty.
Hopefully it's not whisker regrowth. That would be really frustrating.
On Fri, 12 Jun. 2020, 12:15 am Charles via cctalk, <cctalk at classiccmp.org>
wrote:
>
> 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 cctalk
mailing list