Re: Malfunctioning VT240 - help please

[Charles via cctalk]

On 6/21/20 10:41 AM, Jon Elson wrote:


On 06/20/2020 09:41 PM, Charles wrote:

On 6/20/20 8:31 PM, Jon Elson wrote:


I confirmed the bad one by removing the piggyback and the failure 
returned. Now I need to desolder the bad one without ruining the 
board. I may just cut the leads off close to the bad chip, and 
solder the replacement to the stumps. (Normally I remove the legs 
and install a machine-pin DIP socket). Or just solder the piggyback 
and leave it there... thoughts?


Cut the leads close to the body.  Apply a soldering iron to each 
lead, and pull the lead out with tweezers,
simultaneously heating and pulling.  This is very gentle to the 
board, just doing one at a time.  Then, you can vacuum out the holes 
and install a new chip or socket.


I've done this many times, and never wrecked a board.

Jon

That's how I do it... the vacuuming is the problem. Someday I need to 
get a good vacuum desoldering station. Right now I just have a 
spring-loaded solder sucker (which I can do a pretty decent job with 
on most boards). But this high-density layout (2 traces between DIP 
pads) I'm a bit wary of.


Just be gentle, and you should be able to do it.  Also, in some cases, 
you might heat from the opposite side from the solder sucker.  That 
way, you can keep the soldering iron on the pad until you have 
triggered the sucker.  But, yes, the hollow soldering iron with 
powered vacuum is amazing the first time you try it.  I got one at an 
auction years ago, it is much better than the regular iron and 
plunger-sucker.


Jon


The small company I first worked for had a Pace unit. I remember not 
being impressed with it - frequent clogs, pads lifting, and not getting 
all the solder out, no matter how we set things. Still beat solder-wick 
though!


I got it done, but pin 16 (which connects directly to the internal-layer 
ground plane) was a bear. From the feel of it and the heat required, the 
draftsman didn't bother to make pad reliefs. Anyway it's now socketed, 
so of course it will never fail again!


I also made a small jumper on a 15-pin D-sub to connect Monitor Present 
L to ground, so that annoying "Monitor Error 9" message stops ;) On to 
the next project!

Re: Malfunctioning VT240 - help please

[Jon Elson via cctalk]

I confirmed the bad one by removing the piggyback and the 
failure returned. Now I need to desolder the bad one 
without ruining the board. I may just cut the leads off 
close to the bad chip, and solder the replacement to the 
stumps. (Normally I remove the legs and install a 
machine-pin DIP socket). Or just solder the piggyback and 
leave it there... thoughts?


Cut the leads close to the body.  Apply a soldering iron to 
each lead, and pull the lead out with tweezers,
simultaneously heating and pulling.  This is very gentle to 
the board, just doing one at a time.  Then, you can vacuum 
out the holes and install a new chip or socket.


I've done this many times, and never wrecked a board.

Jon

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

On 06/11/2020 02:29 AM, Mattis Lind via cctalk wrote:
>/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. /
That was a good guess, everyone ;) I got some new 4116's and piggybacked 
(dry, no solder) two of them atop my suspects at E3 & E4.


Didn't fix it. Of course :/

In the meantime I've acquired a nice HP 1630G logic analyzer complete 
with pods and cables. Setting it up was going to take quite a while 
since I'm not familiar with this model. So I decided to try a simple 
brute-force approach before the analyzer. I piggybacked another 4116 
onto each soldered-in 4116, one at a time. Actually easy to do since 
with the leads properly formed, I didn't even have to solder it in 
place, just turn off the power and move it to the next chip.


On the 16th, the last one of course, the terminal booted normally and 
works again. :)


I confirmed the bad one by removing the piggyback and the failure 
returned. Now I need to desolder the bad one without ruining the board. 
I may just cut the leads off close to the bad chip, and solder the 
replacement to the stumps. (Normally I remove the legs and install a 
machine-pin DIP socket). Or just solder the piggyback and leave it 
there... thoughts?

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

Make that "fuse-link PROMs". My mistake.

-Charles

On 6/15/20 10:41 AM, Tony Duell wrote:

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

I've finally looked at the printset for the VT240 and I must be
missing something

