Many years ago, a friend gave me an Overland T490 tape drive which has
some kind of autoloader attached which takes ten tapes. I was told it
came out of a Tandem system. The tapes are square cartridges similar
but different to a DEC TK50. I can't find very much information about
the drive on the web but there are some hints that it might be compatible
with an IBM 3480. It powers up nicely and the fan works and after a
short pause, a green LED illuminates. There are only two buttons on
the front, "unload" and "format".
There are two DD50 connectors on the back. One had a terminator plugged
into it labelled "SCSI differential". The other had a ridiculously long
cable with DD50 plugs on it connected, lending further credence that
this is a differential (pre-LVD I expect) SCSI device.
I would like to get this drive working with my Alpha or VAX VMS systems
but I have never had any luck getting them to talk to it. Recently,
I tried a using a DD50-HD68 cable I found somewhere to connect it to
a differential SCSI card in my Alphaserver 800 but I could not get VMS
to see the drive. Not knowing what SCSI id the drive is likely to be
using makes it hard to know where to start looking for it.
There are no switches on the outside of the drive which could be used
to set the SCSI id so I opened it up to see if I could find any hints
inside. I didn't see anything that looked like it could be used to
set the SCSI id inside either. What I did find is that the interface
board had a connector labelled "SCSI differential" which had two short
lengths of ribbon cables plugged into it leading to the two DD50
connectors on the rear panel and another connector labelled
"SCSI single ended" with nothing attached. There were also two ten way
jumper packs which were labelled "DI" and "SE" on each side.
So, not having any luck with differential so far, I tried moving the
two jumper packs from "DI" to "SE" and moving the ribbon cable to the
"SCSI single ended" socket. I used a short, known good DD50-DD50 SCSI
cable to connect the drive to my VAX 4000-100A and replaced the
differential terminator with a known good single-ended terminator.
VMS didn't see the drive. VMS has a utility called scsi_info which can
be used to send a SCSI inquiry command and read mode pages etc. Trying it
against each unused SCSI id results in "device timeout" every time. The
system disk is on the same SCSI bus before the tape drive and a SCSI
scanner can be connected after it on the bus. Both devices work fine so
the SCSI bus cabling and termination is in good shape on both sides of
the tape drive. I've tried moving the system disk SCSI id from 0 to 1,
changing the initiator SCSI id from 6 to 7 and replacing the scanner with
a terminator in case there is any sort of SCSI id conflict but scsi_info
still doesn't show up anything that could be the tape drive.
Does anyone have any information about this drive, particularly
whether it should behave like a standard SCSI tape drive and what
SCSI id and/or lun it is expected to use or if there is some trick
required to get it to start talking? Maybe it doesn't like SCSI
inquiry commands?
Extra bonus points awarded for details on how to control the autoloader.
Maybe I did some damage to it when I was trying to get it to work when
I first got it?
Regards,
Peter Coghlan.
> From: Jay Jaeger
> Also, if someone (else, presumably) does up a replica of the indicator
> panel board (perhaps with the option to use LEDs, with some resistor
> packs that could be bypassed for lamps
Two points.
First,there's the question 'are you trying to produce something that just
_looks_ alike, or do you want something that's electrically compatible (i.e.
can be swapped in in place of an original'?
If the latter, it might be going to take a little work; it might not be just
'wire up some LEDs and go'. If you look at the indicator panel prints (pg.
190 of the RF11 prints), the incoming lines are tied to the base of a
transistor; its emitter is tied to ground, and the light bulb is wired
between the collector and +6.5V. This means, I think (I'm basicaly a software
guy :-), that one turns the bulb on by putting a voltage on the input, which
turns the transistor on, and current flows through the bulb to ground. (If I
have that wrong, will someone please orrect me?)
Given that the way TTL works is that 'logic' outputs actually sink currect
when their output is '0' (i.e. current goes _in_ the 'output' pin), it might
take a little work to make the right thing happen. Although maybe not;
looking at the RK11-C prints, it seem to drive the indicator panel straight
>from the output of normal gates. I _think_ what happens is that when a gate's
output is '1', the output's voltage floats high, and that's enough to turn on
the transistor (above) driving the bulb. (Ditto the request for correction!)
But the real issue with 'electrically compatible indicator panels' is the
wiring. In the originals, the flat cables that drive them are soldered directly
to the indicator panel board, and also to the paddle boards. So the _only_
standard interface location is the paddle boards.
I suppose one could put Berg headers on both the indicator panel board and
the paddle boards, and use a standard IDC cable betweenthe two...
Mention of the paddle board interface brings me to the second point: even if
one did produce electrically-compatible indicator panels - where are you
going to use them in a PDP-11 system? Not in the CPUs - those all had their
own front panels. The only PDP-11 devices which used indicator panels which I
know of were:
- the DX11 (I don't think anyone's got one of those)
- the RF11 (ditto - although Guy was discussing emulating one at one point)
- the RP11 (but the indicator panel is built into the controller rack there,
so if one has an RP11, one already has the indicator panel)
- the RK11-C (and several people who have those already have indicator panels)
I agree, the indicator panels look cool - but where are you going to use one
in a historical PDP-11 system?
Sure, one could use either a electrically-compatible or
non-electrically-compatible indicator panel anywhere you want, plugging into
some non-historical hardware, but.. (The non-electrically-compatible
indicator panel Dave did for the QSIC is initially being used in something
which emulates an RK11 and/or RP11, so there's some rationale for it.)
Noel
https://www.ebay.com.au/sch/m.html?_ssn=techparts2020&_nkw=%22PCI-GPIB%2B%22
NI National Instruments PCI-GPIB+ Analyzer PCI IEEE488.2 Interface Card
(~USD140)
Ebay item #
284088568161 Copyright 1998???? 183619B-01
284088565868 Copyright 2001???? 183619C-01
284088570014 Copyright 2005 ASSY192125D-01
While a photo shows the Windows NI Analyzer software in use, the item
doesn't mention it.
If NI will provide the analyzer software, these could be used to capture
HP-IB traffic to characterize the attached devices, timings etc.
The HPDrive project mentions the analyzer cards as being supported
https://www.hp9845.net/9845/projects/hpdrive/#hpdrive
> From the blog of someone who got a KB11-A working
It's Fritz Mueller's blog; at about the top of this page:
https://fritzm.github.io/category/pdp-116.html
he's just turned the machine on for the first time, and you can
follow as he chases, finds and fixes CPU problems. The KB11-C/D
of the -11/70 is _very_ similar to the KB11-A he was dealing with
(they are _basically_ the same CPU, with a cache, and other stuff
added on the other side from the CPU, on the KB11-C/D), so there
are probably some good lessons to be learned.
> dunno if Guy Steele
Ooops; sorry, Guy - the brain is starting to drop bits.
> if the particular machine the system is being built for has an FP11).
> Perhaps the later BSD versions look for the FP11 on startup, and adjust
> their behaviour appropriately, but I'm not familiar with them.
The way user code deals with the existence/non-existence of the FP11 is
pretty simple.
In C (other languages probably do something similar, but I only know about
C),one gives the '-f' flag to 'cc', and when 'cc' invokes the linker, on
machines which don't have floating point support, it uses fcrt0:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/fcrt0.s
as the machine language startup (the thing that calls main()) instead of
crt0. The difference is that fcrt0 sets the UNIX 'illegal instruction'
signal, in that process, to go to a handler which emulates the FP11
instructions.
In V6, as distributed, the binary of all applications which use floating
point are linked this way, so they will all run OK 'as is' on a machine with
no floating point (including those which don't suppport any kind of FP11,
such as the -11/40). When run on a machine with an FP11, there are no illegal
instruction traps, and that emulator code is just never used.
I'm not sure what the deal with BSD is, for machines without an FP11; fcrt0.s
is still included in BSD2.9, so maybe it's still using this approach. I have
this vague recollection that at some point, floating point instruction
emulation was added to the kernel, removing all the signal overhead, but that
might be a bogus recollection.
Noel
Would anyone like to make an offer on this AF01? It's a multi-channel
A/D converter for old pdp8 and pdp12's. I really don't think I need it,
I just pulled it out of my closet, and I don't want to put it back in.
Copy me off list. Complete, multiple MUX channels (16 A121's) the A704
and the op amp (A200)
Hi!
Some time ago, I got my hands on a DECtape II, though no tapes.
That'll change after a long time and in a few days, even multiple
tapes will come in.
With that drive, I started some first tests. It's PSU seems to be
all fine, providing stable 5 and 12 V.
It's board's wire wrapping is in factory settings, so baud rate etc.
is all known.
However, when I checked the two drives capstans, they're old. One
has a crack, and as things go, they feel partially either hard or
gooey. Are there recommendations to exchange these for new ones? I
also noticed that one of the two motors rotates quite freely
(both unconnected from the board, so I'm sure they're not magnetically
braked) while the other ... can be turned without any unreasonable
torque, but it won't continue to spin at all.
Also, when the tapes arrive, are there recommendations in case their
drive belts are gone?
And a final question: There are three firmware versions archived for
the TU58 control board. It's a known version:
jbglaw at charon:~/customers/Glaw/VAX/DECtape II$ md5sum *.bin | sort
0e5f30a960e72c9d64174a4da8f48f50 23-294E2-00.bin
5e059396f779aef9cd80bc75a36c90b2 23-089E2-00.bin
5e059396f779aef9cd80bc75a36c90b2 jbglaw-DECtapeII-ROM.bin
a407fbb5aaa4823a92dd2bc374d1d3ae 23-389E2-00.bin
I guess I got the oldest version? Were there board changes, or could I
put in a compatible 2Kx8 ROM with any of these versions? I guess any
firmware will probably work "good enough", but if I'd avoid known
problems (are the differences known?), I'd rather avoid them.
But after all, I'm quite happy that all the bits'n'pieces will come
together in a few days. Yay!
MfG, JBG
--
> From: Rod Smallwood
> Let me see what artwork I have
I'm curious as to what you'd be able to find. Like I said, I'm pretty sure
DEC never did an RK11-C inlay; the engineering drawings for the 19" indicator
panel (included in the RF11 engineering drawings:
http://www.bitsavers.org/pdf/dec/unibus/RF11_EngrDrws_Oct70.pdf
on pp. 187-188) list many inlays, but not an RK11 one. Also, I've looked
through the RK11-C manual:
http://www.bitsavers.org/pdf/dec/unibus/RK11-C_manual1971.pdf
but it contains no mention of an indicator panel, which it surely would if
there was one.
> From: Henk Gooijen
> I have *two* DX11 front panels with the 144 lamps & 4 'paddle'
> connections boards. ... Given you have 144 lamps panel with the RK11-C
> front, what would you do to light up the lamps?
Uhhh... plug the paddle boards on the end of the flat cables from the
indicator panel into the pre-wired slots in the RK11-C backplane (see the
RK11-C engineering drawings:
http://www.bitsavers.org/pdf/dec/unibus/RK11-C_schemFeb1971.pdf
pg. 36)? :-)
Hence my comment that to make use of the _inlay_ I proposed to produce, one
had to have an RK11-C _and_ a spare DEC indicator panel...
Noel
Eric,
I would qualify that statement and say - I'm the Tek computer Monty :)
I have a Tektronix 4052 and 4054A, plus two Tektronix 4041 (68000 based
GPIB controller) computers :)
Both the 4052 and 4054A also have Tektronix 401x terminal emulation at up
to 9600 baud, so I don't have a use for the Siemens terminal.
Monty
On Wed, Dec 8, 2021 at 12:58 PM Eric Moore <mooreericnyc at gmail.com> wrote:
> Holy shit Monty, you are the tek terminal Monty.
>
> I just posted on facebook in the tek 4051 basic group, do you know anyone
> with a tek 41XX or 42XX terminal?
>
> -Eric
>
>
> On Wed, Dec 8, 2021, 12:51 PM Monty McGraw via cctalk <
> cctalk at classiccmp.org> wrote:
>
>> I have this terminal in my garage - sitting on its custom stand.
>>
>> I purchased it years ago, but don't have a use for it.
>>
>> Here is my photo of it:
>>
>> https://drive.google.com/file/d/1SV4-Xx7XLHIoA898ZPRC74wZv2e8YsVK/view?usp=…
>>
>> I'm near Houston Texas.
>>
>> It is too big and heavy to ship.
>>
>> Monty McGraw
>>
>
