Subject: RE: ISA Expansion Box

From: "Cini, Richard" <[email-masked]>
Date: Mon Apr 28 08:14:00 2003

I have one of these boxes. It appears that IBM took another PC case off the
assembly line, stuck in a power supply and a passive backplane. There are
two interface cards, one for the PC and one for the expansion box, connected
by a very stiff cable -- don't recall what's on them but probably buffering
ICs and the like. The cable is about 3/4" in diameter. It terminates in
D-shell connectors but I don't recall the pin count (probably D50). The
stiffness of the cable borders on inflexible and mine pops-out of the metal
shell constantly.

Rich

-----Original Message-----
From: Ethan Dicks [mailto:[email-masked]]
Sent: Thursday, April 24, 2003 11:42 AM
To: [email-masked]
Subject: Re: ISA Expansion Box

--- pmulry <[email-masked]> wrote:
> i've never actually seen one of these.  If somone has clear pics can they
> make them available for download. if not to complicated might be able to
> make one using an isa riser card that came with an old 486. do they
> connect to serial port or piggyback an isa slot?

They are a box with a passive ISA back plane and a pair of ISA cards
that are connected with a single round cable about as big around as
your thumb.  The box itself is styled like an XT (down to the sloping
front).

-ethan
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

---

From: [email-masked] (Tony Duell)
Date: Mon Apr 28 17:33:39 2003

> assembly line, stuck in a power supply and a passive backplane. There are

Apart from the front label, it _is_ a standard PC/XT case (8 slots).

> ICs and the like. The cable is about 3/4" in diameter. It terminates in

Yes, basically buffers for all the signals. The schematics are in the 
Options and Adapters TechRef.

> D-shell connectors but I don't recall the pin count (probably D50). The

It's a DC62 connector IIRC (62 pins in the same shell as a normal 37 pin 
connector).

-tony

---

From: "Curt vendel" <[email-masked]>
Date: Wed Apr 30 00:52:37 2003

Anyone have one available for a low and decent price, I prefer the front
loaders and I need something with Quad Density as I've got varying tapes
from 800,1600 and 6250 that I need to read.

I currently have a Qualstar 3404s which only does 1600/3200, if anyone is
interested in it or wants to do a trade plus $$$

I'd love an M4 9914 but I doubt anyone is willing to part with one cheap.

Curt

---

From: Joe <[email-masked]>
Date: Tue May 6 10:48:01 2003

I just picked up a Qualstar 1260. Can anyone tell me anything about it?
What kind of interface/controller does it need? It has an interface cable
with a male D-subminiture connector with 62 pins in three rows.

    Joe

---

From: "Rick Bensene" <[email-masked]>
Date: Tue May 6 11:57:01 2003

Hello, everyone,

I recently became the owner of a nice PDP 11/34A system.  It has 248Kb
of parity RAM,
programmer's panel, RL11 w/1 RL01, RK11 w/3 RK05's, RX211 w/dual RX02
drives, EAE, DZ11, and standard console port w/RTC interrupt generator.

I've got it so that it'll boot RT-11 V5.3 from one of the RL01 packs
that I got with the
machine.  It appears that this pack also has the TSX-Plus (can't recall
the version,.. 5.1A?)
multi-user extension for RT-11 installed.  Problem is, I can't login
when I start up TSX-Plus
because I don't know the PPN's or passwords.

There's a file called ACCESS.TSX that appears to be the
username/password database, but
it appears to be stored in encoded form...I've tried dumping it in
RAD50, as well as in
HEX, OCTAL, and ASCII, and haven't been able to make heads nor tails of
it.

Does anyone know the structure of this file, and how it is encoded?  I'd
like to be able
to get a few ports running on the DZ11 and see how it performs in a
timeshared RT-11
environment.

My long term goal is to get RSTS/E up and running on the machine.
According to some of
the docs, it's possible to run RSTS/E on an 11 with 1 RL01 and 2 RK05's,
which I should
be able to do, though I've not hooked up the RK11 (it has the RK11's
backplane
installed, but I've removed the UNIBUS jumper that connected the main
backplane
to the RK11's backplane and installed the terminator in its place) and
RK05's as yet.

