MirrorRepos/RomWBW
1
0
Fork 1
mirror of https://github.com/wwarthen/RomWBW.git synced 2026-02-06 22:43:15 -06:00
Code Issues Projects Releases Wiki Activity

BPBIOS Sources From Jörg Linder

Browse Source 
Jörg Linder has disassembled and thoroughly commented a great deal of the BPBIOS binaries.   This was an incredible amount of work.  I have added all of these to the RomWBW build scripts and will ultimately integrate them more completely.
This commit is contained in:
Wayne Warthen
2025-06-16 20:19:07 -07:00
parent eefb0d2df1
commit bccd80882c
68 changed files with 22402 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
Doc/CPM/BPBIOS/BPBIOS_1_Introduction.md Normal file
View File

@@ -0,0 +1,81 @@
# B/P Bios
# Banked and Portable Basic IO System
# 1 Introduction
The Banked and Portable (B/P) Basic I/O System (BIOS) is an effort to standardize many of the logical to physical mapping mechanisms on Microcomputers running Z-Systems with ZSDOS. In expanding the capabilities of such systems, it became apparent that standard BIOSes do not contain the functionality necessary, adequate standardization in extended BIOS calls, nor an internal structure to fully support external determination of system parameters. B/P Bios provides a method of achieving these goals, while also possessing the flexibility to operate on a wide range of hardware systems with a much smaller level of systems programming than previously required.
## 1.1 About This Manual
Documentation on B/P Bios consists of this manual plus the latest addendum on the distribution disk in the file README.2ND. This manual is divided into the following sections:
* The Features of B/P Bios summarizes the significant features of B/P Bios in general, highlighting advantages and the few limitations in the system.
* Tailoring B/P Bios contains details on altering the many options to generate a customized `.REL` file tailored to your system.
* Installing a B/P Bios details the installation of B/P Bios in both Unbanked and Banked configurations in a "how to" fashion.
* Programming for B/P Bios describes the interfaces, data structures and recommended programming practices to insure the maximum benefit and performance from systems with B/P Bios.
* The B/P Bios Utilities describes the purpose, operation, and customization of all supplied B/P Bios utilities and support routines.
* Appendices which summarize various technical information.
* A glossary defining many technical terms used in this Manual.
* An index of key words and phrases used in this Manual.
For those not interested in the technical details, or who want to bring the system up with a pre-configured version as quickly as possible, Section 4, Installing a B/P Bios, will lead you through the installation steps needed to perform the final tailoring to your specific computer. Other chapters cover details of the individual software modules comprising the B/P Bios, and specifics on the utilities provided to ease you use of this product.
## 1.2 Notational Conventions
Various shorthand terms and notations are used throughout this manual. Terms are listed in the Glossary at the end of this manual.
Though the symbols seem cryptic at first, they are a consistent way of briefly summarizing program syntax. Once you learn to read them you can tell at a glance how to enter even the most complicated commands.
Several special symbols are used in program syntax descriptions. By convention, square brackets (\[\]) indicate optional command line items. You may or may not include items shown between brackets in your command, but if you do not, programs usually substitute a default value of their own. If items between brackets are used in a command, all other items between the brackets must also be used, unless these items are themselves bracketed.
All of the support utilities developed to support the B/P Bios system contain built-in help screens which use the above conventions to display helpful syntax summaries. Help is always invoked by following the command with two slashes (`//`). So for example,
`ZXD //`
invokes help for ZXD, the ZSDOS extended directory program. Interactive ZSDOS programs such as BPCNFG2 also contain more detailed help messages which appear as a session progresses.
Many utilities may be invoked from the command line with options which command the programs to behave in slightly different ways. By convention, options are given after other command parameters. For example, the `P` option in the command
`ZXD *.* P`
causes the ZXD directory utility to list all files (*.*) and send its output to the printer (P). For convenience, a single slash character (/) can often be used in place of leading parameters to signify that the rest of the command line consists of option characters. Therefore, the command
`ZXD /P`
is identical in meaning to the previous example (see 6.23 for more on ZXD).
## 1.3 What is B/P Bios?
B/P Bios is a set of software subroutines which directly control the chips and other hardware in your computer and present a standard software interface to the Operating System such as our ZSDOS/ZDDOS, Echelon's ZRDOS, or even Digital Research's CP/M 2.2. These routines comply with the CP/M 2.2 standards for a Basic IO System (BIOS) with many extensions; some based on CP/M 3.x (aka CP/M Plus), and others developed to provide necessary capabilities of modern software. When properly coded, the modules comprising a B/P Bios perform with all the standard support utilities, nearly all Z-System utilities, and most application programs without alteration.
The ability to operate Banked, Non-banked and Boot System versions of the Bios with a single suite of software, across a number of different hardware machines, plus the maximization of Transient Program Area for application programs in banked systems are features which are offered by no other system of which we are aware.
## 1.4 The History of B/P Bios
Our earlier work developing ZSDOS convinced us that we needed to attack the machine-dependent software in Z80-compatible computers and develop some standard enhancements in order to exercise the full potential of our machines. This premise is even more true today with large Hard Disks (over 100 Megabytes) being very common, needs for large RAM Drives, and an ever shrinking Transient Program Area. Attempts to gain flexibility with normal operating systems were constrained by the 64k addressable memory range in Z80-compatible systems, and forced frequent operating system changes exemplified by NZCOM and NZBLITZ where different operating configurations could be quickly changed to accommodate application program needs.
In the mid to late 1980's, several efforts had been made to bank portions of CP/M 2.2 "type" systems. XBIOS was a banked Bios for only the HD64180-based MicroMint SB-180 family. While it displayed an excellent and flexible interface and the ability to operate with a variety of peripherals, it had several quirks and noticeably degraded the computer performance. A banked Bios was also produced for the XLM-180 single board S-100 computer, but required special versions of many Z-System utilities, and was not produced in any significant quantity. Other spinoffs, such as the Epson portable, attempted banking of the Bios, but most failed to achieve our comprehensive goals of compatibility with the existing software base, high performance, and portability.
In 1989, Cam developed the first prototype of B/P Bios in a Non-banked mode on his TeleTek while Hal concentrated on extending ZSDOS and the Command Processor. As of 1997, B/P Bios has been installed on:
| Computer | Features |
| :--- | :--- |
| YASBEC | Z180 CPU, FD1772 FDC, DP8490 SCSI, 1MB RAM |
| Ampro LB w/MDISK | Z80 CPU, FD1770 FDC, MDISK 1MB RAM |
| MicroMint SB-180 | HD64180 CPU, SMS9266 FDC, 256KB RAM |
| MicroMint SB180FX | HD64180Z CPU, SMS9266 FDC, 512KB RAM |
| Compu/Time S-100 | Z80 CPU, FD1795 FDC, 1 MB RAM |
| Teletek | Z80 CPU, NEC765 FDC, 64KB RAM |
| D-X Designs P112 | Z182 CPU, SMC FDC37C665 FDC, Flash ROM, 512KB RAM (mods for 5380 SCSI and GIDE) |

36
Doc/CPM/BPBIOS/BPBIOS_2_Features.md Normal file
View File

