I'm trying to repair a partially functioning Cybernetics Data Products
ADT-2002 scrolling LED sign from the early 80's. Previous owner said
there was a power failure or lightning strike, don't remember which, and
gave it to me. The brief version of the instructions are taped to the
keyboard, and that is the only manual I can find.
Power supply is functional and delivering 5 volts where it should.
On boot it's supposed to say "UNIT OPERATIONAL" on the display before
plugging in the keyboard ribbon cable. There is garbage displayed instead.
When the keyboard is plugged in, the display responds to start/stop
scroll (green and red keys), and messages can be input. The memory
(yellow key) and control (blue key) functions don't seem to work.
There actually is a microprocessor (8048 or 8051), but inside the
keyboard only.
Another observation: The display only scrolls a couple of characters,
jumps back to the beginning and repeats forever.
But the actual display board has a 24-pin Harris PROM (fuse link), seven
2102's 1K memory for the 7 rows of LEDs and many 7400 TTL including?
4-bit counters, comparators and adders. No CPU at all, so it must be a
state machine, and a fairly complex one at that unless some of the
"smarts" are actually in the keyboard microprocessor. The cable from the
keyboard connects directly to the PROM without any buffering.
I have found that only the lowest 4 bits of the memory address lines
have activity on them, which explains why two characters scroll before
it repeats (16 columns). I can't find anything strange looking (e.g.
non-TTL levels) on the middle and upper nibbles except that they don't move.
There does not seem to be any information on this unit online. I'd like
to find a repair manual (probably too long a long shot), but even a
schematic would save a lot of hair pulling!
Thanks for any help.
So I've had a boat anchor pdt11/150 here for awhile. It's probably one
of the weirdest pdp11s ever built: An 11/03 CPU ish, six serial ports,
ish, and a pair of RX01 drives.
Ish.
The trick is the system is very closed in: There are 4 boards inside
with a lot of early microprocessors to do the IO instead of a real Q
bus. The bottom board is a controller that is sort of like an RX01 but
instead of using the DX: driver it uses a special PD: driver. The CPU
connects to this with a 14 pin DIP ribbon cable, and on the back of the
CPU module is a 64kb memory module and a serial module that has a
console, printer, modem and three additional serial ports that are their
own thing.
Problem with this one was that it would not come up. Serial tests seemed
to fail using an error code of waiting for input which didn't make a lot
of sense. So today I decided to pull the serial board and see if I could
swap the UARTs.
I quickly figured out the problem: The serial board "connects" to the
main board by two sets of bars with three screws each that hold the
board to an interconnecting header that sends the signals. As soon as I
loosened the screws I realized that the header isn't connecting to pins
on either board, it literally presses against pads on the boards that
complete the circuit. Nothing but pressure and springiness holds it
together. No screw, pin and socket, anything.
With that I cleaned off the headers and wiped down the pads on the
boards till they shined like the top of the chrystler building. I then
reassembled and torqued the screws down evenly, finishing with the
center screw first followed by the outside screws. It is to note that
the hinges that hold the CPU and memory/serial boards to the body of
this thing attach to the bottom of those screws so when you open it up
you are flexing the assembly and probably stretching the screws a bit.
Which results in bad contact...
Plugged it in and all is well.
RT-11SJ (S) V05.01C
.DIR SY:
SPCINV.SAV 10 21-Mar-1989 OTHELO.SAV 45 21-Mar-1989
SPCINV.DAT 1 21-Mar-1989 TODAY .SAV 20 22-Feb-1988
DECMAN.SAV 14 21-Mar-1989 SPACWR.SAV 13 21-Mar-1989
STRTRK.SAV 54 21-Mar-1989 SWAP .SYS 26P 27-Jul-1984
RT11SJ.SYS 64P 19-Jun-1988 TT .SYS 2P 19-Jun-1988
PD .SYS 3P 19-Jun-1988 DX .SYS 4P 21-Jan-2000
PIP .SAV 30P 21-Jan-2000 DUP .SAV 52P 21-Jan-2000
DIR .SAV 20P 21-Jan-2000
15 Files, 358 Blocks
128 Free blocks
Another little DEC mystery solved. One odd thing about these: There are
only four chip slots for the CPU and microcode, but one of the carriers
has two dies on it so the system *does* have EIS and FIS instructions.
Why not...
Chris
The outpouring of messages and help has been quite inspirational. It
seems that the Perq data is really important, so I will be going back
today for a bit to try and get the boxes of data tapes out of there.
DC600's, I'm sure they will need to be restored somehow but I'll try to
get them.
In the meantime here are 4 pictures from 2005 of the stash. To be honest
almost nothing has changed between then and now, it was like looking at
pictures of the titanic from 1912 and today.
https://www.crystel.com/bob/bob%201.jpghttps://www.crystel.com/bob/bob%202.jpghttps://www.crystel.com/bob/bob%203.jpghttps://www.crystel.com/bob/bob%204.jpg
Chris
> I actually have -B/-C boards, I should plug one in in QBUS mode, and get my
> QSIC prototype working again (it somehow random failed during the last year,
> and I've been too lazy to debug it), and write a little program to DMA blocks
> in and out, and see what happens to the data. If I get really energetic I
> could throw a 'scope on the bus and look at bus cycles and see if they look
> OK.
>
> It would be interesting to have some more detail on the failure.
>
> Noel
Noel,
The experiments you describe above would be very interesting! In the accidental tests
I did using -C boards in an 11/83, RSX booted ok and ran for a good bit but I think errors
Started to accumulate due to bad DMA writes that either were written to the wrong logical block
Or the data written was scrambled. When this happened on my BA23 11/83 I scratched my head
Took the boards to a BA123 11/83 and repeated the mistake. Fortunately I use two SCSI2SD devices
In each system and leave one identical unit unmounted except during disk to disk backups.
With good memory boards I was able to do a disk to disk restore and recover everything up to
My last backup.
> And that might make sense: PMI memory responds to the Q bus just like
> normal memory. So from a Q bus device perspective it's just boring old
> memory and thus no speed improvement. What might speed up is if I did
> memory to memory (VM0:) copies, but with only 2mb running at the moment
> there's not a lot of time to check for performance differences.
Chris,
I think the way that you see the biggest performance improvements in PMI over Q22 memory
Is when you have heavy asynchronous I/O happening at the same time the CPU is compute bound
And the memory access is not well cached due to the type of programs being run. This is more
Likely to happen in a busy multi-user environment. RSX has a tool IOX that was developed to load a
RSX system and simulate multiple users. The CPU can get at memory via the PMI and not be delayed
Waiting on the Q22 bus. This is particularly helpful with larger block mode Q22 transfers that don?t cause
CPU memory access delays.
Mark
> From: Mark Matlock
> Are you able to use a Qbus MTI controller in the 11/84's Qbus section
> of the backplane? This is something I've often wondered about but never
> tried.
I looked into this in some detail, but I don't know:
https://gunkies.org/wiki/KTJ11-B_UNIBUS_adapter#QBUS_slots
Amswering it definitively would probably require looking at DMA and interrupt cycles
with a logic analyzer on the bus, to see what the CPU does with them. And the KDJ11-B
and KDJ11-E (the 11/94 uses the same bacplane with a different CPU card) might act
differently.
> For anyone who is curious about what Happens when a M8637-C version
> board is used as PMI memory in an 11/83 I can speak From experience.
> ...
> After this the disk is corrupted and you will need to restore the
> system disk from backups
Ah, very informative; thanks for reporting.
So whatever the fault is (perhaps the QBUS block transfer issue reported
up-thread), it must _seem_ to work, but fail in actuality. It would be
interesting to appply a logic analyzer, and see what the bus transaction
looks like, if it looks OK on the bus (in which case it's an internal
failure).
Noel
> From: Jerry Weiss
> Sorry about the uNOTE confusion..
No problem, it only took me about a minute to find the right one; my note was
to warn other people who didn't know about the number duplication.
> If you look at the Memory Comparison table in this OEM uNOTE, it only
> lists Block Mode for "JD/JE ONLY".
Oh, right. Still, it sounds from reports here like regular DMA doesn't work
in QBUS mode either - and technically that table entry might mean than since
it doesn't work for the QBUS _at all_, that includes no block mode.
I actually have -B/-C boards, I should plug one in in QBUS mode, and get my
QSIC prototype working again (it somehow random failed during the last year,
and I've been too lazy to debug it), and write a little program to DMA blocks
in and out, and see what happens to the data. If I get really energetic I
could throw a 'scope on the bus and look at bus cycles and see if they look
OK.
It would be interesting to have some more detail on the failure.
Noel
