DX11 baud rates under RT11
Tony Duell
Bob (r...@swift.eng.ox.ac.uk) wrote:
: The system in question is running RT11 5.0x (with multiterminal
: support installed). The console is a standard DL11 affair, at 1200
: baud, currently talking to a DECwriterII. A DX11 board is installed,
Unless my brain is failing again, a DX11 is an IBM360 channel interface
for Unibus PDP11's. It's 8 rows of flip-chip cards, along with a PSU, display
panel, power interlock panel and connector panel. I have the prints, but I
can't believe that's what you mean.
Do you mean a DZ11? That's an 8-channel Async mux for the Unibus.
: one port of which is being used to connect the primary terminal, a
: VT100, at 9600 baud. I have reason to suspect (although I've not
: checked) that this DX11 board is not the genuine DEC item, but is a
: clone - perhaps manufactured by BMC(?).
If it's a true clone, it shouldn't matter.... On the other hand there were
some multi-channel Unibus cards (3rd party only, not DEC) that were multiple
DL11's (similar to the DLV11-J for Q-bus). I have a Systime one somewhere. That
thing is set up using wire-wrap links on the board. The DZ11 is configurable
from software.
: Question is, what is the maximum baud rate for a DX11, and how do I
AFAIK it's either 9600 baud or 19200 baud. You may need to cut-and-jumper to
get the latter, though.
: Bob
-tony
Bob
Well for once I've got the joyous task of posting _someone elses_
PDP-11 problems to usenet rather than my own. Well, these are my
problems too I guess, but they're with someone else's machine, rather
than with one of my own :)
I may be given the task (I hope so, I need the money ...) of migrating
a large number of files from RT11 RX01 diskettes and RL01/RL02 packs
to a PC. The reason for this requirement is that the 11/34a which is
currently being used is to be decommisioned. I've moved the machine
this morning and can confirm that it's still up and running.
There are a couple of issues I'd like to investigate. The amount of
data to be transferred is very large, so I'd like to take every step I
can to make the process as painless as possible. I envisage using
KERMIT under RT11 to transfer the data to the PC. I expect to transfer
files individually, although there may be some application for
transferring entire disk images to allow them to be used under one of
the PDP-11 emulators (Supnic's or Wilson's) in future.
The system in question is running RT11 5.0x (with multiterminal
support installed). The console is a standard DL11 affair, at 1200
baud, currently talking to a DECwriterII. A DX11 board is installed,
one port of which is being used to connect the primary terminal, a
VT100, at 9600 baud. I have reason to suspect (although I've not
checked) that this DX11 board is not the genuine DEC item, but is a
clone - perhaps manufactured by BMC(?).
Question is, what is the maximum baud rate for a DX11, and how do I
change the setting? I suspect that it is software settable under RT11
(SET DX something????) rather than being set with jumpers. None of my
own systems have multiplexers installed, so I know very little about
them. I'd like to set the rate to the maximum possible to speed my
transfers.
Next question is, assuming I use KERMIT (alternatives anyone - KERMIT
is slow!) which version would I be best advised to employ? I've used
various RT11 KERMITs in the past, some better than others. The version
currently installed seems to crash the system rather too often for my
liking. The copy I use on my own 11/34c seems a little more reliable,
although this may be because I'm using a second DL11 rather than a
DX11. I've also used John Wilson's KSERVE to transfer entire disk
images. For transferring a large number of individual files, what is
the recommended approach?
Any thoughts on this subject appreciated ....
Bob
--
----------------------------------------------------------------------------
Bob Manners Osney Laboratory
r...@swift.eng.ox.ac.uk Dept of Engineering Science
University of Oxford
01865 288736
Computer Museum: http://swift.eng.ox.ac.uk/rjm/museum.html
Bob is looking for a job: http://swift.eng.ox.ac.uk/rjm/cv.hmtl
----------------------------------------------------------------------------
John Wilson
In article <RJM.97Oc...@swift.eng.ox.ac.uk>,
Bob <r...@swift.eng.ox.ac.uk> wrote:
>The system in question is running RT11 5.0x (with multiterminal
>support installed). The console is a standard DL11 affair, at 1200
>baud, currently talking to a DECwriterII. A DX11 board is installed,
>one port of which is being used to connect the primary terminal, a
>VT100, at 9600 baud. I have reason to suspect (although I've not
>checked) that this DX11 board is not the genuine DEC item, but is a
>clone - perhaps manufactured by BMC(?).
That's believable, if I remember right the *DEC* DX11 is a whole rack o' logic
for talking to IBM channels. Does SHOW TERM give any useful information?
>Question is, what is the maximum baud rate for a DX11, and how do I
>change the setting? I suspect that it is software settable under RT11
>(SET DX something????) rather than being set with jumpers. None of my
>own systems have multiplexers installed, so I know very little about
>them. I'd like to set the rate to the maximum possible to speed my
>transfers.
FWIW, the actual DEC muxes all (?) set the baud rates using software not
jumpers, so it's likely that even if RT doesn't provide a way to set the
baud rates (which I'm sure it does but I'm in a different building from
my docs right now), it would take only a few instructions to do it yourself
so a half-screen quicky MACRO program would let you set things up for the
transfer.
>Next question is, assuming I use KERMIT (alternatives anyone - KERMIT
>is slow!) which version would I be best advised to employ? I've used
>various RT11 KERMITs in the past, some better than others. The version
>currently installed seems to crash the system rather too often for my
>liking. The copy I use on my own 11/34c seems a little more reliable,
>although this may be because I'm using a second DL11 rather than a
>DX11. I've also used John Wilson's KSERVE to transfer entire disk
>images. For transferring a large number of individual files, what is
>the recommended approach?
The expensive answer is SCSI -- I've got a CMD CDU720/M on my 11/34a with
a Zip drive on it, and another Zip drive on my PC, and I've added SCSI
support to PUTR (not released yet because I want to finish the support for
block sizes other than 512, but if someone has an actual use for it I can
put that off until later and upload what I have), this way I can transfer
32 MB at a time (PUTR doesn't know about DU: partitions yet) in no time.
Choice #2 -- get ahold of a DEUNA or DELUA on the 11, and an ethernet board
for the PC, and run Megan Gentry's excellent RTEFTP on both ends (using E11
on the PC side). A lot cheaper than going SCSI, but DEUNA/DELUAs still
cost money if you get them from a dealer, and you'd need to make sure that
you haven't lost the NU: driver that came with RT 5.X.
Choice #3 -- nag me to put the finishing touches on the long packets/sliding
windows upgrades to KSERVE, it's still slow but it's nowhere near as bad
as the 94-byte stop-and-wait classic Kermit that the currently available
KSERVE uses.
John Wilson
D Bit
Tim Shoppa
>data to be transferred is very large, so I'd like to take every step I
>can to make the process as painless as possible. I envisage using
>KERMIT under RT11 to transfer the data to the PC.
This is certainly one option. Another option is to install an 8"
floppy drive on a PC-clone and use it to read RX01 floppies. I
personally prefer the Kermit option, especially using Billy Yodelman's
KRT.
>The system in question is running RT11 5.0x (with multiterminal
>support installed). The console is a standard DL11 affair, at 1200
>baud, currently talking to a DECwriterII. A DX11 board is installed,
>one port of which is being used to connect the primary terminal, a
>VT100, at 9600 baud. I have reason to suspect (although I've not
>checked) that this DX11 board is not the genuine DEC item, but is a
>clone - perhaps manufactured by BMC(?).
I would tend to believe that the DX11 is not DEC, as DEC never sold
a board called a DX11. The closest I know of is the RX11, which isn't
a serial port. Is it, perhaps, a DZ11? Or is it compatible with the
DLV-11E?
>Question is, what is the maximum baud rate for a DX11, and how do I
>change the setting? I suspect that it is software settable under RT11
>(SET DX something????) rather than being set with jumpers.
SET DX commands would work on the DX device, which is a RX01 floppy
disk. I don't think this will help you set the baud rate :-)
If your board is a DL11 with software-adjustable baud rate in a way
that's compatible with a DLV-11E, there
are RT-11 SET commands for changing the baud rate. In this case, I'll
hazard a guess that you're using RT-11's XL handler to handle this
port, in which case a SET XL SPEED=nnnn will be doable. 9600 baud
would be a good start.
> None of my
>own systems have multiplexers installed, so I know very little about
>them. I'd like to set the rate to the maximum possible to speed my
>transfers.
>
>Next question is, assuming I use KERMIT (alternatives anyone - KERMIT
>is slow!) which version would I be best advised to employ? I've used
>various RT11 KERMITs in the past, some better than others. The version
>currently installed seems to crash the system rather too often for my
>liking. The copy I use on my own 11/34c seems a little more reliable,
>although this may be because I'm using a second DL11 rather than a
>DX11. I've also used John Wilson's KSERVE to transfer entire disk
>images. For transferring a large number of individual files, what is
>the recommended approach?
Use Billy Yodelman's latest version of Kermit for RT-11, KRT. You
can get it from ftp.vnet.com, in /pub/users/billy. Slightly older,
but still pretty good, versions are available from kermit.columbia.edu.
Billy, Frank - when are the versions at Columbia going to be updated?
Tim. (sho...@triumf.ca)
Frank da Cruz
In article <6232gg$jnu$1...@nntp.ucs.ubc.ca>,
Tim Shoppa <sho...@alph02.triumf.ca> wrote:
: Use Billy Yodelman's latest version of Kermit for RT-11, KRT. You
: can get it from ftp.vnet.com, in /pub/users/billy. Slightly older,
: but still pretty good, versions are available from kermit.columbia.edu.
: Billy, Frank - when are the versions at Columbia going to be updated?
As far as I know, we have had the latest version of KRT in our archive
ever since it was released in September 1993. Billy is working on a
newer version, but it isn't released yet. Maybe that's the one you are
referring to? It is scheduled for release in November.
PDP-11 users can find all the info about PDP-11 versions of Kermit on
our website:
http://www.columbia.edu/kermit/pdp11.html
- Frank
bi...@mix.com
Tim Shoppa <sho...@alph02.triumf.ca> writes:
> If your board is a DL11 with software-adjustable baud rate in a way
> that's compatible with a DLV-11E, there
> are RT-11 SET commands for changing the baud rate. In this case, I'll
> hazard a guess that you're using RT-11's XL handler to handle this
> port, in which case a SET XL SPEED=nnnn will be doable. 9600 baud
> would be a good start.
XL didn't appear until V5.1 but there is another handler, KM (for
Kermit Modem although in this case modems aren't needed), which I
supply with the KRT Kermit that could be used here. KM also provides
an 8-bit path (XL is a 7-bit handler), hardware flow control (when
used on a port than can do it) and is optimized for Kermit (by not
doing anything beyond what Kermit actually needs).
Billy Y..
bi...@mix.com
Tim Shoppa <sho...@alph02.triumf.ca> writes:
> Billy, Frank - when are the versions at Columbia going to be updated?
Real soon now - it'll take me slightly longer to write up a formal
announcement but I'd expect the files to be available later today.
Billy Y..
Bob
>That's believable, if I remember right the *DEC* DX11 is a whole rack o' logic
>for talking to IBM channels. Does SHOW TERM give any useful information?
Errrrm, as Tony points out below, I meant DZ11. I did wonder when I
was posting it if I meant DX11 or DY11, but decided that a DY11
sounded strange. Of course, I meant DZ. Must be some sort of DEC
dyslexia. Declexia?
>FWIW, the actual DEC muxes all (?) set the baud rates using software not
>jumpers, so it's likely that even if RT doesn't provide a way to set the
>baud rates (which I'm sure it does but I'm in a different building from
>my docs right now), it would take only a few instructions to do it yourself
>so a half-screen quicky MACRO program would let you set things up for the
>transfer.
They only have the manuals (blue) for RT11 4.x at the lab. Looking at
my RT11 v5 manual (vol 2A) shows the DZ11 to be supported. Looking
under SET I can see no speed settings for the TT: handler. I take it
the TT handler deals with the DZ11? Any more ideas as to what I should
look at?
>The expensive answer is SCSI
It'll be hard enough to persuade them to pay me to do it. New hardware
is out of the question. I think this is headed to the skip (dumpster)
on completion of this final job. Of course I may try to save it from
that fate ...
>get ahold of a DEUNA or DELUA on the 11
See above.
>nag me to put the finishing touches on the long packets/sliding
>windows upgrades to KSERVE
That would be cool.
An MSDOS or UNIX KERMIT that would allow me to create directories
locally and move into them without quitting would speed the job up
too, I guess.
Bob
--
------------------------------------------------------------------------------
Bob Manners (My REAL address is: r...@swift.eng.ox.ac.uk)
BOB'S COMPUTER MUSEUM: http://swift.eng.ox.ac.uk/rjm/museum.html
------------------------------------------------------------------------------
Bob
>Unless my brain is failing again, a DX11 is an IBM360 channel interface
>for Unibus PDP11's. It's 8 rows of flip-chip cards, along with a PSU, display
>panel, power interlock panel and connector panel. I have the prints, but I
>can't believe that's what you mean.
I've seen a DX11. Pardon my declexia.
>Do you mean a DZ11? That's an 8-channel Async mux for the Unibus.
Yup.
>If it's a true clone, it shouldn't matter.... On the other hand there were
>some multi-channel Unibus cards (3rd party only, not DEC) that were multiple
>DL11's (similar to the DLV11-J for Q-bus). I have a Systime one somewhere.
>That thing is set up using wire-wrap links on the board. The DZ11 is
>configurable from software.
I could always pop a second DL11 in if necessary.
>AFAIK it's either 9600 baud or 19200 baud. You may need to cut-and-jumper to
>get the latter, though.
19200 would be nice.
Bob
>>There are a couple of issues I'd like to investigate. The amount of
>>data to be transferred is very large, so I'd like to take every step I
>>can to make the process as painless as possible. I envisage using
>>KERMIT under RT11 to transfer the data to the PC.
>This is certainly one option. Another option is to install an 8"
>floppy drive on a PC-clone and use it to read RX01 floppies. I
>personally prefer the Kermit option, especially using Billy Yodelman's
>KRT.
Any idea how to interface an 8" drive to a PC? Would I need a Shugart
type drive? I take it the RX01 type drives are no use in this regard?
What software would I use under DOS to read RT11 volumes? (I think I
have it, but I forget it's name).
>I would tend to believe that the DX11 is not DEC, as DEC never sold
>a board called a DX11. The closest I know of is the RX11, which isn't
>a serial port. Is it, perhaps, a DZ11? Or is it compatible with the
>DLV-11E?
See my previous posts - declexia ---- DZ11, I mean!
>SET DX commands would work on the DX device, which is a RX01 floppy
>disk. I don't think this will help you set the baud rate :-)
Oooops. What device manager ??.SYS is used for the DZ11? TT.SYS ??
>If your board is a DL11 with software-adjustable baud rate in a way
>that's compatible with a DLV-11E, there
>are RT-11 SET commands for changing the baud rate.
Any idea which SET commmands. My RT manuals don't seem to help on this.
>In this case, I'll
>hazard a guess that you're using RT-11's XL handler to handle this
>port, in which case a SET XL SPEED=nnnn will be doable. 9600 baud
>would be a good start.
I'll try that.
>Use Billy Yodelman's latest version of Kermit for RT-11, KRT. You
>can get it from ftp.vnet.com, in /pub/users/billy. Slightly older,
>but still pretty good, versions are available from kermit.columbia.edu.
>Billy, Frank - when are the versions at Columbia going to be updated?
I'll try that. According to the messages of others, I may boot virgin
RT11 5.x without multiterminal support.
John Wilson
In article <34454D5B...@idirect.com>,
Jerome Fine <jhf...@idirect.com> wrote:
>I have never hear of, let alone seen RK05s running on a QBus
>machine, although there is no reason for DEC to not have made
>a Qbus controller for the RK05s.
I've never seen one in person but one of the handbooks shows an RKV11D,
which is the usual RK11D hacked to work with Q-bus (one board different I
think?). If the docs are correct, it only supports 16-bit DMA addresses,
so I guess it dates back to the original LSI-11 days, pretty useless now.
John Wilson
D Bit
bi...@mix.com
Bob <r...@europa.ox.ac.uk> writes:
> Any idea how to interface an 8" drive to a PC? Would I need a Shugart
> type drive?
Long ago there was an editing system (sound, videotape) made by a
company named Adam-Smith. It was 286 (pc) based but had (since RT-11
was what most people used and many still do) an 8" floppy drive and
(an important point) could also read DEC formats. I don't know what
exactly they used for a floppy controller but it might be interesting
to try finding one of those old systems. There is probably a rec.video
newsgroup where someone would remember all this...
> I take it the RX01 type drives are no use in this regard?
Probably not - what I've seen have been Shugart drives.
Billy Y..
bi...@mix.com
Bob <r...@europa.ox.ac.uk> writes:
> An MSDOS or UNIX KERMIT that would allow me to create directories
> locally and move into them without quitting would speed the job up
> too, I guess.
Both of these are also available by ftp from kermit.columbia.edu,
msvibm.zip is the pc Kermit and C-Kermit is the Unix version. Both
have extensive script handling features and the pc version has an
excellent VT terminal emulator too.
Billy Y..
John Wilson
In article <6232po$6...@nntp02.primenet.com>, <bi...@mix.com> wrote:
>All you need here on the PDP-11 is a Kermit server, so John's would
>work fine. I don't know what his maximum packet length is, the current
>RT-11 Kermit (KRT) is distributed with a 1920 byte maximum, or can be
>rebuilt to be bigger, although not a whole lot bigger unless you use
>separate I&D space (RT-11 V5.6 is needed for this though).
KRT's packet length kicks KSERVE's butt, the current KSERVE version only does
classic 94-byte packets and the forthcoming one is limited to 120 on input
(but output can be more) due to the RT-11 TT: ring buffer -- I haven't
investigated how to get around this, I suspect that in V4.0 the only way is
to seize control of the input half of the console DL11, assuming it's really
a DL11, anyway that seems like asking for it.
John Wilson
D Bit
Jerome Fine
>Bob wrote:
>I may be given the task (I hope so, I need the money ...) of migrating
>a large number of files from RT11 RX01 diskettes and RL01/RL02 packs
>to a PC.
Jerome Fine replies:
I agree that if you can get Kermit working and you have the time to wait,
a serial line transfer is the easiest way. I was once given an 11/73 that
normally ran TSX-PLUS with about 300 MBytes. It took many days, but
was real easy after it started - just leave them alone and they will come......!
However, if you are in a hurry and you can beg or borrow a controller for
that 11/73 in your museum for the RL02s (M8061 I believe), then you
have cleared the first hurdle. Since I doubt that you have a compatible
floppy on both the 11/34a and the PC, I am suggesting this route only as
an alternative. THEN, do you have the same size floppy on the PC and
the 11/73 - especially if you have an RX33 which is identical (at the
hardware level) with the HD 5 1/4" floppy on the PC? If so, you
can write up to about 2800 blocks of files on the floppies (for RX33)
and up to 800 blocks for the RX50. No problem on the PC with
PUTR from John Wilson. Note that an RX33 must have an RQDX3.
The RX50 can run also run on either an RQDX2 or and RQDX1.
I realize this is very brief and with a lot missing. However, if you
can't hook up the RL02s to the 11/73 and don't have the same
size floppies on both machines, then Kermit is a simple solution.
Sincerely yours,
Jerome Fine
Tim Shoppa
The only RKV11D that I have seen recently in person was hacked to
support 18 bit addressing. It's supposedly pretty simple, but
I wasn't the one who did it, so the details I can supply stop there. Care to
remind me of the details again, Alan? :-)
Tim. (sho...@triumf.ca)
Tim Shoppa
>>I may be given the task (I hope so, I need the money ...) of migrating
>>a large number of files from RT11 RX01 diskettes and RL01/RL02 packs
>>to a PC.
>
>
>One thing you must not do. DO NOT place RL01 packs in an
>RL02 drive OR RL02 packs in an RL01 drive. The results
>will probably be a disaster!!!!!!!!!!!!!!!!!!!!!!!@#$%^&(*
No, it won't be a disaster. The drive will never go "ready" because
it won't quite be able to lock onto the servo information, and as long
as the drive doesn't go "ready" write current to the heads will
be disabled.
Note that later RL01's and all RL02's have boards which can be
switched between RL01 and RL02 modes by moving jumpers. I've
worked on systems where some clever person installed relays in
place of all the jumpers and wired them to a front panel switch
in the position the "FAULT" light is at. This hack was good enough
to let RL02's read RL01's; I don't think I ever tried writing.
>I have never hear of, let alone seen RK05s running on a QBus
>machine, although there is no reason for DEC to not have made
>a Qbus controller for the RK05s. However, RL01s/RL02s
>run fine on both Unibus/Qbus
Don't forget Omnibus, too :-). Then there's the 11/730 Integrated
Drive Controller, which used the bitslice CPU and microcode
to bit-bang *both* RL02's and R80's. And I believe an even more esoteric
piece of hardware interfaced some VAX console processors to the
RL02 used as console medium. (I could be wrong about this last point,
but I know that the console RL02 on some VAXen would work even when
the main CPU and its Unibuses were kaput.)
Tim. (sho...@triumf.ca)
Tony Duell
John Wilson (wil...@dbit.com) wrote:
: In article <34454D5B...@idirect.com>,
: Jerome Fine <jhf...@idirect.com> wrote:
: >I have never hear of, let alone seen RK05s running on a QBus
: >machine, although there is no reason for DEC to not have made
: >a Qbus controller for the RK05s.
: I've never seen one in person but one of the handbooks shows an RKV11D,
: which is the usual RK11D hacked to work with Q-bus (one board different I
It exists, but it's not exactly common...
It's a 2U rack (same box as one of the 4-slot Q-bus units, but with a different
backplane) containing 4 boards. 3 of them are identical (same M-number) as
3 of the RK11-D boards, the other one is custom, and contains 4 40 pin BERG
connectors (and a lot of chips). 2 of the connectors link to a dual-height
Q-bus board that goes into a normal Q-bus slot, the other 2 link to a
paddleboard that goes into the RK05 (it's the same paddleboard as is used
with the RK8-E, BTW).
: think?). If the docs are correct, it only supports 16-bit DMA addresses,
: so I guess it dates back to the original LSI-11 days, pretty useless now.
AFAIK it is only 16 bit as supplied but that extending it to 18 bit is
quite easy. One day I'll have a go...
: John Wilson
: D Bit
-tony
Johnny Billquist
On 16 Oct 1997, Tim Shoppa wrote:
> Don't forget Omnibus, too :-). Then there's the 11/730 Integrated
> Drive Controller, which used the bitslice CPU and microcode
> to bit-bang *both* RL02's and R80's. And I believe an even more esoteric
> piece of hardware interfaced some VAX console processors to the
> RL02 used as console medium. (I could be wrong about this last point,
> but I know that the console RL02 on some VAXen would work even when
> the main CPU and its Unibuses were kaput.)
Actually, I think I can fill you out on that one, Tim.
The only VAXen I know of that has an RL02 is the 86x0 machines. These also
happens to have a front end PDP-11, F-11 based actually. This little
machine is the one who really has the RL02, and it's conntected on a
normal RLV11 controller. The VAX can then talk to the RL02 through the
front end processor, so that's why it might work even if the main CPU and
it's Unibus were kaput. (Well, if the CPU is kaput, then it won't be able
to talk to anything, but since the operator normally talks with the front
end anyway, he/sho can still see the RL02.
Incidentally, the front end on the 86x0 actually boots a version of RT-11.
You can even get to the normal promt and play around on the RT-11 system
on the RL02, if you care to.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Ethan Dicks
In article <EI4z2...@fsa.bris.ac.uk>, Tony Duell <a...@siva.bris.ac.uk> wrote:
>
>[ The RKV11D ] exists, but it's not exactly common...
I've got one attached to an 11/03. It worked the last time it was powered
on, but that's been 5 years.
>...paddleboard that goes into the RK05 (it's the same paddleboard as is used
>with the RK8-E, BTW).
Cool! I've got several -8's as well (-8, 8/L, 8/i, 8/e, 8/a...) All
I need then, is the RK8-E board set (and an RK05-F, because my only 16-sector
pack is an -F pack) :-P Anyone out there looking for 12-sector packs?
>: think?). If the docs are correct, it only supports 16-bit DMA addresses,
>: so I guess it dates back to the original LSI-11 days, pretty useless now.
>
>AFAIK it is only 16 bit as supplied but that extending it to 18 bit is
>quite easy. One day I'll have a go...
How does one a) hack an RKV11D and b) tell if it's already hacked?
-ethan
--
Ethan Dicks http://www.infinet.com/~erd/
(dicks) at (math) . (ohio-state) . (edu) sellto: postmaster@[127.0.0.1]
harvestbot fodder: pres...@whitehouse.gov fcc...@fcc.gov root@[127.0.0.1]
John Wilson
In article <tsw-161097...@cypher.cagent.com>,
Tom Watson <t...@cagent.com> wrote:
>Others have posted some commercial solutions to the "problem" but it
>really isn't that bad. The basic 8" floppy uses the same data rates as a
>1.2Meg 5 1/4" floppy. The big problem is the connector. The 8" drive
>uses a 50 pin connector, and the 5 1/4" drive uses a 34 pin connector.
>All of the signals are there, but as usual, IBM long ago diddled with
>things a bit.
FYI this isn't quite 100% true, the 34-pin interface is missing TG43
and the 2SIDE pin and I think there's a READY pin. Also the 8" disk
uses a head load pin but not a motor-on pin (the 8" motor runs all the
time). You can get around most of these, and you don't need TG43 for
reading (some drives keep track of the current track themselves and
don't need TG43 at all), but for writing I imagine you could get into
trouble if you don't reduce the write current on inner tracks using
this pin. Some PC FDCs (like the 37C65) generate the TG43 (a.k.a. /RWC)
pin but only under certain circumstances (the 37C65 has 3 different modes,
I think this pin is used for /RPM in AT-compatible mode), the CompatiCard
IV has a software-programmable output for setting it (which PUTR does),
and I guess you could use a LPT port pin with an OC driver to do it from
software. The PC doesn't have a use for the 2SIDE or READY pins though
so those don't matter.
John Wilson
D Bit
Carl R. Friend
Tim Shoppa, in article nr. <625olp$frk$1...@nntp.ucs.ubc.ca>, wrote:
> I seemed to recall a 86x0-size machine which used a PRO 350/380 as
> the console and a RL02 as a console device.
The 85xx systems used a PRO 350 as a console front-end but didn't
use an RL02 as the storage medium. Rather, they used a small RD (?)
device internal to the PRO cabinet. The PRO is labelled "VAX Console".
I recently rescued a VAX 8550 from my employer and am looking into
getting 3-phase power installed (at the RCS Mill) to possibly run it.
--
______________________________________________________________________
| | |
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:carl....@stoneweb.com | |
| http://www.ultranet.com/~engelbrt/carl/museum | ICBM: N42:22 W71:47 |
|________________________________________________|_____________________|
John Wilson
In article <RJM.97Oc...@europa.ox.ac.uk>,
Bob <r...@europa.ox.ac.uk> wrote:
>Any idea how to interface an 8" drive to a PC? Would I need a Shugart
>What software would I use under DOS to read RT11 volumes? (I think I
>have it, but I forget it's name).
A Shugart SA8xx compatible drive uses a very similar interface to the
usual SA4xx 3.5"/5.25" interface so you should be able to use one with
a trick cable. Micro Solutions sells such cables for their CompatiCard IV
floppy controller, which also has a working single density mode, which is
unusual in PC FDCs these days. PUTR (ftp.dbit.com/pub/putr/putr.com)
includes support for RT11 (or OS/8) RX01 disks using this setup, I still
haven't got my own 100% working 8" setup so I haven't tested it much
personally but I'm told that it works OK.
Re actual RX01/RX02 drives, these drives have most of their own "brains"
and the interface is nothing like the raw SA4xx interface used by PCs,
however it's a *lot* simpler so it ought to be pretty easy to build a
board for PCs that can use these drives. Some day... Since the PC would
have only the same access that PDP-8/PDP-11 controllers do, there'd *still*
be no way to format fresh disks with these drives though. So the best deal
would be to have one of each, since the SA8xx route wouldn't work with RX02
disks since their format is different from what the PC FDCs can handle,
RX01s are fine though.
John Wilson
D Bit
Tom Watson
>
> Any idea how to interface an 8" drive to a PC? Would I need a Shugart
> type drive? I take it the RX01 type drives are no use in this regard?
> What software would I use under DOS to read RT11 volumes? (I think I
> have it, but I forget it's name).
>
Others have posted some commercial solutions to the "problem" but it
really isn't that bad. The basic 8" floppy uses the same data rates as a
1.2Meg 5 1/4" floppy. The big problem is the connector. The 8" drive
uses a 50 pin connector, and the 5 1/4" drive uses a 34 pin connector.
All of the signals are there, but as usual, IBM long ago diddled with
things a bit. They use a "twist" between the A & B drives to change the
selects, and because they needed to turn the motors on and off, they
flipped that signal as well. Most 8" drives have no motor control signal
(always on), so it really isn't a problem.
Why do I know about this?? I have a machine at home that uses (normally)
8" drives, and I've successfully hooked up 1.2Meg 5 1/4" floppies to it.
The biggest problem is the normal 8" drive has 77 tracks, but the 5 1/4"
one has 80 tracks. The other parameters (data rate [250/500k bits/sec],
rotational speed [360 RPM]) are the same.
Transferring of data via floppy disks? I'd use something that writes DOS
formatted files to the drive. The 'mtools' package (Linux) or 'dosread'
(Minix) can make these type of files (assuming you have the ability to
access the drive sector by sector). I suspect that reading the RT11
floppy on a PC would be the more difficult task. It would be doable, but
I don't know about the software that exists.
If anyone is interested, I'll go look at the little jumper block that I
built that converts the 50 pin 8" connector to the 34 pin 5 1/4"
connector. It is two IDC connectors with a bunch of wires. It costs less
than $10. to build (if you can get the parts).
That ends the hardware lesson for today, we now return you to the
regularly scheduled newsgroup.
--
t...@cagent.com (Home: t...@johana.com)
Please forward spam to: anna...@hr.house.gov (my Congressman), I do.
Tim Shoppa
In article <Pine.VUL.3.93.971016...@Zeke.Update.UU.SE>,
Johnny Billquist <b...@update.uu.se> wrote:
>> to bit-bang *both* RL02's and R80's. And I believe an even more esoteric
>> piece of hardware interfaced some VAX console processors to the
>> RL02 used as console medium. (I could be wrong about this last point,
>> but I know that the console RL02 on some VAXen would work even when
>> the main CPU and its Unibuses were kaput.)
>
>Actually, I think I can fill you out on that one, Tim.
>
>The only VAXen I know of that has an RL02 is the 86x0 machines. These also
>happens to have a front end PDP-11, F-11 based actually. This little
>machine is the one who really has the RL02, and it's conntected on a
>normal RLV11 controller. The VAX can then talk to the RL02 through the
>front end processor, so that's why it might work even if the main CPU and
>it's Unibus were kaput.
OK, I must've been confusing things. I seemed to recall a 86x0-size
machine which used a PRO 350/380 as the console and a RL02 as a console
device. I think I may have been merging two different console systems
in my head :-).
Tim. (sho...@triumf.ca)
Varga Akos Endre
> The 85xx systems used a PRO 350 as a console front-end but didn't
> use an RL02 as the storage medium. Rather, they used a small RD (?)
> device internal to the PRO cabinet. The PRO is labelled "VAX Console".
Hm, I saw two of those boxes in a basement. Okay, there were two
surplus 8550s too, one beeing completly okay, this we will take
home if we can find some place and 3-phase for it:) But about those
VAX Consoles, can they be used as standalone boxes? I'm mean is
there a point to use them so? ;-)
Akos Varga
ham...@netweb.hu
Chuck Guldenschuh
In article <Pine.LNX.3.96.971017083214.14918B-
100...@pc0176sd.sysdata.siemens.at>, ham...@pc0176sd.sysdata.siemens.at
says...
to 350's (F11).
They probably could be used standalone. There's one board that
would probably need to be removed. I think that the interface
board to the 85xx was some IEEE bus variant (but I could be
REALLY off-base). The software installed on it was a cut-down
version of P/OS, with the VAX Console stuff layered on.
The hard drive was probably an RD53 (33MB?) or possibly an RD54
(65MB), so if you could find the appropriate software, you could
certainly run P/OS or RT-11 on it. As to useful, I couldn't say.
/s/ Chuck Guldenschuh
Don Stokes
Varga Akos Endre <ham...@netweb.hu> wrote:
>Hm, I saw two of those boxes in a basement. Okay, there were two
>surplus 8550s too, one beeing completly okay, this we will take
>home if we can find some place and 3-phase for it:)
Don't bother. They're big, noisy, power-hungry, impossible to get parts
for, and DEC never quite got all the bugs out of memory system. (They
got to the point that they just refused to replace memory showing
correctable errors, because all memory for these beasts showed errors.
I think the MCL design was just stuffed, or the bus was being pushed
beyond its real limit, or something. Using the later PMCL cards didn't
help.)
Twice the power of your MicroVAX III, but at twenty times the running costs,
I'm not sure the extra grunt is worth it. MTBF isn't spectacular either --
they lack the sheer robustness of the Qbus systems.
>But about those VAX Consoles, can they be used as standalone boxes?
They're (mostly) DEC Pro 350s. F11 (11/23) CPU, not-compatible-with-anything
I/O bus. Work OK tho. There's an interesting little I/O card in them to
talk to the VAX, but otherwise they're common garden Pros with twin floppies
(RX50) and an RD52. You'll probably want to disable the bit that runs
the VAX Console software.
>I'm mean is there a point to use them so? ;-)
That's arguable. 8-) They run a bastardised version of RSX-11M-PLUS (or
is it more akin to basic RSX-11M?) called P/OS. I believe there was
development kit, although you might be able to get development tools
off another RSX system. DECUS C exists for RSX, I assume for P/OS as
well.
RT-11 has been known to run on these beasts as well.
The other trick would be to grab the RD52 out of one for the VAX -- you'll
need to reformat it, and it's only 30M, but it can be handy to have an extra
disk. I once loaded the base VMS saveset onto an RD52 and fiddled the
startup so as not to install the rest of the kit (since it wouldn't fit);
I then used this proto-VMS system to recover an un-backed-up system disk
that had track 0 scrozzled by a hardware, uh, misconfiguration. (Losing
track 0 usually wipes out the first home block and the root directory, both
of which are essential to the bootstrap process.) If nothing else, it's a
good place to put a "rescue" filesystem or Standalone BACKUP (for VMS
systems). The RD52 is one of the better of the RD5x drives, reliability-
wise. It's also one of the heaviest power users -- you need to do some
quick sums before putting one into a BA23 alongside another hard drive.
--
Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724
Network Design, Cable Plans, LANs, WANs, Radio Networks, Internet Consulting
Don Stokes
Terry Kennedy <te...@spcuna.spc.edu> wrote:
> For CPU power + ease of adding reasonable disks, not much beats the VAX-
>station 3100's. I had some 30's and 40's that I sped up to 38's and 48's (if
>you have the right rev CPU board it's a crystal swap, and if you care about
>the CPU ID you can change the 2 firmware ROMs). And the Model 76 at between
>7 and 8 VUPS has come way down, too. All of these can be had with a SCSI
>adapter for hanging large disks on the box.
Huh? I thought _all_ the 3100s had SCSI.
> Of course, the best offer I got on a VAX 4000-500 CPU card was $350, and
>I built a whole system out of it for under $1500 (CPU, 64MB, 2GB RF73, TK70)
>so those should be hitting the hobbyist range soon for people who are looking
>for a larger, faster box. I've seen 4000-200's in dumpsters.
In _your_ dumpsters, maybe. I'm not sure how many 4000/200s are in
Hungarian dumpsters, and I haven't seen too many around these parts.
bi...@mix.com
Don Stokes <d...@news.daedalus.co.nz> writes:
> RT-11 has been known to run on these beasts as well.
It works fine and the supplied comm handler (XL) even talks to the
serial port on them (after sysgenning, that is)...
Billy Y..
Tim Shoppa
In article <62cu30$b...@wnnews1.netlink.net.nz>,
Don Stokes <d...@news.daedalus.co.nz> wrote:
>Terry Kennedy <te...@spcuna.spc.edu> wrote:
>>the CPU ID you can change the 2 firmware ROMs). And the Model 76 at between
>>7 and 8 VUPS has come way down, too. All of these can be had with a SCSI
>>adapter for hanging large disks on the box.
>
>Huh? I thought _all_ the 3100s had SCSI.
No, not all. The earliest ones had disk controllers which handled
MFM hard drives and non-SCSI floppy drives. Then for a while
there were controllers that did the above *and* had one SCSI port.
Then came the two-SCSI-port ones with no floppy or MFM controllers.
And most 3100's were available with no disk controller at all, if
you chose to order them that way.
Tim. (sho...@triumf.ca)
Terry Kennedy
Nope. There's complete diskless (I think that was a special [aka CSS] option,
though), ST506/ST506, ST506/SCSI, and SCSI/SCSI.
> In _your_ dumpsters, maybe. I'm not sure how many 4000/200s are in
> Hungarian dumpsters, and I haven't seen too many around these parts.
True. This stuff seems more common in the US, for some odd reason 8-)
It's available pretty cheap here, though, even if you have to buy it - I
got some R400X's (DSSI expansion cabinets) and a BA440 (CPU cabinet for the
high-end 4000's) for $150 each from a used equipement dealer a few months
ago.
I don't know what the shipping for something like that would be, but the
low-end 4000's (4000-200, etc.) are Q-bus CPU's and international shipment
for just the boards should be pretty inexpensive (they'll work in a BA23/
BA123).
Heck, I once packed up 3 8650's worth of boards for shipment to Sweden,
but they vanished somewhere between being picked up here and being delivered
to Sweden (much to Johnny's disappointment).
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA
+1 201 915 9381 (voice) +1 201 435-3662 (FAX)
Varga Akos Endre
> Varga Akos Endre <ham...@netweb.hu> wrote:
> >Hm, I saw two of those boxes in a basement. Okay, there were two
> >surplus 8550s too, one beeing completly okay, this we will take
> >home if we can find some place and 3-phase for it:)
>
> Don't bother. They're big, noisy, power-hungry, impossible to get parts
> for, and DEC never quite got all the bugs out of memory system. (They
Well, but it happens to be, that we like big noisy machines:) Maybe
the other 8550 in that basement could be our spare-part shop :)
The 8550 itself is maybe slow and stuff, but if we want speed and
co, there are an Alpha and an Ultra in our 'club', so we don't
want the 8550 to do hard jobs. It would be just for fun. Pervert,
but we're not alone, I'M SURE;)
> >But about those VAX Consoles, can they be used as standalone boxes?
> >I'm mean is there a point to use them so? ;-)
>
> That's arguable. 8-) They run a bastardised version of RSX-11M-PLUS (or
> is it more akin to basic RSX-11M?) called P/OS. I believe there was
> development kit, although you might be able to get development tools
> off another RSX system. DECUS C exists for RSX, I assume for P/OS as
> well.
You've just convinced me to borrow one of them. I wonder if they're
working though... Well, we could give it a shot. We're planning to
make a 'museum'...
> The other trick would be to grab the RD52 out of one for the VAX -- you'll
Yes, that's a good idea too:)
Thanks for your time!
Akos Varga
ham...@netweb.hu
Don Stokes
Varga Akos Endre <ham...@netweb.hu> wrote:
>Well, but it happens to be, that we like big noisy machines:) Maybe
>the other 8550 in that basement could be our spare-part shop :)
>The 8550 itself is maybe slow and stuff, but if we want speed and
>co, there are an Alpha and an Ultra in our 'club', so we don't
>want the 8550 to do hard jobs. It would be just for fun. Pervert,
>but we're not alone, I'M SURE;)
I just can't imagine any possible reason for wanting to collect a Nautilus
(85x0, 8700, 8800). A computer is collectable if it's:
Well engineered
Historically significant
Popular
First of a significant series
The Nautilus was none of these things. People only bought them because
they were the biggest VAX available. Engineering-wise, they're a lovely
example of the principle that pigs fly just fine given sufficient thrust.
I've never met anyone who thought there was anything lovable about them.
They were closed-architecture, buggy, and backward technology-wise -- at
the time they came out it was already clear that CMOS was going to take
over, and the 3000 series was almost ready. It took DEC a little while
to realise that ECL dinosaurs (which only avoided blowing themselves
around the machine room with their cooling systems due to the sheer weight
of the cabinets required to contain them) were not the way of the future,
and that pissing off the customers by ensuring that third party suppliers'
cards were just as (horrendously) expensive as DEC's was not a good way
to make the customers keep coming back.
Basically, the release of the Nautilus, the BI and the events surrounding
them, were not among DEC's greatest achievements.
Don Stokes
Terry Kennedy <te...@spcuna.spc.edu> wrote:
>Don Stokes <d...@news.daedalus.co.nz> writes:
>> Huh? I thought _all_ the 3100s had SCSI.
> Nope. There's complete diskless (I think that was a special [aka CSS] option,
>though), ST506/ST506, ST506/SCSI, and SCSI/SCSI.
Oh, OK. I've never seen a 3100 that didn't have SCSI. But then there's
what is in the catalogue, and what the local office decides it's gonna sell
& support, and the two ain't the same...
> I don't know what the shipping for something like that would be, but the
>low-end 4000's (4000-200, etc.) are Q-bus CPU's and international shipment
>for just the boards should be pretty inexpensive (they'll work in a BA23/
>BA123).
Might take you up on that. (Is there anyone here not running something
that's come from or at least via your junk room?) What is the going rate
for a 4000/200 CPU & memory?
4000s never seemed too popular here -- folks here seemed to hold out for
the equivalent 3100 models, which were much cheaper in themselves and
offered cheap SCSI storage instead of expensive DSSI disks.
Varga Akos Endre
> I just can't imagine any possible reason for wanting to collect a Nautilus
> (85x0, 8700, 8800). A computer is collectable if it's:
> Well engineered
> Historically significant
> Popular
> First of a significant series
>
> The Nautilus was none of these things. People only bought them because
> they were the biggest VAX available. Engineering-wise, they're a lovely
But I do think that you should not only remember good things in life,
the not-that-fab things should get preserved aswell... All architectures
had ups and downs (some just downs:), and if you scrap everything you
don't like, you'll regret. They should be displayed with a lebel on
them that says: "Kids, don't try that..." ;-)
Akos Varga
ham...@netweb.hu
Don Stokes
>the not-that-fab things should get preserved aswell... All architectures
>had ups and downs (some just downs:), and if you scrap everything you
>don't like, you'll regret. They should be displayed with a lebel on
>them that says: "Kids, don't try that..." ;-)
Well, by all means, keep the brute, but don't forget to put a notice
saying "junk me first" on it for when space starts getting tight.
There's a difference between a museum and a room full of junk.
Just considering what should be kept -- of the pdp11 & VAX lines, I'd keep
(space etc permitting):
pdp11/20 First pdp11.
pdp11/45 First pdp11 capable of running a real timesharing, native,
protected OS. Main development of Unix on this machine.
pdp11/70 Biggest production 11. 22 bits, native MASSBUS direct to
memory system. (A /45 with bipolar memory was slightly
faster CPU-wise, but couldn't match the /70 on I/O bound
loads.)
pdp11/03 (or at least the KD11 CPU) first microprocessor 11, first
16bit microprocessor(?)
pdp11/74 (if you can get one!) Not a big player in the 11 game, since
the number installed anywhere (including inside DEC) can be
counted on the fingers of one hand, but a legend all the
same...
VAX 11/780 32 bits in a minicomputer, the Original Unit of One[1].
VAX 11/750 Not spectacular technically, very much a 780 in a smalled
box, with most of the good bits removed to make it fit,
but became the VAX for the rest of us, until the MicroVAX II.
pdp11/73 J-11 chipset, the "11/70 on a chip" (well, minus the cache
and the I/O system and ...) Last DEC 11 CPU; all subsequent
11s were based on the J-11. (Or did the T-11 come after
this?)
MicroVAX II VAX on a chip. The 78032 was technologically a cul-de-sac,
but it clearly indicated that the future was not in big ECL
dinosaurs.
VAX 9000 As big as the VAX could get. State of the art in air-cooled
systems. (Although the 9000's code name, Aquarius, indicates
water cooling in early designs...)
pdp11/93 Last DEC-produced pdp11.
MicroVAX 3100/90 VAX joins the 90s. CMOS NVAX chip offers performance
comparable to RISC-based systems, at a comparable price.
CPU produced on same fab lines as EV4 Alpha. SCSI-based
I/O produces well-balanced system.
I'm tempted to add the uVAX III or original 3100 as the start of the CMOS
microprocessor VAX series (the 3100 gets an extra point for being the point
where DEC finally got the hint about its policies regarding expensive DEC
proprietary disk subsystems vs cheap SCSI disks), the F-11 based 11s
(memory management on a micro), the Pro (personal pdp11) and the MicroVAX
2000 (personal VAX), but I think the list is long enough. 8-)
(Actually, the PDT-11/150 ought to qualify as a personal pdp11, but for
reasons I'll never understand, was marketed as an intelligent terminal
instead. Ran RT-11 from floppies just fine. Maybe the small "personal"
systems would be best left out -- DEC's record in these, from the Robin
to the VAXmate, is a bit depressing.)
I haven't included the PDP-10 series, since they weren't a big part of
computing life in these parts -- only two were sold in NZ, both to the
Health Computing Services project, something the NZ computer industry would
rather forget. Of the two -10s, one was sold/given to the University of
Auckland, the other shipped to a university in Australia (I forget which
one). I've seen bits of both of these machines -- the one shipped to Aus
was at least partly housed in Max Burnet's collection, along with the few
remaining parts of the UWA's PDP-6. (I assume these are now part of the
Australian Computer Museum. John?) The other -10's front panel was
lurking in a corridor at the DEC office in Auckland.
[1] From Max Burnet's NOP SIG poster.
Varga Akos Endre
[VAX8550]
> Well, by all means, keep the brute, but don't forget to put a notice
> saying "junk me first" on it for when space starts getting tight.
:)
> pdp11/20 First pdp11.
Don't know if there ever was a /20 around here. Well, I'm going to
find out soon:)
> pdp11/70 Biggest production 11. 22 bits, native MASSBUS direct to
I think we may get one of these... Maybe... (and of course when we
found the place for them)
> pdp11/74 (if you can get one!) Not a big player in the 11 game, since
^^^^^^^^^^^^^^^^^
I don't think so :)
> VAX 11/780 32 bits in a minicomputer, the Original Unit of One[1].
... and its hungarian clone, called (I think) the TPA580
There is on of these units with 2 slave processors, it should
be interresting they say...
> MicroVAX II VAX on a chip. The 78032 was technologically a cul-de-sac,
We allready have a few of them, but since they're so cute and small,
everyone of us wants one for home 'use'
> VAX 9000 As big as the VAX could get. State of the art in air-cooled
Hm, I think there are only 3 9000s in Hungary, and two of them was
smuggled in...:) Really, when DEC Hungary was launched, they couldn't
believe their eyes, that those machines are there... But it was such a
big secret, that it wasn't a "VAX9000" for the outsiders, but a
"TPA11-9000"... And then the Iron Curtain came down...
> systems. (Although the 9000's code name, Aquarius, indicates
> water cooling in early designs...)
Water cooling? Really?
> I'm tempted to add the uVAX III or original 3100 as the start of the CMOS
Well, I've allready got one;)
> (memory management on a micro), the Pro (personal pdp11) and the MicroVAX
If we count the Vax Conolse for a PRO, then it could be done...
> 2000 (personal VAX), but I think the list is long enough. 8-)
Yes, a couple of 2000s...
> I haven't included the PDP-10 series, since they weren't a big part of
Hm, and then we could collect IBM 360s, and 370s and... and...
But it is nice to play with the thought of such a collection.
Akos Varga
ham...@netweb.hu
Andy Stewart
In article <623rfs$9eu$1...@nntp.ucs.ubc.ca>, sho...@alph02.triumf.ca (Tim Shoppa) writes:
> In article <34454D5B...@idirect.com>,
> Jerome Fine <jhf...@idirect.com> wrote:
[lots cut out]
> ... And I believe an even more esoteric
> piece of hardware interfaced some VAX console processors to the
> RL02 used as console medium. (I could be wrong about this last point,
> but I know that the console RL02 on some VAXen would work even when
> the main CPU and its Unibuses were kaput.)
>
> Tim. (sho...@triumf.ca)
The VAX 86x0 had a T11 buried in it's guts that had dual cables coming out
and down to the Unibus box below (?) the RL02 console media.
There was a Q-Bus backplane (DDV11?) mounted in this Unibus box with
an RLV12 RL02 controller, a Q-Bus extender card and a Q-Bus terminator card.
RT-11 was running on the T11.
The VAX-11/780 had a real LSI-11 on a Q-Bus to talk to the RXV11 / RX01.
The VAX 85x0/8700/8800 used the PRO-380 as the Console.
NB. The later VAX 88x0 used a MicroVAX II as the Console.
I think all the other VAXen either had the Console implemented in Microcode
(eg VAX-11/750) or as VAX Instruction code ROMs (eg MicroVAX 3100)
Another exception might be the VAX 9000.
My two cents worth, Andy.
Megan
stewar...@decus.org.au (Andy Stewart) writes:
>The VAX 86x0 had a T11 buried in it's guts that had dual cables coming out
>and down to the Unibus box below (?) the RL02 console media.
>There was a Q-Bus backplane (DDV11?) mounted in this Unibus box with
>an RLV12 RL02 controller, a Q-Bus extender card and a Q-Bus terminator card.
>RT-11 was running on the T11.
Yes, and I spent a couple of very late days in marboro working on
console code for the beast based on the XL driver (which may still
be a conditional assembly - look for the VE$NUS conditional). I
finally got it working, and proceeded to use it to dial a modem and
connect to the RT development system back in the Mill for the first,
and probably only, mail sent using that incarnation of console code.
Megan Gentry
Former RT-11 Developer
+--------------------------------------+-------------------------------------+
| Megan Gentry | tcp/ip (work): gen...@zk3.dec.com |
| Unix Support and Engineering Group | or: gen...@rusure.enet.dec.com |
| Digital Equipment Corporation | (non-work): m...@world.std.com |
| 110 Spitbrook Rd. ZK03-2/T43 | URL http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "Still real-time after all these |
| (603) 881 1055 | years." |
+--------------------------------------+-------------------------------------+