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.part3 < 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 15:45:36 GMT
  4.  
  5. This is the third in a series of posts about why the DECmate series of small
  6. computers is not quite what we know as a PDP-8.  Already covered are the minor
  7. CPU issues, and the significent differences in the console interfaces between
  8. all PDP-8s and all DECmates, and what can be done about these particular
  9. consequences, etc.
  10.  
  11. 3)    Disk issues.
  12.  
  13.     Systems such as OS/8 and P?S/8 have to be configured for whatever
  14. machine-specific disk environment they run on, so in theory, this aspect of
  15. compatibility shouldn't be an issue.  However, there are some problematic
  16. compatibility details anyway.
  17.  
  18.     The DECmate I is essential compatible on this issue, as the boot
  19. device of the DECmate I is either an RX01/02 or an RL02.  The only actual
  20. difference between the DECmate I RX interface and a PDP-8 version is that
  21. the VT-78-style interface is present, i.e., the software has to deal with
  22. the potential of two pairs of RX drives.  This is controlled by the SEL
  23. IOT (6750) which is defined as: load pair select per AC[11] where 0=the drive
  24. pair found on the PDP-8 and 1=the optional pair found only on the VT-78 or
  25. DECmate I (VT-278).  Some system handlers for RX do not include the SEL
  26. instruction to ensure this condition, but it is the default state of the
  27. machine.  All software, such as the non-system handler to access the second
  28. pair, is responsible for resetting the select line to ensure the proper
  29. functioning of the system handler; it is likely that certain, but not all,
  30. existing system handlers for RX usage will be so tightly coded that this
  31. convention must be obeyed, since this is another tradeoff of features and
  32. performance versus handler space that could not have been anticipated by
  33. the authors of these handlers.  There are user-written RX handlers to
  34. accomplish such things as byte-mode transfers to gain back 33% more disk
  35. space over the standard DEC 12-bit mode.  There are also handlers to allow
  36. for accompishing this with/without the use of the otherwise wasted space on
  37. track 0, and also to mimic the disk layout of COS and/or WPS to allow
  38. conversion programs such as WPFLOP to function.  Still others are designed to
  39. be able to boot a byte-mode system so that the system device also benefits
  40. from the additional space, etc.  There also exists a set of handlers for use
  41. on RT-11-style disk layout to gain faster throughput as well.
  42.  
  43. The overall point here is that there has been a lot of RX work provided by the
  44. user community seeking performance beyond what little DEC has provided.  By
  45. switching the "rules" and requiring the software maintain yet another item of
  46. "housekeeping" compromises these handlers yet further.  (Even in 12-bit mode,
  47. it is impossible to accomplish all of the requirements of an RX handler in
  48. only two pages, the OS/8 upper limit.  There exists an analogous handler for
  49. P?S/8 usage, which requires three pages; P?S/8 allows handlers up to 32 pages
  50. long.  Thus, any two-page handler is compromised in some way, usually in the
  51. area of error recovery or performance, possibly only affecting certain models,
  52. etc.)
  53.  
  54. The DECmate II complicates this issue further.  On this specific machine, the
  55. RX-78 option allows for one or two pairs of RX01/02 (and at the same time
  56. prevents the RD51D hard disk option; you can either have one pair of RX50 and
  57. a hard disk or up to eight floppies implemented as two pairs of RX01/02 and
  58. two pairs of RX50).  However, the selection interface of the DECmate II is
  59. incompatible with that of the VT-78 and DECMate I, and requires several more
  60. instructions to provide compatible selection with the prior models.  Thus,
  61. all existing user-written and older DEC-provided handlers cannot run on the
  62. DECmate II.  Only those that can be modified slightly can be made to run on
  63. this hardware (which is somewhat more difficult presently than necessary; see
  64. below).
  65.  
  66. This issue is complicated further by a specific design "philosophy" of OS/278:
  67. In OS/8, the RX done flag is used as a status indicator.  Assuming no interrupt
  68. enabled (or the RX device interrupt is specifically disabled; this is in the
  69. province of any interrupt-driven program designed for the machine, etc.) the
  70. done flag being up is used as an idle status indicator.  The reason for this
  71. is that a handler can never know the current status of the drives when it is
  72. called; there could be a system reset in progress, which takes up to five
  73. seconds to complete.  The convention for the handlers is to assume that you
  74. should wait for the done flag to raise, since it's already up or will be
  75. up (eventually) at which time you should proceed with the main work of the
  76. call.  Handler exit is accomplished by executing an innocuous function that
  77. cannot fail (such as READ ERROR REGISTER) and then exiting without waiting for
  78. the function to complete.  (The problem is that to test the done flag is to
  79. clear it, since the relevant IOT (SDN) is Skip on DoNe set, clear done flag.)
  80. Thus, the hardware is now in a favorable state for the next caller.  Should
  81. a power-clear condition occur at some point, the handler will have to wait
  82. for up to five seconds, but can otherwise proceed, etc.
  83.  
  84. When OS/278 was introduced, the new designers revised this convention.  Under
  85. OS/278, the RX done flag is always assumed to be clear.  This sometimes causes
  86. handlers to fail, or at the least go through some error recovery cycles before
  87. accomplishing the requested handler calls, etc.  There exists some user 
  88. programs that make the system crash when run from an OS/278 floppy, while
  89. functioning correctly when run from an OS/278 hard disk volume!  All of this
  90. is traceable to bad interaction with the new convention.
  91.  
  92. To operate under this convention will add an undue burden to the handlers
  93. written by the user community, and it isn't necessary.  I have already written
  94. P?S/8 handlers that work perfectly fine under the original flag convention on
  95. the DECmate II hardware.  (I have created a "bootable" RX01/02 P?S/8 system.
  96. Since the hardware of the DECmate II can only boot to an RX50 or hard disk
  97. volume, it is necessary to first boot to the RX50, then run a "re-boot"
  98. program to bring up the RX01/02-based P?S/8, which is meant to be booted
  99. directly on a PDP-8 or VT-78 or DECmate I, etc.)
  100.  
  101. OS/8 version 5 will restore the original convention, and thus will require
  102. rewriting the DEC-style handlers accordingly.  However, all user-written
  103. handlers will function as intended, i.e., will function only on the PDP-8
  104. system they were designed for.  If possible, all handlers should be modified
  105. to be compatible with the restrictions of all of the machines.  (Some of the
  106. specific requirements are: 1) Must be able to have decent throughput on the
  107. slow VT-78; this is often not the case, especially on writes.  2) Must be
  108. able to support the SEL hardware of the VT-78/DECmate I, and preferably the
  109. DECmate II.  3) Should have decent error recovery if possible.  In general,
  110. it's impossible to have all of this, especially if the format involves the
  111. use of byte-mode transfers, and the format is single density, thus requiring
  112. checking for the possibility of performing byte-mode single density transfers
  113. on RX02 as opposed to RX01 which programs slightly differently in this
  114. mode, etc.)
  115.  
  116. In any case, the user-community software investment in RX utility will not
  117. go to waste.
  118.  
  119. In the case of the DECmate I, there is only one consideration: the RL8A
  120. controller allows for the ability to support existing software for RL01
  121. or RL02, but not both.  There exists a support jumper on the RL8A hardware
  122. that prevents some unforeseen consequence from occuring regarding the bit
  123. normally used in the RL02 for additional seek cylinders, etc.  Apparently,
  124. the jumper has to be set so that the hardware isn't subject to a mis-set
  125. bit in the software.  Several theories exist as to what the proper setting
  126. of this bit is, that the hardware provides to the drives, etc.  Possible
  127. examples are: 1) always one. 2) always zero. 3) Sign extension of the bit
  128. immediately to the right of this bit. 4) some form of parity.  In any case,
  129. RL01 software doesn't maintain any consistent usage of this bit, so the
  130. hardware jumper is used to maintain compatibility.  When the RL02 is used,
  131. the software correctly uses this (extra) bit.  Thus, mixed systems of RL01
  132. and RL02 are not allowed.  In theory, if/when we find out what this bit
  133. setting is, we can possibly modify all of the RL01 software to support an
  134. RL01 in a controller where the bit is set for full RL02 support, similar to
  135. the existing PDP-11 support currently.
  136.  
  137. In any case, RL8A users cannot currently mix RL01 and RL02 drives.  The DECmate
  138. I RL-278 controller apparently lacks this jumper altogether, thus only allowing
  139. RL02 drives, until the software clean-up described is implemented.  In the
  140. case of RL02 software specifically, the DECmate I is fully compatible.  (This
  141. does assume that the software is *otherwise* compatible, such as with the
  142. DECmate console interface or CPU differences!)
  143.  
  144. On the DECmate II, III, III+, new software has to be written for the RX50, 
  145. since the DEC-provided OS/278 handlers instigate the above-mentioned flag
  146. incompatibility.  This should prove as difficult as modifying the user-written
  147. handlers, etc.
  148.  
  149. DECmate II and III+ hard disk volume software is essentially acceptable, up
  150. to a point, since this is the province of these machines only.
  151.  
  152. Next time, problems of the RX50 and hard disk volume software not covered yet.
  153.  
  154. cjl
  155.  
  156.  
  157.