10 Jun
2020
10 Jun
'20
10:48 a.m.
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.
10 Jun
10 Jun
2:31 p.m.
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
3:04 p.m.
On 6/10/20 4:31 PM, Jon Elson wrote:
On 06/10/2020 12:48 PM, Charles via cctalk wrote:
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!
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
8:08 p.m.
On 6/10/20 4:31 PM, Jon Elson wrote:
On 06/10/2020 12:48 PM, Charles via cctalk wrote:
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!
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 
11 Jun
11 Jun
12:29 a.m.
torsdag 11 juni 2020 skrev Charles via cctalk <cctalk at classiccmp.org>:
On 6/10/20 4:31 PM, Jon Elson 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
On 06/10/2020 12:48 PM, Charles via cctalk
wrote:
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!
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
7:14 a.m.
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) :(
8:31 a.m.
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
12:44 p.m.
On 6/11/20 10:31 AM, 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.
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!
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
1:15 p.m.
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.
2:30 p.m.
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.
<snip>
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 ;)
11:37 a.m.
On 11 Jun 2020, at 15:14, Charles via cctalk
<cctalk at classiccmp.org> 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: @binarydinosaurs f: facebook.com/binarydinosaurs
w: www.binarydinosaurs.co.uk
1:33 p.m.
On Thu, Jun 11, 2020 at 2:37 PM Adrian Graham via cctalk
<cctalk at classiccmp.org> wrote:
Definitely check the -5V for the 4116s.
-ethan
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 
2:30 p.m.
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
<cctalk at classiccmp.org> wrote:
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 <nw.johnson at ieee.org>
Please consider the environment when deciding if you really need to print this message
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 
15 Jun
15 Jun
4:29 a.m.
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) :(
8:41 a.m.
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
6:13 p.m.
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
11 Jun
11 Jun
8:49 a.m.
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
1650
days inactive
1656
days old
16 comments
8 participants
participants (8)
-
ard.p850ug1＠gmail.com -
binarydinosaurs＠gmail.com -
charlesmorris800＠centurytel.net -
doug＠doughq.com -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
mattislind＠gmail.com -
nw.johnson＠ieee.org