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