On 6/11/20 2:29 AM, Mattis Lind wrote:
torsdag 11 juni 2020 skrev Charles via cctalk <cctalk@classiccmp.org
<mailto:cctalk@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) :(