@@ -0,0 +1,36 @@
# 2 Features of B/P Bios
B/P BIOS is designed to be completely compatible with the CP/M 2.2 standards for a Basic IO System, as well as to provide many extensions needed for banked memory which is becoming so prevalent with newer systems and processors. Additionally, strict coding standards used in the various modules forming the BIOS ease interface problems with applications programs and provide a more robust framework for future development. The extensions added to the basic CP/M 2.2 foundation include many elements from Digital Research's CP/M 3 (aka CP/M Plus), but in a more logically consistent manner. Also included in banked versions are provisions for managing up to 8 MB of extended memory for banked applications, RAM Drives and potentially multitasking in future versions. To provide insight into the methodology used, let us now examine some of the features in a generic B/P Bios.
## 2.1 Character IO
As defined by Digital Research in their CP/M 2.2 standards, character IO consisted of logical devices referred to as TTY, CRT, UC1, CON, etc. B/P Bios extends and generalizes these interfaces using the IOBYTE to define four physical devices called COM1, COM2, PIO and NUL. The first two, COM1 and COM2, are serial ports; PIO is a Parallel port, while NUL is a "bit-bucket" which can be replaced by a customized driver, or used in lieu of an actual device. Digital Research provided only a limited interface capability to the character devices in CP/M 2.2, consisting of a Console (CON), an auxiliary Input and Output (RDR/PUN), and a Printer (LST). The ability to sense Input and Output Status with these devices was extremely limited and was enhanced in CP/M 3. These enhanced capabilities are completely incorporated into B/P Bios with the addition of strict register usage so that only relevant registers may be altered in the respective routines. By manipulating the IOBYTE, any of the four physical devices may be used in the three logical devices of CONsole, AUXiliary, and Printer (LST).
Also featured in B/P Bios are modifications of CP/M 3 functions to initialize (or re-initialize) all devices and parameters, and return the address of a table which contains names and parameters of the defined character devices. While not totally compatible with CP/M 3 equivalents, these functions are consistent with the spirit and functionality needed with this advanced system. Included in the device table are; flags defining whether the device is capable of Input, Output or Both, Data rates for serial devices (Maximum and Set), Serial data format where applicable, and Handshaking method (CTS/RTS, XON/XOFF or None), as well as Input and Output Data masks for stripping unneeded bits from characters during IO.
## 2.2 Mass Storage IO
All versions of Digital Research's CP/M BIOSes define only a generic Disk driver with implementations of Floppy, Hard, RAM and Tape drives left to the user or developer. In B/P Bios, we went several steps further to ease many problems. First, we retained all standard CP/M 2.2 functions and parameters, added CP/M 3 features for returning the Disk Parameter Header (DPH) table address, and flushing of the software deblocking code segment, and added a new vector to the BIOS jump table to provide a standard method of directly addressing low-level device functions. Several standard low-level Floppy Disk functions are supported and used by the standard utilities, including a function to return the type of Disk Controller in use which permits a single support utility to adapt to a wide variety of hardware platforms. In a like manner, low-level functions are provided for SCSI/SASI Hard Disk drives, and provisions for RAM Disk drives in the event special hardware is implemented. The methods used to implement these access mechanisms may be logically extended to handle Tape Drives or Network Interfaces.
## 2.3 Clock Support for Time and Date
Many Hardware vendors have added provisions for Time and Date as non-standard extensions to CP/M 2.2 BIOSes, and more have incorporated such support into CP/M 3 BIOSes. We opted to define the CP/M 3 clock vector as a ZSDOS-standard clock building on our previous Operating System work. This entry point into the Bios completely complies with our ZSDOS standards and can completely replace the separate clock driver when used with ZSDOS. For systems capable of returning tenths-of-seconds, such as the YASBEC and SB-180, the standard has been enhanced to support this capability as well.
## 2.4 Banked Memory Support
While Digital Research added banked memory support to their CP/M 3, it was in a manner incompatible with Bios interface standards defined for earlier CP/M standards. The method used in B/P Bios is compliant with CP/M 2.2 in direct accessing of Bios functions with only one minor exception when using the Banked ZSDOS2, and contains many of the CP/M 3 extensions added for banked memory support, with some being modified to be consistent with standards adopted for Z-System software. The exception to CP/M 2.2 accesses occurs when the Operating System can access certain buffers in the System Memory Bank. With ZSDOS 2, Allocation Bit Buffers (ALV), Check Buffers (CSV), and the Disk Host Buffer are all contained in the System Bank and not directly accessible from Transient Programs. To compensate for this, we have added a command to ZSDOS 2 to return the free space on disks (the most common reason for accessing these buffers) and tailored several utilities to adapt to banked and non-banked systems.
In addition to the primitives initiated by Digital Research, we added functions to directly access Words and Bytes in extended banks of memory, Directly accessing software routines contained in alternate memory banks, and properly managing the system when errors occur. These features make B/P Bios much more robust and resilient than other products. These features are implemented by methods transparent to the system utilities so that the same functions are available in both banked and non-banked versions.
## 2.5 Other Features
B/P Bios contains a standardized identification method which may be used to determine the hardware on which the software is operating. This allows applications to "adapt" to the environment in a manner similar to that used in the rest of the Z-System community. It also minimizes system "crashes" by executing programs which assume certain hardware features which may be detrimental if executed on other systems. The effects of identification of physical system parameters is most readily noticed by virtue of a single suite of support programs performing low-level functions such as formatting and diagnostics which function across widely differing hardware platforms. Portability on this scale can rarely be seen in other computer systems.
The ZCPR 3.4 Environment with extensions is mandatory in a B/P Bios system. Beginning with the addition of System Segment address and size information for CPR, DOS and BIOS which were added in the ZCPR 3.4 Environment, B/P Bios also adds a Resident User Space which may be used to locate unique routines for custom applications in a manner similar to, but more consistent than NZ-COM. An Environment Version number of 90H identifies the Z3 Environment as being compliant with B/P definitions.
In Banked systems, application programs may also be placed in alternate memory banks using location and sizing information contained at standard positions within the Bios Header Structure. This feature permits significantly greater functionality without sacrificing precious Transient Program Area. While the scheme employed in the initial distribution is subject to minor adjustments as the banked ZSDOS2 becomes more firmly developed, experimentation and suggestions into this realm are encouraged.

232
Doc/CPM/BPBIOS/BPBIOS_3_Tailoring.md Normal file
View File