Another issue I've got is that the machine gets unstable when I put the
RX211 controller
in.  Sometimes the system behaves with it in place, other times, it
doesn't.
I have made sure that the NPG jumpers are removed on the backplane slots
that the RL11 and
RX211 are installed in (the last two slots on the 9 slot backplane).
The UNIBUS is properly terminated.  When the system behaves with the
RX11 in place, I can intermittently
read/write floppies, but, it's intermittent, and when it's not working,
the whole machine
gets pretty confused.  The RX211 has its switches set to the standard
settings as
documented in the RX211 uuser's guide, and the interrupt priority header
is the standard
one also.  I'm a little baffled. The backplane is full with the RX211
installed.  The
+5V power on the backplane is clean, and running at +4.98V.  When I
remove the RX211 and
insert a NPG/Interrupt Grant jumper, the machine runs beautifully.  Is
this a sign of
a sick RX211, or some kind of bus loading problem?

Any help that all you DEC fans can give would be greatly appreciated.

Thanks in advance,

Rick Bensene
The Old Calculator Web Museum
http://oldcalculatormuseum.com

---

From: Ethan Dicks <[email-masked]>
Date: Tue May 6 13:04:00 2003

--- Rick Bensene <[email-masked]> wrote:
> When I remove the RX211 and insert a NPG/Interrupt Grant jumper, the
> machine runs beautifully. 

Always a good sign.

> Is this a sign of a sick RX211, or some kind of bus loading problem?

If you have multiple backplanes, bus loading is something to sit down
and calculate - each peripheral is documented (in the handbooks of the
period) with its AC and DC loads.

Having personally run 11/34s with a full BA-11 (three backplanes
including the CPU) loaded to the gills with peripherals (serial
interfaces and disk, mostly), I haven't yet run into a problem
that appeared to be bus loading.  I would suspect the RX211 if
the rest of the box seemed reasonable.

