                Implementing UNIX on a PDP-11/34
                               or
        What does the `F' in "RK05-F" really stand for ?

                          Dave Horsfall
                  Computing Services Unit (CSU)
                        University of NSW

        This  article is relates some of the author's experiences
in implementing UNIX on a PDP-11/34.  My efforts were  not  quite
as  straight-forward as they could have been, since all my previ­
ous experience has been with 11/40's.  This  article  will  point
out some of the major differences between the two models that af­
fect system implementation, and gives  some  advice  to  would-be
purchasers of 11/34's intending to run UNIX.

        Most  difficulties  appeared  when trying to transport an
11/40 system to the 11/34.  The first difficulty that cropped  up
(apart  from  the  lack of a console; I'll come to that later) is
the lack of a stack limit register.  This was actually the result
of  a  modification to UNIX to utilize the register should it ex­
ist, to prevent the kernel stack from smashing the per-user area.
Also,  the code to handle bus traps had a few nasty side effects.
This showed up when using `m40.s' as a basis  for  the  low  core
program.   This  meant that all code referring to the stack limit
register had to be `conditionalised'.  This affects  `mch.s'  and
`once.c'.   If  the  FPU  floating point unit is installed (as it
usually is; at least on the 11/34's I  have  seen)  then  `mch.s'
must  be changed to support it.  The CSU system generation proce­
dures assume a generalised `mch.s' program with appropriate  fea­
tures  conditionally  assembled in; `mkconf' will generate a file
to be prefixed to `mch.s'  containing  the  definitions  such  as
"FPU = 1"  etc.  `Mkconf' has been extended to recognize keywords
such as "stacklimit", "fpu" etc and generate the appropriate pre­
fix  file.   Since we generate most of the UNIX systems on campus
for PDP's of various configurations, 'mkconf' is a great help.

        The second difficulty is the lack of a conventional  con­
sole.   Given that UNIX refers to the switch register quite a lot
during various stages of booting  and  running,  this  is  indeed
quite  a  problem.  Instead of a conventional switch register and
display, there is an arrangement of little buttons and  a  seven-
segment  display,  vaguely  reminiscent  of  a pocket calculator.
There is no switch register as such; you have to button in a num­
ber  (which  appears in the display; it's quite fun just watching
it) then press a button to actually load the damned thing, where­
upon  an  LED come on to indicate that the display is indeed dis­
playing the switch register (as opposed to  displaying  something
else  e.g  the last value examined).  This lack of a display such
as `ADDR/DATA' also means that you can't tell what the system  is
doing - if it is doing anything at all.

        The boot procedure is quite funny (funny queer; not funny
ha-ha; although it does have its hilarious aspects).  While hold­
ing  down the `CNTRL' button, one presses the `HALT' button, then
the `BOOT' button.  The ROM console emulator program  then  comes
alive on the console terminal.  If you are booting from say `RK0'
you then type in `DK0' (which must be in upper case, although you
can say just `DK').  It would be a good idea at this point if the
switch register contained neither `0' nor `173030'  (for  obvious
reasons;  none  of this "Load Addr 773110; Start" business).  The
value I normally use is plain `1'.  At least there is a button to
clear  the  switch  register.   Given  that the ROM expects upper
case, and that UNIX prefers you to talk  in  lower  case,  it  is
quite easy for problems to occur here.

        The  subtitle of this article refers to the fact that the
two 11/34 systems I have installed both have an RK05-J (the  nor­
mal  one)  and an RK05-F (double density; equivalent logically to
two drives but on one cartridge).  DEC must be flogging  lots  of
these.   The implications of this is that there is but one remov­
able volume, and UNIX (for all its reliability - sorry  Ian)  re­
quires  two for effective system backups.  The second volume does
not have to be a disk; it can be a mag-tape  drive.   Given  that
you can copy half of the `F' on to the `J', followed by the other
half; the question that naturally arises is "How the hell do  you
back  up the `J' if it is not being used as pure scratch ?".  How
indeed !  The only technique is to bring up a stand-alone utility
such as `RKDF' and when the `F' is nicely backed up, you copy the
`J' on to one half of it, copy this in turn to another  `J'  then
restore said half of the `F'.  This also introduces another prob­
lem; that of recovering from file system loss.  Should a file  be
spread  over  both halves of the `F', it will naturally appear on
two `J's, and the only way to recover it (for the ordinary mortal
user) is to restore the whole damned lot in a manner analogous to
the backup procedure.  It is also possible to treat the RK  as  a
tape  and  use `dump/restor' on it.  However, you still need some
sort of emergency backup system just in case you can't  even  use
`restor'.   Ken Higgs of Water Research Laboratory can tell a few
stories about this.  In other words, one removable drive (with or
without  a  fixed drive) is not enough.  You need either a second
removable drive or a mag-tape drive as well.   Life  may  not  be
meant to be easy, but there is no point in making it hard either.

        There is another consequence of the RK05-F in  that  UNIX
regards  it as two platters, and will therefore try to initiate a
seek on one of them while the other is busy.   Needless  to  say,
this  doesn't quite work.  We modified our RK driver to implement
the concept of `concatenated volumes', in which several  contigu­
ous drives may be treated as one enormous drive with one schedul­
ing queue.  Should this then be specified  as  "optimized"  (with
the  funny  rotated  blocks)  the driver does the right thing and
plants block #1 in the middle of the  whole  virtual  disk  (this
calculation is done automatically by the driver; it knows how big
each individual drive is and hence knows where the middle of  the
whole  lot  is).  This does not work too well however on multiple
physical drives, but it is better than nothing.

        All in all, transporting UNIX  from  a  PDP-11/40  to  an
11/34 is not quite a trivial exercise, and it is arguable whether
the problems encountered stem  from  the  idiosyncracies  of  the
11/34 or from UNIX itself ...

-- Dave




