@@ -0,0 +1,232 @@
# 3 Tailoring a B/P Bios
To customize a B/P Bios for your use, or adapt it to a new hardware set, you will need an editor and an assembler capable of producing standard Microsoft Relocatable files. Systems using the Hitachi HD64180 or Zilog Z180 must be assembled with either ZMAC or SLR180 which recognize the extended mnemonic set, or with a Z80 assembler and MACRO file which permits assembly of the extended instructions. For Z80 and compatible processors, suitable assemblers include ZMAC and Z80ASM. For any assembler, failure to produce standard Microsoft Relocatable code will preclude the ability of our Standard utilities to properly install B/P Bios systems.
## 3.1 Theory of Operation
In order to understand the need for, and principles behind B/P Bios, you must understand the way in which CP/M 2.2, as modified by the Z-System, uses the available memory address space of a Z80 microprocessor. For standard versions of CP/M and compatible systems, the only absolute memory addresses are contained in the Base Page which is the range of 0 to 100H. All addresses above this point are variable (within certain limits). User programs are normally run from the Transient Program Area (TPA) which is the remaining space after all Operating System components have been allocated. The following depicts the assigned areas pictorially along with some common elements assigned to each memory area:
```generic
FFFFH /------------------\
| Z-System Buffers | ENV, TCAP, IOP, FCP, RCP
|------------------|
| Bios | Code + ALV, CSV, Sector Buffers
|------------------|
| Operating System | CP/M 2.2, ZRDOS, ZSDOS1
|------------------|
| Command Processor| CCP, ZCPR3.x
|------------------|
| Transient |
| |
| Program |
| |
| Area |
0100H |------------------|
| Base Page | IOBYTE, Jmp WB, Jmp Dos, FCB, Buffer
0000H \------------------/
```
As more and more functionality was added to the Z-System Buffers, bigger drives were added using more ALV space, and additional functionality was added to Bios code in recent systems, the available TPA space has become increasingly scarce.
B/P Bios attacks this problem at the source in a manner which is easily adaptable to different hardware platforms. It uses additional memory for more than the traditional role of simple RAM Disks, it moves much of the added overhead to alternate memory banks. The generic scheme appears pictorially as:
```generic
FFFFH /----------\
| |
| BNK1 |
| |
8000H |----------| /----------\ /----------\ /----------\
| | | |\ | |\ | |\
| BNK0 | | BNK2 | | BNKU | | BNK3 ||\
| | | || | || | |||
0000H \----------/ \----------/ \----------/ \----------/
\- - - - - / \- - - - - / \- - - - - /|
| BNKM |
\----------/
TPA SYSTEM USER RAM DISK
```
As can be seen from the above diagram, multiple banks of memory may be assigned to different functional regions of memory, with each 32k bank (except for the one defined as BNK1) being switched in and out of the lower 32k of the processor's memory map. The bank defined as BNK1 is ALWAYS present and is referred to as the Common Bank. This bank holds the portions of the Operating System (Command Processor, Operating System, BIOS, and Z-System tables) which may be accessed from other areas, and which therefore must always be "visible" in the processor's memory. It also contains the code to control the Bank switching mechanisms within the B/P Bios.
To illustrate this functional division, the memory map of a basic B/P Bios system is divided as:
```generic
FFFFH /------------------\
| Z-System Buffers |
|------------------|
| User Space |
|------------------|
| Bios |
|------------------|
| Operating System |
|------------------|
| Command Processor| /------------------\ 8000H
|------------------| / | Bios Buffers |
8000H | Transient | | Banked Bios Part |
| | |------------------|
| | | Banked Dos Part |
| Program | |------------------|
| | | Banked CCP Part |
| | |------------------|
| Area | | CCP Restoral |
0100H |------------------| |------------------| 0100H
| Base Page | | Base Page Copy |
0000H \------------------/ \------------------/ 0000H
TPA (BNK0/BNK1) System Bank (BNK2)
```
The B/P Bios banking concept defines a one byte Bank Number permitting up to 8 Megabytes to be directly controlled. Certain assumptions are made in the numbering scheme, the foremost of which is that BNK0 is the lowest physical RAM bank, BNK1 is the next incremental RAM bank, with others follow in incrementing sequential order. A couple of examples may serve to illustrate this process. The YASBEC is offered with a couple of options in the Memory Map. Units with the MEM-1, 2 or 3 decoder PALs assign the first 128k bytes of physical memory to the Boot ROM, so BNK0 is set to 4 (Banks 0-3 are the ROM). The MEM-4 PAL only uses the first 32k (Physical Bank 0) for the ROM which means that BNK0 is assigned to 1, BNK1 to 2 and so on up to the 1 Megabyte maximum where BNKM is 31.
The Ampro Little Board equipped with MDISK, on the other hand, completely removes the Boot ROM from the memory map leaving a maximum of 1 MB of contiguous RAM space. In this system, BNK0 is set to 0 and BNKM to 31 of a fully equipped 1 MB MDISK board.
The region beginning after BNK1 is referred to as the System Bank. It begins at the bank number assigned to BNK2 and ends at the bank number immediately before that assigned to the User Bank, BNKU if present, or BNK3 if no User Bank area is defined.
If present, one or more 32k banks of memory may be defined with the BNKU equate for unique user programs or storage areas. This area begins with the bank number set to the label and ends at the bank number immediately before the BNK3 label. BNK3 defines a high area of physical memory which is most often used for a RAM Disk providing fast temporary workspace in the form of an emulated disk drive.
B/P Bios contains protection mechanisms in the form of software checks to insure that critical portions of the memory map are enforced. In the case of Non-banked systems, a check is made to insure that the system size is not so great that the Bios may overwrite reserved Z-System areas in high memory (RCP, IOP, etc). If a possible overflow condition is detected, the message
`++ mem ovfl ++`
will be issued when the system is started. In Banked Bios systems, this message will be displayed if the top of the system portions in the SYStem Bank exceeds the 32k bank size. For most systems, this space still permits drives of several hundred megabytes to be accommodated.
Since the Common portions of the operating system components must remain visible to applications, a similar check is made to insure that the lowest address used by the Command Processor is equal to or greater than 8000H. This factor is checked both in both MOVxSYS and BPBUILD with either a warning issued in the case of the former, or validity checks on entry in the case of the latter.
## 3.2 B/P Bios Files
This BIOS is divided into a number of files, some of which depend highly on the specific hardware used on the computer, and some of which are generic and need not be edited to assemble a working system. Much use is made of conditional assembly to tailor the resulting Bios file to the desired configuration. The Basic file, `BPBIO-xx.Z80`, specifies which files are used to assemble the Bios image under the direction of an included file, `DEF-xx.LIB`. It is this file which selects features and contains the Hardware-dependent mnemonic equates. By maintaining the maximum possible code in common modules which require no alterations, versions of B/P Bios are relatively easy to convert to different machines. The independent modules used in the B/P Bios system are:
| Filename | Description |
| :--- | :--- |
| `BOOTRAM.Z80` | (only needed in BOOT ROM applications) |
| `BOOTROM.Z80` | (only needed in BOOT ROM applications) |
| `BYTEIO.Z80` | Character IO per IOBYTE using IIO-xx routines |
| `DEBLOCK.Z80` | Disk Deblocking routines |
| `DPB.LIB` | 3.5/5.25" Floppy Format Definitions (if AutoSelect) |
| `DPB8.LIB` | 8"/Hi-Density Floppy Format Definitions (if AutoSelect) |
| `DPB2.LIB` | Additional Floppy Definitions (optional if AutoSelect) |
| `DPBRAM.LIB` | Fixed Floppy Format Definitions (if Not AutoSelect) |
| `DPH.LIB` | Disk Parameter Header Table & Floppy definitions |
| `FLOPPY.Z80` | Floppy Disk High-Level Control |
| `SECTRAN.Z80` | Sector Translate routines |
| `SELFLP1.Z80` | Floppy Select routine (if Not auto selecting) |
| `SELFLP2.Z80` | Floppy Select routine (if auto selecting) |
| `SELRWD.Z80` | Generic Read/Write routines |
| `Z3BASE.LIB` | ZCPR 3.x file equate for Environment settings |
Other files are hardware version dependent to varying extents. These modules requiring customization for different hardware systems are given names which end with a generic "-xx" designator to identify specific versions. Tailoring these modules ranges from simple prompt line customization to complete re-writes. Versions of B/P Bios generated to date are identified as:
| ID | Computer system |
| :---: | :--- |
| `-18` | MicroMint SB-180 | (64180 CPU, 9266 FDC, 5380 SCSI) |
| `-YS` | YASBEC | (Z180 CPU, 1772 FDC, DP8490 SCSI) |
| `-AM` | Ampro Little Board | (Z80 CPU, 1770 FDC, 1MB MDISK) |
| `-CT` | Compu/Time S-100 board set | (Z80 CPU, 1795 FDC, 1MB Memory) |
| `-TT` | Teletek | (Z80 CPU, 765 FDC) |
Files associated with specific hardware versions or require tailoring are:
| Filename | Description |
| :--- | :--- |
| `BPBIO-xx.Z80` | Basic file, tailored for included file names |
| `CBOOT-xx.Z80` | Cold Boot routines, Sign-on prompts |
| `DEF-xx.LIB` | Equates for option settings, mode, speed, etc. |
| `DPBHD-xx.LIB` | Hard Drive Partition Definitions (optional) |
| `DPBM-xx.LIB` | Ram Drive Definition (optional) |
| `DPHHD-xx.LIB` | Hard Drive DPH definitions (optional) |
| `DPHM-xx.LIB` | Ram Drive DPH Definition (optional) |
| `FDC-xx.Z80` | Floppy Disk Low-Level interface/driver routines |
| `HARD-xx.Z80` | Hard Drive Low-Level interface/driver routines (optional) |
| `IBMV-xx.Z80` | Banking Support Routines (if banked) |
| `ICFG-xx.Z80` | Configuration file for speed, Physical Disks, etc. |
| `IIO-xx.Z80` | Character IO definitions and routines |
| `RAMD-xx.Z80` | Ram Drive interface/driver routines (optional) |
| `TIM-xx.Z80` | Counter/Timer routines and ZSDOS Clock Driver |
| `WBOOT-xx.Z80` | Warm Boot and re-initialization routines |
## 3.3 B/P Bios Options
The most logical starting point in beginning a configuration is to edit the `DEF-xx.LIB` file to select your desired options. This file is the basic guide to choosing the options for your system, and some careful choices here will minimize the Bios size and maximize your functionality. Some of the more important options and a brief description of them are:
**MOVCPM** - Integrate into MOVCPM "type" loader? If the system is to be integrated into a MOVCPM system, the Environment descriptor contained in the CBOOT routine is always moved into position as part of the Cold Start process. If set to NO, a check will be made to see if an Environment Descriptor is already loaded, and the Bios copy will not be loaded if one is present.
NOTE: When assembling a Bios for Boot Track Installation (MOVCPM set to YES), many options are deleted to conserve space and the Bios Version Number is forced to 1.1.
**BANKED** - Is this a banked BIOS? If set to YES, the Bank control module, IBMV, is included in the assembly, and much of the code is relocated to the system bank. Note that a Banked system CANNOT be placed on the System Tracks, or integrated into a MOVCPM image.
**IBMOVS** - Are Direct Inter-Bank Moves possible? If set to YES, direct transfer of data between banks is possible such as with the Zilog Z180/Hitachi 64180. If NO, a 256-byte transfer buffer is included in high Common Memory and Interbank moves require transfer of bytes through this buffer.
**ZSDOS2** - Assemble this for a Banked ZSDOS2 system? If YES, the ALV and CSV buffers will be placed in the System bank invisible to normal programs. This has the side effect that many CP/M programs which perform sizing of files (Directory Listers, DATSWEEP, MEX, etc) which do not know about this function will report erroneous sizes. The advantage is that no sacrifice in TPA is required for large Hard Disks. Set this to NO if you want strict CP/M 2.2 compatibility.
**FASTWB** - Restore the Command Processor from the System Bank RAM? If set to YES, Warm Boots will restore the Command Processor from a reserved area in the System RAM bank rather than from the boot tracks. For the maximum benefit of B/P Bios, always attempt to set this to YES. In systems without extended memory, it MUST be set to NO.
**MHZ** - Set to Processor Speed in closest even Megahertz (e.g. for a 9.216 MHz clock rate, set to 9). The value entered here is used in many systems to compute Timing values and/or serial data rate parameters.
**CALCSK** - Calculate Diskette Skew Table? If NO, a Skew table is used for each floppy format included in the image. Calculating Skew is generally more efficient from a size perspective, although slightly slower by factors which are so small as to be practically unmeasurable.
**HAVIOP** - Include IOP code into Jump table? If the IOPINIT routine satisfies your IOP initialization requirements, you may turn this off by setting to NO and save a little space. This typically will be turned off when generating a system for MOVCPM integration to conserve space.
**INROM** - Is the Alternate Bank in ROM? Set to NO for Normal Disk-based systems. Please contact the authors if you need additional information concerning ROM-based system components.
**BIOERM** - Print BIOS error messages? Set this to YES if you desire direct BIOS printing of Floppy Disk Error Messages. If you are building a BIOS for placement on Boot Tracks, however, you will probably not have room and must turn this Off. Set to NO to simply return the normal Success/Fail error flag with no Message printout.
**FLOPY8** - Include 8"/Hi-Density Floppy Formats? Some systems (SB-180, Compu/Time) can handle both 5.25" and 8" disks. If your hardware supports the capability and you want use 8" disks as well as the normal 3.5 and 5.25" diskettes, setting this to YES will add formats contained in `DPB8.LIB` and control logic to the assembly. Future systems may take advantage of the "High-Density" 3.5 and 5.25" Floppy Disks which use higher data rates. Their definitions will be controlled by this flag as well.
NOTE: If AUTOSL is set to NO, this option will probably cause the BIOS to be larger than necessary since these additional formats may not be accessible.
**MORDPB** - Use more Floppy DPB's (in addition to normal 4-5.25" and optional 8")? If YES, the file `DPB2.LIB` is included. Many of the formats are Dummies and may be filled with any non-conflicting formats you desire.
NOTE: If AUTOSL if set to NO, this option will probably cause the BIOS to be larger than necessary since these additional formats may not be accessible.
**MORDEV** - Include Additional Character Device Drivers? Is set to YES, user-defined drivers are added to the Character IO table, and associated driver code is assembled. Systems featuring expansion board such as the SB-180 and YASBEC may now take advantage of additional serial and parallel interfaces within the basic Bios. Set to NO to limit code to the basic 4 drivers.
NOTE: When assembling a Bios for Boot Track Installation (MOVCPM set to YES), MORDEV is overridden to conserve space, and the Bios Version Number is forced to 1.1 in the distribution files.
**BUFCON** - Use type ahead buffer for the Console? If set to YES, code is added to create and manage a type-ahead buffer for the driver assembled as the console. This device will be controlled by either interrupts (in systems such as the YASBEC and SB-180) or background polling (in Ampro and Compu/Time). This means that characters typed while the computer is doing something else will not be lost, but will be held until requested.
**BUFAUX** - Use type ahead buffer on Auxiliary Port? As with BUFCON above, setting to YES will add code to create and manage a type ahead buffer for the auxiliary device. Since the AUX port typically is used for Modem connections, buffering the input will minimize the loss of characters from the remote end.
**AUTOSL** - Auto-select floppy formats? If set to YES, selection of Floppy disks will use an algorithm in `SELFLP2.Z80` to identify the format of the disk from the DPB files included (`DPB.LIB`, optional `DPB8.LIB`, and optional `DPB2.LIB`) and log the disk if a match is found. There must be NO conflicting definitions included in the various files for this to function properly. See the notes in the various files to clarify the restrictions. If set to NO, the single file `DPBRAM.LIB` is included which may be tailored to contain only the fixed format or formats desired per disk drive. This results in the smallest code requirement, but least flexibility.
**RAMDSK** - Include code for a RAM-Disk? If set to YES, any memory above the System or User bank may be used for a RAM Drive (default is drive M:) by including the file `RAMD-xx.Z80`. Parameters to determine the size and configuration are also included in the files `DPHM-xx.LIB` and `DPBM-xx.LIB`. In systems without extended memory, or to conserve space such as when building a system for the boot tracks, this may be disabled by setting to NO.
**HARDDSK** - Include SCSI Hard Disk Driver? Set to YES if you wish to include the ability to access Hard Disk Drives. In a floppy-only system, a NO entry will minimize BIOS code.
**HDINTS** - (System Dependent) In some systems such as the YASBEC, Interrupt-driven Hard Disk Controllers using DMA transfer capabilities may be used. If you wish to use this type of driver specified in the file `HARDI-xx.Z80` instead of the normal polled routines included in `HARD-xx.Z80`, set this option to TRUE. In most cases, this driver will require more Transient Program Area since the Interrupt Handling routine must be in Common Memory.
**CLOCK** - Include ZSDOS Clock Driver Code? If set to YES, the vector at BIOS+4EH will contain a ZSDOS-compatible clock driver with the physical code contained in the `TIM-xx.Z80` module. If set to NO, calls to BIOS+4EH return an error code.
**TICTOC** - (System Dependent) Use pseudo heartbeat counter? This feature is used in systems such as the Ampro Little Board and Compu/Time SBC880 which do not have an Interrupt scheme to control a Real Time Clock. Instead, a series of traps are included in the code (Character IO Status polls, Floppy Disk Status polls) to check for overflow of a 1-Second Counter. It is less desirable than an Interrupt based system, but suffices when no other method is available. Set to NO if not needed.
**QSIZE** - Size in bytes of type ahead buffers controlled by BUFCON and BUFAUX.
**REFRSH** - Activate Dynamic Refresh features of Z180/HD64180 processors? In some computers using these processors such as the YASBEC, refresh is not needed and merely slows down processing. Set to NO if you do not need this feature. If your processor uses dynamic memory, or needs the signal for other purposes (e.g. The SB180 uses Refresh for Floppy Disk DMA), Set this to YES.
**Z3** - Include ZCPR init code? Since a Z3 Environment is mandatory in a B/P Bios (which now "owns" the Environment), this option has little effect.
For assembly of a Banked version of B/P Bios, the identification of various banks of memory must be made so that the various system components "know" where things are located. Refer to Section 3.1 above for a description of these areas. The BNK0 value should be the first bank of RAM in the System unless other decoding is done. The following equates must be set:
| Equate | Description |
| :--- | :--- |
| BNK0 | First 32k TPA Bank (switched in/out) |
| BNK1 | Second 32k TPA Bank (Common Bank) |
| BNK2 | Beginning of System Bank (BIOS, DOS, CPR) area |
| BNKU | Beginning of Bank sequence for User Applications |
| BNK3 | Beginning of Extra Banks (first bank to use for RAM Disk) |
| BNKM | Maximum Bank Number assigned |
## 3.4 Configuration Considerations
When assembling a version of B/P Bios for integration into an IMG file, size of the resulting image is not much of a concern, so you need not worry about minor issues of size. For integration into a system for loading onto diskette boot tracks, however, the limitation is very real in order to insure that the CPR/DOS/BIOS and Boot Sector(s) can fit on the reserved system tracks. Typically, a limit of slightly under 4.5k exists for the Bios component. When the MOVCPM flag is set to YES for this type of assembly, warnings will be issued when the image exceeds 4352 bytes (the maximum for systems with 2 boot records), and 4480 bytes (the maximum for systems with a single boot record). Achieving these limits often requires disabling many of the features.
The first thing you should do before assembling the BIOS is to back up the entire disk, then copy only the necessary files onto a work disk for any editing. After setting the options as desired, edit the hardware definitions in `ICFG-xx.Z80` to reflect the physical characteristics of your floppy and hard drives, as well as any other pertinent items. Then edit the logical characteristics for your Hard and Ram Drives (if any) in `DPBHD-xx.LIB` and `DPBM-xx.LIB`. If you do not desire any of the standard floppy formats or want to change them, edit `DPB.LIB` and/or `DPB2.LIB` (if using auto selection) or `DPBRAM.LIB` if you are using fixed floppy formats. Finally edit the DPH files to place the logical drives where desired in the range A..P.
Decide whether you want to generate a system using the Image file construct developed in support of B/P Bios (BPBUILD/LDSYS), or for integration on a floppy disk's boot tracks. If the latter, you probably will not be able to have all options turned on. For example, with the MicroMint SB-180, the following options must be turned Off: BANKED, ZSDOS2, BIOERM, FLOPY8, MORDPB, BUFAUX and usually either CLOCK or RAMDSK. As an aid to space reduction, conditional assembly based on the MOVCPM flag automatically inhibits all but double-sided Floppy formats from `DPB.LIB`. If configuring for Floppy Boot tracks (MOVCPM flag set to TRUE), a warning will be printed during assembly if the size exceeds that available for a One or Two-sector boot record. Using the BPBUILD/LDSYS method, you may vary nearly all system parameters, even making different systems for later dynamic loading.
If you are using a version of the B/P Bios already set for your type of computer, you are now ready to assemble, build a system and execute it. The only remaining task would be an optional tailoring of the sign on banner in the file `CBOOT-xx.Z80` and reassembly to a `.REL` file.
For those converting a standard version of the B/P Bios to a new hardware system, we recommend that you begin with a Floppy-only system in Non-Banked mode then expand from there. The easiest way to test out new versions is to use the System Image (IMG file) mode, then advance to boot track installations if that is desired. Enhancements that can be added after testing previous versions may be to add Hard Drives, RAM Drive, and finally Banking.

