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