home *** CD-ROM | disk | FTP | other *** search
/ ftp.update.uu.se / ftp.update.uu.se.2014.03.zip / ftp.update.uu.se / pub / decmate / DECmate.part2 < prev    next >
Internet Message Format  |  1993-10-18  |  10KB

  1. From: lasner@watsun.cc.columbia.edu (Charles Lasner)
  2. Subject: Re: Why a DECmate isn't a PDP-8
  3. Date: Sun, 7 Mar 1993 03:05:55 GMT
  4.  
  5. This is the second in a series of posts about why the DECmate series of
  6. small computers is not quite what we know as a PDP-8.  Part one dealt with
  7. the few minor CPU issues and detailed the significent differences in the
  8. console interfaces between all PDP-8 (and VT-78) models and the DECmates.
  9.  
  10. 2a)    Consequences of the console problems and what to do about them.
  11.  
  12.     Since the console interface is hopelessly "mangled" we have to learn
  13. to live with it.  Existing PDP-8 programs designed for the various OSes will
  14. have to be either supported as is or be changed for DECmate and PDP-8 use.
  15.  
  16. P?S/8 has already undergone a console "overhaul" such that all system programs
  17. can now be run on any model of PDP-8, VT-78, PDP-12, or DECmate.  (The family
  18. of 8 rule applied to P?S/8 as well as OS/8, thus neither will run on a PDP-5
  19. or PDP-8/s.)  To accomplish a compatible console interface compromise, the
  20. following rules were laid down:
  21.  
  22.     If a program is meant to strictly run on a PDP-8 or VT-78 only, then
  23. it can assume the old-style console interface exists.  Thus, *only* on a PDP-8
  24. can the following code or equivalent be used:
  25.  
  26.     KSF            /FLAG UP?
  27.     JMP    NOT        /FORGET IT
  28.     KRS            /READ IT IN NOW; DON'T DISTURB THE FLAG
  29.     AND    (177)        /GET RID OF PARITY BIT
  30.     TAD    (-3)        /COMPARE TO ^C
  31.     SZA CLA            /SKIP IF IT MATCHES
  32.     JMP    CLRIT        /JUMP IF OTHER
  33. /    DO WHAT'S NEEDED HERE, SUCH AS SET THE DF TO 00, ETC.
  34.     JMP I    (7600)        /KEYBOARD MONITOR WILL NOTICE THE ^C
  35.  
  36. CLRIT,    KCC            /CLEAR THE FLAG WE NOTICED ON OTHER THAN ^C
  37. NOT,    CLA            /CONTINUE PROCESSING; NO ^C PRESSED
  38.  
  39. This code is applicable to OS/8 and P?S/8, but only on PDP-8's, not DECmates.
  40. The changes to the keyboard monitor of either system has to still include the
  41. check for ^C by noticing the KSF skips, execute KRB and check if the character
  42. is ^C and take the appropriate action, etc.
  43.  
  44. Note that the pre-DECmate P?S/8 and all pre-V4 OS/8 family systems essentially
  45. worked this way, etc.
  46.  
  47. To function on the DECmate, P?S/8 was modified so that there is a new system
  48. concept: the "soft ^C" bit.  In this specific case, it was defined as bit[11]
  49. of the memory size word in 007611 to facilitate being set with an ISZ
  50. instruction, etc.  Here is a reworked piece of code that can function only
  51. on the newly reworked P?S/8 system:
  52.  
  53.     KSF            /FLAG UP?
  54.     JMP    NOT        /FORGET IT
  55.     KRB            /WE MUST READ THE CHARACTER IN
  56.     AND    (177)        /GET RID OF PARITY BIT
  57.     TAD    (-3)        /COMPARE TO ^C
  58.     SZA CLA            /SKIP IF IT MATCHES
  59.     JMP    NOT        /JUMP IF OTHER
  60. /    DO WHAT'S NEEDED HERE, SUCH AS SET THE DF TO 00, ETC.
  61.     ISZ I    (7611)        /SET THE "^C WAS HIT" BIT
  62.     JMP I    (7600)        /KEYBOARD MONITOR WILL NOTICE THE ^C
  63.  
  64. The keyboard monitor in this case won't have a skipping KSF, but since it
  65. also examines bit[11] of 007611, it will notice the abort that way.  Thus,
  66. we have an equivalent of the original code that works on either PDP-8 or
  67. DECmate hardware, but only under the new operating system.  This code has
  68. an additional advantage:  certain applications run from an alternate device
  69. where a user abort can occur, such as another terminal on other than devices
  70. 03/04, etc.  This could be a serial printer with a keyboard, or a graphics
  71. terminal, etc., where it could be desirable to write an application that
  72. would have the option of user abort from this alternate device.  The program
  73. can check for its local abort condition and exit as the replacement console
  74. routines would above, thus logically extending the operation to the alternate
  75. device.
  76.  
  77. OS/8 requires modification to allow a similar abort exit that is as generic.
  78. The keyboard monitor will have to be made sensitive to a new bit, as well as
  79. responding to a skipping KSF/KRB combination that detects ^C, which will allow
  80. compatibility with older programs, but only if the hardware is actually a PDP-8
  81. or VT-78, etc.  The current candidate is 007601, which is the function word in
  82. OS/8's memory save routine that is initiated in 007600.  The breakdown of that
  83. word is:
  84.  
  85. 1 0 1 0 0 0 0 0 0 0 0 0
  86.  
  87. ^______________________        Indicates this call is a write function
  88.  
  89.   ^ ^ ^ ^ ^ ___________           Indicates that 8 pages should be written out
  90.  
  91.             ^ ^ ^               Indicates that field 00 is to be used
  92.  
  93.                   ^ ^ ^         These bits are usually undefined
  94.  
  95. The use of bits[9-11] of the function word of OS/8 are not defined for any
  96. file-structured device with a minor exception: bit[11] being set is optionally
  97. to be set for the benefit of the existing DECtape/LINCtape handlers to indicate
  98. that the caller believes that there is less overhead directing the handler to
  99. initiate searching for the requested block in the forward direction, whereas
  100. the default is to search backwards.  Statistically, most searches ought to be
  101. initiated backwards on these devices because it is likely that the next tape
  102. transfer is contiguous to the previous one.  However, once the latest transfer
  103. is completed, it is impossible to restart another transfer without backing up
  104. the tape because the latest block has already partially gone by.  Thus, in
  105. practice, the only calls that can benefit are those where the caller needs
  106. widely spread out information stored on known blocks that are futher apart
  107. than the overshoot factor of the tape (typically 2-3 blocks must be skipped
  108. to make use of an additional forward transfer; the DECtape copy program makes
  109. use of this feature by only copying half the tape deliberately skipping over
  110. many blocks, and then copying only the previously skipped blocks while
  111. spinning the tape in the reverse direction skipping over the previously copied
  112. blocks.).
  113.  
  114. In actual fact, there are only a small handful of static calls within OS/8
  115. that are made with this bit set, due to the design of OS/8 lacking much need
  116. for the feature of search direction override; the usual OS/8 component isn't
  117. forward of the previously read in component, etc.  Thus, while a useful feature
  118. in principle, not much of OS/8 sets the bit because in the static sense, there
  119. isn't too much that can be done to predict this situation.
  120.  
  121. Actually, this is unfortunate, since in the dynamic sense, there are quite a
  122. few more situations where the actual call could have been made more efficiently
  123. had the handler been aware of the circumstances which were not told to the
  124. handler.
  125.  
  126. In P?S/8, the OS tells the handler nothing at all in this regard, yet overall
  127. performance is noticeably better.  Part of the reason for this is that in P?S/8
  128. DECtape handlers, the handler is internally responsible for maintaining the
  129. current position of the tape.  Any call will be used to determine whether to
  130. search forward or backwards based solely on the current tape position info
  131. obtained from the previous call to the handler.
  132.  
  133. Years ago I wrote such a handler for OS/8 that ignores bit[11] in the
  134. function word and instead maintains this "dead reckoning" on its own.  If
  135. interest is warranted, I can locate this code and make it available to the
  136. user community.  (It is not an exact knee-jerk "clone" of the standard OS/8
  137. TC01/08 DECtape handler as there are design philosophy differences on other
  138. issues as well, but IMHO any user would appreciate the differences and would
  139. prefer my handler to the standard one.)
  140.  
  141. In any case, it is clear that the following handlers are up for consideration:
  142.  
  143. TC01/08 system and non-system handlers.
  144. TD8E system and non-system handlers and the TD8E MR-8EC ROM system handler.
  145. PDP-12 LINCtape handler
  146. LINC-8 LINCtape hander for a modified LINC-8 and the non-system handler.  Also
  147. the 12K system handler for an unmodified LINC-8 and a possible two-page handler
  148. for use as a non-system handler on original hardware.
  149.  
  150. The TC01/08 system consideration was outlined above.  The TD8E system handler
  151. is also written to obey this bit.  Among other considerations already 
  152. implemented in P?S/8 is the same optimization for search direction on this
  153. hardware.  It is likely that both the system and non-system handlers can be
  154. made similarly "smarter".  The ROM-based system ignores the bit.  The PDP-12
  155. hardware is too complicated to allow the OS/8 handlers to deal with the bit,
  156. so all transfers are made starting with a reverse search.  It is conceivable
  157. that the LINC-8 handlers can be made similarly smarter; the modified LINC-8
  158. hardware includes helpouts to the handler for P?S/8 to accomplish this already,
  159. but it isn't clear that the non-system handler for an unmodified machine can
  160. accomplish this in less than two pages.
  161.  
  162. In any case, it would appear that an adequate job can be done to eradicate the
  163. need for this bit in OS/8 completely.  The worst-case consequence of the bit
  164. is that the call to save memory during the exit via 007600 would involve a
  165. transfer initiated with a forward search.  (And it's conceivable that this
  166. might even be the proper thing to do!)  There are no other OS/8 handlers that
  167. pay attention to this bit.  (Note, there are non-file-structured devices that
  168. use these bits; this is irrelevant!)
  169.  
  170. So, a replacement console routine for OS/8 Version 5 would be the same as
  171. the P?S/8 example, except that the location being incremented would be
  172. 007601, not 007611.  The OS/8 keyboard monitor would have to be made sensitive
  173. to bit[11] of 007601 as well as the case of the KSF/KRB skip of a ^C but only
  174. on PDP-8 hardware.
  175.  
  176. Thus, a replacement OS/8 system can be built for use on PDP-8's or DECmates,
  177. but every system program that requires DECmate application must be upgraded
  178. to the new standard.
  179.  
  180. Along the way, some other issues will be addressed, such as creeping model
  181. dependencies, which must be eliminated to allow one system version to run
  182. on all of the machines it ought to, which is not currently the case in OS/8.
  183. (P?S/8 already has accomplished this:  you can carry a single RX01-type 8"
  184. floppy disk to any appropriately configured machine all the way from a
  185. classic 1965 PDP-8 through a DECmate II and boot that very same disk on
  186. any of the machines.)
  187.  
  188. Next time, more DECmate-specific quirks that impede compatibility due to
  189. other problems, etc.
  190.  
  191. cjl
  192.  
  193.