The only PALs I can find are the 'logic units' in the  video memory
updating circuitry. That circuitry is pretty much the same as  the
Rainbow colour graphics board and I suspect the PAL logic is much the
same too. I have the Rainbow's PAL equations if you need them but I
doubt that's the problem.

-tony

Re: Malfunctioning VT240 - help please

[Tony Duell via cctalk]

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

I've finally looked at the printset for the VT240 and I must be
missing something

The only PALs I can find are the 'logic units' in the  video memory
updating circuitry. That circuitry is pretty much the same as  the
Rainbow colour graphics board and I suspect the PAL logic is much the
same too. I have the Rainbow's PAL equations if you need them but I
doubt that's the problem.

-tony

Re: Malfunctioning VT240 - help please

[Doug Jackson via cctalk]

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, 
wrote:

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

Re: Malfunctioning VT240 - help please

[Nigel Johnson via cctalk]

One trick I found with the -5V if it is driven by  a charge pump: check 
the voltage. If it is being pulled down since the charge pump cannot 
supply the current, just disconnect the charge pump and put a lab supply 
in its place.  The increased current will clean out whatever is shorting 
it to ground without harming any good chips.  If you are lucky a puff of 
smoke will identify the chip. Otherwise there may be enough memory 
running to give you a diagnostic message to say which bit.


I did it once on an $1800 board, all chips soldered in, results in minutes!

cheers,

Nigel


On 11/06/2020 16:33, Ethan Dicks via cctalk wrote:

On Thu, Jun 11, 2020 at 2:37 PM Adrian Graham via cctalk
 wrote:

The 4116's are soldered to the board, too

You’ve just mentioned the magic 4116 word, I’d bet some of your dollars that 
it’s either one of those that’s gone south or the -5V required to run them

Definitely check the -5V for the 4116s.

-ethan


 


--
Nigel Johnson
MSc., MIEEE, MCSE
VE3ID/G4AJQ/VA3MCU

Amateur Radio, the origin of the open-source concept!


You can reach me by voice on Skype:  TILBURY2591

If time travel ever will be possible, it already is. Ask me again yesterday

This e-mail is not and cannot, by its nature, be confidential. En route from me 
to you, it will pass across the public Internet, easily readable by any number 
of system administrators along the way.
   Nigel Johnson 


Please consider the environment when deciding if you really need to print this message

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

On 6/11/20 3:15 PM, Mattis Lind wrote:


The T11 is not halted - it's looping endlessly in the first ROM. There 
is a brief burst of DRAM select activity on the scope just before it 
hangs in the loop.


 That burst of DRAM activity might indicate a DRAM problem. One thing 
I have tried in the past is to put a known good DRAM on top of one 
DRAM is the array. So to say in parallel. In the cases I have tried I 
managed to make systems pass the memory check. Then test each and 
every one in the DRAM array in the same way. Might be worth a try.




The 2681 https://www.nxp.com/docs/en/data-sheet/SCC2681.pdf shouldn't 
be to difficult to configure and is located on the same bus as the 
keyboard so you should be able to send something  on the UART to 
either the printer/aux or the host.




Thanks again. I have some 4116's on order too. I'll try the piggyback 
trick, and if it works, will desolder the offending RAM (and install a 
machined-pin socket!) I will probably never have to change it again - 
but the PC board wouldn't like another desolder operation...


If that doesn't work, then I'll start writing diagnostic software using 
the 2681. Of course then I have to debug the program before I can debug 
the terminal ;)

Re: Malfunctioning VT240 - help please

[Ethan Dicks via cctalk]

On Thu, Jun 11, 2020 at 2:37 PM Adrian Graham via cctalk
 wrote:
> > The 4116's are soldered to the board, too
>
> You’ve just mentioned the magic 4116 word, I’d bet some of your dollars that 
> it’s either one of those that’s gone south or the -5V required to run them

Definitely check the -5V for the 4116s.

-ethan

Re: Malfunctioning VT240 - help please

[Mattis Lind via cctalk]

> The T11 is not halted - it's looping endlessly in the first ROM. There is
> a brief burst of DRAM select activity on the scope just before it hangs in
> the loop.
>
 That burst of DRAM activity might indicate a DRAM problem. One thing I