One thing to identify is what else shares its BR level.  ISTR most
DEC cards were either BR4 or BR5.  Remember that an interrupting
device breaks the grant chain for all peripherals to the rear of
the bus.  There's a small chance that the offending device is at
the same BR level as the RX211 and in *front* of it.  If possible,
try putting the RX211 at the front, then test.  No reason to leave
it there permenently - it should be a robust enough device to go
anywhere in the Unibus (which is not true of some cards on the Qbus,
especially when an RQDX1 is involved, but that's another story).

Without knowing details about the states of the Unibus arbitration
signals (that you almost certainly don't know), it's tough to guess
what might be wrong.  There is a "PDP-11 Bus Handbook" out there - 
slim and pale blue.  It contains much wisdom if you can find a copy.
Also, don't be afraid to use older docs, even back to the 11/20 - the
Unibus did evolve a little over the years (MUD slots vs SPC, etc.),
but the underlying handshaking didn't mutate much.  That's why you
can take a PDP-11/20 card and drop it in an 11/84.

-ethan
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---

From: "Rick Bensene" <[email-masked]>
Date: Wed May 7 18:32:00 2003

In response to problems that I'd mention regarding getting the RL11
controller
to happily co-exist with the RX11 Ethan Dicks said:

> One thing to identify is what else shares its BR level.  ISTR most DEC
cards were either BR4 or > BR5.  Remember that an interrupting device
breaks the grant chain for all peripherals to the 
> rear of the bus.  There's a small chance that the offending device is
at the same BR level as 
> the RX211 and in *front* of it.  If possible, try putting the RX211 at
the front, then test.  No > reason to leave it there permenently - it
should be a robust enough device to go anywhere in the
> Unibus (which is not true of some cards on the Qbus, especially when
an RQDX1 is involved, but 
> that's another story).

So, I followed this advice, and greatly so, everything worked fine.
However, I later found
that the position wasn't really the issue.  The problem was that the BR
selection
header on  the RX211 controller really squeezez the tolerance in terms
of inter-board
spacing.  What was happening is that with the RX211 behind the RL11
controller, the
BR selection header on the RX211 was apparently shorting some
connections on the back
of the RL11 controller.  So, *that's* what that fully looking piece of
semi-transparent
orangish-material that I found in the base of the cabinet when cleaning
things up...apparently
it was some kind of insulator placed on top of the header to prevent
just such shorts.
Fortunately, the shorts didn't cause any damage.  When I swapped the
boards' positions,
the interference didn't exist anymore, and everything works like a
champ.  The RL01 drive
works flawlessly, and both the RX02 drives also work great.

Here's another question for you DEC folks:

The system has the main backplane (closest to the front panel), then
there's the RK11
backplane, which is connected to the main bus by a bus jumper, and from
the last slot (A&B)
of the RK11 backplane, is another jumper which conncts to a 9-slot
expansion backplane.

Question is:  Is this correct?  Should the RK11 backplane (4 slots in
which the RK11
4-board RK11 controller plugs into) be situated BETWEEN the main bus and
the expansion
bus, or should it be located at the end?

Next question, back on the TSX-Plus password hacking part of the thread;
On one of the floppies I was given, I found a program called TSAUTH.SAV.
This program
runs from RT-11, and appears to be a tool to manage the ACCESS.TSX and
CREDIT.TSX files.
The CREDIT file appears to be a structured text file, which contains
PPN's, "user names", and privilege information for each account.  The
ACCESS file appears to be where the
passwords are strored in some encrypted form.

The TSAUTH program has just  gives the normal "*" prompt when run.  I
tried all kinds of combinations of characters for commands, and found
that it responds to "A", "L", "P", "E", and "K".  E exits the program.
The other commands result in a "PPN:" prompt.  By looking
through the CREDIT.TSX file, I could find out PPN's, so I tried entering
one of the PPN's
listed in the CREDIT file after typing the "K" command (which I assumed
means "KILL"),
figuring that would wipe out the user's entry.  It didn't.  Using
BINCOM, I backup
copies of the CREDIT and ACCESS files with the actual files, and there
was no change.
If I moved the ACCESS.TSX and CHARGE.TSX files to different names and
ran the TSAUTH
program, it complained that it couldn't find the ACCESS file, so I know
the program is
somehow supposed to manipulate this stuff.  DUMPing the TSAUTH.SAV file
results in
some text clues that make it clear that the program is an administrative
tool.
Messages such as one asking the user if they wish to make a new
authorization file,
and how many entries to reserve for users should be created.  I tinkered
with the program
for quite a while, and couldn't get it to emit those messages no matter
what I did.
The "E" command is used to exit the program -- the only command that I
could really
tell that did anything.  Does anyone have any TSX-Plus Version 5 manuals
that they could
look up this command and let me know how it works?

Many thanks to all,

Rick

---

From: "R. D. Davis" <[email-masked]>
Date: Wed May 7 20:37:01 2003

> Next question, back on the TSX-Plus password hacking part of the thread;

You mean password cracking, not hacking (refer to TNHD).  Anyway,
enough picking nits and on with the info. that you need... :-) Not
sure if Big Brother's screwey laws make it illegal to share such info.
now, but it would be wrong to not share this info., so, here goes...

Here's a copy of some info. from Usenet that others kindly provided me
with a couple of years ago... ermmm, I mean, almost a decade ago...
wow, the message headers even contain bang paths! How time flies.

|Article 1121 of vmsnet.pdp-11:
|Path: news.umbc.edu!europa.eng.gtefsd.com!MathWorks.Com!mvb.saic.com!info-pdp11
|From: Roger N Wallace <[email-masked]>
|Newsgroups: vmsnet.pdp-11
|Subject: Re: RT/11 Booting, backups, floppy duplication, CPU (was: 11/73 Cabling)
|Message-ID: <[email-masked]>
|Date: Wed, 24 Aug 1994 07:12:59 -0400 (EDT)
|Organization: Info-Pdp11<==>Vmsnet.Pdp-11 Gateway
|X-Gateway-Source-Info: Mailing List
|Lines: 53

>On 23 Aug 1994, davis robert wrote:

>> 
>> Out of curiosity, I entered "TSX" at the prompt and TSX appeared to
>> start up!  I hit a dead-end however when I couldn't get past the
>> password prompt... I couldn't guess any of the right passwords or
>> usernames.  :-( I'll take a look through the TSX-Plus manual before I
>> ask any more questions about this.
>> 

>	Fortunately (for this situation), it is very easy to circumvent 
>TSX+ security _provided_ you have physical access to the system and can
>boot RT-11.  Incidentally, TSX+ _must_ start from the single-job monitor
>under RT-11, so that monitor (or the "baseline" monitor, which is 
>essentially a "featureless" version of -SJ) is what you have.
>
>	As to getting "in" to TSX+, characteristics of each of the terminal
>lines are set in initialization "command" files, which are normally given 
>names like LINE1.*, LINE2.*, ....., where * is usually either "COM" or "TSX".
>The "TSX" extension makes editing the file [when running under TSX+] a 
>privileged operation.  LINE1 is usually assigned to the system console.  
>In some cases (which would make your task a bit more complicated) the 
>individual LINEn.* files will contain only characteristics of that particular
>line, with more general characteristics set with a call to a "LINES.*" file.
>
>	When you get to the point that you can use the RT-11 text editor "KED",
>open the LINE1.* file and look for a line like:
>
>	RUN/LOCK LOGON
>
>which, depending on TSX+ version [check the TSX+ startup banner], could be
>abbreviated to something like:
>
>	r logon
>
>Simply delete this line.  The LOGON program will then not be called when the
>line starts up, and no password prompt will appear.  If the RUN LOGON command
>is not in the LINE1.* file, check any command files _called_ by LINE1.* for
>occurrence of the command, and delete it where you find it.
>
>	Typically, the system console under TSX+ is set up to start 
>automatically as TSX+ boots.  It _may_, however, be necessary to hit a 
>carriage return to initiate the LINE1.* procedure.
>
>	You're in reasonably good shape since you apparently have running 
>versions of RT-11 and TSX+.  However, if the hard drive is a _real_ ST-412
>(or DEC RD-51) with only 10 MB, then it is likely that -- in order to save
>space -- not all system software components were installed.  
>
>						Roger Wallace

|Article 1125 of vmsnet.pdp-11:
|Path: news.umbc.edu!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!doc.ic.ac.uk!uknet!festival!unixa.nerc-murchison.ac.uk!unixa.nerc-murchison.ac.uk!not-for-mail
|From: [email-masked] (Russ Evans)
|Newsgroups: vmsnet.pdp-11,alt.sys.pdp11
|Subject: Re: RT/11 Booting, backups, floppy duplication, CPU (was: 11/73 Cabling)
|Date: 24 Aug 1994 18:41:11 +0100
|Organization: British Geological Survey (RG-N)
|Lines: 32
|Message-ID: <[email-masked]>
|References: <[email-masked]> <[email-masked]>    <[email-masked]> <[email-masked]>    <[email-masked]> <[email-masked]>
|NNTP-Posting-Host: mhua.nmh.ac.uk
|Xref: news.umbc.edu vmsnet.pdp-11:1125 alt.sys.pdp11:185

>[email-masked] (Megan) writes:
>>>start up!  I hit a dead-end however when I couldn't get past the
>>>password prompt... I couldn't guess any of the right passwords or
>>>usernames.  :-( I'll take a look through the TSX-Plus manual before I
>>>ask any more questions about this.
>
>>Sorry, I'm a sometimes TSX user, not an expert (Bob Schor?)
>
>If you can get a version of RT-11 running, you can modify the TSX+
>password/access file (ACCESS.TSX, I think) and add a new user with
>full privileges (I hope you never thought that TSX+ was at all secure!).
>The TSX+ program to do this is called TSAUTH.SAV.  You need to find 
>this and run it under RT-11.  The documentation should be included in
>the system manager component of your TSX+ manuals.  Writing from 
>memory, the syntax should be something like:
>	.RUN TSAUTH
>	* AUTH SYSTEM/PASSWORD=SECRET/PRIVILEGE=ALL
>	* EXIT
>	.
>
>You may find that the access file has been PROTECTed to provide 
>another stumbling block to the potential hacker.  Issue the command
>	.UNPROTECT SY:ACCESS.TSX
>in order to make it accessible (this won't do any harm, in any event).
>
>Alternatively, and if I recollect correctly, simply deleting the access
>file should have the effect of leaving the system entirely open.  It 
>may also be possible to turn password access off using the TSXMOD
>kernel modification utility (but I don't recall how, if at all).  On the 
>whole, I would recommend the course of action described above!
>
>Russ

|Article 1131 of vmsnet.pdp-11:
|Path: news.umbc.edu!europa.eng.gtefsd.com!MathWorks.Com!mvb.saic.com!info-pdp11
|From: Roger N Wallace <[email-masked]>
|Newsgroups: vmsnet.pdp-11
|Subject: Re: RT/11 Booting, backups, floppy duplication, CPU (was: 11/73 Cabling)
|Message-ID: <[email-masked]>
|Date: Wed, 24 Aug 1994 18:37:34 -0400 (EDT)
|Organization: Info-Pdp11<==>Vmsnet.Pdp-11 Gateway
|X-Gateway-Source-Info: Mailing List
|Lines: 25

>	The system password (default "TSX") can be changed with TSXMOD, or
>by the system operator with a "SET ..." command under TSX.  Whether an 
>individual line requires the system password can be set during SYSGEN or
>by the operator with a "SET TT n [NO]SYSPASSWORD".
>
>	Running TSAUTH from RT11 to define a new user with known password 
>will work fine, _provided_ TSAUTH is present on the system disk.  Running
>TSAUTH is a privileged operation under TSX, but can be done by anyone under
>RT-11.  For this reason, the manuals recommend not keeping TSAUTH on the 
>system disk.
>
>	Not running LOGON for a particular line will bypass all user login
>security, but will leave the requirement for the system password if it has
>been enabled.
>
>	TSX is reasonably secure if user privileges have been properly set
>and the only access to the system is through its serial ports.  But, unless
>_physical_ access to the system is controlled, anybody can boot RT11 and 
>get to any and all files on the hard drive.  MicroVAX / VAXStation systems
>are also essentially "wide open" unless physical access to the machine is 
>controlled.
>
>						Roger Wallace

|Article 1137 of vmsnet.pdp-11:
|Path: news.umbc.edu!haven.umd.edu!umd5.umd.edu!mojo.eng.umd.edu!bloom-beacon.mit.edu!cambridge-news.cygnus.com!noc.near.net!eisner!youdelman
|From: [email-masked]
|Newsgroups: vmsnet.pdp-11
|Subject: Re: RT/11 Booting, backups, floppy duplication, CPU (was: 11/73 Cabling)
|Message-ID: <1994Aug25.060322.5086@eisner>
|Date: 25 Aug 94 06:03:22 -0400
|References: <[email-masked]>
|Organization: DECUServe
|Lines: 29

>In article <[email-masked]> Roger N Wallace
><[email-masked]> writes:
>
>> 	TSX is reasonably secure if user privileges have been properly set
>> and the only access to the system is through its serial ports.  But, unless
>> _physical_ access to the system is controlled, anybody can boot RT11 and 
>> get to any and all files on the hard drive.  MicroVAX / VAXStation systems
>> are also essentially "wide open" unless physical access to the machine is 
>> controlled.
>
>Speaking as one who's run an anonymously accessable bbs under TSX for
>many years, which has been beat upon by some pretty talented people,
>yes it can be made quite secure.  There are only two things that are
>unusual enough to even be worth mentioning here.
>
>Prior to V6.4 tailgating on modem lines can be a problem, but one can
>run a small detached job on earlier versions that watches these lines
>and does the same thing (I include it (KRTAIL.MAC) with Kermit).
>
>Under any version a user can escape control of a command file if the
>application (such as a bbs message editor) allows the lead-in character
>for TSX's program controlled terminal options to be echoed back to the
>terminal - one option will cause the remainder of the command file to
>be immediately typed out.  After that the program may exited without,
>for instance, being logged off (if that's what the command file would
>have done).
>
>Billy Y..

Hopefully this is of some help.  Good luck! :-)

RDD

-- 
Copyright (C) 2003 R. D. Davis The difference between humans & other animals: 
All Rights Reserved            an unnatural belief that we're above Nature & 
[email-masked]  410-744-4900  her other creatures, using dogma to justify such
http://www.rddavis.org         beliefs and to justify much human cruelty.

---

From: Ethan Dicks <[email-masked]>
Date: Thu May 8 13:30:01 2003

--- Rick Bensene <[email-masked]> wrote:
> controller to happily co-exist with the RX11 Ethan Dicks said:
> 
> > If possible, try putting the RX211 at the front, then test.  
> 
> However, I later found that the position wasn't really the issue. 
> The problem was that the BR selection header on  the RX211 controller
> really squeezez the tolerance in terms of inter-board spacing.

Cards that use the circuit-board-based jumper plugs frequently do.

> What was happening is that with the RX211 behind the RL11 controller,
> the BR selection header on the RX211 was apparently shorting some
> connections on the back of the RL11 controller.  So, *that's* what that
> fully looking piece of semi-transparent orangish-material that I found 
> in the base of the cabinet when cleaning things up...apparently

Indeed it is.  I must confess that the possibility hadn't occurred to me
(novice vs. expert expectations and what not).  Yes.  There's supposed
to be an insulator on the top of the BR selection PCB.  The adhesive
does frequently dry out and fall off.

Very late model Unibus boards have a BR selector that looks like a DIP
resistor (yellow body, no exposed conductors).  In many cases, though,
newer designs just didn't have a selector.  The BR level was fixed.

> Fortunately, the shorts didn't cause any damage.

Frequently the case with DEC stuff... short that cause damage tend to
show it right away (with magic smoke heralding the event!)

> When I swapped the boards' positions, the interference didn't exist
> anymore, and everything works like a champ. 

Given the boards in question, an admirable solution.  It can be a problem
when you are trying to load out a DD11-DK and want to use the SPC slot
next to the terminator - I have tended to put things like LP11s there.

> The RL01 drive works flawlessly, and both the RX02 drives also work
> great.

Congrats.

> The system has the main backplane... then there's the RK11 backplane...
> (then) a 9-slot expansion backplane.
> 
> Question is:  Is this correct?  Should the RK11 backplane... be situated
> BETWEEN the main bus and the expansion bus, or should it be located at
> the end?

It kinda depends on what else is in there.  There are some peripherals
that want to be very close to the CPU because they can't buffer 
operations and would starve if some other device were in front of them.
The RL11 should have a "silo" (the RL8A does, I'm pretty sure) that
allows it to be somewhat patient about initiating transfers.  I would
expect the RK11 to be less sophisticated, and more sensitive to timing
issues.  Ethernet cards and streaming tape controllers are other classes
of devices that tend to want to be near the front.  Terminal cards and
line printer controllers tend to be more tolerant, owing to the relative
slowness of the I/O (compared to disk and network).

So... if it's there right now, I'd probably leave it, unless you run 
across a comment in a DEC handbook that suggests that it needs to be
somewhere else.  Unless you are getting data errors with peripherals
behind it, it's probably not hurting anything.
 
-ethan

---

From: "Rick Bensene" <[email-masked]>
Date: Thu May 8 17:50:01 2003

I wrote:
> > Question is:  Is this correct?  Should the RK11 backplane... be 
> > situated BETWEEN the main bus and the expansion bus, or 
> should it be 
> > located at the end?
>
To which Ethan D. replied:
 
> It kinda depends on what else is in there.  There are some 
> peripherals that want to be very close to the CPU because 
> they can't buffer 
> operations and would starve if some other device were in 
> front of them. The RL11 should have a "silo" (the RL8A does, 
> I'm pretty sure) that allows it to be somewhat patient about 
> initiating transfers.  I would expect the RK11 to be less 
> sophisticated, and more sensitive to timing issues.  Ethernet 
> cards and streaming tape controllers are other classes of 
> devices that tend to want to be near the front.  Terminal 
> cards and line printer controllers tend to be more tolerant, 
> owing to the relative slowness of the I/O (compared to disk 
> and network).
> 
> across a comment in a DEC handbook that suggests that it 
> needs to be somewhere else.  Unless you are getting data 
> errors with peripherals behind it, it's probably not hurting anything.
>  

Well, I went ahead and populated the RK11 slots with the RK11 backplane
in the 'middle' position between the main bus and the DD11-DK expansion
backplane.
I put M9202 Unibus jumpers connecting the main backplane to the
RK11 backplane, and another connecting the RK11 backplane to the DD11-DK
expansion backplane.

I carefully checked to make sure NPG & the four BG signals were getting
across the whole
bus.  I wire-wrapped jumpers on the DD11-DK expansion backplane to
provide continuity for the
four BG signals across the empty slots in the DD11-DK, and dougble
checked everything.
I powered up, no smoke or anything, but the machine wouldn't boot off of
the RL01. It
would halt at 000002, with no sign of activity on the RL01.  So, I
figured that I'd
done something wrong.  I swapped the position of the RK11 backplane to
the end of
the bus, and put the DD11-DK in the middle.  I again double-checked my
NPG and BG wiring,
and all seemed OK.  I moved the RL11 to the first slot of the DD11-DK
backplane, and
put a grant continuity card in the D section of the slot in the main bus
that was
vacated by the RL11 (and while I was working on the bus, put the NPG
jumper on that slot).
This time when I powered up, everything worked.  I can now talk to the
RL01, an RK05,
and the RX02 drives.    The mystery is why it didn't work before and did
with things
swapped around?  Oh well, sometimes mysteries are better left unsolved.
I'm just happy
that things are working...and I've got lots of slots free to populate
with other things
that I may scare up over time.

Thanks to Ethan for his great advice.  I could probably put the RK11
backplane back in the
'middle', but things are working as they are, and I've done a lot of
copying back and
forth between the RL01 and the RK05, and there doesn't seem to be any
kind of problems with
them getting in the way of each other in terms of bus timing.

Now to try to get the DZ11 in there and working.

Rick Bensene

---

From: "Rick Bensene" <[email-masked]>
Date: Sun May 18 13:10:01 2003

Hello, all,

I've been working for about the past three weeks on getting the PDP
11/34a
up and running under RSTS/E.

As a recap, the machine has 2 RX02 floppy drives, 1 RL01 drive, and 2
RK05j drives, 256Kb of
parity RAM, programmer's panel, DZ11 8-port serial mux, console serial
w/line clock, and EAE.

There were lots of fits and starts on getting all of the peripherals
working.  Most of
the problems were due to my ignorance of the characteristics of the
UNIBUS.  After getting
some tutorials from a number of folks on and off the list, I learned the
magic of
grant continuity and NPG jumpers.

In conjunction with lots of time with simh, and the wonderful program
vtserver, I now have
RSTS/E V7 running successfully on the machine.   Right now it's only got
a single terminal,
as I have to remove an NPG jumper to install the DZ11, but the system is
SYSGENed to
recognize the DZ11 when it is installed.    Learning the ins and out of
SYSGEN was
quite an experience, but in retrospect, it's an amazingly robust and
(once the concepts are
understood) relatively straightforward process.

As many indicated would occur, it's a little slow, but very usable.  The
main reason for the 
slowness is that I have to add extra swap on the RK05's, which aren't
the fastest drives in the world. The rack really shakes when running a
big program as the RK05's thrash.

Unfortunately, I don't have any RSTS documentation other than the HELP
system, and a few
tidbits that I've found on the web.  Someone needs to scan at least the
BASIC PLUS manual
and put it up on the Web for reference.

A few questions for the knowledgable out there:

1) Are RX floppy devices not file-structured devices under RSTS?  I've
tried using the standalone
utility DSKINIT program to format one, and it won't regognize DX0:.  The
DX0: device shows up in the HARDWARE list.  I can write a BASIC-PLUS
program that opens DX0: and can write data out to it, 
but it just acts like one 'file', not a file-structured device.  Is
there any way to make the floppy drives under RSTS 7 file-structured
devices?

2) I see references to BASIC-PLUS-2?  What are the differences between
BASIC-PLUS and
BASIC-PLUS-2?  I don't have any bits for BASIC-PLUS-2, but am curious
about it.

3) Does anyone know if there was a FOCAL run-time system ever built for
RSTS/E?

4) Can I take RT-11 (V4 or V5.3) .SAV programs and use them under the
RT-11 runtime system under RSTS/E? an MACRO be used to assemble/link
programs written for RT-11 to run in the RT11 runtime
systme under RSTS/E?  I suspect not, but am not sure.

5) Is there a version of KERMIT for RSTS/E V7?  Anyone know where I can
get it?

6) My 11/34a doesn't have the floating point hardware option.  I had to
SYSGEN RSTS with
software-based 16-bit floating point.  This certainly slows things down.
However, I've heard
that the FP11 significantly slows with the overall operation of the
11/34a.  Would it be worthwhile for me to find and install an FP11, or
not?

7) I have a 16-port backpanel for the DZ11.  It takes two ribbon cables,
one cable for each
of two DZ11's that can connect up to it.  I've got the right ribbon
cable for connecting the
one DZ11 that I have up to the backpanel to get 8 RS-232 ports.  Anyone
know the pinout for
the DB-25 EIA connectors on the backpanel?  I can probably figure it out
with a breakout box,
but it someone has it, all the easier.  I'm hoping to hook the 8 ports
up to a Xylogics Annex
terminal server, and be able to TELNET to it.  That way I can play with
the machine (which is out in the shop) from my office in the house.

