home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / ZCPR33 / BANKSYS.DOC < prev    next >
Text File  |  2000-06-30  |  10KB  |  237 lines
  1. FROM: CAMERON W. COTRILL
  2. TO: ALL ZSYSTEM SOFTWARE DEVELOPERS
  3.  
  4. Revised 01/09/88  Cameron W. Cotrill
  5.                   BANKED CP/M 2.2 COMPATIBLE OS
  6.  
  7.     With the advent of the 64180 and Z280, having more than 64k 
  8. of memory has become easy.  Prior to this, there have been ways 
  9. of bank switching a Z80 system, and most use similar methods - 
  10. low memory is swapped while high memory is retained.  Despite the 
  11. fact that banking methods used are similar, nobody has proposed 
  12. any details of extending the CP/M 2.2 and ZCPR3 environment to 
  13. support banked memory.  This document is a proposal to set forth 
  14. the hardware and software interfaces to support such a system in 
  15. a manner that is consistent with the hardware independence of 
  16. ZCPR3 and CP/M 2.2.
  17.  
  18.     The starting point for this definition is a Z80 system using 
  19. ZCPR3 and ZSDOS, and supporting at least 2 banks of memory.  In 
  20. requiring the ZCPR3 environment specification, more information 
  21. on the system is available and the OS can take advantage of this. 
  22. One important application of the environment (and required TCAP 
  23. definition) is enhanced line editing is possible using BDOS 
  24. function 10 (A superset of CP/M+).  The address that banking 
  25. takes place is not important, but must be a page boundary between 
  26. 8000h and 0F000h.  Most banked Z80 systems fit this 
  27. specification.
  28.  
  29.     In order to support banking, the entire operating system must 
  30. be altered.  Naturally, backward compatibility with existing 
  31. programs and utilities must be maintained to the maximum degree 
  32. possible.  This means that CCP, BDOS, and BIOS entry points must 
  33. be maintained as in CP/M 2.2, and all functions supported by CP/M 
  34. BDOS and BIOS must also be maintained.
  35.  
  36.  
  37. I. MEMORY MANAGEMENT
  38.  
  39.     Currently, extended ram (above 64k) is used for RAM disk on 
  40. most systems that have it.  A few bank part of the BIOS to allow 
  41. for larger TPA's, but no uniform specification to use this memory 
  42. is yet available to applications programs. 
  43.  
  44.     In order to allow applications programs to use banked memory, 
  45. system independent memory management routines must be added to 
  46. BDOS.  Naturally, the hardware dependent parts of bank switching 
  47. must be handled by new BIOS entry points.  The necessary added 
  48. routines would spill BDOS over the 3.5k space it has allotted to 
  49. it.  However, since we are banking the system, the overflow can 
  50. be stuck in a reserved bank and swapped in and out as needed.  
  51. The same follows for BIOS.
  52.  
  53.     To facilitate this, we will reserve bank 0 as the system 
  54. bank. The normal TPA will be located in bank 1, with banks 2-nnnn 
  55. available as extended memory for the application or the system. 
  56. Starting at address 0 in the system bank is the Banked BIOS area. 
  57. This area is 8k long and is reserved for BIOS (and boot ROM if 
  58. desired).  Above this, at address 2000h, is the banked BDOS area. 
  59. This reserved area is also 8k.  At 4000h is the 2k CCP buffer. 
  60. The BIOS should load CCP from this buffer instead of from disk. 
  61. BDOS is never re-loaded.  The memory above CCP BUFFER (starting 
  62. at 4800h) and extending up to the bank boundary is used for 
  63. system extensions.
  64.  
  65.     System Bank
  66.     -----------
  67.     Z3ENV
  68.     Z3 BUF                        Must not be banked
  69.     RES BIOS
  70.     RES BDOS (3.5k)
  71.     CCP (2k)
  72.     -----------
  73.     TOP TPA                       May be banked
  74.     -----------
  75.     SYS EXTEND
  76.     CCP BUFFER (2k)               Must be banked
  77.     BANKED BDOS (8k)
  78.     BANKED BIOS (8k)
  79.  
  80.     It is important to note which addresses are fixed in the 
  81. system and which addresses are not.  The addresses of Banked 
  82. BIOS, Banked BDOS, CCP Buffer, and the starting address of SYS 
  83. Extend are fixed.  All other addresses in the system may be 
  84. adjusted as required by the system implementor, so long as 
  85. modules with specified sizes (CCP, BDOS) are kept to the proper 
  86. size and in order.
  87.  
  88.     In order to provide maximum utility for programs using 
  89. banking, the following types of services must be provided by the 
  90. OS -
  91.     1. Allocate bank to application
  92.     2. Free bank
  93.     3. Call routine in bank nnnn
  94.     4. Jump to routine in bank nnnn
  95.     5. Get data from bank nnnn
  96.     6. Store data to bank nnnn
  97.     7. Get bank size
  98.     8. Get/Set DMA bank (for disk ops)
  99.  
  100. This set of functions will allow a program to use banked memory 
  101. for either program memory, data memory, or both.  No restrictions 
  102. are placed upon how banks of memory may be requested by the 
  103. application.
  104.  
  105.      For the purposes of this document, the term application 
  106. shall be defined as a transient program, RSX, or Device Driver.
  107.  
  108.     In order to prevent undue restrictions on memory size, the 
  109. bank number will be a 16 bit unsigned number.  This will allow up 
  110. to 65536 banks of memory (about 3.14 gigabytes if 48k banks are 
  111. used).  This should be enough memory capacity for a while.
  112.  
  113.     Physical memory need not be this big, nor does BIOS need to 
  114. allocate the banks in sequential order.  BDOS will call the BIOS 
  115. alloc entry point to get a bank of memory. In order for BIOS to 
  116. keep track of what application owns what memory, a task number 
  117. will be passed to BIOS in BC.  If a bank is available, BIOS will 
  118. return the bank number in HL.  If no bank is available, 0 is 
  119. returned in HL.  Note that 0 is a valid bank but is never used by 
  120. an application as it is reserved for the system.  It is proposed 
  121. that task numbers 0-3f be reserved for BIOS.  All other task 
  122. numbers will be assigned by BDOS.  
  123.  
  124.     Since BIOS handles the details of memory allocation, this 
  125. means BIOS may allocate memory to itself.  Note that since BIOS 
  126. takes care of the physical details of banking, it is possible to 
  127. support virtual memory for banking.  This is probably best used 
  128. with the Z280 which has direct MMU support for this, but could be 
  129. used with any system. 
  130.  
  131.     Note that the 2k used by CCP must not be banked.  The primary 
  132. reason for this is to allow banked programs a guaranteed 2k of 
  133. global memory that can be used for data and program common to all 
  134. banks.
  135.  
  136.     Upon termination of an application, all banks used by the 
  137. application will be freed by OS.
  138.  
  139.     Note that what is required for BDOS/BIOS compatibility is an 
  140. offset of 0DFAH from BDOS entry point to BIOS Warm Boot.  If the 
  141. resident portion of BDOS is under 0E00H in length, the remaining 
  142. space may be used for system segments or BIOS.
  143.  
  144.  
  145. II. SYSTEM EXTENSIONS
  146.  
  147.     System extensions are additions to either BDOS or BIOS that 
  148. can define new functions or alter existing functions.  A Device 
  149. Driver (DD) alters BIOS functions and a Resident System Extension 
  150. (RSX) alters BDOS functions.  As such, the DD is hardware 
  151. dependent and the RSX is hardware independent.  Both are 
  152. relocatable modules that are loaded into the System Extension 
  153. Area on the system page or into an alternate bank if the system 
  154. area is full.
  155.  
  156.     Several new BDOS calls need to be provided to manipulate 
  157. these modules.  The modules themselves have a similar structure. 
  158. Pertinent information about the module is kept in the module 
  159. header.  Details of the added BDOS calls and the module header 
  160. structure need to be defined.
  161.  
  162.  
  163. III. ENHANCED BDOS FUNCTIONS
  164.  
  165.     Several enhancements to the internal operation of BDOS are 
  166. proposed:
  167.     1. Hashed directory buffer to speed unambig file directory 
  168. searches.
  169.     2. Multisector I/O support.
  170.     3. Enhanced Function 10 including last line recall and 
  171. insert/overwrite editing.
  172.     4. I/O redirection.  The following capabilities are 
  173. suggested: Unix-like STDIN, STDOUT, STDERR logical device 
  174. assignment, re-assign RDR: and PUN: as single AUX: device, make 
  175. device names valid as files with BDOS doing the stream to block 
  176. conversion.
  177.  
  178.     Several BDOS utility functions are proposed in order to make 
  179. life easier for the programmer. 
  180.  
  181.     1. Parse FCB.  Parses the next token in the command line into 
  182. a FCB.  This includes named directory resolution, password 
  183. protection, etc.
  184.  
  185.     2. Full screen STDOUT string I/O functions.
  186.     3. AUX: status (used for modem)
  187.  
  188.     Recommended BIOS revisions are:
  189.     1. Full track buffering.
  190.     2. Disk caching (write thru)
  191.  
  192.      In addition, there may be other SYSLIB functions such as 
  193. those that get system addresses that may be desirable to 
  194. implement as BDOS/BIOS calls.
  195.  
  196.  
  197. IV. MULTITASKING
  198.  
  199.      Multitasking will require BDOS and BIOS to be-reenterant (or 
  200. alternatively, BIOS can be maintained as non-reenterant if a task 
  201. switch is disallowed until the IO operation is completed).  BDOS 
  202. must have a separate RAM area for each task (which must include a 
  203. separate DIR buffer).  Clearly, common memory can't be used for 
  204. this.  The data could be located in the system bank, but a better 
  205. solution would be to limit multitasking to the 180 and 280 
  206. processors, where changing the memory partitions on the fly is 
  207. simple.  This fits well with the current location of RAM in 
  208. ZSDOS.  BIOS variables could be stored in a similar matter.
  209.  
  210.                          TPA bank           Alt bank
  211.   bios bank point   +-----------------+ +---------------+
  212.                     |     bdos        | | bios bank ram |
  213.   bdos bank point   +-----------------+ +---------------+
  214.                     |                 | | bdos bank ram |
  215. normal bank point   +-----------------+ +---------------+
  216.  
  217.      Due to possible severe compatibility problems, I recommend 
  218. that multitasking be implemented only after the banked OS is 
  219. defined and implemented.  This suggestion does not mean that we 
  220. shouldn't carefully consider the impact of multitasking on the 
  221. banked standards!
  222.  
  223. V. SUMMARY
  224.  
  225.      This represents some of my thoughts on banking.  I don't 
  226. make any claims to have all the answers - indeed my motivation to 
  227. write this document is to spur others to think, question, ponder, 
  228. and suggest improvements to the ideas presented here.  We don't 
  229. have anybody like Microsoft or IBM to drag us along.  This means 
  230. that for better or worse, we control our own destiny.  Let's get 
  231. together and discuss the issues banking raises so together we can 
  232. define the next generation of ZSystem.  
  233.  
  234.      I can be reached on the Ladera Z-Node (Al Hawley's wonderful 
  235. board) and on Z Node Central.  Leave a message for Cameron W. 
  236. Cotrill.
  237.