home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Bug_Fixes / V7_on11-34 / unix_on_1134.txt < prev   
Encoding:
Text File  |  2001-02-28  |  6.5 KB  |  135 lines

  1.                 Implementing UNIX on a PDP-11/34
  2.                                or
  3.         What does the `F' in "RK05-F" really stand for ?
  4.  
  5.                           Dave Horsfall
  6.                   Computing Services Unit (CSU)
  7.                         University of NSW
  8.  
  9.         This  article is relates some of the author's experiences
  10. in implementing UNIX on a PDP-11/34.  My efforts were  not  quite
  11. as  straight-forward as they could have been, since all my previ¡
  12. ous experience has been with 11/40's.  This  article  will  point
  13. out some of the major differences between the two models that af¡
  14. fect system implementation, and gives  some  advice  to  would-be
  15. purchasers of 11/34's intending to run UNIX.
  16.  
  17.         Most  difficulties  appeared  when trying to transport an
  18. 11/40 system to the 11/34.  The first difficulty that cropped  up
  19. (apart  from  the  lack of a console; I'll come to that later) is
  20. the lack of a stack limit register.  This was actually the result
  21. of  a  modification to UNIX to utilize the register should it ex¡
  22. ist, to prevent the kernel stack from smashing the per-user area.
  23. Also,  the code to handle bus traps had a few nasty side effects.
  24. This showed up when using `m40.s' as a basis  for  the  low  core
  25. program.   This  meant that all code referring to the stack limit
  26. register had to be `conditionalised'.  This affects  `mch.s'  and
  27. `once.c'.   If  the  FPU  floating point unit is installed (as it
  28. usually is; at least on the 11/34's I  have  seen)  then  `mch.s'
  29. must  be changed to support it.  The CSU system generation proce¡
  30. dures assume a generalised `mch.s' program with appropriate  fea¡
  31. tures  conditionally  assembled in; `mkconf' will generate a file
  32. to be prefixed to `mch.s'  containing  the  definitions  such  as
  33. "FPU = 1"  etc.  `Mkconf' has been extended to recognize keywords
  34. such as "stacklimit", "fpu" etc and generate the appropriate pre¡
  35. fix  file.   Since we generate most of the UNIX systems on campus
  36. for PDP's of various configurations, 'mkconf' is a great help.
  37.  
  38.         The second difficulty is the lack of a conventional  con¡
  39. sole.   Given that UNIX refers to the switch register quite a lot
  40. during various stages of booting  and  running,  this  is  indeed
  41. quite  a  problem.  Instead of a conventional switch register and
  42. display, there is an arrangement of little buttons and  a  seven-
  43. segment  display,  vaguely  reminiscent  of  a pocket calculator.
  44. There is no switch register as such; you have to button in a num¡
  45. ber  (which  appears in the display; it's quite fun just watching
  46. it) then press a button to actually load the damned thing, where¡
  47. upon  an  LED come on to indicate that the display is indeed dis¡
  48. playing the switch register (as opposed to  displaying  something
  49. else  e.g  the last value examined).  This lack of a display such
  50. as `ADDR/DATA' also means that you can't tell what the system  is
  51. doing - if it is doing anything at all.
  52.  
  53.         The boot procedure is quite funny (funny queer; not funny
  54. ha-ha; although it does have its hilarious aspects).  While hold¡
  55. ing  down the `CNTRL' button, one presses the `HALT' button, then
  56. the `BOOT' button.  The ROM console emulator program  then  comes
  57. alive on the console terminal.  If you are booting from say `RK0'
  58. you then type in `DK0' (which must be in upper case, although you
  59. can say just `DK').  It would be a good idea at this point if the
  60. switch register contained neither `0' nor `173030'  (for  obvious
  61. reasons;  none  of this "Load Addr 773110; Start" business).  The
  62. value I normally use is plain `1'.  At least there is a button to
  63. clear  the  switch  register.   Given  that the ROM expects upper
  64. case, and that UNIX prefers you to talk  in  lower  case,  it  is
  65. quite easy for problems to occur here.
  66.  
  67.         The  subtitle of this article refers to the fact that the
  68. two 11/34 systems I have installed both have an RK05-J (the  nor¡
  69. mal  one)  and an RK05-F (double density; equivalent logically to
  70. two drives but on one cartridge).  DEC must be flogging  lots  of
  71. these.   The implications of this is that there is but one remov¡
  72. able volume, and UNIX (for all its reliability - sorry  Ian)  re¡
  73. quires  two for effective system backups.  The second volume does
  74. not have to be a disk; it can be a mag-tape  drive.   Given  that
  75. you can copy half of the `F' on to the `J', followed by the other
  76. half; the question that naturally arises is "How the hell do  you
  77. back  up the `J' if it is not being used as pure scratch ?".  How
  78. indeed !  The only technique is to bring up a stand-alone utility
  79. such as `RKDF' and when the `F' is nicely backed up, you copy the
  80. `J' on to one half of it, copy this in turn to another  `J'  then
  81. restore said half of the `F'.  This also introduces another prob¡
  82. lem; that of recovering from file system loss.  Should a file  be
  83. spread  over  both halves of the `F', it will naturally appear on
  84. two `J's, and the only way to recover it (for the ordinary mortal
  85. user) is to restore the whole damned lot in a manner analogous to
  86. the backup procedure.  It is also possible to treat the RK  as  a
  87. tape  and  use `dump/restor' on it.  However, you still need some
  88. sort of emergency backup system just in case you can't  even  use
  89. `restor'.   Ken Higgs of Water Research Laboratory can tell a few
  90. stories about this.  In other words, one removable drive (with or
  91. without  a  fixed drive) is not enough.  You need either a second
  92. removable drive or a mag-tape drive as well.   Life  may  not  be
  93. meant to be easy, but there is no point in making it hard either.
  94.  
  95.         There is another consequence of the RK05-F in  that  UNIX
  96. regards  it as two platters, and will therefore try to initiate a
  97. seek on one of them while the other is busy.   Needless  to  say,
  98. this  doesn't quite work.  We modified our RK driver to implement
  99. the concept of `concatenated volumes', in which several  contigu¡
  100. ous drives may be treated as one enormous drive with one schedul¡
  101. ing queue.  Should this then be specified  as  "optimized"  (with
  102. the  funny  rotated  blocks)  the driver does the right thing and
  103. plants block #1 in the middle of the  whole  virtual  disk  (this
  104. calculation is done automatically by the driver; it knows how big
  105. each individual drive is and hence knows where the middle of  the
  106. whole  lot  is).  This does not work too well however on multiple
  107. physical drives, but it is better than nothing.
  108.  
  109.         All in all, transporting UNIX  from  a  PDP-11/40  to  an
  110. 11/34 is not quite a trivial exercise, and it is arguable whether
  111. the problems encountered stem  from  the  idiosyncracies  of  the
  112. 11/34 or from UNIX itself ...
  113.  
  114. -- Dave
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.