have tried in the past is to put a known good DRAM on top of one DRAM is
the array. So to say in parallel. In the cases I have tried I managed to
make systems pass the memory check. Then test each and every one in the
DRAM array in the same way. Might be worth a try.

> All the glue logic and memory map adders/multiplexers seem to be grossly
> working with outputs that change state. I was hoping to find a bad or
> immovable line on one of them... Now this makes me even more suspicious
> that there is a bad address (or block of addresses) in RAM and that's where
> the test is hanging.
>
> My 7D01 (16 channels) is hopelessly outclassed here. I looked at that HP
> 1661 but it does not appear to come with the probes, which are so often
> discarded by surplus or scrappers. (A similar aggravation with our classic
> computers, of course).
>
Ahh. Missed that it lacked probes. That is a common problem unfortunately.


> Unfortunately I only have one 27256 in the drawer, so have to order some
> more before making memory test PROMs...and I also have to figure out a
> simple way of outputting the RAM failure address!
>


The 2681 https://www.nxp.com/docs/en/data-sheet/SCC2681.pdf shouldn't be to
difficult to configure and is located on the same bus as the keyboard so
you should be able to send something  on the UART to either the printer/aux
or the host.

>

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

On 6/11/20 10:31 AM, Mattis Lind wrote:





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.

The VT100 also makes use of a binary code for the very early errors 
like ROM and RAM faults so assuming the same behaviour here is not 
that far fetched I think.


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?


Yes. The 7D01 was older than I expected. I thought maybe a HP1630 or 
possibly 1615 which is old...

I guess that the memory depth of the 7D01 is not that much.

Assuming that the CPU does a HALT when it stops it should stop 
reference memory so if you let your logic analyzer just store all 
addresses until it stops you might be able to find the last (whatever 
memory depth you have) instructions. Use the memory strobe to clock in 
the address into the logic analyzer. Then you can do hand disassembly 
of this part. Or load it into Ersatz-11 and SimH and do the disassembly.
But maybe it is a good idea to find a slightly more modern LA? Maybe a 
HP 166x (There is one 1661 on Ebay at $70) which is quite portable and 
easy to use. Or HP 167x which has much better memory depth.


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.

Yes. That could be an alternative. Maybe you can figure out how to 
communicate over the serial port. Perhaps you can write something 
simplistic that outputs something to the serial port?


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

That could probably happen. But I have seen more cases with failed 
memory chips than PALs that have self-altered.

/Mattis


===

The T11 is not halted - it's looping endlessly in the first ROM. There 
is a brief burst of DRAM select activity on the scope just before it 
hangs in the loop.


All the glue logic and memory map adders/multiplexers seem to be grossly 
working with outputs that change state. I was hoping to find a bad or 
immovable line on one of them... Now this makes me even more suspicious 
that there is a bad address (or block of addresses) in RAM and that's 
where the test is hanging.


My 7D01 (16 channels) is hopelessly outclassed here. I looked at that HP 
1661 but it does not appear to come with the probes, which are so often 
discarded by surplus or scrappers. (A similar aggravation with our 
classic computers, of course).


Unfortunately I only have one 27256 in the drawer, so have to order some 
more before making memory test PROMs...and I also have to figure out a 
simple way of outputting the RAM failure address!

Re: Malfunctioning VT240 - help please

[Adrian Graham via cctalk]

