FROM: CAMERON W. COTRILL TO: ALL ZSYSTEM SOFTWARE DEVELOPERS Revised 01/09/88 Cameron W. Cotrill BANKED CP/M 2.2 COMPATIBLE OS With the advent of the 64180 and Z280, having more than 64k of memory has become easy. Prior to this, there have been ways of bank switching a Z80 system, and most use similar methods - low memory is swapped while high memory is retained. Despite the fact that banking methods used are similar, nobody has proposed any details of extending the CP/M 2.2 and ZCPR3 environment to support banked memory. This document is a proposal to set forth the hardware and software interfaces to support such a system in a manner that is consistent with the hardware independence of ZCPR3 and CP/M 2.2. The starting point for this definition is a Z80 system using ZCPR3 and ZSDOS, and supporting at least 2 banks of memory. In requiring the ZCPR3 environment specification, more information on the system is available and the OS can take advantage of this. One important application of the environment (and required TCAP definition) is enhanced line editing is possible using BDOS function 10 (A superset of CP/M+). The address that banking takes place is not important, but must be a page boundary between 8000h and 0F000h. Most banked Z80 systems fit this specification. In order to support banking, the entire operating system must be altered. Naturally, backward compatibility with existing programs and utilities must be maintained to the maximum degree possible. This means that CCP, BDOS, and BIOS entry points must be maintained as in CP/M 2.2, and all functions supported by CP/M BDOS and BIOS must also be maintained. I. MEMORY MANAGEMENT Currently, extended ram (above 64k) is used for RAM disk on most systems that have it. A few bank part of the BIOS to allow for larger TPA's, but no uniform specification to use this memory is yet available to applications programs. In order to allow applications programs to use banked memory, system independent memory management routines must be added to BDOS. Naturally, the hardware dependent parts of bank switching must be handled by new BIOS entry points. The necessary added routines would spill BDOS over the 3.5k space it has allotted to it. However, since we are banking the system, the overflow can be stuck in a reserved bank and swapped in and out as needed. The same follows for BIOS. To facilitate this, we will reserve bank 0 as the system bank. The normal TPA will be located in bank 1, with banks 2-nnnn available as extended memory for the application or the system. Starting at address 0 in the system bank is the Banked BIOS area. This area is 8k long and is reserved for BIOS (and boot ROM if desired). Above this, at address 2000h, is the banked BDOS area. This reserved area is also 8k. At 4000h is the 2k CCP buffer. The BIOS should load CCP from this buffer instead of from disk. BDOS is never re-loaded. The memory above CCP BUFFER (starting at 4800h) and extending up to the bank boundary is used for system extensions. System Bank ----------- Z3ENV Z3 BUF Must not be banked RES BIOS RES BDOS (3.5k) CCP (2k) ----------- TOP TPA May be banked ----------- SYS EXTEND CCP BUFFER (2k) Must be banked BANKED BDOS (8k) BANKED BIOS (8k) It is important to note which addresses are fixed in the system and which addresses are not. The addresses of Banked BIOS, Banked BDOS, CCP Buffer, and the starting address of SYS Extend are fixed. All other addresses in the system may be adjusted as required by the system implementor, so long as modules with specified sizes (CCP, BDOS) are kept to the proper size and in order. In order to provide maximum utility for programs using banking, the following types of services must be provided by the OS - 1. Allocate bank to application 2. Free bank 3. Call routine in bank nnnn 4. Jump to routine in bank nnnn 5. Get data from bank nnnn 6. Store data to bank nnnn 7. Get bank size 8. Get/Set DMA bank (for disk ops) This set of functions will allow a program to use banked memory for either program memory, data memory, or both. No restrictions are placed upon how banks of memory may be requested by the application. For the purposes of this document, the term application shall be defined as a transient program, RSX, or Device Driver. In order to prevent undue restrictions on memory size, the bank number will be a 16 bit unsigned number. This will allow up to 65536 banks of memory (about 3.14 gigabytes if 48k banks are used). This should be enough memory capacity for a while. Physical memory need not be this big, nor does BIOS need to allocate the banks in sequential order. BDOS will call the BIOS alloc entry point to get a bank of memory. In order for BIOS to keep track of what application owns what memory, a task number will be passed to BIOS in BC. If a bank is available, BIOS will return the bank number in HL. If no bank is available, 0 is returned in HL. Note that 0 is a valid bank but is never used by an application as it is reserved for the system. It is proposed that task numbers 0-3f be reserved for BIOS. All other task numbers will be assigned by BDOS. Since BIOS handles the details of memory allocation, this means BIOS may allocate memory to itself. Note that since BIOS takes care of the physical details of banking, it is possible to support virtual memory for banking. This is probably best used with the Z280 which has direct MMU support for this, but could be used with any system. Note that the 2k used by CCP must not be banked. The primary reason for this is to allow banked programs a guaranteed 2k of global memory that can be used for data and program common to all banks. Upon termination of an application, all banks used by the application will be freed by OS. Note that what is required for BDOS/BIOS compatibility is an offset of 0DFAH from BDOS entry point to BIOS Warm Boot. If the resident portion of BDOS is under 0E00H in length, the remaining space may be used for system segments or BIOS. II. SYSTEM EXTENSIONS System extensions are additions to either BDOS or BIOS that can define new functions or alter existing functions. A Device Driver (DD) alters BIOS functions and a Resident System Extension (RSX) alters BDOS functions. As such, the DD is hardware dependent and the RSX is hardware independent. Both are relocatable modules that are loaded into the System Extension Area on the system page or into an alternate bank if the system area is full. Several new BDOS calls need to be provided to manipulate these modules. The modules themselves have a similar structure. Pertinent information about the module is kept in the module header. Details of the added BDOS calls and the module header structure need to be defined. III. ENHANCED BDOS FUNCTIONS Several enhancements to the internal operation of BDOS are proposed: 1. Hashed directory buffer to speed unambig file directory searches. 2. Multisector I/O support. 3. Enhanced Function 10 including last line recall and insert/overwrite editing. 4. I/O redirection. The following capabilities are suggested: Unix-like STDIN, STDOUT, STDERR logical device assignment, re-assign RDR: and PUN: as single AUX: device, make device names valid as files with BDOS doing the stream to block conversion. Several BDOS utility functions are proposed in order to make life easier for the programmer. 1. Parse FCB. Parses the next token in the command line into a FCB. This includes named directory resolution, password protection, etc. 2. Full screen STDOUT string I/O functions. 3. AUX: status (used for modem) Recommended BIOS revisions are: 1. Full track buffering. 2. Disk caching (write thru) In addition, there may be other SYSLIB functions such as those that get system addresses that may be desirable to implement as BDOS/BIOS calls. IV. MULTITASKING Multitasking will require BDOS and BIOS to be-reenterant (or alternatively, BIOS can be maintained as non-reenterant if a task switch is disallowed until the IO operation is completed). BDOS must have a separate RAM area for each task (which must include a separate DIR buffer). Clearly, common memory can't be used for this. The data could be located in the system bank, but a better solution would be to limit multitasking to the 180 and 280 processors, where changing the memory partitions on the fly is simple. This fits well with the current location of RAM in ZSDOS. BIOS variables could be stored in a similar matter. TPA bank Alt bank bios bank point +-----------------+ +---------------+ | bdos | | bios bank ram | bdos bank point +-----------------+ +---------------+ | | | bdos bank ram | normal bank point +-----------------+ +---------------+ Due to possible severe compatibility problems, I recommend that multitasking be implemented only after the banked OS is defined and implemented. This suggestion does not mean that we shouldn't carefully consider the impact of multitasking on the banked standards! V. SUMMARY This represents some of my thoughts on banking. I don't make any claims to have all the answers - indeed my motivation to write this document is to spur others to think, question, ponder, and suggest improvements to the ideas presented here. We don't have anybody like Microsoft or IBM to drag us along. This means that for better or worse, we control our own destiny. Let's get together and discuss the issues banking raises so together we can define the next generation of ZSystem. I can be reached on the Ladera Z-Node (Al Hawley's wonderful board) and on Z Node Central. Leave a message for Cameron W. Cotrill.