200
Doc/CPM/BPBIOS/BPBIOS_4_Installation.md Normal file
View File

@@ -0,0 +1,200 @@
# 4 Installing a B/P Bios
The Distribution diskette(s) on which B/P Bios is furnished are configured for booting from the vanilla hardware for the version ordered. A 9600 bps serial terminal is standard, and will allow you to immediately bring up a minimal Non-Banked Floppy Disk system. Due to the variety of different system configurations and size restrictions in some versions, only the Floppy Disk Mass Storage capability can be assured on the initial boot disk. Where space remained on the boot tracks, limited Hard Drive support is also provided, and in some configurations, even RAM Drive support exists.
After booting from either an established system, or the boot tracks of the distribution disk, format one or more fresh diskettes and copy the distribution diskette(s) contents to the backup diskette(s). Copy the boot tracks from the master to the copies using BPSYSGEN (see 6.6). Remove the master diskette(s) for safekeeping and work only with the copies you just made.
Using the backup diskette with the B/P utilities on it, execute BPCNFG in the Boot Track configuration mode (see 6.2), adjusting all the options to your specific operating environment. When you have completed tailoring the system, it is ready for booting by placing the diskette in drive A: and resetting the system.
The sample `STARTUP.COM` file on the distribution disk will automatically execute a sequence of instructions when the system is booted. It contains various instructions which further tailor the system and load portions of the operating system which are too big to fit on the boot tracks. The default instruction sequence is:
| Command | Explanation |
| :--- | :--- |
| `LDDS` | Load the DateStamper style File Stamp routine and clock |
| `LDR SYS.RCP,SYS.FCP,SYS.NDR` | Load ZCPR 3 Environment segments for Resident Command Processor, Flow Control Pkg and Named Dirs |
| `IOPINIT` | Initialize the IO Processor Pkg |
| `TD S` | Prompt for Date and Time, Set Clk / Alternatives are to use `TDD` (6.21) or `SETCLOK` (6.18) |
| `IF ~EX MYTERM.Z3T` | If the file `MYTERM.Z3T` does Not exist... |
| `TCSELECT MYTERM.Z3T` | ..select which terminal you have creating a `MYTERM.Z3T` file |
| `FI` | ...end of the `IF` |
| `LDR MYTERM.Z3T` | Load the Terminal Definition data |
If you wish to alter any of these initial instructions to, for example, initialize the RAM drive using INIRAMD, add File Time Stamp capabilities to it with INITDIR or PUTDS and copy some files there with COPY, these may be added with ALIAS, VALIAS, SALIAS or other compatible files available from the ZSYSTEM or ZCPR33 areas on Z-Nodes.
After the initial system is up and running from the Default Boot Track system, you may expand the operation by generating systems for different purposes in order to gain the most advantage from your system. Many types of installation are possible, the simplest of which is a Non-Banked system using only 64k of the systems memory, all of which is in primary memory. Such a system uses a normal Command Processor such as the ZCPR3.x family, and a Non-Banked Operating System such as our ZSDOS Version 1. Non-Banked systems may be installed on a Disk's Boot Tracks, or created as an Image File for dynamic loading using the LDSYS Utility (see 6.15).
Banked systems MUST be created with the BPBUILD Utility (see 6.1) and loaded with LDSYS (see 6.15). The techniques to manage different memory banks to form a complete Operating Environment are rather intricate and are best handled by our utilities. Many Image files may be created and loaded as needed to tailor your system for optimum performance. The following sections describe these various types of installations in detail.
## 4.1 Boot Track Installation
For most of the existing CP/M compatible computers to begin executing a Disk Operating System, a program must be placed on a specified area of a Floppy or Hard Disk Drive. Normally, the first two or three tracks on the disk are reserved for this purpose and are referred to as the "Boot Tracks". Since the space so defined is generally restricted, neither a complete B/P Bios nor a Banked installation is possible. Instead, a scaled-down system roughly equivalent to those currently in use is used to start the computer and serve as the Operating System, with larger systems loaded later as needed.
If you are using a pre-configured version of B/P Bios for your hardware, you may simply continue to use the Boot Track system from the distribution disk(s) by copying the system as described in Section 4 above using BPSYSGEN (see 6.6). If you elect to alter or otherwise customize the Boot Track system, you must assemble the B/P Bios source setting certain of the equates in the `DEF-xx.LIB` file to insure a correct type of system. To assemble a Boot Track system, the most important equates are:
| Equate | |
| :---: | :--- |
| `MOVCPM` | Set to `YES` |
| `BANKED` | Set to `NO` |
| `ZSDOS2` | Set to `NO` |
One element of Banked Systems is available in a Boot Track installation if additional memory is available, and your B/P Bios routines support such a feature. This feature reloads the Command Processor from Banked memory instead of from the Boot Tracks of a disk, and generally produces less code (taking less space on the Boot Tracks) and executes faster. It is set with:
| Equate | |
| :---: | :--- |
| `FASTWB` | Set to `YES` if desired, `NO` if Warm Boot from disk |
Some of the features that generally need to be disabled to scale a smaller system are set as:
| Equate | |
| :---: | :--- |
| `MORDPB` | Set to `NO` |
| `DPB8` | Set to `NO` |
| `MORDEV` | Set to `NO` |
When at least these equates and any others you desire to change (see section 4) have been made to the component files of the system, assemble your `BPBIO-xx` file to a Microsoft standard `.REL` file. This output file may be used to overlay the Bios portion of the `MOVxSYS.COM` system generation utility (see 6.16) furnished with your distribution disk, or an equivalent program provided with your computer. MOVxSYS or its equivalent (MOVCPM, MOVZSYS, etc) is a special program customized for your particular hardware containing all the Operating System components which will be placed on the Boot Tracks, along with a routine to alter the internal addresses to correspond to a specified memory size.
To Add the new Bios you just assembled, execute INSTAL12 (see procedures in 6.13) specifying your computer's MOVxSYS or equivalent program and follow the prompts to overlay the new Bios. Once INSTAL12 has saved a relocatable or absolute file, you are ready to create a boot disk containing the modified system.
If you used the command INSTAL12 to install system segments on MOVxSYS or equivalent program, you must first create an Absolute System Model file. Since the functional portion of your new program is identical to the original MOVxSYS or equivalent, use the method explained in your original documentation to generate a new system. With MOVxSYS, the command is:
| Command | |
| :---: | :--- |
| `MOVxSYS nn *` | replace MOVxSYS with your version |
Where `nn` is the size of the system (typically 51 for a moderate boot system). The asterisk tells the program to retain the image in memory and not write it to a disk file. You may now use BPSYSGEN to write the new image to the system tracks of your boot diskette. Do this by executing BPSYSGEN with no arguments and issue a single Carriage Return when asked for the source of the Image.
If you used the command `INSTAL12 /A` to install replacement system segments over a System Image file, or used a utility which wrote the new image to a disk file, use BPSYSGEN to write the image file to the system tracks of your boot disk. The proper command is
`BPSYSGEN filename`
where filename is the name of the disk file you just created by executing MOVxSYS or equivalent with output to a disk file, or with INSTAL12 on an existing image file.
If the system is written to a Hard Disk, and your system supports booting from a Hard Disk such as the YASBEC, you normally must alter the default Boot Sector from the default Floppy Disk Boot Sector contained in MOVxSYS or equivalent. This alteration is accomplished by HDBOOT (see 6.9) which must be customized to the specific Hardware System used.
After the above actions have been completed as appropriate, tailor the Boot Track system to reflect the desired starting configurations with BPCNFG (see 6.2). Such items as the desired Startup file name, Bank Numbers (critical if FASTWB is used), and drive types and assignments are routinely tailored at this point. When the you have finished this step, test your new system by resetting the system, or cycling the power and you should be up and running!
## 4.2 Non-Banked Image Installation
A Non-Banked system may be installed as an Image File as opposed to the basic Boot Track installation covered in 4.1 above. To create an Image File, you must have `.REL` or `.ZRL` versions of a Command Processor (ZCPR3.x or equivalent recommended), an Operating (`ZSDOS.ZRL` recommended), and a REL version of B/P Bios for your system assembled with the MOVCPM equate in `DEF-xx.LIB` set to NO. Other equates in this file may be set as described above for the Boot Track system. Since Image Files are not as constrained in size as is installation for Boot Tracks, more features may generally be activated such as Error Messages, RAM Drive, additional Hard Drive partitions, and complete Floppy Format suites. The main precaution here is that large Hard Drives will rapidly cause significant loss of Transient Program Area since all Drive parameters must be in protected high memory above the Bios.
After the Bios has been assembled, an Image file must be produced. This is accomplished with the BPBUILD Utility (see 6.1). Set the File names in Menu 1 to reflect only Non-Banked files (or minimally banked Bios if FASTWB is set to YES), and let BPBUILD do the work. Since the standard Non-Banked System segments are normally set to the "standard" CP/M 2.2 sizes, you may answer the "autosize" query with a Y to obtain the maximum Transient Program Area in the resulting system. When BPBUILD completes its work, a file, normally with the default type of `.IMG`, will have been placed in the currently logged Drive/User area and you are ready to perform the next step in preparation of the Non-Banked Image.
As with the Boot Track installation covered above, several system items must be tailored before the Image may be safely loaded and executed. This is done by calling BPCNFG with the Image file name as an argument, or specify Image configuration from the interactive menu (see 6.2). Set all items as you desire them in the operating system, particularly the Bank Numbers (if FASTWB is active), and the Disk Drive characteristics and assignments. When this has been satisfactorily completed, you are ready to load and execute the newly-created system.
Installing an Image File (default file type of `.IMG`) is extremely easy. Only the utility `LDSYS.COM` (see 6.15) is needed. If the file type has not been changed from the default `.IMG`, only the basic name of the Image File need be passed to LDSYS when executed as:
| Command | |
| :---: | :--- |
| `LDSYS IMGFILE` | where IMGFILE.IMG is your Image file name |
The operating parameters of the currently-executing system are first examined for suitability of loading the Image File. If it is possible to proceed, the Image File is loaded, placed in the proper memory locations, and commanded to begin execution by calling the B/P Bios Cold Boot Vector. The Cold Boot (Bios Function 0) performs final installation, displays any desired opening prompt and transfers control to the Command Processor with any specified Startup file for use by a ZCPR3.x Command Processor Replacement.
Since a non-banked Image File will probably closely resemble that contained on the Boot Tracks, the same STARTUP file may generally be used to complete the initial tailoring sequence. If a different file is desired, the Image File may be altered to specify a different file using BPCNFG.
## 4.3 Banked Bios, Non-banked System Installation
With the B/P Bios system, an Image system may be created and loaded which places portions of the Bios Only in the System bank, retaining a non-banked Operating System and therefore maximum compatibility with existing applications software. A few thousand bytes can normally be reclaimed for Transient Programs in this manner, although large and/or increasing numbers of logical drives will still reduce TPA space because of the need to store Allocation Vector information in Common Memory.
To prepare such a system, simply edit the needed Bios files if necessary with particular emphasis on the `DEF-xx.LIB` file where the following equates must be set as:
| Equate | |
| :---: | :--- |
| `MOVCPM` | Set to `NO` |
| `BANKED` | Set to `YES` |
| `ZSDOS2` | Set to `NO` |
Since banked memory MUST be available for this type of installation, you will probably want the Fast Warm Boot feature available to maximize system performance. To activate this option, set the following equate as:
| Equate | |
| :---: | :--- |
| `FASTWB` | Set to `YES` |
When the editing is complete, assemble the Bios to a Microoft `.REL` file with an appropriate assembler such as ZMAC and build an Image system with BPBUILD (see 6.1) changing the Bios file name in menu 1 to the name of the newly created Bios file. Next, configure the default conditions if necessary with BPCNFG (see 6.2) and you are ready to activate the new system in the same manner as all Image files by calling LDSYS with the Image file argument as:
| Command | |
| :---: | :--- |
| `LDSYS BBSYS` | where BBSYS.IMG is your Image File Name |
As with the completely Non-Banked system described above in Section 4.2, no new requirements are established for a Startup file over that used for the initial Boot System, since both the Command Processor and Disk Operating System are unbanked, and no data areas needed by application programs are placed in the System Bank. As with all Image Files, additional features such as full Bios Error Messages, more extensive Floppy Disk Formats and RAM drive may generally be included in the System definition prior to assembly since the size constraints of Boot Track systems do not apply.
## 4.4 Fully Banked Image Installation
To create a system taking maximum advantage of banked memory, a special banked Operating System and Command Processor are needed. These have been furnished in initial form with this package as `ZSDOS20.ZRL` and `Z40.ZRL` respectively. They use the Banking features of B/P Bios and locate the maximum practicable amount of executable code and data in the System Bank. Of significant importance to maximizing the Transient Program Area is that the Drive Allocation Bit maps are placed in the System Bank meaning that adding large hard drives, or multiple drives produce only minimal expansion to the resident portion of the Bios.
NOTE: The latest versions are `ZS203.ZRL`, `ZS227G.ZRL`, and `Z41.ZRL` as included in the public release of B/P Bios. See also sections 7 and 8.
A Fully banked Bios is created by editing the B/P Bios files as needed to customize the system to your desires. Insure that the following `DEF-xx.LIB` equates are set as:
| Equate | |
| :---: | :--- |
| `MOVCPM` | Set to `NO` |
| `BANKED` | Set to `YES` |
| `ZSDOS2` | Set to `YES` |
Assemble the resultant B/P Bios to a Microsoft `.REL` file, Build an Image file with BPBUILD (see 6.1) and configure the produced Image file with BPCNFG (see 6.2). When you are confident that all default settings have been made, activate the file by entering:
| Command | |
| :---: | :--- |
| `LDSYS FBANKSYS` | where FBANKSYS.IMG is your Image File Name |
Several differences may exist in the Startup file used for a Fully banked system. Generally the changes amount to deleting items such as a File Stamp module for the Non-banked ZSDOS1 which is not necessary with the fully-banked ZSDOS 2 and Z40. Only the type of clock need be specified for ZSDOS2. Furthermore, since the Z40 Command Processor Replacement contains most commonly-used commands gathered from a number of Resident Command Processor (RCP) packages, there is normally no need to load an RCP. A simple Startup file found adequate during development of the fully-banked B/P system is:
| Command | Explanation |
| :--- | :--- |
| `ZSCFG2 CB` | Set ZSDOS 2 clock to Bios+4EH |
| `LDR SYS.FCP,SYS.NDR` | Load ZCPR 3 Environment segments for Flow Control and Named Dirs |
| `IOPINIT` | Initialize the IO Processor Pkg |
| `TD S` | Prompt for Date and Time, Set Clk / Alternatives are to use `TDD` (6.21) or `SETCLOK` (6.18) |
| `IF ~EX MYTERM.Z3T` | If the file `MYTERM.Z3T` does Not exist... |
| `TCSELECT MYTERM.Z3T` | ..select which terminal you have creating a `MYTERM.Z3T` file |
| `FI` | ...end if the `IF` |
| `LDR MYTERM.Z3T` | Load the Terminal Definition data |
Since the requirements for a fully-banked system differ significantly from a non-banked one, we recommend that you use a different name for the Startup file. For example, `STARTUP.COM` is the default name used with Boot Track systems for initial operation, and with Non-banked Image Files, while STARTB may be a suitable name for the script to be executed upon loading a fully-banked system. The name of the desired Startup file may be easily altered in either Boot Track or Image systems from Option 1 in BPCNFG (see 6.2).
An option available to start from a large Image File is to configure a Startup file for execution by the Boot Track system containing a single command. The command would simply invoke LDSYS with the desired Banked Image File as an argument such as:
| Command | |
| :---: | :--- |
| `LDSYS BANKSYS` | where BANKSYS.IMG is your Image file |
In this case, none of the normal initialization sequences cited above would be executed by the Boot Track system, and only those contained in the Startup for `BANKSYS.IMG` would occur. Other options abound and are left to the community to invent new combinations and sequences.
## 4.5 In Case of Problems...
While We attempted to outline procedures for the majority of installations we considered feasible, there may be occasions where you inadvertently find yourself in a position where you seem to have lost the ability to get your system up and running.
**PROBLEM:** When loading an `.IMG` file with LDSYS, the screen displays the LDSYS banner, system addresses, and halts with the last screen displaying: "...loading banked system".
_SOLUTION:_ Something is not set correctly in the Bios, since all lines after the last one displayed are printed from the newly-loaded Bios. One of the most common causes for this problem is incorrect bank number settings. Use the hidden selection in Menu 1 of BPCNFG (see 6.2) to verify that the correct bank numbers have been set for TPA and SYStem banks. Another common cause of this problem is incorrect settings for the Console port, or a setting in the IOBYTE which directs Console data to a device other than the one intended. Use Menu 2 BPCNFG to properly set the IOBYTE and the console parameters.
**PROBLEM:** You boot from or load a B/P Bios system from a Hard Drive, and immediately after starting, the system attempts to log onto Floppy Drive 0.
_SOLUTION:_ The most common cause for this symptom is that the desired Hard Drive and Floppy Drive definitions were not swapped to define a Hard Drive Partition as the A: drive. Use BPCNFG (see 6.2), Menu 5 to exchange drives to the desired configuration. A similar situation may exist where a Hard Drive is activated immediately after booting when a Floppy drive is desired as the A: Drive.
**PROBLEM:** The computer seems to boot satisfactorily, but after a few programs or any program which executes a Warm Boot (or entering Control-C), the system goes into "Never-never Land" and must be reset.
_SOLUTION:_ This symptom is most often caused by an inability to access and load the Command Processor. This is most probably caused by assembling B/P Bios with the FASTWB equate in `DEF-xx.LIB` set to YES when the system contains no extended memory, or incorrect settings of the Bank Numbers. To check Bank Number settings, use the hidden function in BPCNFG, Menu 1 (see 6.2).
**PROBLEM:** When doing a Cold Boot from a Hard Drive (from Power up or Reset), the system goes to a Floppy Drive before displaying the initial sign on messages, and remains logged on the Floppy.
_SOLUTION:_ This is most often due to your forgetting to run the HDBOOT utility on the Hard Drive Boot system after applying it with BPSYSGEN. Normally, systems created with MOVxSYS contain a Floppy Disk Boot sector which will load the initial Operating System from a Floppy. HDBOOT (see 6.9) modifies this record on a specified Hard Drive Unit so that the Operating System is loaded from a Hard Drive. Run HDBOOT on the Desired Hard Drive, then use BPCNFG (see 6.2) to insure that the logical drives are positioned as desired (Menu 5).
**PROBLEM:** When Booting, the system console either doesn't display anything, or prints strange characters.
_SOLUTION:_ This is most often due to incorrect settings for the current Console, most probably the Data rate, or CPU Clock Frequency. Boot from a good system, then use BPCNFG (see 6.2) to adjust the settings on the problem system. Pay particular attention to Menu 1 (CPU Clock Rate) and Menu 2 (IOBYTE and Serial Port Data Rates).
**PROBLEM:** When running a fully-banked system with ZSDOS 2, some programs seem to "hang" or "lock up" the system on exit.
_SOLUTION:_ One of the most common sources of this symptom is with the application program where the author used code which assumes that the BDOS and Command Processor are of a certain size, or bear a fixed relationship to the addresses in page 0. You may experience this most often when using an IMG system built by answering YES to the Autosizing query in BPBUILD (see 6.1). To compensate for such ill-behaved programs, you may use a two-step build process as:
1. Use BPBUILD to create an IMG file answering YES to Autosizing on exit. This maximizes TPA placing the Resident Bios as high as possible in memory.
2. Execute BPBUILD again with an argument of the name you gave to the file just created above. This loads the definition from the IMG file. Immediately exit with a Carriage Return, and answer NO to Autosizing, and YES to placing system segments at standard locations. This procedure keeps the Bios address constant, but will move the starting addresses of BDOS and Command Processor down, if possible, to simulate "standard" sizes used in CP/M 2.2.