This has been a great adventure, and a lot of fun.  Thanks to the CC'ers
who've helped
me out along the way!

Best to all,
Rick Bensene

---

From: Stan Barr <[email-masked]>
Date: Sun May 18 13:39:00 2003

Hi,

> and put it up on the Web for reference.

http://elvira.stacken.kth.se/rstsdoc/rsts-doc-v80/
http://pdp-11.trailing-edge.com/rsts11/

I've been running RSTS/E on simh for a while, but I'm no expert so
I can't help you a whole lot.

I've just started to get to grips with RT-11, and today I managed to
compile and run a program, so I'm feeling quite pleased :-)
I just need to do it on the Micro-11/73 now...

-- 
Cheers,
Stan Barr  [email-masked]

The future was never like this!

---

From: Kevin Handy <[email-masked]>
Date: Sun May 18 14:25:00 2003

>up and running under RSTS/E.
[snip]

>and put it up on the Web for reference.
As others may have told you

    http://elvira.stacken.kth.se/

but it has documentation for V8 and V9, but not V7.
V7 is quite old, and, as I understand it, anything up to V9.6 may
be used under hobbyest license. Sorry, don't know which is the
best version for a 34, but many improvements were made on the
way to 9.6.

>there any way to make the floppy drives under RSTS 7 file-structured
Were there 8 inch floppies really available to PDP11's in the V7 timeframe?
Apparently they are recognized at some level,  but I think you needed to use
a program ('fit'?) to do anything with them.

I think you may just need a newer version of RSTS to get more support.

>BASIC-PLUS-2?  I don't have any bits for BASIC-PLUS-2, but am curious
Basic-Plus is an interperture[sp], Basic+2 is a compiler.

Basic+2 also gives you access to RMS data files, and many other
enhancements, like speed and more memory available for your program,
and the ability to use modules ompiled in other languages.

>3) Does anyone know if there was a FOCAL run-time system ever built for
Probably someone did one.  Look to the DECUS archives.
Hopefully someone has recovered a atpe.

>systme under RSTS/E?  I suspect not, but am not sure.
Depends on the program. RSTS/E only implements a subset of the RT11
system, but many programs should work.

>5) Is there a version of KERMIT for RSTS/E V7?  Anyone know where I can
Should be available. Look on http://www.columbia.edu/kermit

>11/34a.  Would it be worthwhile for me to find and install an FP11, or
Depends on how much floating point you do.  Adding floating point
processor should allow you to reduce the size of the monitor/compilers.
(by losing the floating point emulation)

>the machine (which is out in the shop) from my office in the house.
Should be standard RS-232. Shouldn't be anything special about them.
Should only need pins 2,3,7 to get things started to work (assuming the
server can handle Xon/Xoff). Ad more wires as you need additional features.