> On 11 Jun 2020, at 15:14, Charles via cctalk  wrote:
> 
> =
> 
> 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) :(
> 


You’ve just mentioned the magic 4116 word, I’d bet some of your dollars that 
it’s either one of those that’s gone south or the -5V required to run them

-- 
Adrian Graham
Owner of Binary Dinosaurs, the UK's biggest private home computer collection?
t: @binarydinosaursf: facebook.com/binarydinosaurs
w: www.binarydinosaurs.co.uk

Re: Malfunctioning VT240 - help please

[Jon Elson via cctalk]

On 06/11/2020 02:29 AM, Mattis Lind via cctalk wrote:
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.
Sure, once you call a subroutine and then try to return, 
corrupted memory would throw the processor into never-never 
land.  And, that could leave the bus in a weird state, 
perhaps with no valid memory or device selected.


Jon

Re: Malfunctioning VT240 - help please

[Mattis Lind via cctalk]

>
>
>
> 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.
>
The VT100 also makes use of a binary code for the very early errors like
ROM and RAM faults so assuming the same behaviour here is not that far
fetched I think.


> 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?
>

Yes. The 7D01 was older than I expected. I thought maybe a HP1630 or
possibly 1615 which is old...
I guess that the memory depth of the 7D01 is not that much.

Assuming that the CPU does a HALT when it stops it should stop reference
memory so if you let your logic analyzer just store all addresses until it
stops you might be able to find the last (whatever memory depth you have)
instructions. Use the memory strobe to clock in the address into the logic
analyzer. Then you can do hand disassembly of this part. Or load it into
Ersatz-11 and SimH and do the disassembly.

But maybe it is a good idea to find a slightly more modern LA? Maybe a HP
166x (There is one 1661 on Ebay at $70) which is quite portable and easy to
use. Or HP 167x which has much better memory depth.

> 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.
>
Yes. That could be an alternative. Maybe you can figure out how to
communicate over the serial port. Perhaps you can write something
simplistic that outputs something to the serial port?


> My fear is that one of the PALs has altered itself from tin-whisker
> migration (fuse regrowth) :(
>
That could probably happen. But I have seen more cases with failed memory
chips than PALs that have self-altered.

/Mattis

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

On 6/11/20 2:29 AM, Mattis Lind wrote:



torsdag 11 juni 2020 skrev Charles via cctalk >:



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) :(

Re: Malfunctioning VT240 - help please

[Mattis Lind via cctalk]

torsdag 11 juni 2020 skrev Charles via cctalk :

>
> 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

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

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!

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

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


Yes, I've been experimenting with this. It's not 1 volt, it's 4 to 3 
volts and back again at the rate the lines should be switching :)


If it were contention caused by the LS245, the short circuit current 
would be far higher. I've also tried strapping the OE\ on the '245 high 
with no change. I removed all four ROMs and if there's bus contention it 
is not coming from them. Unfortunately the USART and UART are not in 
sockets, but no change when their chip selects are forced invalid.


Even more interestingly, I have discovered that when the T11 is crashed 
completely (e.g. after I slip with a scope probe on the DAL or other 
lines), if I connect DAL3 when at a steady high, through a 1K to ground, 
results in a 0-3 volt output switching at the instruction cycle rate 
with a slow risetime and a rapid fall! That is not possible if the bus 
were tristated or in contention...


There has to be something in the T11 internal drivers that is latching 
up somehow. It would really help to have another T11 aka 310 aka 
21-17311 ALSO aka KR1807VM1 (Russian clone) to try - but apparently the 
Atari enthusiasts have snapped them all up and I refuse to pay over $100 
for a tested working one on Ebay!

Re: Malfunctioning VT240 - help please

[Jon Elson via cctalk]

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

Re: Malfunctioning VT240 - help please

[Charles via cctalk]

OK. the keyboard is working properly as far as I can tell, data is going 
in and out, and I even swapped it for the keyboard on my VT220 and the 
same symptoms persisted.


I just verified all four ROMs on the T11, and the ROM for the 8085, 
against the images I found on the MAME site. So far so good.


One interesting finding - two of the lines (DAL3 and DAL1) on the T11 do 
change states several times, but once the self-test has crashed, they 
stay high with almost one volt of "wiggle". All the other data/address 
lines are either high, low or switching between a good 1 and 0.


There are several places that the bus connects, including the ROMs, 
1-bit dynamic RAMs and various octal latches & bidirectional buffers. I 
connected a 10 ma VOM between each line and ground (to make sure a 
low-resistance path (such as in the 'LS245 at E55) wasn't forcing it 
high somehow.


All of the DAL15-0 lines requires more than 1.9 ma to bring it to ground 
(well, 50 mv burden at 250 mv full scale, anyway).


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.


The T11 spec sheet says that a good logic 0 (<0.4 volt) should be 
possible with up to 3.2 ma sink... So I suspect the T11 has a couple of 
bad output pull-down transistors on those lines. Anyone got a spare T11 
chip I can buy or borrow? Or send you mine to plug into your board and 
see if it fails the same way? :)

thanks.

Re: Malfunctioning VT240 - help please

[Matt Burke via cctalk]

On 07/06/2020 18:27, Charles via cctalk wrote:
> Until a few minutes ago, my VT240 was operating normally, but now it's
> unresponsive (fails during power-on self test).
>
> Normal behavior was: display a checkerboard, then two different
> intensity all-white bands growing slowly up from the bottom of the
> screen, then a beep and the expected "VT240 Monitor Error 9" (because
> I'm using an old B composite monitor instead of the DEC VR201 with
> special cable). Thereafter, normal operation.
>
> Now, it briefly displays the checkerboard (and all four keyboard
> lights turn on, then off); then the Lock and Wait lights come on and
> nothing else happens. Blank screen.
>

The keyboard LEDs are used to indicate the test being performed, in this
case test 5 failed. They are listed in the pocket service guide. For the
first 6 codes it just says fatal error, replace terminal controller
board. I don't think it is the keyboard. You should get an error code 7
on screen for that.

I'm afraid I haven't looked into the VT240 firmware but I have looked at
the VT220 previously. Here are some of my notes on the self test:

0 = 8051 Internal RAM Test (Data=0xAA)
0 = 8051 Internal RAM Test (Data=0x55)
0 = 8051 Internal RAM Test (Data=0x00)
1 = 8051 Internal ROM Checksum (8840: lcall $8870)
2 = External ROM Checksum 0x8000 (884B: lcall $8870)
3 = External ROM Checksum 0xC000
8 = Screen RAM 0 (Addr=0xA000 Data=0xAA)
9 = Screen RAM 1 (Addr=0xA800 Data=0xAA)
A = Atrrib RAM 0 (Addr=0x8000 Data=0xAA)
B = Attrib RAM 1 (Addr=0x8800 Data=0xAA)
8 = Screen RAM 0 (Addr=0xA000 Data=0x55)
9 = Screen RAM 1 (Addr=0xA800 Data=0x55)
A = Atrrib RAM 0 (Addr=0x8000 Data=0x55)
B = Attrib RAM 1 (Addr=0x8800 Data=0x55)
8 = Screen RAM 0 (Addr=0xA000 Data=??)
9 = Screen RAM 1 (Addr=0xA800 Data=??)
A = Atrrib RAM 0 (Addr=0x8000 Data=??)
B = Attrib RAM 1 (Addr=0x8800 Data=??)
C = Character ROM (read only)
D = Alt Character RAM (read/write)
E = Alt Character RAM (?)

I know the VT240 uses a different processor to the VT220 but this gives
you an idea of the sort of things that are being tested early on. I
imagine the VT240 will carry out a similar set of tests.

Matt

Malfunctioning VT240 - help please

[Charles via cctalk]

Until a few minutes ago, my VT240 was operating normally, but now it's 
unresponsive (fails during power-on self test).


Normal behavior was: display a checkerboard, then two different 
intensity all-white bands growing slowly up from the bottom of the 
screen, then a beep and the expected "VT240 Monitor Error 9" (because 
I'm using an old B composite monitor instead of the DEC VR201 with 
special cable). Thereafter, normal operation.


Now, it briefly displays the checkerboard (and all four keyboard lights 
turn on, then off); then the Lock and Wait lights come on and nothing 
else happens. Blank screen.


Power-OK light on the back is illuminated and 5.19 volts measured on the 
board. Haven't checked +12 (or the internally derived keyboard +5) yet.


Another possibly useful observation: I can press the Setup (or any 
other) key about four times and hear a keyclick sound each time. But 
then it stops playing the click sound if I keep pressing keys. This 
suggests that the interrupt on the CPU (a T11) is not being responded to.


The technical manual is very detailed but does not describe the 
specifics of the POST, which could be useful in locating the failed 
circuit (or firmware).


Can anyone with experience in debugging these terminals lend a hand? 
Should I even be looking at the main board, or the keyboard which also 
has an 8051 CPU??


thanks.