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@classiccmp.org> wrote: > > 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) :( > >