1364
Doc/CPM/BPBIOS/BPBIOS_5_Programming.md Normal file
View File

File diff suppressed because it is too large Load Diff

2579
Doc/CPM/BPBIOS/BPBIOS_6_Utilities.md Normal file
View File

File diff suppressed because it is too large Load Diff

37
Doc/CPM/BPBIOS/BPBIOS_7_ZSDOS2.md Normal file
View File

@@ -0,0 +1,37 @@
# 7 ZSDOS Version 2
Version 2 of ZSDOS is currently in a developmental phase. The version provided with this package is preliminary and should not be considered a final work. Be sure you back up any files which you don't mind sacrificing, and please let us know in as much detail as possible any problems you experience.
In addition to the ZSDOS Version call (Function 48) returning 20H signifying ZSDOS2, three new Operating System functions have been added. They are:
| Function 46 | Return Disk Free Space |
| ---: | :--- |
| Enter: | C = 46 (function #) |
| | E = Drive # (A=0..P=15) |
| Exit: | A = 0 if Ok, <>0 if Error |
| | Disk Free Space in kilobytes is placed in DMA+0 (LSB) thru DMA+3 (MSB) |
This function returns Disk Free Space from fully-banked systems where the ALV buffers are not directly accessible by applications programs. It **MUST** be used to reliably determine free space since there is no way for programs to ascertain which System Bank (if more than one) contains the Allocation Bit Map. For most reasonably-sized systems, only the lower two or three bytes will be used, but four bytes are allocated to accommodate a maximally-sized system.
| Function | Return Environment Descriptor Address |
| ---: | :--- |
| Enter: | C = 49 (function #) |
| Exit: | HL = Address of Env Desc. |
This function returns the address of a ZCPR 3.4 "type" Environment Descriptor needed in B/P Bios systems. Rather than rely on the Command Processor inserting the ENV address into application programs upon execution, this function may be used to reliably acquire the ENV address at any time.
| Function 152 | Parse File Name |
| ---: | :--- |
| Enter: | C = 152 (function #) |
| | DE = Pointer to dest FCB |
| | DMA --> start of parse string |
| Exit: | A = Number of "?" in fn.ft |
| | DE = points to delimiter |
| | FCB+15 will be 0 if parse Ok, 0FFH if errors occurred |
This function may be used to replace Z3LIB library routines in a more robust manner and produce consequently smaller applications programs. It is fully compliant with ZCPR 3.4 parse specifications.
## 7.1 NOTES Spring 2001
The versions of ZSDOS2 (the Banked Z-System DOS) and Z4x Banked Command Processor Replacement have been modified over the years. The manual may refer to specific versions, or by generic names. As of the Spring 2001 release under the GNU General Public License, Two versions of ZSDOS2 are provided; `ZS203.ZRL` which contains code for hashed directories, and `ZS227G,ZRL` which does not.

10
Doc/CPM/BPBIOS/BPBIOS_8_ZCPR4.md Normal file
View File

@@ -0,0 +1,10 @@
# 8 ZCPR Version 4
`Z40.ZRL` is a consolidation of ZCPR34 and many of the RCP features commonly in use, modified by the need to bank as much of the Command Processor as possible. When Z40 is used in a Fully-Banked system, you may not need much of, or any Resident Command Processor with your system. Z40 relys on ZSDOS2 and will **NOT** work without it since the Command Line Parser and disk free space calculations have been removed in favor of ZSDOS2 services. Additionally, the prompt line displays the time and will only function correctly if he ZSDOS2 clock is enabled. Comments on how these new System components work would be appreciated.
More complete documentation is provided in the `Z40.HLP` files included with the distribution diskettes, and a list of active functions is available with the H command at the prompt. To read the On-line help files, use `HELP.COM` available for downloading from any Z-Node.
## 8.1 NOTES Spring 2001
The versions of ZSDOS2 (the Banked Z-System DOS) and Z4x Banked Command Processor Replacement have been modified over the years. The manual may refer to specific versions, or by generic names. As of the Spring 2001 release under the GNU General Public License, the latest version of the Z4x Processor Replacement is `Z41.ZRL` which features a small amount of tailoring. A new utility; **`CONFZ4.COM`** is available for this purpose.

100
Doc/CPM/BPBIOS/BPBIOS_9_Glossary.md Normal file
View File

@@ -0,0 +1,100 @@
# GLOSSARY
**Application Programs**
In contrast to utility programs (see), application programs or applications are larger programs such as word processors which function interactively with the user.
**BDOS**
Basic Disk Operating System. The machine-independent, but usually processor-dependent, program which controls the interface between application programs and the machine-dependent hardware devices such as printers, disk drives, clocks, etc. It also establishes the concept of files on media and controls the opening, reading, writing, and closing of such constructs.
**BGii**
BackGrounder ii from Plu*Perfect Systems, a windowing task-switching system for CP/M users with hard or RAM disks.
**BIOS**
Basic Input/Output System. Machine-dependent routines which perform actual peripheral device control such as sending and receiving characters to the console, reading and writing to disk drives, etc.
**Bit**
BInary digiT. An element which can have only a single on or off state.
**Bit Map**
An array of bits used to represent or map large arrays of binary information in a compact form.
**Boot**
The term used for the starting sequence of a computer. Generally applies to starting from a "Cold," or power-off state, and includes the loading of Operating System, and configuration steps.
**Byte**
A grouping of eight bits.
**CPR**
Command Processor Replacement. Replaces CCP (see below). Example: ZCPR
**CCP**
Console Command Processor. The portion of the operating system that interprets user's commands and either executes them directly or loads application programs from disk for execution. The CCP may be overwritten by applications, and is reloaded by the "Warm Boot" function of the BIOS.
**Checksum**
An value which arithmetically summarizes the contents of a series of memory locations, and used to check the current contents for errors.
**Clock Driver**
A software link between a Non-banked ZSDOS and the clock on your system. The clock driver allows ZSDOS and its utilities to read the clock which is normally inherent in the B/P Bios.
**Command Script**
Sometimes called simply scripts, command scripts allow you to create a single command which issues other commands to perform a unique set of actions. CP/M submit files are one kind of command script familiar to all CP/M users. ZCPR also offers more sophisticated types of scripts such as aliases and command files (e.g., ALIAS.CMD).
**DateStamper**
A software package developed by Plu*Perfect Systems to allow time and date stamping of files. The Boot System uses an external module in the file LDDS.COM to implement DateStamper, while ZSDOS2 automatically supports this stamping method. DateStamper is unique among file stampers for microcomputers for two reasons: first, it maintains all file stamps within a file; second, it maintains stamps for create, access, and modify time/date for each file.
**DDT**
Dynamic Debugging Tool. A utility distributed with CP/M 2.2 which can display, disassemble, or alter disk files or areas of memory using opcodes or hexadecimal values.
**DOS**
Disk Operating System. Often used term for the BDOS, but generally refers to the aggregate of CCP, BDOS and BIOS.

1
Doc/ChangeLog.txt
View File

@@ -11,6 +11,7 @@ Version 3.6
- WBW: Added enhanced Hi-Tech C Compiler files from Ladislau Szilagyi
- WBW: Added boundary check to ram/rom disk driver
- WBW: Per Peter Onion, switch KERMIT default file xfer mode to binary
- J?L: Source for ZSDOS2 and BPBIOS Utilities (from disassembly)
Version 3.5.1
-------------

BIN
Doc/RomWBW Applications.pdf
View File

Binary file not shown.

BIN
Doc/RomWBW Disk Catalog.pdf
View File

Binary file not shown.

BIN
Doc/RomWBW Hardware.pdf
View File

Binary file not shown.

BIN
Doc/RomWBW Introduction.pdf
View File

Binary file not shown.

BIN
Doc/RomWBW System Guide.pdf
View File

Binary file not shown.

BIN
Doc/RomWBW User Guide.pdf
View File

Binary file not shown.