> From: Bob Smith <bobsmithofd at gmail.com>
> saw a comment that this belonged to CJL.
Chris Lindblad? Sorry, I'm drawing a blank on someone with those initials who
is connected with the LINC.
> From: Jon Elson
> Wow, those were fairly rare back when, and now there may only be a
> couple in existence.
Yeah, that's why I was hoping that someone connected to this community would
get it, so we don't lose track of this rare artifact.
I'd buy it, but i) it's not a PDP-11, and fails my 'PDP-11's only' test
(intended to put a strict limit on the amount of junk I accumulate), and ii) I
already have a whole bunch of PDP-11 gear I have yet to get to. :-( There's no
way I would ever get to it.
> Two complete CPUs, capable of running at the same time in shared memory
> (I think).
The documentation (1967 Small Computer Handbook) is unclear. It is clear that
the general mode of operation was for only one CPU at a time to be running,
but that appears to be to simplify programming (although it does say that "In
the PDP-8 mode, the LINC subsystem is disabled"). The memory is indeed shared;
it's on the PDP-8, and the LINC gains access via the standard PDP-8 'data
break' (i.e. DMA) mechanism.
Noel
> From: Paul Koning
> I suppose they still charge you an insurance fee according to what you
> declared as the value?
Yes, IIRC.
> This seems like a pretty clear case of fraud, and you should report it
> to the authorities.
Well, at the time, I thought it was just a local manager being a hard-ass; so maybe
not worth the effort of taking further steps. Now, of course, it looks more like a
policy change, but the incident I was a party to is now many months ago, so perhaps
not optimal for reporting.
Noel
Hi, a heads-up on sending expensive items via FedEx. They appear to have a new
policy, limiting honouring insurance coverage; so, in my opinion, they are
now unsuitable for shipping valuable items.
Data point 1: a couple of months back, I bought a PDP-11/40 on eBait. It was
shipped via FedEx in two separate packages: one with boards, and one holding
the chassis/front-panel. They somehow managed to lose the second box - and
then refused to fully pay out the insurance coverage on that box. We provided
them with data on an open eBay auction for an identical item, to prove that
our valuation was not inflated, but it didn't help - they only paid out a
reduced amout, not what the thing was worth, and _what we had insured it for_
(even though _they_ lost it).
Data point 2: I collect Japanese woodblock prints; a large dealer I do
business with used to do all their shipping via FedEx - dozens of shipments
per week - but as of yesterday I as informed that they are now switching. Why?
FedEx lost a valuable, insured, package - and would only pay out US1K on it,
not the full insured value, leaving the dealer to absorb most of the loss
(several US$K).
There's a clear pattern here; FedEx is refusing to honour the full insurance
coverage when an item is lost. So I wouldn't ship anythihg valuable via FedEx
unless you can find an outside insurer to cover it - since Fedex's own
insurance coverage now often cannot be relied upon.
Noel
Quick question: Does anyone have a copy of dx.sys for RT11 version 5.5?
I'm getting my RX01 disk running but don't seem to have this driver and
the 5.1 driver does. not. work. under 5.5
Thanks!
Chris
Ok, so this evening I went back to the house to do a quick evacuation of
the most critical stuff and take some better pictures. This time I
brought a massive xeon flashlight which helps to get quicker pictures
with less shake.
I also picked up a pile of Perq boards, and all the DC600 tapes and
floppies I could take out. The car was loaded with them, someone is
going to have to curate these. But since I know that the most important
thing is the software and not the hardware I decided this is what to get
as the top priority.
There appears to be a third Perq in there as well on the other side of
the basement. No big drives (14 inch or 8 inch) but a lot of MFM and
SCSI disks. Couldn't grab those, too heavy.
I'm going to put together a list of people and see if I can figure out a
way to get things out. The garage is blocked by an old car, and this
stuff will not go up the steps. Too narrow.
Never dull. Latest pictures are at https://www.crystel.com/bob (I moved
the old ones to a subfolder). I also took a better set of pictures of
the VME boards, look like Sun boards.
C
I've started scanning a few more of the BHP docs I recovered a while back, and thought this one was interesting.
A 1973 gizmo that buffers just enough received data for a relay to close and power up a teleprinter's motor to
operating speed before printing, apparently half a second was sufficient it reckons.
The buffering is through a pair of 64 x 4-bit Fairchild 3341 FIFO memory chips.
https://archive.org/details/utec-bmc-6092-buffered-idle-line-motor-control-…
One of the other docs mentions they had an ASR33 with this buffered motor control installed connected to PDP-11/10.
Steve.
> From: Chris Zach
> We have to move fast though, this needs to be cleaned out. How can
> people help me on this?
I'm sure there must be institutions that would love to have the PERQs; they
were very important machines, historically, and are quite rare.
Alas, although I'd normally be up for helping in such a recovery operation
(I'm in Virginia), I'm recovering from a moderate case of Covid19 (didn't
have to go to hospital, luckily, but I had a bad fever), and am still pretty
weak, so it's probably beyond me at this point.
Noel
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
