home *** CD-ROM | disk | FTP | other *** search
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-