Colossal Cave Adventure is a CP/M port of the 1976 classic game
originally written by Will Crowther for the PDP-10 mainframe. See
-[https://en.wikipedia.org/wiki/Colossal_Cave_Adventure] and
-[https://if50.substack.com/p/1976-adventure]
+
/Source/Images/d_games
@@ -3273,11 +3273,28 @@ operating system, or which produce programs for execution in embedded
systems without an operating system.
This is the Mar 21, 2023 update 17 released by Tony Nicholson who
currently maintains HI-TECH C at
-[https://github.com/agn453/HI-TECH-Z80-C]
+https://github.com/agn453/HI-TECH-Z80-C
The manual is available in the Doc/Language directory, HI-TECH Z80 C
Compiler Manual.txt
A good blog post about the HI-TECH C Compiler is available at
-[https://techtinkering.com/2008/10/22/installing-the-hi-tech-z80-c-compiler-for-cpm]
+https://techtinkering.com/2008/10/22/installing-the-hi-tech-z80-c-compiler-for-cpm
+User area 1 contains another complete copy of the HI-TECH C Compiler. It
+is identical to the copy in user area 0 except for the following files
+which were enhanced by Ladislau Szilagyi from his GitHub Repository at
+https://github.com/Laci1953/HiTech-C-compiler-enhanced . The files take
+advantage of additional banked memory using the RomWBW HBIOS API. As
+such, they require RomWBW to operate. They should be compatible with all
+CP/M and compatible operations systems provided in RomWBW.
+The enhanced files are:
+
+CGEN.COM
+CPP.COM
+OPTIM.COM
+P1.COM
+ZAS.COM (replaced with Z80AS)
+
+A thread discussing this enhanced version of HI-TECH C is found at
+https://groups.google.com/g/rc2014-z80/c/sBCCIpOnnGg .
The following files are found in
/Source/Images/d_hitechc
@@ -3303,8 +3320,8 @@ Hard Disk Image: hd_msxroms2.img
The collection of MSX ROMs (2 disks) as provided by Les Bird.
+https://github.com/lesbird/MSX8 . You will need appropriate hardware to
+run the loader.
Please review the file ROMLIST.TXT for information on the current
operational status of the ROM and it’s long file name/description.
This disk (RomWBW slice) is not automatically included with the RomWBW
@@ -3330,7 +3347,7 @@ differences.
The manual can be found in the Docs/Language directory,
Turbo_Pascal_Version_3.0_Reference_Manual_1986.pdf
A good overview of using Turbo Pascal in CP/M is available at
-[https://techtinkering.com/2013/03/05/turbo-pascal-a-great-choice-for-programming-under-cpm]
+https://techtinkering.com/2013/03/05/turbo-pascal-a-great-choice-for-programming-under-cpm
The following files are found in
/Source/Images/d_tpascal
@@ -3718,9 +3735,9 @@ Hard Disk Image: hd_z80asm.img
Z80DIS User Manual (1985).pdf
A run through of using the assembler is available at
-[https://8bitlabs.ca/Posts/2023/05/20/learning-z80-asm]
+https://8bitlabs.ca/Posts/2023/05/20/learning-z80-asm
And another shorter, but shows linker usage guide
-[https://pollmyfinger.wordpress.com/2022/01/10/modular-retro-z80-assembly-language-programming-using-slr-systems-z80asm-and-srlnk/]
+https://pollmyfinger.wordpress.com/2022/01/10/modular-retro-z80-assembly-language-programming-using-slr-systems-z80asm-and-srlnk/
The following files are found in
Outside of the hardware platforms adapted to RomWBW, there are a variety
diff --git a/index.html b/index.html
index db9808c3..bdf11599 100644
--- a/index.html
+++ b/index.html
@@ -543,5 +543,5 @@ Repository.
diff --git a/search/search_index.json b/search/search_index.json
index 1113f311..2d1430b9 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"RomWBW ReadMe \\ Version 3.6 \\ Wayne Warthen ( wwarthen@gmail.com ) \\ 31 May 2025 Overview RomWBW software provides a complete, commercial quality implementation of CP/M (and workalike) operating systems and applications for modern Z80/180/280 retro-computing hardware systems. A wide variety of platforms are supported including those produced by these developer communities: RetroBrew Computers ( https://www.retrobrewcomputers.org ) RC2014 ( https://rc2014.co.uk ), RC2014-Z80 ( https://groups.google.com/g/rc2014-z80 ) Retro Computing ( https://groups.google.com/g/retro-comp ) Small Computer Central ( https://smallcomputercentral.com/ ) A complete list of the currently supported platforms is found in the [Installation] section. Supported hardware features of RomWBW include: Z80 Family CPUs including Z80, Z180, and Z280 Banked memory services for several banking designs Disk drivers for RAM, ROM, Floppy, IDE ATA/ATAPI, CF, SD, USB, Zip, Iomega Serial drivers including UART (16550-like), ASCI, ACIA, SIO Video drivers including TMS9918, SY6545, MOS8563, HD6445 Keyboard (PS/2) drivers via VT8242 or PPI interfaces Real time clock drivers including DS1302, BQ4845 Support for CP/NET networking using Wiznet, MT011 or Serial Built-in VT-100 terminal emulation support RomWBW is distributed as both source code and pre-built ROM and disk images. Some of the provided software can be launched directly from the ROM firmware itself: System Monitor Operating Systems (CP/M 2.2, ZSDOS) ROM BASIC (Nascom BASIC and Tasty BASIC) ROM Forth A dynamic disk drive letter assignment mechanism allows mapping operating system drive letters to any available disk media. Additionally, mass storage devices (IDE Disk, CF Card, SD Card, etc.) support the use of multiple slices (up to 256 per device). Each slice contains a complete CP/M filesystem and can be mapped independently to any drive letter. This overcomes the inherent size limitations in legacy OSes and allows up to 2GB of accessible storage on a single device, with up to 128MB accessible at any one time. The pre-built ROM firmware images are generally suitable for most users. However, it is also very easy to modify and build custom ROM images that fully tailor the firmware to your specific preferences. All tools required to build custom ROM firmware under Windows are included \u2013 no need to install assemblers, etc. The firmware can also be built using Linux or MacOS after confirming a few standard tools have been installed. Multiple disk images are provided in the distribution. Most disk images contain a complete, bootable, ready-to-run implementation of a specific operating system. A \u201ccombo\u201d disk image contains multiple slices, each with a full operating system implementation. If you use this disk image, you can easily pick whichever operating system you want to boot without changing media. By design, RomWBW isolates all of the hardware specific functions in the ROM chip itself. The ROM provides a hardware abstraction layer such that all of the operating systems and applications on a disk will run on any RomWBW-based system. To put it simply, you can take a disk (or CF/SD/USB Card) and move it between systems transparently. A tool is provided that allows you to access a FAT-12/16/32 filesystem. The FAT filesystem may be coresident on the same disk media as RomWBW slices or on stand-alone media. This makes exchanging files with modern OSes such as Windows, MacOS, and Linux very easy. Acquiring RomWBW The RomWBW Repository ( https://github.com/wwarthen/RomWBW ) on GitHub is the official distribution location for all project source and documentation. The fully-built distribution releases are available on the RomWBW Releases Page ( https://github.com/wwarthen/RomWBW/releases ) of the repository. On this page, you will normally see a Development Snapshot as well as recent stable releases. Unless you have a specific reason, I suggest you stick to the most recent stable release. The asset named RomWBW-vX.X.X-Package.zip includes all pre-built ROM and Disk images as well as full source code. The other assets contain only source code and do not have the pre-built ROM or disk images. All source code and distributions are maintained on GitHub. Code contributions are very welcome. Installation & Operation In general, installation of RomWBW on your platform is very simple. You just need to program your ROM with the correct ROM image from the RomWBW distribution. Subsequently, you can write disk images on your disk drives (IDE disk, CF Card, SD Card, etc.) which then provides even more functionality. Complete instructions for installation and operation of RomWBW are found in the RomWBW User Guide . It is also a good idea to review the Release Notes for helpful release-specific information. Documentation Documentation for RomWBW includes: RomWBW Introduction RomWBW User Guide RomWBW System Guide RomWBW Applications RomWBW Disk Catalog RomWBW Hardware Acknowledgments I want to acknowledge that a great deal of the code and inspiration for RomWBW has been provided by or derived from the work of others in the RetroBrew Computers Community. I sincerely appreciate all of their contributions. The list below is probably missing many names \u2013 please let me know if I missed you! Andrew Lynch started it all when he created the N8VEM Z80 SBC which became the first platform RomWBW supported. Some of his original code can still be found in RomWBW. Dan Werner wrote much of the code from which RomWBW was originally derived and he has always been a great source of knowledge and advice. Douglas Goodall contributed code, time, testing, and advice in \u201cthe early days\u201d. He created an entire suite of application programs to enhance the use of RomWBW. Unfortunately, they have become unusable due to internal changes within RomWBW. As of RomWBW 2.6, these applications are no longer provided. Sergey Kiselev created several hardware platforms for RomWBW including the very popular Zeta. David Giles created support for the Z180 CSIO which is now included SD Card driver. Phil Summers contributed the Forth and BASIC adaptations in ROM, the AY-3-8910 sound driver, DMA support, and a long list of general code and documentation enhancements. Ed Brindley contributed some of the code that supports the RCBus platform. Spencer Owen created the RC2014 series of hobbyist kit computers which has exponentially increased RomWBW usage. Some of his kits include RomWBW. Stephen Cousins has likewise created a series of hobbyist kit computers at Small Computer Central and is distributing RomWBW with many of them. Alan Cox has contributed some driver code and has provided a great deal of advice. The CP/NET client files were developed by Douglas Miller. Phillip Stevens contributed support for FreeRTOS. Curt Mayer contributed the original Linux / MacOS build process. UNA BIOS and FDISK80 are the products of John Coffman. FLASH4 is a product of Will Sowerbutts. CLRDIR is a product of Max Scane. Tasty Basic is a product of Dimitri Theulings. Dean Netherton contributed eZ80 CPU support, the sound driver interface, and the SN76489 sound driver. The RomWBW Disk Catalog document was produced by Mykl Orders. Rob Prouse has created many of the supplemental disk images including Aztec C, HiTech C, SLR Z80ASM, Turbo Pascal, Microsoft BASIC Compiler, Microsoft Fortran Compiler, and a Games compendium. Martin R has provided substantial help reviewing and improving the User Guide and Applications documents. Mark Pruden has made a wide variety of contributions including: significant content in the Disk Catalog and User Guide creation of the Introduction and Hardware documents Z3PLUS operating system disk image COPYSL and SLABEL utility a feature for RomWBW configuration by NVRAM the /B bulk mode of disk assignment to the ASSIGN utility Jacques Pelletier has contributed the DS1501 RTC driver code. Jose Collado has contributed enhancements to the TMS driver including compatibility with standard TMS register configuration. Kevin Boone has contributed a generic HBIOS date/time utility (WDATE). Matt Carroll has contributed a fix to XM.COM that corrects the port specification when doing a send. Dean Jenkins enhanced the build process to accommodate the Raspberry Pi 4. Tom Plano has contributed a new utility (HTALK) to allow talking directly to HBIOS COM ports. Lars Nelson has contributed several generic utilities such as a universal (OS agnostic) UNARC application. Dylan Hall added support for specifying a secondary console. Bill Shen has contributed boot loaders for several of his systems. Laszlo Szolnoki has contributed an EF9345 video display controller driver. Ladislau Szilagyi has contributed an enhanced version of CP/M Cowgol that leverages RomWBW memory banking. Les Bird has contributed support for the NABU w/ Option Board Contributions of all kinds to RomWBW are very welcome. Licensing RomWBW is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. RomWBW is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with RomWBW. If not, see https://www.gnu.org/licenses/ . Portions of RomWBW were created by, contributed by, or derived from the work of others. It is believed that these works are being used in accordance with the intentions and/or licensing of their creators. If anyone feels their work is being used outside of its intended licensing, please notify: Wayne Warthen wwarthen@gmail.com RomWBW is an aggregate work. It is composed of many individual, standalone programs that are distributed as a whole to function as a cohesive system. Each program may have its own licensing which may be different from other programs within the aggregate. In some cases, a single program (e.g., CP/M Operating System) is composed of multiple components with different licenses. It is believed that in all such cases the licenses are compatible with GPL version 3. RomWBW encourages code contributions from others. Contributors may assert their own copyright in their contributions by annotating the contributed source code appropriately. Contributors are further encouraged to submit their contributions via the RomWBW source code control system to ensure their contributions are clearly documented. All contributions to RomWBW are subject to this license. Getting Assistance The best way to get assistance with RomWBW or any aspect of the RetroBrew Computers projects is via one of the community forums: RetroBrew Computers Forum RC2014 Google Group retro-comp Google Group Submission of issues and bugs are welcome at the RomWBW GitHub Repository . Also feel free to email Wayne Warthen at wwarthen@gmail.com .","title":"Home"},{"location":"#overview","text":"RomWBW software provides a complete, commercial quality implementation of CP/M (and workalike) operating systems and applications for modern Z80/180/280 retro-computing hardware systems. A wide variety of platforms are supported including those produced by these developer communities: RetroBrew Computers ( https://www.retrobrewcomputers.org ) RC2014 ( https://rc2014.co.uk ), RC2014-Z80 ( https://groups.google.com/g/rc2014-z80 ) Retro Computing ( https://groups.google.com/g/retro-comp ) Small Computer Central ( https://smallcomputercentral.com/ ) A complete list of the currently supported platforms is found in the [Installation] section. Supported hardware features of RomWBW include: Z80 Family CPUs including Z80, Z180, and Z280 Banked memory services for several banking designs Disk drivers for RAM, ROM, Floppy, IDE ATA/ATAPI, CF, SD, USB, Zip, Iomega Serial drivers including UART (16550-like), ASCI, ACIA, SIO Video drivers including TMS9918, SY6545, MOS8563, HD6445 Keyboard (PS/2) drivers via VT8242 or PPI interfaces Real time clock drivers including DS1302, BQ4845 Support for CP/NET networking using Wiznet, MT011 or Serial Built-in VT-100 terminal emulation support RomWBW is distributed as both source code and pre-built ROM and disk images. Some of the provided software can be launched directly from the ROM firmware itself: System Monitor Operating Systems (CP/M 2.2, ZSDOS) ROM BASIC (Nascom BASIC and Tasty BASIC) ROM Forth A dynamic disk drive letter assignment mechanism allows mapping operating system drive letters to any available disk media. Additionally, mass storage devices (IDE Disk, CF Card, SD Card, etc.) support the use of multiple slices (up to 256 per device). Each slice contains a complete CP/M filesystem and can be mapped independently to any drive letter. This overcomes the inherent size limitations in legacy OSes and allows up to 2GB of accessible storage on a single device, with up to 128MB accessible at any one time. The pre-built ROM firmware images are generally suitable for most users. However, it is also very easy to modify and build custom ROM images that fully tailor the firmware to your specific preferences. All tools required to build custom ROM firmware under Windows are included \u2013 no need to install assemblers, etc. The firmware can also be built using Linux or MacOS after confirming a few standard tools have been installed. Multiple disk images are provided in the distribution. Most disk images contain a complete, bootable, ready-to-run implementation of a specific operating system. A \u201ccombo\u201d disk image contains multiple slices, each with a full operating system implementation. If you use this disk image, you can easily pick whichever operating system you want to boot without changing media. By design, RomWBW isolates all of the hardware specific functions in the ROM chip itself. The ROM provides a hardware abstraction layer such that all of the operating systems and applications on a disk will run on any RomWBW-based system. To put it simply, you can take a disk (or CF/SD/USB Card) and move it between systems transparently. A tool is provided that allows you to access a FAT-12/16/32 filesystem. The FAT filesystem may be coresident on the same disk media as RomWBW slices or on stand-alone media. This makes exchanging files with modern OSes such as Windows, MacOS, and Linux very easy.","title":"Overview"},{"location":"#acquiring-romwbw","text":"The RomWBW Repository ( https://github.com/wwarthen/RomWBW ) on GitHub is the official distribution location for all project source and documentation. The fully-built distribution releases are available on the RomWBW Releases Page ( https://github.com/wwarthen/RomWBW/releases ) of the repository. On this page, you will normally see a Development Snapshot as well as recent stable releases. Unless you have a specific reason, I suggest you stick to the most recent stable release. The asset named RomWBW-vX.X.X-Package.zip includes all pre-built ROM and Disk images as well as full source code. The other assets contain only source code and do not have the pre-built ROM or disk images. All source code and distributions are maintained on GitHub. Code contributions are very welcome.","title":"Acquiring RomWBW"},{"location":"#installation-operation","text":"In general, installation of RomWBW on your platform is very simple. You just need to program your ROM with the correct ROM image from the RomWBW distribution. Subsequently, you can write disk images on your disk drives (IDE disk, CF Card, SD Card, etc.) which then provides even more functionality. Complete instructions for installation and operation of RomWBW are found in the RomWBW User Guide . It is also a good idea to review the Release Notes for helpful release-specific information.","title":"Installation & Operation"},{"location":"#documentation","text":"Documentation for RomWBW includes: RomWBW Introduction RomWBW User Guide RomWBW System Guide RomWBW Applications RomWBW Disk Catalog RomWBW Hardware","title":"Documentation"},{"location":"#acknowledgments","text":"I want to acknowledge that a great deal of the code and inspiration for RomWBW has been provided by or derived from the work of others in the RetroBrew Computers Community. I sincerely appreciate all of their contributions. The list below is probably missing many names \u2013 please let me know if I missed you! Andrew Lynch started it all when he created the N8VEM Z80 SBC which became the first platform RomWBW supported. Some of his original code can still be found in RomWBW. Dan Werner wrote much of the code from which RomWBW was originally derived and he has always been a great source of knowledge and advice. Douglas Goodall contributed code, time, testing, and advice in \u201cthe early days\u201d. He created an entire suite of application programs to enhance the use of RomWBW. Unfortunately, they have become unusable due to internal changes within RomWBW. As of RomWBW 2.6, these applications are no longer provided. Sergey Kiselev created several hardware platforms for RomWBW including the very popular Zeta. David Giles created support for the Z180 CSIO which is now included SD Card driver. Phil Summers contributed the Forth and BASIC adaptations in ROM, the AY-3-8910 sound driver, DMA support, and a long list of general code and documentation enhancements. Ed Brindley contributed some of the code that supports the RCBus platform. Spencer Owen created the RC2014 series of hobbyist kit computers which has exponentially increased RomWBW usage. Some of his kits include RomWBW. Stephen Cousins has likewise created a series of hobbyist kit computers at Small Computer Central and is distributing RomWBW with many of them. Alan Cox has contributed some driver code and has provided a great deal of advice. The CP/NET client files were developed by Douglas Miller. Phillip Stevens contributed support for FreeRTOS. Curt Mayer contributed the original Linux / MacOS build process. UNA BIOS and FDISK80 are the products of John Coffman. FLASH4 is a product of Will Sowerbutts. CLRDIR is a product of Max Scane. Tasty Basic is a product of Dimitri Theulings. Dean Netherton contributed eZ80 CPU support, the sound driver interface, and the SN76489 sound driver. The RomWBW Disk Catalog document was produced by Mykl Orders. Rob Prouse has created many of the supplemental disk images including Aztec C, HiTech C, SLR Z80ASM, Turbo Pascal, Microsoft BASIC Compiler, Microsoft Fortran Compiler, and a Games compendium. Martin R has provided substantial help reviewing and improving the User Guide and Applications documents. Mark Pruden has made a wide variety of contributions including: significant content in the Disk Catalog and User Guide creation of the Introduction and Hardware documents Z3PLUS operating system disk image COPYSL and SLABEL utility a feature for RomWBW configuration by NVRAM the /B bulk mode of disk assignment to the ASSIGN utility Jacques Pelletier has contributed the DS1501 RTC driver code. Jose Collado has contributed enhancements to the TMS driver including compatibility with standard TMS register configuration. Kevin Boone has contributed a generic HBIOS date/time utility (WDATE). Matt Carroll has contributed a fix to XM.COM that corrects the port specification when doing a send. Dean Jenkins enhanced the build process to accommodate the Raspberry Pi 4. Tom Plano has contributed a new utility (HTALK) to allow talking directly to HBIOS COM ports. Lars Nelson has contributed several generic utilities such as a universal (OS agnostic) UNARC application. Dylan Hall added support for specifying a secondary console. Bill Shen has contributed boot loaders for several of his systems. Laszlo Szolnoki has contributed an EF9345 video display controller driver. Ladislau Szilagyi has contributed an enhanced version of CP/M Cowgol that leverages RomWBW memory banking. Les Bird has contributed support for the NABU w/ Option Board Contributions of all kinds to RomWBW are very welcome.","title":"Acknowledgments"},{"location":"#licensing","text":"RomWBW is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. RomWBW is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with RomWBW. If not, see https://www.gnu.org/licenses/ . Portions of RomWBW were created by, contributed by, or derived from the work of others. It is believed that these works are being used in accordance with the intentions and/or licensing of their creators. If anyone feels their work is being used outside of its intended licensing, please notify: Wayne Warthen wwarthen@gmail.com RomWBW is an aggregate work. It is composed of many individual, standalone programs that are distributed as a whole to function as a cohesive system. Each program may have its own licensing which may be different from other programs within the aggregate. In some cases, a single program (e.g., CP/M Operating System) is composed of multiple components with different licenses. It is believed that in all such cases the licenses are compatible with GPL version 3. RomWBW encourages code contributions from others. Contributors may assert their own copyright in their contributions by annotating the contributed source code appropriately. Contributors are further encouraged to submit their contributions via the RomWBW source code control system to ensure their contributions are clearly documented. All contributions to RomWBW are subject to this license.","title":"Licensing"},{"location":"#getting-assistance","text":"The best way to get assistance with RomWBW or any aspect of the RetroBrew Computers projects is via one of the community forums: RetroBrew Computers Forum RC2014 Google Group retro-comp Google Group Submission of issues and bugs are welcome at the RomWBW GitHub Repository . Also feel free to email Wayne Warthen at wwarthen@gmail.com .","title":"Getting Assistance"},{"location":"Applications/","text":"RomWBW Applications Guide \\ Version 3.6 \\ MartinR \\& Phillip Summers ( ) \\ 31 May 2025 Summary RomWBW is supplied with a suite of software applications that enhance the use of the system. Some of these applications have been written entirely from scratch for RomWBW. Others are pre-existing software that has been customized for the RomWBW environment. This document serves as a reference for these RomWBW-specific applications. The primary usage documentation for RomWBW is the RomWBW User Guide . It is assumed that the reader is generally familiar with this document. RomWBW also includes many generic software applications that have not been modified for RomWBW (e.g., MSBASIC). These generic applications are not documented here. Please refer to the application specific documentation for these generic applications. The documentation for some of these generic applications is included in the Doc folder of the RomWBW distribution. The applications described in this document fall into two general categories. ROM Applications are software applications that are loaded from the the ROM memory of your RomWBW system. CP/M Applications are software applications that are loaded from disk using a previously loaded CP/M (or CP/M like) operating system using its command line. Note that some applications are available in both forms. For example, Microsoft BASIC is available as a ROM application and as an application that runs under CP/M. Only the ROM variant is documented here because the CP/M variant is not RomWBW-specific. You will see that two of the RomWBW operating systems are included here as ROM Applications. Although operating systems are normally loaded from disk, RomWBW does include a way to launch CP/M 2.2 and Z-System directly from ROM. Most RomWBW systems include a ROM disk. A running operating system can load applications from the ROM disk just like a floppy or hard disk. Applications loaded from the ROM disk by CP/M are considered to be CP/M applications, not ROM applications. Boot Menu The system start-up process is described in some detail in the RomWBW User Guide, and for the sake of completeness there is some overlap here. When a RomWBW system is started the user is presented with a sign-on message at the default console detailing the RomWBW version and build date. The system follows this with the list of hardware that it has discovered, a list of devices and the system units assigned to them, before finally inviting the to select a boot device with the prompt: Boot [H=Help]: At this point, the user may specify a unit, optionally with a slice, to boot from. Note that it is not possible to boot from from the serial (ASCI) or memory disk (MD) devices. Alternatively the user may select one of the built-in Boot Loader commands. A menu of which may be displayed by pressing the H or ? keys (for Help). Furthermore, a ROM application may also be started from this prompt. This start-up process is described in some detailed in the RomWBW User Guide, and there is some overlap here. Help After pressing H or ? at the boot prompt the user will be presented with the following list of available commands: L - List ROM Applications D - Device Inventory R - Reboot System I [] - Set Console Interface/Baud code V [] - View/Set HBIOS Diagnostic Verbosity [.] - Boot Disk Unit/Slice The function performed by each command is described below: L: Lists the applications and operating systems that are built into the RomWBW ROM - e.g., low-level monitor utility, CP/M, or BASIC. D: Displays the list of system devices that was first displayed when the system was started. R: Will restart the system. Note that this does not reset hardware devices in the same way that power-on or pressing the reset button would. I: Allows the user to select the interface connected to the console, and optionally the Baud rate. This could be used to allow the system to be operated from a second console. V: Enables the display of invalid RomWBW HBIOS API calls. This option is very unlikely to be used by a user and is used for development purposes. And, finally, the system may be booted by specifying the unit number, and optional slice, separated by a period(\u2018.\u2019), of where the disk operating system software is located - eg 2, 4.1, 5.3 Alternatively, a RomWBW ROM application may be started by pressing the appropriate key from the applications menu, shown in the following section. List ROM Applications If the user presses the L key at the Boot Loader prompt then the system will display the list of ROM applications that are built into RomWBW. If a command letter is known, then it may be entered directly at the prompt rather than first displaying the menu. The ROM applications available from the boot prompt are: M: Monitor C: CP/M 2.2 Z: Z-System B: BASIC T: Tasty BASIC F: Forth P: Play a Game N: Network Boot X: XModem Flash Updater U: User App Each of these will now be described in greater detail. ROM Applications Monitor The Monitor program is a low-level utility that can be used for testing and programming. It allows programs to be entered, memory to be examined and modified, and input/output devices to be read or written to. It\u2019s key advantage is that is available at boot up. Its key disadvantages are that code cannot be entered in assembly language and there is no ability to save to persistent storage (disks). The available memory area for programming is 0100h-EDFFh . The following areas are reserved: Memory Area Function 0000-00FFh Jump and restart (RST) vectors EE00-FDFFh Monitor FE00-FFFFh HBIOS proxy The monitor uses a prompt in the format of xx> where xx is the RomWBW bank id number. For example, the prompt may look like this and means that Bank Id 0x8E is currently mapped into the low 32K of processor memory. 8E> Please refer to Section 4 of the \\$doc_sys# for a description of the RomWBW Bank Id and how it relates to the physical bank of memory being mapped to the lower 32K of the processor. The method of assigning banks for specific RomWBW functions is also described. Commands can be entered at the command prompt. Automatic case conversion takes place on command entry and all numeric arguments are expected to be in hex format. The Monitor allows access to all memory locations but ROM and Flash memory cannot be written to. At startup, the Monitor will select the default \u201cUser\u201d bank. The S command is provided to allow selecting alternate banks. There now follows a more detailed guide to using the RomWBW Monitor program: Command Summary ? - Will display a summary of the available commands. Monitor Commands (all values in hex): B - Boot system D xxxx [yyyy] - Dump memory from xxxx to yyyy F xxxx yyyy zz - Fill memory from xxxx to yyyy with zz H - Halt system I xxxx - Input from port xxxx K - Keyboard echo L - Load Intel hex data M xxxx yyyy zzzz - Move memory block xxxx-yyyy to zzzz O xxxx yy - Output value yy to port xxxx P xxxx - Program RAM at address xxxx R xxxx [[yy] [zzzz]] - Run code at address xxxx Pass yy and zzzz to register A and BC S xx - Set bank to xx U - Set bank to previous bank T xxxx - X-modem transfer to memory location xxxx X - Exit monitor Cold Boot B - Performs a cold boot of the RomWBW system. A complete re-initialization of the system is performed and the system returns to the Boot Loader prompt. Dump Memory D xxxx [yyyy] - Dump memory from hex location xxxx to yyyy on the screen as lines of 16 hexadecimal bytes with their ASCII equivalents (if within a set range, else a \u2018.\u2019 is printed). If the end address is omitted then 256 bytes are displayed. A good tool to see where code is located, check for version id, obtain details for chip configurations and execution paths. Example: D 100 1FF 0100: 10 0B 01 5A 33 45 4E 56 01 00 00 2A 06 00 F9 11 ...Z3ENV...*..\u00f9. 0110: DE 38 37 ED 52 4D 44 0B 6B 62 13 36 00 ED B0 21 \u00de87\u00edRMD.kb.6.\u00ed\u00b0! 0120: 7D 32 E5 21 80 00 4E 23 06 00 09 36 00 21 81 00 }2\u00e5!..N#...6.!.. 0130: E5 CD 6C 1F C1 C1 E5 2A C9 8C E5 CD 45 05 E5 CD \u00e5\u00cdl.\u00c1\u00c1\u00e5*\u00c9.\u00e5\u00cdE.\u00e5\u00cd 0140: 59 1F C3 00 00 C3 AE 01 C3 51 04 C3 4C 02 C3 57 Y.\u00c3..\u00ee.\u00c3Q.\u00c3L.\u00c3W 0150: 02 C3 64 02 C3 75 02 C3 88 02 C3 B2 03 C3 0D 04 .\u00c3d.\u00c3u.\u00c3..\u00f2.\u00c3.. 0160: C3 19 04 C3 22 04 C3 2A 04 C3 35 04 C3 40 04 C3 \u00c3..\u00c3\".\u00c3*.\u00c35.\u00c3@.\u00c3 0170: 48 04 C3 50 04 C3 50 04 C3 50 04 C3 8F 02 C3 93 H.\u00c3P.\u00c3P.\u00c3P.\u00c3..\u00c3. 0180: 02 C3 94 02 C3 95 02 C3 85 04 C3 C7 04 C3 D1 01 .\u00c3..\u00c3..\u00c3..\u00c3\u00c7.\u00c3\u00d1. 0190: C3 48 02 C3 E7 04 C3 56 03 C3 D0 01 C3 D0 01 C3 \u00c3H.\u00c3\u00e7.\u00c3V.\u00c3\u00d0.\u00c3\u00d0.\u00c3 01A0: D0 01 C3 D0 01 C3 D0 01 C3 D0 01 01 02 01 CD 6B \u00d0.\u00c3\u00d0.\u00c3\u00d0.\u00c3\u00d0....\u00cdk 01B0: 04 54 68 69 73 20 66 75 6E 63 74 69 6F 6E 20 6E .This function n 01C0: 6F 74 20 73 75 70 70 6F 72 74 65 64 2E 0D 0A 00 ot supported.... 01D0: C9 3E FF 32 3C 00 3A 5D 00 FE 20 28 14 D6 30 32 \u00c9>\u00ff2<.:].\u00fe (.\u00d602 01E0: AB 01 32 AD 01 3A 5E 00 FE 20 28 05 D6 30 32 AC \u00ab.2\u00ad.:^.\u00fe (.\u00d602\u00ac 01F0: 01 C5 01 F0 F8 CF E5 26 00 0E 0A CD 39 02 7D 3C .\u00c5.\u00f0\u00f8\u00cf\u00e5&...\u00cd9.}< Fill Memory F xxxx yyyy zz - Fill memory from hex xxxx to yyyy with a single value of zz over the full range. The Dump command can be used to confirm that the fill completed as expected. A good way to zero out memory areas before writing machine data for debug purposes. Halt System H - Halt system. A Z80 HALT instruction is executed. The system remains in the halt state until the system is physically rebooted. Interrupts will not restart the system. On systems that support a HALT status LED, the LED will be illuminated. Input from Port I xxxx - Input data from port xxxx and display to the screen. This command is used to read values from hardware I/O ports and display the contents in hexadecimal. Keyboard Echo K - Echo any key-presses from the terminal. Press \u2018ESC\u2019 key to quit. This facility provides that any key stroke sent to the computer will be echoed back to the terminal. File down loads will be echoed as well while this facility is \u2018on\u2019. Load Hex L - Load a Intel Hex data via the terminal program. The load address is defined in the hex file of the assembled code. The terminal emulator program should be configured to give a delay at the end of each line to allow the monitor enough time to parse the line and move the data to memory. Keep in mind that this will be transient unless the system supports battery backed memory. Saving to memory drive is not supported. Move Memory M xxxx yyyy zzzz - Move hex memory block xxxx to yyyy to memory starting at hex location zzzz. Care should be taken to insure that there is enough memory at the destination so that code does not get over-written or memory wrapped around. Output to Port O xxxx yy - Output data byte xx to port xxxx. This command is used to send hexadecimal values to hardware I/O ports to verify their operation and is the companion to the I operation. Use clip leaded LEDs to confirm the data written. Program Memory P xxxx - Program memory location xxxx. This routine will allow you to program a hexadecimal value \u2018into memory starting at location xxxx. Press \u2019Enter\u2019 on a blank line to return to the Monitor prompt. The limitation around programming memory is that it must be entered in hexadecimal. An alternative is to use the L command to load a program that has been assembled to a hex file on the remote computer. An excellent online resource for looking up opcodes for entry can be found here: https://clrhome.org/table . Run Program R xxxx [[yy] [zzzz]] - Run program at location xxxx. If optional arguments yy and zzzz are entered they are loaded into the A and BC register respectively. The return address of the Monitor is saved on the stack so the program can return to the monitor. On return to the monitor, the contents of the A, HL, DE and BC registers are displayed. Set Bank S xx - Set the physical memory bank to the RomWBW Bank Id indicated by xx. Memory addresses 0x0000-0x7FFF (i.e. bottom 32k) are affected. Because the interrupt vectors are stored in the bottom page of this range, this function is disabled when interrupt mode 1 is being used (IM1). Interrupt mode 2 is not affected as the associated jump vectors are stored in high memory. Changing the bank also impacts the restart vectors (RST), so executing code that calls the HBIOS using the RST 08 assembly code will not work. The monitor stack resides in high memory and is not affected but any code that changes the stack to low memory will be affected. The U command may be used to undo the change and return the selected memory bank back to the previously selected one. Section 4 of the RomWBW System Guide provides detail on how Bank Ids map to the physical memory of the system and also how specific banks are utilized by RomWBW. Undo Bank U - Change the bank in memory back to the previously selected bank. This command should be used in conjunction with the S command. X-Modem Transfer T xxxx - Receive an X-modem file transfer and load it into memory starting at location xxxx. 128 byte blocks and checksum mode is the only supported protocol. Exit Monitor X - Exit the monitor program back to the main boot menu. RomWBW System Configuration System Configuration ( SYSCONF ) is a utility that allows system configuration to be set, dynamically and stored in NVRAM provided by an RTC chip. ( SYSCONF ) is both a ROM application (\u2018W\u2019 Menu option), and a CP/M utility. Noting however the CP/M utility is not included on an disk image, it is found in the Binary/Applications folder of the RomWBW distribution. The RomWBW User Guide has additional information on the use of NVRAM to set your system configuration. Basic Operation The application is an interactive application; it does not have a command line syntax. Instead commands are executed from within the application in a command line structure. When you first start the ( SYSCONF ) utility it will display the current switches followed by a command listing. When you first run the ( SYSCONF ) utility the NVRAM will be uninitialised, and can be initialised using the (R)eset command, which writes default values to NVRAM. Updates are done immediately to NVRAM as you enter them, i.e. there is no confirm changes step. If you make any incorrect changes, you simply need to enter a new command to set the Switch value correctly. Once a change has been made it is available, however it may not take effect until the next system reboot. This is dependent on the Switch itself. If no NVRAM is provided by your hardware, then running this application will just report the missing hardware and exit immediately. To exit from the application use the (Q)uit command. Commands and Syntax The following are the accepted commands, unless otherwise specified a \u201cSpace\u201d character is used to delimit parameters in the command. Command Argument(s) Description (P)rint -none- Display a list of the current switch value(s) (S)et {SW} {val},\u2026 Sets an Switch {SW} with specific values(s) (R)eset -none- Reset all setting to default (H)elp {SW} Provides help on the syntax (values) (Q)uit -none- Exit the application Where Argument Description {SW} Switch ID, typically this is 2 character name to identify the switch {val},\u2026 a \u201cComma\u201d separated list of values to set into the switch Switch Options Auto Boot (AB) This switch will define if the system will perform auto boot at the RomWBW boot prompt. Enabling this will not prevent a user from typing a boot command, so long as the timeout is not exceeded. When configured this replaces the ( AUTO_CMD ) variable defined in build configuration. Making changes to auto boot has no affect until the next reboot. Arguments Type Arguments Description Enable \u2018E\u2019 Auto Boot. eg. \u201cE,10\u201d will auto boot, after 10 seconds Timout Timeout in seconds in the range 0-15, 0 = immediate Disabled \u2018D\u2019 No Auto Boot. e.g. \u201cD\u201d will disable autoboot Examples Command Description S AB E,10 Enable Auto Boot with 10 second delay S AB D Disable Auto Boot Boot Options (BO) This switch will define the boot command to be executed when auto boot is enabled. When configured this replaces the ( AUTO_CMD ) variable defined in the ROM build configuration. Making changes to boot options has no affect until the next reboot. Arguments Type Arguments Description Disk \u2018D\u2019 Disk Boot. eg. \u201cD,2,14\u201d will boot, disk unit 2, slice 14 Disk Unit Number Unit number in the range 0-127 Disk Slice Slice in the range 0-255, use 0 for floppy boot ROM \u2018R\u2019 ROM App. e.g. \u201cR,M\u201d will boot the Monitor App Rom App Name single character used on the Menu to identify the app Examples Command Description S BO D,2,14 Set the default boot from Disk; Unit 2, Slice 14 S BO R,M Set the default boot to be the (M)onitor Rom Application CP/M 2.2 This option will boot the CP/M 2.2 disk operating system from an image contained within the ROM. Please refer to the CPM User Manual in the Doc/CPM folder of the distribution for CP/M usage. There are also many online resources. During the build process the system will create a ROM disk containing a number of curated CP/M applications, and also a RAM drive. The capacity of each will depend upon the size of the ROM and RAM available to the system. A more complete set of utilities are provided within the disk image files provided as part of RomWBW. A number of the applications provided are generic to CP/M, while others rely on particular hardware or aspects of RomWBW itself. Those that are written specific to RomWBW include: ASSIGN, CPUSPD, FDU, FORMAT, FLASH, FDISK80, MODE, REBOOT, RTC, SYSCOPY, TALK, TIMER, XM, and COPYSL. The CP/M utilities supplied with RomWBW warrant more detailed descriptions, and so are described in some detail in their own section of this user guide. In summary they provide the initial capability to manage and update your RomWBW system, to create other bootable media (hardware dependent) and to write/debug code using assembler and BASIC. Z-System Z-System is a complete alternative, but entirely compatible, disk operating system to CP/M. Z-System is comprised of ZSDOS 1.1 which is a replacement for CP/M\u2019s Basic Disk Operating System (BDOS), and ZCPR which is a replacement for the Console Command Processor (CCP). Either or both may be used, although using both together will allow ZCPR to make use of specific ZSDOS features. Documentation for Z-System may be found in the Doc/CPM folder of the RomWBW distribution and the reader is referred to those. BASIC For those who are not familiar with BASIC, it stands for Beginners All Purpose Symbolic Instruction Code. RomWBW contains two versions of ROM BASIC, a full implementation and a \u201ctiny\u201d BASIC. The full implementation is a version of Microsoft BASIC from the NASCOM Computer. A comprehensive instruction manual is available in the Doc/Contrib directory. RomWBW specific features Sound Graphics Terminal Support RomWBW unsupported features Cassette loading Cassette saving TastyBASIC TastyBASIC offers a minimal implementation of BASIC that is only 2304 bytes in size. It originates from Li-Chen Wang\u2019s Palo Alto Tiny BASIC from around 1976. It\u2019s small size is suited the tiny memory capacities of the time. This implementation is by Dimitri Theulings and his original source can be found at https://github.com/dimitrit/tastybasic . Features / Limitations Integer arithmetic, numbers -32767 to 32767 Singles letter variables A-Z 1-dimensional array support Strings are not supported Direct Commands LIST , RUN , NEW , CLEAR , BYE Statements LET , IF , GOTO , GOSUB RETURN , REM , FOR TO NEXT STEP , INPUT , PRINT , POKE , END Functions PEEK , RND , ABS , USR , SIZE Operators >= , # , > , = , <= , < Operator precedence is supported. Type BYE to return to the boot menu. FORTH CamelForth is the version of Forth included as part of the boot ROM in RomWBW. It has been converted from the Z80 CP/M version published at https://www.camelforth.com/page.php?5 . The author is Brad Rodriguez who is a prolific Forth enthusiast, whose work can be found here: https://www.bradrodriguez.com/papers . For those are who are not familiar with Forth, I recommend the wikipedia article https://en.wikipedia.org/wiki/Forth_(programming_language) and the Forth Interest Group website https://www.forth.org/ . Important things to know Forth is case sensitive. To exit back to the boot loader type bye To get a list of available words type WORDS To reset Forth to its initial state type COLD Most of the code you find on the internet will not run unless modified or additional Forth words are added to the dictionary. This implementation does not support loading or saving of programs. All programs need to be typed in. Additionally, screen editing and code blocks are not supported. A CP/M version is not provided with RomWBW, this is only a ROM application. If you need to run it under CP/M you would need to download it from the camelforth web site, the link is above. Structure of Forth source files File Description camel80.azm Code Primitives camel80d.azm CPU Dependencies camel80h.azm High Level words camel80r.azm RomWBW additions glosshi.txt Glossary of high level words glosslo.txt Glossary of low level words glossr.txt Glossary of RomWBW additions RomWBW Additions Extensions and changes to this implementation compared to the original distribution are: The source code has been converted from Z80mr assembler to Hector Peraza\u2019s zsm. An additional file camel80r.azm has been added for including additional words to the dictionary at build time. However, as currently configured there is very little space allocated for addition words. Exceeding the allocated ROM space will generate an error message when building. James Bowman\u2019s double precision words have been added from his RC2014 version: https://github.com/jamesbowman/camelforth-z80 . Word Syntax Description D+ d1 d2 \u2013 d1+d2 Add double numbers 2>R d \u2013 2 to R 2R> d \u2013 fetch 2 from R M*/ d1 n2 u3 \u2013 d=(d1*n2)/u3 double precision mult. div SVC hl de bc n \u2013 hl de bc af Execute a RomWBW function P! n p \u2013 Write a byte to a I/O port P@ p \u2013 n Read a byte from and I/O port Play a Game 2048 2048 is a puzzle game that can be both mindless and challenging. It appears deceptively simple but failure can creep up on you suddenly. It requires an ANSI/VT-100 compatible colour terminal to play. 2048 is like a sliding puzzle game except the puzzle tiles are numbers instead of pictures. Instead of moving a single tile all tiles are moved simultaneously in the same direction. Where two tiles of the same number collide, they are reduced to one tile with the combined value. After every move a new tile is added with a starting value of 2. The goal is to create a tile of 2048 before all tile locations are occupied. Reaching the highest points score, which is the sum of all the tiles is a secondary goal. The game will automatically end when there are no more possible moves. Play consists of entering a direction to move. Directions can be entered using any of three different keyboard direction sets. Direction | Keys ----------|---------- Up | w ^E 8 Down | s ^X 2 Left | a ^S 4 Right | d ^D 6 The puzzle board is a 4x4 grid. At start, the grid will be populated with two 2 tiles. An example game sequence is shown below with new tiles to the game shown in brackets. Start Move 1 - Up Move 2 - Left Move 3 - Left +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | |(2)| | | | | 4 | | 4 | | | | | 4 | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | | | | | | | | | | | |(4)| | 4 | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | |(2)| | | | | | | | | | | | | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | | | | | |(2)| | | 2 | | | | | 2 | |(2)| | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ Move 4 - Left Move 5 - Up Move 6 - Right Move 7 - Up +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | 4 | | | | | 8 | | | 4 | | | | 8 | 4 | | | | 8 | 8 | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | 4 | | |(4)| | 4 | | | | | | | | 4 | | | | | 2 | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | | | | | | | | | | | | | | | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | 4 | | | | |(2)| | | | |(2)| | | 2 | |(2)| | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ This is how I lost this game: +---+---+---+---+ | 4 | 2 | 16| 4 | +---+---+---+---+ | 32| 64| 8 | 2 | +---+---+---+---+ | 4 | 8 |128| 32| +---+---+---+---+ |(2)| 16| 8 | 4 | +---+---+---+---+ Press Q at any time to bring up the option to Quit or Restart the game. Network Boot If your RomWBW system is equipped with an RCBus MT011 module, it is possible to boot into CP/M 2.2 directly from a CP/NET network server. This means that the operating system will be loaded directly from the network server and all of your drive letters will be provided by the network server. This function requires substantial knowledge of CP/NET and it\u2019s implementation within RomWBW. Section 10 of the RomWBW User Guide provides complete instructions for setting up a CP/NET based network under RomWBW including a section on network booting. Xmodem Flash Updater The RomWBW Xmodem flash updater provides the capability to update RomWBW from the boot loader using an x-modem file transfer. It offers similar capabilities to Will Sowerbutts FLASH4 utility except that the flashing process occurs during the file transfer. These are the key differences between the two methods are: Xmodem Flash Updater FLASH.COM (aka FLASH4) Available from the boot loader Well proven and tested Xmodem transfer is integrated Wider range of supported chips and hardware Integrated checksum utilities Wider range of supported platforms Capability to copy a ROM image Only reprograms sectors that have changed More convenient one step process Ability save and verify ROM images No intermediate storage required Progress display while flashing . Displays chip identification information . Faster file transfer The major disadvantages of the Updater is that it is new and relatively untested. There is the risk that a failed transfer will result in a partially flashed and unbootable ROM. There are some limitations on serial transfer speeds. The updater utility was initially intended to support the Retrobrew SBC-V2-005 platform using Atmel 39SF040 flash chips but has now been extended to be more generic in operation. Supported flash chips are 39SF040, 29F040, AT49F040, AT29C040, M29F040 , MX29F040, A29010B, A29040B The Atmel 39SF040 chip is recommended as it can erase and write 4Kb sectors. Other chips require the whole chip to be erased. Usage In most cases, completing a ROM update is a simple as: Booting to the boot loader prompt Selecting option X - Xmodem Flash Updater Selecting option U - Update Initiating an X-modem transfer of your ROM image on your console device Selecting option R - Reboot If your console device is not able to transfer a ROM image i.e. your console is a VDU then you will have to use the console options to identify which character-input/output device is to be used as the serial device for transfer. When your console is the serial device used for the transfer, no progress information is displayed as this would disrupt the x-modem file transfer. If you use an alternate character-input/output devices as the serial device for the transfer then progress information will be displayed on the console device. Due to different platform processor speeds, serials speeds and flow control capabilities the default console or serial device speed may need to be reduced for a successful transfer and flash to occur. The Set Console Interface/Baud code option at the Boot Loader can be used to change the speed if required. Additionally, the Updater has options to set to and revert from a recommended speed. See the RomWBW Applications guide for additional information on performing upgrades. Console Options Option ( C ) - Set Console Device Option ( S ) - Set Serial Device By default the updater assumes that the current console is a serial device and that the ROM file to be flashed will also be transferred across this device, so the Console and Serial device are both the same. Either device can be can be change to another character-input/output device but the updater will always expect to receive the x-modem transfer on the Serial Device The advantage of transferring on a different device to the console is that progress information can be displayed during the transfer. Option ( > ) - Set Recommended Baud Rate Option ( \\< ) - Revert to Original Baud Rate Programming options Option ( U ) - Begin Update The will begin the update process. The updater will expect to start receiving an x-modem file on the serial device unit. X-modem sends the file in packets of 128 bytes. The updater will cache 32 packets which is 1 flash sector and then write that sector to the flash device. If using separate console, bank and sector progress information will shown BANK 00 s00 s01 s02 s03 s04 s05 s06 s06 s07 BANK 01 s00 s01 s02 s03 s04 s05 s06 s06 s07 BANK 02 s00 s01 s02 s03 s04 s05 s06 s06 s07 etc The x-modem file transfer protocol does not provide any filename or size information for the transfer so the updater does not perform any checks on the file suitability. The updater expects the file size to be a multiple of 4 kilobytes and will write all data received to the flash device. A system update file (128kb .img) or complete ROM can be received and written (512kb or 1024kb .rom) If the update fails it is recommended that you retry before rebooting or exiting to the Boot loader as your machine may not be bootable. Option ( D ) - Duplicate flash #1 to flash #2 This option will make a copy of flash #1 onto flash #2. The purpose of this is to enable making a backup copy of the current flash. Intended for systems using 2x512Kb Flash devices. Option ( V ) - Toggle Write Verify By default each flash sector will be verified after being written. Slight performance improvements can be gained if turned off and could be used if you are experiencing reliable transfers and flashing. Exit options Option ( R ) - Reboot Execute a cold reboot. This should be done after a successful update. If you perform a cold reboot after a failed update then it is likely that your system will be unusable and removing and reprogramming the flash will be required. Option ( Q ) - Quit to boot loader. The SBC Boot Loader is reloaded from ROM and executed. After a successful update a Reboot should be performed. However, in the case of a failed update this option could be used to attempt to load CP/M and perform the normal x-modem / flash process to recover. CRC Utility options Option ( 1 ) and ( 2 ) - Calculate and display CRC32 of 1st or 2nd 512k ROM. Option ( 3 ) - Calculate and display CRC32 of a 1024k (2x512Kb) ROM. Can be used to verify if a ROM image has been transferred and flashed correctly. Refer to the Tera Term section below for details on configuring the automatic display of a files CRC after it has been transferred. In Windows, right clicking on a file should also give you a context menu option CRC SHA which will allow you to select a CRC32 calculation to be done on the selected file. Tera Term macro configuration Macros are a useful tool for automatic common tasks. There are a number of instances where using macros to facilitate the update process could be worthwhile if you are: Following the RomWBW development builds. Doing lots of configuration changes. Doing development on RomWBW drivers Macros can be used to automate sending ROM updates or images and for my own purposed I have set up a separate macro for transferring each of the standard build ROM, my own custom configuration ROM and update ROM. An example macro file to send an *.upd file, using checksum mode and display the crc32 value of the transmitted file: Xmodem send, checksum, display crc32 xmodemsend '\\\\desktop\\users\\phillip\\documents\\github\\romwbw\\binary\\sbc_std_cust.upd' 1 crc32file crc '\\\\desktop\\users\\phillip\\documents\\github\\romwbw\\binary\\sbc_std_cust.rom' sprintf '0x%08x' crc messagebox inputstr 'crc32' Serial speed guidelines As identified in the introduction, there are limitations on serial speed depending on processor speed and flow control settings. Listed below are some of the results identified during testing. Configuration Processor Speed Maximum Serial Speed UART no flow control 2MHz 9600 UART no flow control 4MHz 19200 UART no flow control 5MHz 19200 UART no flow control 8MHz 38400 UART no flow control 10MHz 38400 USB-fifo 2MHz+ n/a ASCI no flow control 18.432MHz 9600 ASCI with flow control 18.432MHz 38400 The Set Recommend Baud Rate option in the Updater menu follows the following guidelines. Processor Speed Baud Rate 1MHz 4800 2-3MHz 9600 4-7MHz 19200 8-20MHz 38400 These can be customized in the updater.asm source code in the CLKTBL table if desired. Feedback to the RomWBW developers on these guidelines would be appreciated. Notes All testing was done with Tera Term x-modem, Forcing checksum mode using macros was found to give the most reliable transfer. Partial writes can be completed with 39SF040 chips. Other chips require entire flash to be erased before being written. An SBC V2-005 MegaFlash or Z80 MBC required for 1mb flash support. The Updater assumes both chips are same type Failure handling has not been tested. Timing broadly calibrated on a Z80 SBC-v2 Unabios not supported User Application RomWBW provides the facility for a user to build, include and execute their own custom application directly from the applications menu at boot-up. All that\u2019s needed is for the user to create their custom code ready for inclusion, recognising that there are certain constraints in doing this. In order to build properly, the build process requires that the file usrrom.asm be found in the /Source/HBIOS folder of the RomWBW tree. This source file needs to assemble using TASM and it must start at (ORG) address 00100H as the RomWBW HBIOS reserves locations 00000H to 000FFH for internal use. Further, the user application must assemble to a maximum of USR-SIZ bytes. During execution, the user application may make use of HBIOS calls as necessary, and at exit it should return to the RomWBW boot loader using the HBIOS warm reset. Note that no disk operating system (eg CP/M) functions will be available as no disk operating system will have been loaded. There is a sample usrrom.asm supplied in Source/HBIOS and it is recommended that, at least initially, users create their own application based on this as a template because it already creates the necessary variables, starts at (ORG) 00100H, and ensures that the assembled file is padded to create a file USR-SIZ in length. Equally, should the the user\u2019s application prove too large for the space available then assembly will be terminated with an error. Users should not remove this check from the templated code. If required, the user application may make use of the Z80 interrupt system but if the user application wishes to rely on HBIOS functionality then it must adhere to the HBIOS framework for managing interupts. Alternatively, if the user appliction has no need for the HBIOS then it may use its own custom code for handling interrupts. In that case, a hard reset, rather than an HBIOS warm start, would be necessary to return control to RomWBW. CP/M Applications - ROM-Based & Disk-Based There now follows a more detailed guide to using the small suite of custom applications included with RomWBW. In general, these applications are operating system agnostic \u2013 they run under any of the included operating systems. However, they all require RomWBW \u2013 they are not generic CP/M applications. Most of the applications are custom written for RomWBW. However, some are standard CP/M applications that have been adapted to run under RomWBW (e.g. XM/XModem). The applications are generally matched to the version of RomWBW they are distributed with. So, if you upgrade the version of RomWBW in your system ROM, you will want to copy the corresponding applications to any storage devices you are using. Most of the applications are included on the RomWBW ROM disk, so they are easy to access. The applications are also included with all of the operating system disk images provided with RomWBW. So, a simple way to ensure you have matching applications is to write the disk images onto your disk media when upgrading your ROM. Of course, this will destroy any existing data on your disk media, so don\u2019t do this if you are saving any data on the media. Most of the applications are included as source code in the RomWBW distribution and are built during the normal build process. The source code is found in the Source/Apps directory of the distribution. The binary executable applications are found in the Binary/Apps directory. The table below clarifies where each of the applications may be found. It is not an exhaustive list, with further applications existing on both the ROM-based and disk-based versions of CP/M. All of the Applications included within RomWBW may be found within the Binary/Apps directory. Application ROM Disk Boot Disks ASSIGN Yes Yes BBCBASIC No Yes CLRDIR Yes Yes COPYSL No Yes CPUSPD Yes Yes FAT No Yes FDISK80 Yes Yes FDU Yes Yes FLASH Yes Yes FORMAT Yes Yes HTALK Yes Yes MODE Yes Yes REBOOT Yes Yes RTC Yes Yes SURVEY Yes Yes SYSCOPY Yes Yes TALK Yes Yes TBASIC No Yes TIMER Yes Yes TUNE No Yes VGMPLAY No Yes WDATE No Yes XM Yes Yes ZMD No Yes ZMP No Yes All of the CP/M applications may be found in the RomWBW Binary/Apps directory and a user may copy those they need to their own customized disk/slice. Independently of whether the CP/M system was started from ROM or a boot disk, such as a floppy disk or a slice on a CF or uSD memory card, applications may be located on and executed from either the ROM-disk itself or from other media. There are multiple disk images available for CP/M (eg floppy, legacy hard-disk and new hard-disk formats) and they all contain essentially the same set of applications. There are particular advantages for each method of booting into CP/M. ROM-based CP/M: A clean and reliable copy of CP/M with no possibility of corruption No additional hardware required Fast to boot Rolled forward with new releases of RomWBW Disk-based CP/M: Greater capacity allows for a larger number of applications Allows for user-customisation of applications available Allows individual disks to be tailored to a particular purpose, eg word processor For systems starting CP/M from a disk created from an image file, there are a small number of additional applications stored in the USER 2 area of the disk. These applications do not form part of CP/M, but rather are small utilities used for test purposes during develpment work. They may, or may not, fuction correctly with any given hardware or software configuration. Documentation for these untilities is very limited, though the source files maybe found in the /Source folder. Note that these utiltites are not available when starting CP/M from the ROM image or from a floppy disk. A number of the CP/M applications available are described in more detail in the following sections, each with an indication as to whether that application may be found on the ROM-disk, a boot-disk, or both. ASSIGN ASSIGN ROM-based Yes Disk-based Yes RomWBW includes a flexible mechanism for associating the operating system drive letters (A: - P:) to the physical devices in the system. Drive letter assignments can be changed on a running operating system without rebooting. The ASSIGN command facilitates this by allowing you to display, assign, reassign, or remove the drive letter assignments. Syntax ASSIGN /? ASSIGN /L ASSIGN = ASSIGN ASSIGN [ ],... ASSIGN =[ :[ ]],... ASSIGN = ,... ASSIGN /B='*''*'['*' '*'['*' '*'...]] Usage ASSIGN /? will display brief command usage and version information. ASSIGN /L will display a list of all the devices available to be used in drive assignments in the running system. The devices listed may or may not contain media. Although some device types support the use of slices, the list does not indicate this. ASSIGN A: just specifying the drive letter will display the assignment for the drive letter ASSIGN with no parameters will list all of the current drive assignments. Usage (Specific) The following describes how to assign drive specifically by identifing each drive by its unique device and slice id\u2019s ASSIGN will display the assignment for the specific drive For example, ASSIGN C: will display the assignment for drive C:. ASSIGN = [: ] will assign (or reassign) a drive letter to a new device and (optionally) slice. If no slice is specified, then slice 0 is assumed. For example, ASSIGN C:=IDE0 will assign drive letter C: to device IDE0, slice 0. ASSIGN D:=IDE0:3 will assign drive letter D: to device IDE0 slice 3. The ASSIGN command will not allow you to specify a slice (other than zero) for devices that do not support slices. A slice should only be specified for hard disk devices (SD, IDE, PPIDE). Floppy disk drives and RAM/ROM drives do not have slices. ASSIGN = can be used to remove the assignment from a drive letter. So, ASSIGN E:= will remove the association of drive letter E: from any previous device. ASSIGN = is used to swap the assignments of two drive letters. For example, ASSIGN C:=D: will swap the device assignments of C: and D:. The ASSIGN command supports \u201cstacking\u201d of instructions. For example, ASSIGN C:=IDE0:0,D:=IDE0:1,E:= will assign C: and D: to the first two slices of IDE 0 and will unassign E:. When the command runs it will echo the resultant assignments to the console to confirm its actions. It will also display the remaining space available in disk buffers. Usage (Bulk) The following describes how to assign drives in bulk without having to specify the identifiers of each drive being mapped. Instead bulk mode has a predefined set options (identified by single letter) which will map drives. Bulk mode works by assigning drives sequentially starting at A: until all drives are used, or there are no more options to process. Each option will typically map between 0 and N drives depending on the option and the available hardware in your system. ASSIGN /B= \u2026 will perform bulk assignment . The following options will assign a small number of devices, typically you would place at beginning of an option list. Option Name Description Assigned B Boot The boot device 1 A RAM Ram drive 0,1 O ROM Rom drive 0,1 F Floppy All floppy devices, with/without media 0,1,2,.. P Preserve Skip and preserve the next drive assignment 1 X Exclude Un-assign / Exclude the next drive 1 A drive e.g. RAM, ROM, FLOPPY can only be assigned if it exists. if you system doesn\u2019t have the hardware that supports the device, then no devices will be assigned, and the next option will be processed. B assigns the boot device. If used the B oot drive should typically be assigned first. P will not make any changes to the next drive, it will skip over it. While the X option will un-assign the next drive, leaving a gap. The remaining options will fill drives mostly to end, from hard drive slices, generally choose 1 of the following: Option Name Description Assigned S Slices Assign slices from boot hard drive \u2026max H Hard Drive Assign slices evenly from all hard drives \u2026max L Legacy HD Assign slices from all hard drives (legacy) 6,\u2026max Z Exclude All Un-assign all remaining drives \u2026max S lices assignment will map all remaining drives to slices from the boot device. If I have other hard drives present these will not be mapped by this option. e.g. ASSIGN /B=BAOS Will first assign drives A:(Boot), B:(RAM), C:(ROM) this leaves 13 drives which will be assigned to slices from the boot hard drive (D: thru P:), leaving no unused drives. \u2019H\u2019ard drive assignment will attempt to fill all remaining drive letters by splitting the number of drives remaining evenly across all. e.g. ASSIGN /B=BAOH Will first assign drives A:(Boot), B:(RAM), C:(ROM) this leaves 13 drives available. If I have 3 hard disks then (13/3) = 4 slices from each hard drive will be assigned to drives (D: thru O:), leaving a single unused drive (P:). L egacy hard drive assignment is identical to how the startup hard disk assignment works. ie. Attempt to assign up to 8 hard drives split across hard drives detected at boot. e.g. ASSIGN /B=BAOL Will first assign drives A:(Boot), B:(RAM), C:(ROM) . If I have 3 hard disks then (8/3) = 2 slices from each hard drive will be assigned to drives (D: thru I:), leaving 7 unused drives (J: thru P:). Notes If the ASSIGN command encounters any rule violations or errors, it will abort with an error and none of the drive assignments will be implemented. In other words, the command is atomic and will either completely succeed or completely fail. All assigned drives utilize disk buffer space from a limited pool. The ASSIGN command will display the amount of buffer space remaining after an assign command is executed. Buffer space is freed if a drive is unassigned. If the total assignments exceed the available disk buffer space available, the command will abort with an error message. The ASSIGN command does not check to see if the device and slice being assigned actually contains readable media. If the assigned device has no media, you will receive an I/O error when you attempt to use the drive letter. The ASSIGN command does not check that the media is large enough to support the slice you specify. In other words, you could potentially assign a drive letter to a slice that is beyond the end of the media in a device. In this case, subsequent attempts to use that drive letter will result in an I/O error. Additionally, the ASSIGN command does not check to see if the slice specified refers to an area on your media that is occupied by other data (such as a FAT filesystem). You will not be allowed to assign multiple drive letters to a single device and slice. In other words, only one drive letter may refer to a single filesystem at a time. Attempts to assign a duplicate drive letter will fail and display an error. If you wish to assign a different drive letter to a device/unit/slice, unassign the existing drive letter first. Drive letter A: must always be assigned to a device and slice. The ASSIGN command will enforce this. The changes made by this command are not permanent. The assignments will persist through a warm start, but when you reboot your system, all drive letters will return to their default assignments. A SUBMIT batch file can be used to setup desired drive assignments automatically at boot. Be aware that this command will allow you to reassign or remove the assignment of your system drive letter. This can cause your operating system to fail and force you to reboot. The ASSIGN command does not prevent you from assigning a drive letter to a slice that does not fit on the physical media. However, any subsequent attempt to refer to that drive letter will result in an immediate OS error of \u201cno disk\u201d. Refer to \u201cHard Disk Capacity\u201d in the RomWBW User Guide for a discussion of the exact number of slices that will fit on a specific physical disk size. This command is particularly sensitive to being matched to the appropriate version of the RomWBW ROM you are using. Be very careful to keep all copies of ASSIGN.COM up to date with your ROM. Additionally, the ASSIGN command must be able to adjust to CP/M 2.2 vs. CP/M 3. If you utilize an RSX that modifies the BDOS version returned, you are likely to have serious problems. In this case, be sure to use ASSIGN prior to loading the RSX or after it is unloaded. Etymology The ASSIGN command is an original product and the source code is provided in the RomWBW distribution. BBCBASIC (BBC BASIC) BBCBASIC ROM-based No Disk-based Yes BBC BASIC is an interpreted version of the BASIC programming language originally developed by Acorn Computers for the 6502 CPU. Compared to other BASIC implementations, BBC BASIC adds structured programming as well as a built-in Z80 assembler. Syntax BBCBASIC [ \\ ] Usage The full documentation for BBC BASIC (Z80) is found online at https://www.bbcbasic.co.uk/bbcbasic/mancpm/index.html . Notes The cursor and screen management assumes the use of an ANSI/VT-100 terminal which is generally correct for RomWBW. Support for a hardware system timer is also implemented. If your system does not have a hardware timer, the TIME function will always return 0 and the timeout parameter of the INKEY(n) function will not be observed (will never timeout). Etymology This is a RomWBW HBIOS adaptation of BBCBASIC v5.00 by R.T.Russell. This implementation was adapted from the source code found at https://github.com/rtrussell/BBCZ80 . The adaptation to RomWBW was minimal and includes: VT100 terminal control TIME function CLRDIR (Clear Directory) CLRDIR ROM-based Yes Disk-based Yes The CLRDIR command is used to initialise the directory area of a drive. Syntax CLRDIR Usage CLRDIR will initialise the directory area of the specified drive. The drive may take any form - eg floppy disk, hard-disk, CF, uSD etc. The use of FDISK80 to reserve space, or slices, for CP/M use as drives will not initialise the directory areas of those slices. The resultant directory areas will contain garbage left over from a previous use of the disk (or media) and using them in this state with CP/M will very likely lead to failed or corrupted data storage. Use CLRDIR to initialise the directory properly. FDU will initialise the directory of a floppy disk as part of the formatting process and so CLRDIR is unnecessary for a floppy disk. CLRDIR is, therefore, primarily used with other types such as hard-disk, CF and uSD. The CLRDIR command may also be used to effectively \u2018reformat\u2019 a used disk by reinitialising its directory area and effectively making it blank again. Use CLRDIR with caution as changes made to disks by CLRDIR cannot be undone. Notes If CLRDIR is used on disk containing data then the directory area will be reinitialised and the data previously stored will be lost. CPUSPD (CPU Speed) CPUSPD ROM-based Yes Disk-based Yes The CPUSPD application is used to change the running speed and wait states of a RomWBW system. It can also be used to invoke a warm or cold reboot of the system. The functionality is highly dependent on the capabilities of your system. Syntax CPUSPD [ [,[ ][,[ ]]] CPUSPD (W)armBoot CPUSPD (C)oldBoot is one of (H)alf, (F)ull, (D)ouble, or (Q)uad. is a number specifying the desired memory wait states. is a number specifying the desired I/O wait states. Usage Entering CPUSPD with no parameters will display the current CPU speed and wait state information of the running system. Wait state information is not available for all systems. To modify the running speed of a system, you can specify the * * parameter. To modify either or both of the wait states, you can enter the desired number. Either or both of the wait state parameters may be omitted and the current wait state settings will remain in effect. Notes The ability to modify the running speed and wait states of a system varies widely depending on the hardware capabilities and the HBIOS configuration settings. Note that it is frequently impossible to tell if a system is capable of dynamic speed changes. This function makes the changes blindly. If an attempt is made to change the speed of a system that is definitely incapable of doing so, then an error result is returned. Z180-based systems will be able to adjust their CPU speed depending on the specific variant of the Z180 chip being used: Z180 Variant Capability Z80180 (original) Half Z8S180 Rev. K Half, Full Z8S180 Rev. N Half, Full, Double SBC and MBC systems may be able to change their CPU speed if the hardware supports it and it is enabled in the HBIOS configuration. The CPUSPD command makes no attempt to ensure that the new CPU speed will actually work on the current hardware. Setting a CPU speed that exceeds the capabilities of the system will result in unstable operation or a system stall. In the case of Z180 CPUs, it is frequently necessary to add memory wait states when increasing the CPU speed. Some peripherals are dependent on the CPU speed. For example, the Z180 ASCI baud rate and system timer are derived from the CPU speed. The CPUSPD application will attempt to adjust these peripherals for correct operation after modifying the CPU speed. However, in some cases this may not be possible. The baud rate of ASCI ports have a limited set of divisors. If there is no satisfactory divisor to retain the existing baud rate under the new CPU speed, then the baud rate of the ASCI port(s) will be affected. Etymology The CPUSPD application was custom written for RomWBW. All of the hardware interface code is specific to RomWBW and the application will not operate correctly on non-RomWBW systems. The source code is provided in the RomWBW distribution. COPYSL (Copy Slice) COPYSL ROM-based No Disk-based Yes The purpose of this utility is to allow the copying of whole disk slices from one disk slice to another slice This tool is only supported by RomWBW HBIOS, it uses HDIOS for all its disk IO. UNA UBIOS is not supported by this tool. This tool is running on CP/M 2.2 or 3.0 and has access to full 64kb of RAM, with a minimum of 48kb TPA This tool only works with hard disk devices, other media types like floppy, are not supported at this time. This tool works across different hard disk device types, even of different physical type Both hd1k and hd512 are fully supported, however copying from one layout type to the other is not supported. During operation data is copied in a single read/write pass, data is not verified by default. If there is a write error, it will be reported, and operation will stop. Syntax This tool operates at the disk level via RomWBW, thus all disk identifiers are in the RomWBW \\.\\ format. The syntax (similar to copy) for the command is: COPYSL \\ [ . \\ ] = \\ [ . \\ ] [ / \\ ] E.g. COPYSL 3.3=2.10 /U Means copy from slice 10 on disk 2, onto disk 3 slice 3. This is in unattended mode, so you will not be asked to confirm the copy operation. Options F - Full disk copy. Copies the complete disk slice, all sectors. U - Unattended. Will complete copy without confirmation from the user. V - Verify. Does an additional read and verify after write. Usage When run COPYSL will perform command line argument validation and display an error if they are illegal. Also any disk IO errors will cause COPYSL to exit. When specifying slice number(s) a check is made that the slice number is valid, i.e. not too large that it would extend past the end of the partition (hd1k), or the end of the media (hd512). For hd512 a check is also performed to ensure that the slice would not extend into the first defined partition. The copy operation will be faster if the source disk has been formatted with the CP/M file system, since during copy the CP/M directory is scanned, and unused blocks are not copied. If a filesystem is not found, (or the /F option is chosen) all data is copied. Verification (if option chosen) will do an aditional read (after write) and compare the data read matches what was written. This compare is only on every 32\u2019nd byte. This is done for efficiency. During copy dots \u201c.\u201d will be displayed to indicate progress of the copy. Each \u201c.\u201d represents 16 kBytes of data. Each line of \u201c.\u201d \u2019s is 1 mBytes. Notes This tool has been tested on both SD and CF media types and with hd1k and hd512 formatted media. You cannot copy slices between different hard disk formats (hd512 and hd1k) because the slices are incompatible. Etymology The COPYSL application was custom written for RomWBW and contributed by Mark Pruden. FAT (FAT Utility) FAT ROM-based Yes Disk-based Yes The operating systems included with RomWBW do not have any native ability to access MS-DOS FAT filesystems. The FAT application can be used overcome this. It will allow you to transfer files between CP/M and FAT filesystems (wildcards supported). It can also erase files, format, and list directories of FAT filesystems. Syntax FAT DIR FAT COPY FAT REN FAT DEL [|] FAT MD FAT FORMAT is a FAT path , are FAT or CP/M filenames , are FAT filenames is a FAT filename is a FAT directory name is a RomWBW disk unit number CP/M filespec: :FILENAME.EXT ( is CP/M drive letter A-P) FAT filespec: :/DIR/FILENAME.EXT ( is RomWBW disk unit #) Usage The FAT application determines whether you are referring to a CP/M filesystem or a FAT filesystem based on the way you specify the file or path. If the file or path is prefixed with a number (n:), then it is assumed this is a FAT filesystem reference and is referring to the FAT filesystem on RomWBW disk unit \u2018n\u2019. Otherwise, the file specification is assumed to be a normal CP/M file specification. If you wanted to list the directory of the FAT filesystem on RomWBW disk unit 2, you would use FAT DIR 2: . If you only wanted to see the \u201c.TXT\u201d files, you would use FAT DIR 2:*.TXT . If you wanted to copy all of the files on CP/M drive B: to the FAT filesystem on RomWBW disk unit 4, you would use the command FAT COPY B:*.* 4: If you wanted to copy the files to the \u201cFOO\u201d directory, then you would use FAT COPY B:*.* 4:\\FOO . To copy files in the opposite direction, you just reverse the parameters. To rename the file \u201cXXX.DAT\u201d to \u201cYYY.DAT\u201d on a FAT filesystem, you could use a command like \u201cFAT REN 2:XXX.DAT 2:YYY.DAT\u201d. To delete a file \u201cXXX.DAT\u201d on a FAT filesystem in directory \u201cFOO\u201d, you would use a command like FAT DEL 2:\\FOO\\XXX.DAT . To make a directory called \u201cFOO2\u201d on a FAT filesystem, you would use a command line FAT MD 2:\\FOO2 . To format the filesystem on a FAT partition, you would use a command like FAT FORMAT 2: . Use this with caution because it will destroy all data on any pre-existing FAT filesystem on disk unit 2. Notes Partitioned or non-partitioned media is handled automatically. A floppy drive is a good example of a non-partitioned FAT filesystem and will be recognized. Larger media will typically have a partition table which will be recognized by the application to find the FAT filesystem. Although RomWBW-style CP/M media does not know anything about partition tables, it is entirely possible to have media that has both CP/M and FAT file systems on it. This is accomplished by creating a FAT filesystem on the media that starts on a track beyond the last track used by CP/M. Each CP/M slice can occupy up to 8MB. So, make sure to start your FAT partition beyond (slice count) * 9MB. The application infers whether you are attempting to reference a FAT or CP/M filesystem via the drive specifier (char before \u2018:\u2019). A numeric drive character specifies the HBIOS disk unit number for FAT access. An alpha (A-P) character indicates a CP/M file system access targeting the specified drive letter. If there is no drive character specified, the current CP/M filesystem and current CP/M drive is assumed. For example: 2:README.TXT refers to FAT file \u201cREADME.TXT\u201d on disk unit #2 C:README.TXT refers to CP/M file \u201cREADME.TXT\u201d on CP/M drive C README.TXT refers to CP/M file \u201cREADME.TXT\u201d on the current CP/M drive Files with SYS, HIDDEN, or R/O only attributes are not given any special treatment. Such files are found and processed like any other file. However, any attempt to write to a read-only file will fail and the application will abort. It is not currently possible to reference CP/M user areas other than the current user. To copy files to alternate user areas, you must switch to the desired user number first or use an additional step to copy the file to the desired user area. Accessing FAT filesystems on a floppy requires the use of RomWBW HBIOS v2.9.1-pre.13 or greater. Only the first 8 RomWBW disk units (0-7) can be referenced. Files written are not verified. Wildcard matching in FAT filesystems is a bit unusual as implemented by FatFs. See FatFs documentation. Etymology The FAT application is an original RomWBW work, but utilizes the FsFat library for all of the FAT filesystem work. This application is written in C and requires SDCC to compile. As such it is not part of the RomWBW build process. However, the full project and source code is found in the FAT GitHub Repository . Known Issues CP/M (and workalike) OSes have significant restrictions on filename characters. The FAT application will block any attempt to create a file on the CP/M filesystem containing any of these prohibited characters: < > . , ; : ? * [ ] |/ \\ The operation will be aborted with \u201c Error: Invalid Path Name \u201d if such a filename character is encountered. Since MS-DOS does allow some of these characters, you can have issues when copying files from MS-DOS to CP/M if the MS-DOS filenames use these characters. Unfortunately, FAT is not yet smart enough to substitute illegal characters with legal ones. So, you will need to clean the filenames before trying to copy them to CP/M. The FAT application does try to detect the scenario where you are copying a file to itself. However, this detection is not perfect and can corrupt a file if it occurs. Be careful to avoid this. FDISK80 FDISK80 ROM-based Yes Disk-based Yes FDISK80 allows you to create and manage traditional partitions on your hard disk media. Depending on the hard disk format and features you are using, RomWBW may need hard disk partitions defined. Please refer to the RomWBW User Guide for more information on the use of partitions within RomWBW. It is very important to understand that RomWBW slices are completely different from disk partitions. This application is provided by John Coffman. The primary documentation is in the file \u201cFDisk Manual.pdf\u201d found in the Doc directory of the RomWBW distribution. Usage FDISK80 is an interactive application. At startup it will ask you for the disk unit that you want to partition. When your RomWBW system boots, it will display a table with the disk unit numbers. Use the disk unit numbers from that table to enter the desired disk unit to partition. FDISK80 operates very much like other FDISK disk partitioning applications. Please refer to the file called \u201cFDisk Manual.pdf\u201d in the Doc directory of the RomWBW distribution for further instructions. If \u2018slices\u2019 for CP/M have been created using FDISK80 , then these will need to have their directory areas initialised properly using CLRDIR . Failure to do this will likely result in corrupted data. There is also more information on using FAT partitions with RomWBW in the RomWBW User Guide document in the Doc directory of the distribution. Notes Hard disk partition tables allow a maximum of 1024 cylinders when defining partitions. However, RomWBW uses exclusively Logical Block Addressing (LBA) which does not have this limitation. When defining partitions is usually best to define the start and size of of the partition using bytes or sectors. Etymology The source for this application was provided directly by John Coffman. It is a C program and requires a build environment that includes the SDCC compiler. As such, it is not included in the RomWBW build process, only the binary executable is included. Please contact John Coffman if you would like a copy of the source. FDU (Floppy Disk Utility) FDU ROM-based Yes Disk-based Yes The FDU application is a Floppy Disk Utility that provides functions to format and test floppy disk media. Syntax FDU Usage This application has an interactive user interface. At startup, you will be prompted to select the floppy interface hardware in your system. Following this, you will see the main menu of the program with many functions to manage floppy disk drives. The primary documentation for this application is in a file called \u201cFDU.txt\u201d in the Doc directory of the RomWBW distribution. Please consult this file for usage information. Notes This application interfaces directly to the floppy hardware in your system. It does not use the RomWBW HBIOS. This means that even if your system is not configured for floppy drives, you can still use FDU to test your floppy drives and format floppy media. This also means it is critical that you choose the correct hardware interface from the initial selection when starting the application. Etymology The FDU command is an original product and the source code is provided in the RomWBW distribution. FLASH (Flash EEPROM) FLASH ROM-based Yes Disk-based Yes Most of the hardware platforms that run RomWBW support the use of EEPROMs \u2013 Electronically Erasable Programmable ROMs. The FLASH application can be used to reprogram such ROMS in-situ (in-place), thus making it possible to upgrade ROMs without a programmer or even removing the ROM from your system. This application is provided by Will Sowerbutts. Syntax FLASH READ [options] FLASH VERIFY [options] FLASH WRITE [options] is the filename of the ROM image file FLASH4 will auto-detect most parameters so additional options should not normally be required. Options: /V : Enable verbose output (one line per sector) /P or /PARTIAL : Allow flashing a large ROM from a smaller image file /ROM : Allow read-only use of unknown chip types /Z180DMA : Force Z180 DMA engine /UNABIOS : Force UNA BIOS bank switching /ROMWBW : Force RomWBW (v2.6+) bank switching /ROMWBWOLD : Force RomWBW (v2.5 and earlier) bank switching /P112 : Force P112 bank switching /N8VEMSBC : Force N8VEM SBC (v1, v2), Zeta (v1) SBC bank switching Usage To program your EEPROM ROM chip, first transfer the file to your RomWBW system. Then use the command FLASH WRITE * `*. The application will auto-detect the type of EEPROM chip you have, program it, and verify it. You can use the FLASH READ form of the command to read the ROM image from your system into a file. This is useful if you want to save a copy of your current ROM before reprogramming it. Although FLASH WRITE automatically performs a verification, you can manually perform a verification function with the FLASH VERIFY form of the command. The author\u2019s documentation for the application is found in the RomWBW distribution in the Doc/Contrib directory. Notes The application supports a significant number of EEPROM parts. It should automatically detect your part. If it does not recognize your chip, make sure that you do not have a write protect jumper set \u2013 this jumper can prevent the ROM chip from being recognized. Reprogramming a ROM chip in-place is inherently dangerous. If anything goes wrong, you will be left with a non-functional system and no ability to run the FLASH application again. Use this application with caution and be prepared to use a hardware ROM programmer to restore your system if needed. Etymology This application was written and provided by Will Sowerbutts. He provides it in binary format and is included in the RomWBW distribution as a binary file. The source code for this application can be found at the FLASH4 GitHub repository . FORMAT FORMAT ROM-based Yes Disk-based Yes This application is just a placeholder for a future version that will make it simpler to format media including floppy disks. Syntax FORMAT Notes This application currently just displays a few lines of information briefly instructing a user how to format media. It performs no actual function beyond this display currently. Etymology The FORMAT command is an original product and the source code is provided in the RomWBW distribution. HTALK (HBIOS Talk) HTALK ROM-based Yes Disk-based Yes HTALK is a variation of the TALK utility, but it works directly against HBIOS Character Units. Syntax HTALK COMn: Usage HTALK operates at the HBIOS level. The parameter to TALK refers to a HBIOS character unit. Upon execution all characters typed at the console will be sent to the device specified and all characters received by the specified device will be echoed on the console. Press Control+Z on the console to terminate the application. Notes Etymology The TALK command was created and donated to RomWBW by Tom Plano. It is an original product designed specifically for RomWBW. MODE MODE ROM-based Yes Disk-based Yes The MODE command allows you to adjust the operating characteristics such as baud rate, data bits, stop bits, and parity bits of serial ports dynamically. Syntax MODE /? MODE COM : [ [, [, [, ]]]] [/P] /? displays command usage and version information is the character device unit number is numerical baudrate is (N)one, (O)dd, (E)ven, (M)ark, or (S)pace is number of data bits, typically 7 or 8 is number of stop bits, typically 1 or 2 /P prompts user prior to setting new configuration Usage MODE /? will display basic command usage and version information. MODE with no parameters will list all devices and their current configuration. MODE < n > will display the current configuration of the specified character device unit. MODE COM : [ [, [, [, ]]]] [/P] requests that the specified configuration be set on the character device unit. You can use commas with no values to leave some values unchanged. As an example, MODE COM0: 9600,,,2 will setup character device unit 0 for 9600 baud and 2 stop bits while leaving data bits and stop bits as is. Appending /P in a command specifying a new configuration will cause the terminal output to pause and wait for the user to press a key. This allows the user to change the local terminal setup before continuing. Notes Specified baud rate and line characteristics must be supported by the serial unit. Any parameters not specified will remain unchanged. Changes are not persisted and will revert to system defaults at next system boot. Not all character devices support all MODE options. Some devices (notably ASCI devices) have limited baud rate divisors. An attempt to set a baud rate that the device cannot support will fail with an error message. Etymology The MODE command is an original product and the source code is provided in the RomWBW distribution. REBOOT REBOOT ROM-based Yes Disk-based Yes The REBOOT application is used to restart a running system from an operating system prompt. It can invoke either a warm or cold restart via command line switches. Syntax REBOOT /W REBOOT /C REBOOT /? /C initiates a cold restart /W initiates a warm restart /? displays command line usage Usage Entering REBOOT with no parameters will display the usage and version information. Use /C or /W to immediately initiate a cold or warm restart. Notes A warm restart just returns to the Boot Loader menu. A cold restart will reinitialize the system as though power had been recycled. Etymology The REBOOT application was custom written for RomWBW by MartinR. All of the hardware interface code is specific to RomWBW and the application will not operate correctly on non-RomWBW systems. The source code is provided in the RomWBW distribution. RTC (Real Time Clock) RTC ROM-based Yes Disk-based yes Many RomWBW systems provide real time clock hardware. The RTC application is a simple, interactive program allowing you to display and set the time and registers of the RTC. Syntax RTC Usage After startup, the application provides the following options: Option Function E)xit will terminate the application. T)ime will display the time as read from the RTC hardware. st(A)rt will restart the clock running if it is stopped. S)et will program the RTC clock with the date/time previously entered using the I)nit option. R)aw will read the minute/second of the RTC clock iteratively every time the space key is pressed. Press enter to end. L)oop will read the full date/time of the RTC clock iteratively every time the space key is pressed. Press enter to end. C)harge will enable the battery charging function of the RTC. N)ocharge will disable the battery charging function of the RTC. D)elay allows you to test the built-in timing delay in the program. It is not unusual for it to be wrong. I)nit allows you to enter a date/time value for subsequent programming of the RTC using the S)et option. G)et allows you to read the value of a non-volatile register in the RTC. P)ut allows you to write the value of a non-volatile register in the RTC. B)oot will reboot your system. H)elp displays brief help. Notes When using Get and Put options, the register number to read/write is entered in hex. The non-volatile ram register numbers are 0x20-0x3F. When entering values, you must enter exactly two hex characters. The backspace key is not supported. You do not use enter after entering the two hex characters. Yes, this should be improved. The RTC application interacts directly with the RTC hardware bypassing HBIOS. Etymology The RTC application was originally written by Andrew Lynch as part of the original ECB SBC board development. It has since been modified to support most of the hardware variations included with RomWBW. SLABEL (Slice Label) SLABEL ROM-based No Disk-based Yes Display or change the label of a disk slice. The label applied is only used as informational purposes, displayed by RomWBW when an OS is booted. It has no correlation with any OS volume label scheme that may exist. i.e. It does not affect the CP/M 3 disk label as applied by the SET command Syntax SLABEL [unit.slice=label] [/?] unit.slice the disk unit and slice number to apply the new label to. This is in the same format as when booting the system to a disk label is the new disk label to apply to the disk Usage SLABEL with no arguments will list All existing labels across All disks SLABEL 2.5=MYDRIVE will set the disk label of the 6th slice of disk unit 2 SLABEL /? (or other unrecognised parameters) will display a usage message. Notes There is no capability to update a label onto media that currently does not have existing media information in the third sector, typically this means only bootable media. This will only display labels for the first 64 slices of any device. Slices higher than this are currently ignored. Only bootable RomWBW disk images have a label, which is defined by the OS which is booted. i.e. NZ-COM has a label of \u201cZSDOS 1.1\u201d since that is the booted OS. Prior to RomWBW 3.5 all disk images were defined with the label \u201cUnlabeled\u201d. Etymology The SLABEL application was custom written for RomWBW and contributed by Mark Pruden. SURVEY SURVEY ROM-based Yes Disk-based Yes The SURVEY command interrogates the system for information on disk usage, memory usage and I/O ports used, and reports it to the user. Syntax The SURVEY command takes no arguments. SURVEY Usage The results presented by SURVEY include: Information about any drives, within the first eight (ie A: to H:), which have been logged by the system. This includes: the total number of files; the storage capacity occupied by those files; and the capacity remaining on that drive. Information about the the 64KByte CP/M memory map, which is shown diagramatically, and includes: locations and sizes of the TPA (Transient Program Area), CP/M\u2019s CCP (Console Command Processor),and BDOS (Basic Disk Operating System). The addresses of active CPU I/O ports. Notes The mechanism by which SURVEY discovers I/O ports is very conservative and therefore the list returned may not be exhaustive. In particular, it may fail to discover ports that are \u2018write-only\u2019. SYSCOPY (System Copy) SYSCOPY ROM-based Yes Disk-based Yes To make disk media bootable, you must write a system boot image onto the system tracks of the of the media. The SYSCOPY allows you to read or write the system boot image of disk media. Syntax SYSCOPY = is the drive to receive the operating system image or alternatively a filename to save the operating system image is the drive containing an operating system image or alternatively a filename containing the system image to be placed on the destination Usage Both and can refer to either a drive letter or a file. If a drive letter is specified, the system boot image will be read or written to the system tracks of the drive. If a filename is specified, the system boot image will be read or written to the specified filename. SYSCOPY C:=ZSYS.SYS will read a system boot image from the file ZSYS.SYS and write it onto the system tracks of drive C:. SYSCOPY A:OS.SYS=C: will capture the system boot image from the system tracks of drive C: and store it in the file A:OS.SYS. SYSCOPY D:=C: will copy the system tracks from drive C: onto the system tracks of drive D:. Notes The RomWBW ROM disk contains files with the system boot image for Z-System and CP/M 2.2. These files are called CPM.SYS and ZSYS.SYS respectively. These files can be used as the source of a SYSCOPY command to make a disk bootable with the corresponding operating system. CP/M 3 uses a two phase boot process. To make a CP/M 3 drive bootable, you need to put \u201cCPMLDR.SYS\u201d on the boot tracks of the disk and be sure that the drive also contains the \u201cCPM.SYS\u201d file. The \u201cCPMLDR.SYS\u201d file is not included on the ROM disk, but is found on the CP/M 3 disk image. ZPM3 is similar to CP/M 3. You also put \u201cCPMLDR.SYS\u201d on the system tracks of the drive to make it bootable. The ZPM3 operating system is in the file called \u201cCPM3.SYS\u201d on the ZPM3 disk image. It may seem confusing that ZPM3 is in the file called CPM3.SYS, but it is normal for ZPM3. For the purposes of booting an operating system, each disk slice is considered its own operating system. Each slice can be made bootable with its own system tracks. SYSCOPY uses drive letters to specify where to read/write the system boot images. However, at startup, the boot loaded will require you to enter the actual disk device and slice to boot from. So, you need to be careful to pay attention to the device and slice that is assigned to a drive letter so you will know what to enter at the boot loader prompt. By way of explanation, the boot loader does not know about drive letters because the operating system is not loaded yet. If you want to put a boot system image on a device and slice that is not currently assigned to a drive letter, you will need to assign a drive letter first. Not all disk formats include space for system tracks. Such disk formats cannot contains a system boot image and, therefore, cannot be made bootable. The best example of such disk formats are the ROM and RAM disks. To maximize usable file space on these drives, they do not have system tracks. Obviously, ROM operating system is supported by choosing a ROM operating system at the boot loader prompt. Any attempt to write a system boot image to disk media with no system tracks will cause SYSCOPY to fail with an error message. The system boot images are paired with the ROM version in your system. So, you must take care to update the system tracks of any bootable disk when you upgrade your ROM firmware. The system boot images are not tied to specific hardware configurations. System boot images and operating systems provided with RomWBW will work with any supported RomWBW platform or hardware as long as they are the same version as the RomWBW firmware. Etymology The SYSCOPY command is an original product and the source code is provided in the RomWBW distribution. TALK TALK ROM-based Yes Disk-based Yes It is sometimes useful to direct your console input/output to a designated serial port. For example, if you were to connect a modem to your second serial port, you might want to connect directly to it and have everything you type sent to it and everything it sends be shown on your console. The TALK application does this. Syntax TALK [TTY:|CRT:|BAT:UC1:] Usage TALK operates at the operating system level (not HBIOS). The parameter to TALK refers to logical CP/M serial devices. Upon execution all characters typed at the console will be sent to the device specified and all characters received by the specified device will be echoed on the console. Press Control+Z on the console to terminate the application. Notes This application is designed for CP/M 2.2 or Z-System. Use on later operating systems such as CP/M 3 is not supported. Etymology The TALK command is an original product and the source code is provided in the RomWBW distribution. TBASIC (Tasty BASIC) TBASIC ROM-based No Disk-based Yes Tasty Basic is a basic interpreter for CP/M and RomWBW based on the Z80 port of Palo Alto Tiny Basic. Syntax TBASIC [ \\ ] Usage Notes Tasty Basic is provided on RomWBW as both a ROM implementation and as a CP/M application. The CP/M version should be used if you wish to save Tasty Basic files. Etymology The implementation of Tasty Basic included in RomWBW is the work of Dimitri Theulings. The primary distribution site for this work is https://github.com/dimitrit/tastybasic . TIMER TIMER ROM-based Yes Disk-based Yes Most RomWBW systems have a 50Hz periodic system timer. A counter is incremented every time a timer tick occurs. The TIMER application displays the value of the counter. Syntax TIMER TIMER /? TIMER /C Usage Use TIMER to display the current value of the counter. Use TIMER /C to display the value of the counter continuously. The display of the counter will be something like this: 13426 Ticks 268.52 Seconds The first number is the total number of ticks since system startup, where there are 50 ticks per second. The second number is the total number of seconds since system startup. Numbers are displayed in decimal format. Notes The seconds value is displayed with a fractional value which is not a an actual fraction, but rather the number of ticks past the seconds rollover. All values are in hex. The primary use of the TIMER application is to test the system timer functionality of your system. In theory, you could capture the value before and after some process you want to time. Etymology The TIMER command is an original product and the source code is provided in the RomWBW distribution. TUNE TUNE ROM-based No Disk-based Yes If your RomWBW system has a sound card based on either an AY-3-8190 or YM2149F sound chip, you can use the TUNE application to play PT or MYM sound files. Note: TUNE will detect an AY-3-8910/YM2149 Sound Module re-gardless of whether support for it is included in the RomWBW HBIOS configuration Syntax TUNE * * is the name of a sound file ending in .PT2, .PT3, or .MYM Option Description -MSX Force MSX port addresses A0H/A1H (no PSG detection) -RC Force RCBus port addresses D8H/D0H (no PSG detection) --HBIOS Utilise HBIOS\u2019 sound driver -DELAY Force delay mode (don\u2019t use hardware timer) +T1 Play tune an octave higher +T2 Play tune two octaves higher -T1 Play tune an octave lower -T2 Play tune two octaves lower The +t and -t options apply only to HBIOS mode operation. The -MSX , -RC , and --HBIOS options are mutually exclusive. See Notes below. Usage The TUNE application supports PT and YM sound file formats. It determines the format of the file from the extension of the file, so your tune filenames should end in .PT2, .PT3, or .MYM. To play a sound file, just use the command and specify the file to play after the command. So, for example, TUNE ATTACK.PT2 will immediately begin playing the PT sound file \u201cATTACK.PT2\u201d. Notes The TUNE application automatically probes for compatible hardware at well known port addresses at startup. It will auto-configure itself for the hardware found. If no hardware is detected, it will abort with an error message. Some hardware (notably Why-Em-Ulator) cannot be detected due limitations of the emulation. In such cases, you can force the use of the two most common port addresses using the -MSX or -RC options. On Z180 systems, I/O wait states are added when writing to the sound chip to avoid exceeding its speed limitations. On Z80 systems, you will need to ensure that the CPU clock speed of your system does not exceed the timing limitations of your sound chip. The application probes for an active system timer and uses it to accurately pace the sound file playback. If no system timer is available, a delay loop is calculated instead. The delay loop will not be as accurate as the system timer. If the -DELAY options is specified on the command line, then the delay loop will be used regardless of whether the system has a hardware timer. This is useful if the hardware timer does not run at the 50Hz desired for sound playback. There are two modes of operation. A direct hardware interface for the AY-3-8910 or YM2149 chips, or a compatibility layer thru HBIOS supporting both the AY-3-8910 and the SN76489 chip. By default the application will attempt to interface directly to the sound chip. The optional argument --HBIOS supplied after the filename, will enable the application to use the HBIOS sound driver. The following summarizes the different modes of operation for the application: If you use TUNE with no options, it will use it\u2019s original behavior of searching for and detecting a sound chip. TUNE will play sound files directly to the PSG hardware. In this mode it does not matter if HBIOS does or does not know about the sound chip. If you use TUNE with the --HBIOS option, it will not detect a sound chip and will use the RomWBW HBIOS interface. This will only work if HBIOS was configured for the installed sound card and HBIOS detects the sound chip. If you use TUNE with -RC or -MSX , it will play tunes directly to the PSG hardware (not via HBIOS) and will bypass detection. In this mode it does not matter if HBIOS does or does not know about the sound chip. Note that the HBIOS API for sound cards is pretty good, but does not implement everything that the sound card can do. For best fidelity, use TUNE without the --HBIOS option. All RomWBW operating system boot disks include a selection of sound files in user area 3. Etymology The TUNE application was custom written for RomWBW. All of the hardware interface code is specific to RomWBW. The sound file decoding software was adapted and embedded from pre-existing sources. The YM player code is from MYMPLAY 0.4 by Lieves!Tuore and the PT player code is (c)2004-2007 S.V.Bulba vorobey@mail.khstu.ru . The source code is provided in the RomWBW distribution. VGMPLAY (Video Game Music Play) VGMPLAY ROM-based No Disk-based Yes This application will allow you to play Video Game Music files. VGM files contain music samples from a range of different sound chips that were used in arcade games, game consoles and personal computer systems. Video Game Music files have a .VGM file extension and each file contains an embedded header that identifies the hardware it is intended for and also the title of the music. All RomWBW operating system boot disks include a selection of sound files in user area 3. Additional music files can be found at: VGMRIPS website PROJECT2612 website Sound files are loaded into memory for playback, so the maximum size file that can be played is around 52Kb. Sound chips currently supported are: AY-3-8190 (and equivalent YM2149) YM2612 (and equivalent YM3848) SN76489 (single chip mono and dual chip stereo) YM2151 VGMPLAY supports playback of files with multiple combinations of these chips. Syntax VGMPLAY is the name of a sound file ending in .VGM Usage VGMPLAY does not automatically detect the hardware platform or sound hardware that you are using. This means a version customized for your system must be assembled before use. However, the version as distributed will work with ECB bus SBC systems. To play a sound file, just use the VGMPLAY command and specify the file to play after the command. So, for example, VGMPLAY TEDDY will load the TEDDY.VGM sound file into memory and begin playing it. Playback can be stopped by pressing a key. There may be a delay before playback stops. Notes The default build configuration for VGMPLAY is: CPU speed: Autodetected chip number port notes AY-3-8910 1st 09ah stereo AY-3-8910 2nd not set stereo YM2612 1st 0c0h stereo YM2612 2nd 0c4h stereo SN76489 1st 0c8h mono/left SN76489 2nd 0c9h mono/right YM2151 1st 0cah stereo YM2151 2nd 0cbh stereo Inconsistant, garbled or distorted playback can be an indication that your CPU clock speed is too high for your sound chip. In this case, if your platform supports speed switching, then the CPUSPD application can be used to reduce your processor speed. VGMPLAY is still under development. The source code is provided in the RomWBW distribution. WDATE (WBW DATE) WDATE ROM-based No Disk-based Yes wdate is a utility for CP/M systems that have Wayne Warthen\u2019s RomWBW firmware. It reads or sets the real-time clock, using function calls in the BIOS. It should work on any RTC device that is supported by RomWBW, including the internal interrupt-driven timer that is is available on some systems. wdate differs from the rtc.com utility that is provided with the RomWBW version of CP/M in that it only gets and sets the date/time. rtc.com can also manipulate the nonvolatile RAM in certain clock devices, and modify the charge controller. However, wdate is (I would argue) easier to use, as it takes its input from the command line, which can be edited, and it\u2019s less fussy about the format. It doesn\u2019t require the date to be set if you only want to change the time, for example. In addition, wdate has at least some error checking. wdate displays the day-of-week and month as English text, not numbers. It calculates the day-of-week from the year, month, and day. RTC chips usually store a day-of-week value, but it\u2019s useless in this application for two reasons: first, the BIOS does not expose it. Second, there is no universally-accepted way to interpret it (which day does the week start on? Is \u20180\u2019 a valid day of the week?) Syntax WDATE WDATE WDATE WDATE Usage A> wdate Saturday 27 May 13:14:39 2023 With no arguments, displays the current date and time. A> wdate hr min With two arguments, sets the time in hours and minutes, without changing date or seconds A> wdate hr min sec With three arguments, sets the time in hours, minutes, and seconds, without changing date A> wdate year month day hr min sec With six arguments, sets date and time. All numbers are one or two digits. The two-digit year starts at 2000. A> wdate /? Show a summary of the command-line usage. Notes I\u2019ve tested this utility with the DS1302 clock board designed by Ed Brindly, and on the interrupt-driven timer built into my Z180 board. However, it does not interact with hardware, only BIOS; I would expect it to work with other hardware. wdate checks for the non-existence of RomWBW, and also for failing operations on the RTC. It will display the terse \u201cNo RTC\u201d message in both cases. The RomWBW functions that manipulate the date and time operate on BCD numbers, as RTC chips themselves usually do. wdate works in decimal, so that it can check that the user input makes sense. A substantial part of the program\u2019s code is taken up by number format conversion and range checking. Etymology The WDATE application was written and contributed by Kevin Boone. The source code is available on GitHub at https://github.com/kevinboone/wdate-cpm . XM (X-Modem) XM ROM-based Yes Disk-based Yes An adaptation of Ward Christensen\u2019s X-Modem protocol for transferring files between systems using a serial port. Syntax XM S XM SK XM L XM LK XM R The following may be added to the action codes: | S : Send a file | L : Send a file from a library | R : Receive a file | K : Use 1K blocksize (send operations) | C : Force use of checksum (receive operations) | X : Force 128-byte protocol (receive operations) | 0 - 9 : Specifies HBIOS character unit for transfers is the name of a file to send or receive is the name of a library (.lbr) to extract a file to send For example, the following command will receive a file using checksums on HBIOS character unit 3 and will name the received file MYFILE.TXT . XM RC3 MYFILE.TXT Usage To transfer a file from your host computer to your RomWBW computer, do the following: Enter one of the XM receive commands specifying the name you want to give to the received file. On your host computer select a file to send and initiate the XModem send operation. To transfer a file from your RomWBW computer to your host computer, do the following: Enter one of the XM send commands specifying the name of the file to be sent. On your host computer, specify the name to assign to the received file and initiate and XModem receive operation. Please refer to the documentation of your host computer\u2019s terminal emulation software for specific instructions on how to use XModem. Notes The XModem adaptation that comes with RomWBW will default to using the current HBIOS console port for transfers. Note that if you change your console port at the OS level (e.g., STAT CON:=UC1:), this does not change the HBIOS console. XM attempts to determine the best way to drive the serial port based on your hardware configuration. When possible, it will bypass the HBIOS for faster operation. However, in many cases, it will use HBIOS so that flow control can be used. XM is dependent on a reliable communications channel. You must ensure that the serial port can be serviced fast enough by either using a baud rate that is low enough or ensuring that hardware flow control is fully functional (end to end). Etymology The XM application provided in RomWBW is an adaptation of a pre-existing XModem application. Based on the source code comments, it was originally adapted from Ward Christensen\u2019s MODEM2 by Keith Petersen and is labeled version 12.5. The original source of the application was found on the Walnut Creek CD-ROM and is called XMDM125.ARK dated 7/15/86. The actual application is virtually untouched in the RomWBW adaptation. The majority of the work was in the modem driver which was enhanced to detect the hardware being used and dynamically choose the appropriate driver. The source code is provided in the RomWBW distribution. ZMD (Z-Modem) ZMD ROM-based No Disk-based Yes An adaptation of Robert Kramer\u2019s Remote CP/M File Transfer Program with support for XModem and YModem transfers. NOTE : ZMD does not do ZModem transfers. The Z in ZMD refers to Z-System compatibility. Syntax ZMD \\\\\\ [ \\ ] where \\ can be: S - Send file from BBS SP - Send from private area A - Send ARK/ARC/LBR member R - Receive file from YOU RP - Receive in private area RW - Receive without description(s) F - Displays available upload space \\ can be: X - Xmodem 128 byte blocks (CRC) C - Xmodem 128 byte blocks (Checksum) K - Ymodem 1024 byte blocks (CRC only) and \\ can specify a single digit (0-9) that specifies the RomWBW Character Unit to use for the file transfer. Usage To transfer a file from your host computer to your RomWBW computer, do the following: Enter one of the ZMD receive commands specifying the name you want to give to the received file (no filename required for ZModem transfers). On your host computer select a file to send and initiate an XModem or YModem send operation. To transfer a file from your RomWBW computer to your host computer, do the following: Enter one of the ZMD send commands specifying the name of the file to be sent. On your host computer, specify the name to assign to the received file and initiate an XModem or YModem receive operation. Please refer to the documentation of your host computer\u2019s terminal emulation software for specific instructions on how to use XModem. Notes The ZMP adaptation that comes with RomWBW will default to using the current HBIOS console port for transfers. Note that if you change your console port at the OS level (e.g., STAT CON:=UC1:), this does not change the HBIOS console. ZMP attempts to determine the best way to drive the serial port based on your hardware configuration. When possible, it will bypass the HBIOS for faster operation. However, in many cases, it will use HBIOS so that flow control can be used. ZMP is dependent on a reliable communications channel. You must ensure that the serial port can be serviced fast enough by either using a baud rate that is low enough or ensuring that hardware flow control is fully functional (end to end). Etymology ZMD v1.50 was produced by Robert Kramer. The RomWBW adaptation just uses the RomWBW HBIOS serial API. ZMP (Z-Modem Program) ZMP ROM-based No Disk-based Yes ZMP is a terminal program for interacting with a modem attached to your system. It includes X/Y/ZModem file transfer protocols. An actual modem is not required, but you must have a port for ZMP to use that is independent of the console running ZMP . Syntax ZMD [\\] \\ can specify a single digit (0-9) indicating the RomWBW Character Unit to use for the modem port. Usage Refer to the file ZMP.DOC found on all disk images that include the ZMP application. Notes ZMP requires access to multiple overlay and configuration files to run. It will look for these on the default driver and user area. Depending the operating system used, you may be able to set up a search path and locate these files in other locations. The files used by ZMP are: ZMP.HLP ZMP.DOC ZMP.CFG ZMP.FON ZMXFER.OVR ZMTERM.OVR ZMINIT.OVR ZMCONFIG.OVR The ZMP console is always the active OS console. If no \\ is specified on the command line, ZMP will default to using HBIOS Character Unit 1 as the modem port. Take care to avoid using the same HBIOS Character Unit as both the console and the modem or various strangeness will occur. ZMP is a full screen application and is configured to use ANSI/VT-100 screen control. ZMP does not support the range of port configurations provided by RomWBW. The RomWBW adaptation of ZMP ignores the port configuration options within ZMP . Instead, you should configure the HBIOS Character Unit using the RomWBW MODE command before launching ZMP . ZMP is written in C. As a result, file transfers will be noticeably slower than other assembly language file transfer tools. Etymology ZMP was produced by Ron Murray and was based on HMODEM II. Wayne Hortensius updated the source to compile with the latest version of Hi-Tech C and implemented a few enhancements. The RomWBW overlay was developed by Phil Summers.","title":"Applications"},{"location":"Applications/#summary","text":"RomWBW is supplied with a suite of software applications that enhance the use of the system. Some of these applications have been written entirely from scratch for RomWBW. Others are pre-existing software that has been customized for the RomWBW environment. This document serves as a reference for these RomWBW-specific applications. The primary usage documentation for RomWBW is the RomWBW User Guide . It is assumed that the reader is generally familiar with this document. RomWBW also includes many generic software applications that have not been modified for RomWBW (e.g., MSBASIC). These generic applications are not documented here. Please refer to the application specific documentation for these generic applications. The documentation for some of these generic applications is included in the Doc folder of the RomWBW distribution. The applications described in this document fall into two general categories. ROM Applications are software applications that are loaded from the the ROM memory of your RomWBW system. CP/M Applications are software applications that are loaded from disk using a previously loaded CP/M (or CP/M like) operating system using its command line. Note that some applications are available in both forms. For example, Microsoft BASIC is available as a ROM application and as an application that runs under CP/M. Only the ROM variant is documented here because the CP/M variant is not RomWBW-specific. You will see that two of the RomWBW operating systems are included here as ROM Applications. Although operating systems are normally loaded from disk, RomWBW does include a way to launch CP/M 2.2 and Z-System directly from ROM. Most RomWBW systems include a ROM disk. A running operating system can load applications from the ROM disk just like a floppy or hard disk. Applications loaded from the ROM disk by CP/M are considered to be CP/M applications, not ROM applications.","title":"Summary"},{"location":"Applications/#boot-menu","text":"The system start-up process is described in some detail in the RomWBW User Guide, and for the sake of completeness there is some overlap here. When a RomWBW system is started the user is presented with a sign-on message at the default console detailing the RomWBW version and build date. The system follows this with the list of hardware that it has discovered, a list of devices and the system units assigned to them, before finally inviting the to select a boot device with the prompt: Boot [H=Help]: At this point, the user may specify a unit, optionally with a slice, to boot from. Note that it is not possible to boot from from the serial (ASCI) or memory disk (MD) devices. Alternatively the user may select one of the built-in Boot Loader commands. A menu of which may be displayed by pressing the H or ? keys (for Help). Furthermore, a ROM application may also be started from this prompt. This start-up process is described in some detailed in the RomWBW User Guide, and there is some overlap here.","title":"Boot Menu"},{"location":"Applications/#help","text":"After pressing H or ? at the boot prompt the user will be presented with the following list of available commands: L - List ROM Applications D - Device Inventory R - Reboot System I [] - Set Console Interface/Baud code V [] - View/Set HBIOS Diagnostic Verbosity [.] - Boot Disk Unit/Slice The function performed by each command is described below: L: Lists the applications and operating systems that are built into the RomWBW ROM - e.g., low-level monitor utility, CP/M, or BASIC. D: Displays the list of system devices that was first displayed when the system was started. R: Will restart the system. Note that this does not reset hardware devices in the same way that power-on or pressing the reset button would. I: Allows the user to select the interface connected to the console, and optionally the Baud rate. This could be used to allow the system to be operated from a second console. V: Enables the display of invalid RomWBW HBIOS API calls. This option is very unlikely to be used by a user and is used for development purposes. And, finally, the system may be booted by specifying the unit number, and optional slice, separated by a period(\u2018.\u2019), of where the disk operating system software is located - eg 2, 4.1, 5.3 Alternatively, a RomWBW ROM application may be started by pressing the appropriate key from the applications menu, shown in the following section.","title":"Help"},{"location":"Applications/#list-rom-applications","text":"If the user presses the L key at the Boot Loader prompt then the system will display the list of ROM applications that are built into RomWBW. If a command letter is known, then it may be entered directly at the prompt rather than first displaying the menu. The ROM applications available from the boot prompt are: M: Monitor C: CP/M 2.2 Z: Z-System B: BASIC T: Tasty BASIC F: Forth P: Play a Game N: Network Boot X: XModem Flash Updater U: User App Each of these will now be described in greater detail.","title":"List ROM Applications"},{"location":"Applications/#rom-applications","text":"","title":"ROM Applications"},{"location":"Applications/#monitor","text":"The Monitor program is a low-level utility that can be used for testing and programming. It allows programs to be entered, memory to be examined and modified, and input/output devices to be read or written to. It\u2019s key advantage is that is available at boot up. Its key disadvantages are that code cannot be entered in assembly language and there is no ability to save to persistent storage (disks). The available memory area for programming is 0100h-EDFFh . The following areas are reserved: Memory Area Function 0000-00FFh Jump and restart (RST) vectors EE00-FDFFh Monitor FE00-FFFFh HBIOS proxy The monitor uses a prompt in the format of xx> where xx is the RomWBW bank id number. For example, the prompt may look like this and means that Bank Id 0x8E is currently mapped into the low 32K of processor memory. 8E> Please refer to Section 4 of the \\$doc_sys# for a description of the RomWBW Bank Id and how it relates to the physical bank of memory being mapped to the lower 32K of the processor. The method of assigning banks for specific RomWBW functions is also described. Commands can be entered at the command prompt. Automatic case conversion takes place on command entry and all numeric arguments are expected to be in hex format. The Monitor allows access to all memory locations but ROM and Flash memory cannot be written to. At startup, the Monitor will select the default \u201cUser\u201d bank. The S command is provided to allow selecting alternate banks. There now follows a more detailed guide to using the RomWBW Monitor program:","title":"Monitor"},{"location":"Applications/#command-summary","text":"? - Will display a summary of the available commands. Monitor Commands (all values in hex): B - Boot system D xxxx [yyyy] - Dump memory from xxxx to yyyy F xxxx yyyy zz - Fill memory from xxxx to yyyy with zz H - Halt system I xxxx - Input from port xxxx K - Keyboard echo L - Load Intel hex data M xxxx yyyy zzzz - Move memory block xxxx-yyyy to zzzz O xxxx yy - Output value yy to port xxxx P xxxx - Program RAM at address xxxx R xxxx [[yy] [zzzz]] - Run code at address xxxx Pass yy and zzzz to register A and BC S xx - Set bank to xx U - Set bank to previous bank T xxxx - X-modem transfer to memory location xxxx X - Exit monitor","title":"Command Summary"},{"location":"Applications/#cold-boot","text":"B - Performs a cold boot of the RomWBW system. A complete re-initialization of the system is performed and the system returns to the Boot Loader prompt.","title":"Cold Boot"},{"location":"Applications/#dump-memory","text":"D xxxx [yyyy] - Dump memory from hex location xxxx to yyyy on the screen as lines of 16 hexadecimal bytes with their ASCII equivalents (if within a set range, else a \u2018.\u2019 is printed). If the end address is omitted then 256 bytes are displayed. A good tool to see where code is located, check for version id, obtain details for chip configurations and execution paths. Example: D 100 1FF 0100: 10 0B 01 5A 33 45 4E 56 01 00 00 2A 06 00 F9 11 ...Z3ENV...*..\u00f9. 0110: DE 38 37 ED 52 4D 44 0B 6B 62 13 36 00 ED B0 21 \u00de87\u00edRMD.kb.6.\u00ed\u00b0! 0120: 7D 32 E5 21 80 00 4E 23 06 00 09 36 00 21 81 00 }2\u00e5!..N#...6.!.. 0130: E5 CD 6C 1F C1 C1 E5 2A C9 8C E5 CD 45 05 E5 CD \u00e5\u00cdl.\u00c1\u00c1\u00e5*\u00c9.\u00e5\u00cdE.\u00e5\u00cd 0140: 59 1F C3 00 00 C3 AE 01 C3 51 04 C3 4C 02 C3 57 Y.\u00c3..\u00ee.\u00c3Q.\u00c3L.\u00c3W 0150: 02 C3 64 02 C3 75 02 C3 88 02 C3 B2 03 C3 0D 04 .\u00c3d.\u00c3u.\u00c3..\u00f2.\u00c3.. 0160: C3 19 04 C3 22 04 C3 2A 04 C3 35 04 C3 40 04 C3 \u00c3..\u00c3\".\u00c3*.\u00c35.\u00c3@.\u00c3 0170: 48 04 C3 50 04 C3 50 04 C3 50 04 C3 8F 02 C3 93 H.\u00c3P.\u00c3P.\u00c3P.\u00c3..\u00c3. 0180: 02 C3 94 02 C3 95 02 C3 85 04 C3 C7 04 C3 D1 01 .\u00c3..\u00c3..\u00c3..\u00c3\u00c7.\u00c3\u00d1. 0190: C3 48 02 C3 E7 04 C3 56 03 C3 D0 01 C3 D0 01 C3 \u00c3H.\u00c3\u00e7.\u00c3V.\u00c3\u00d0.\u00c3\u00d0.\u00c3 01A0: D0 01 C3 D0 01 C3 D0 01 C3 D0 01 01 02 01 CD 6B \u00d0.\u00c3\u00d0.\u00c3\u00d0.\u00c3\u00d0....\u00cdk 01B0: 04 54 68 69 73 20 66 75 6E 63 74 69 6F 6E 20 6E .This function n 01C0: 6F 74 20 73 75 70 70 6F 72 74 65 64 2E 0D 0A 00 ot supported.... 01D0: C9 3E FF 32 3C 00 3A 5D 00 FE 20 28 14 D6 30 32 \u00c9>\u00ff2<.:].\u00fe (.\u00d602 01E0: AB 01 32 AD 01 3A 5E 00 FE 20 28 05 D6 30 32 AC \u00ab.2\u00ad.:^.\u00fe (.\u00d602\u00ac 01F0: 01 C5 01 F0 F8 CF E5 26 00 0E 0A CD 39 02 7D 3C .\u00c5.\u00f0\u00f8\u00cf\u00e5&...\u00cd9.}<","title":"Dump Memory"},{"location":"Applications/#fill-memory","text":"F xxxx yyyy zz - Fill memory from hex xxxx to yyyy with a single value of zz over the full range. The Dump command can be used to confirm that the fill completed as expected. A good way to zero out memory areas before writing machine data for debug purposes.","title":"Fill Memory"},{"location":"Applications/#halt-system","text":"H - Halt system. A Z80 HALT instruction is executed. The system remains in the halt state until the system is physically rebooted. Interrupts will not restart the system. On systems that support a HALT status LED, the LED will be illuminated.","title":"Halt System"},{"location":"Applications/#input-from-port","text":"I xxxx - Input data from port xxxx and display to the screen. This command is used to read values from hardware I/O ports and display the contents in hexadecimal.","title":"Input from Port"},{"location":"Applications/#keyboard-echo","text":"K - Echo any key-presses from the terminal. Press \u2018ESC\u2019 key to quit. This facility provides that any key stroke sent to the computer will be echoed back to the terminal. File down loads will be echoed as well while this facility is \u2018on\u2019.","title":"Keyboard Echo"},{"location":"Applications/#load-hex","text":"L - Load a Intel Hex data via the terminal program. The load address is defined in the hex file of the assembled code. The terminal emulator program should be configured to give a delay at the end of each line to allow the monitor enough time to parse the line and move the data to memory. Keep in mind that this will be transient unless the system supports battery backed memory. Saving to memory drive is not supported.","title":"Load Hex"},{"location":"Applications/#move-memory","text":"M xxxx yyyy zzzz - Move hex memory block xxxx to yyyy to memory starting at hex location zzzz. Care should be taken to insure that there is enough memory at the destination so that code does not get over-written or memory wrapped around.","title":"Move Memory"},{"location":"Applications/#output-to-port","text":"O xxxx yy - Output data byte xx to port xxxx. This command is used to send hexadecimal values to hardware I/O ports to verify their operation and is the companion to the I operation. Use clip leaded LEDs to confirm the data written.","title":"Output to Port"},{"location":"Applications/#program-memory","text":"P xxxx - Program memory location xxxx. This routine will allow you to program a hexadecimal value \u2018into memory starting at location xxxx. Press \u2019Enter\u2019 on a blank line to return to the Monitor prompt. The limitation around programming memory is that it must be entered in hexadecimal. An alternative is to use the L command to load a program that has been assembled to a hex file on the remote computer. An excellent online resource for looking up opcodes for entry can be found here: https://clrhome.org/table .","title":"Program Memory"},{"location":"Applications/#run-program","text":"R xxxx [[yy] [zzzz]] - Run program at location xxxx. If optional arguments yy and zzzz are entered they are loaded into the A and BC register respectively. The return address of the Monitor is saved on the stack so the program can return to the monitor. On return to the monitor, the contents of the A, HL, DE and BC registers are displayed.","title":"Run Program"},{"location":"Applications/#set-bank","text":"S xx - Set the physical memory bank to the RomWBW Bank Id indicated by xx. Memory addresses 0x0000-0x7FFF (i.e. bottom 32k) are affected. Because the interrupt vectors are stored in the bottom page of this range, this function is disabled when interrupt mode 1 is being used (IM1). Interrupt mode 2 is not affected as the associated jump vectors are stored in high memory. Changing the bank also impacts the restart vectors (RST), so executing code that calls the HBIOS using the RST 08 assembly code will not work. The monitor stack resides in high memory and is not affected but any code that changes the stack to low memory will be affected. The U command may be used to undo the change and return the selected memory bank back to the previously selected one. Section 4 of the RomWBW System Guide provides detail on how Bank Ids map to the physical memory of the system and also how specific banks are utilized by RomWBW.","title":"Set Bank"},{"location":"Applications/#undo-bank","text":"U - Change the bank in memory back to the previously selected bank. This command should be used in conjunction with the S command.","title":"Undo Bank"},{"location":"Applications/#x-modem-transfer","text":"T xxxx - Receive an X-modem file transfer and load it into memory starting at location xxxx. 128 byte blocks and checksum mode is the only supported protocol.","title":"X-Modem Transfer"},{"location":"Applications/#exit-monitor","text":"X - Exit the monitor program back to the main boot menu.","title":"Exit Monitor"},{"location":"Applications/#romwbw-system-configuration","text":"System Configuration ( SYSCONF ) is a utility that allows system configuration to be set, dynamically and stored in NVRAM provided by an RTC chip. ( SYSCONF ) is both a ROM application (\u2018W\u2019 Menu option), and a CP/M utility. Noting however the CP/M utility is not included on an disk image, it is found in the Binary/Applications folder of the RomWBW distribution. The RomWBW User Guide has additional information on the use of NVRAM to set your system configuration.","title":"RomWBW System Configuration"},{"location":"Applications/#basic-operation","text":"The application is an interactive application; it does not have a command line syntax. Instead commands are executed from within the application in a command line structure. When you first start the ( SYSCONF ) utility it will display the current switches followed by a command listing. When you first run the ( SYSCONF ) utility the NVRAM will be uninitialised, and can be initialised using the (R)eset command, which writes default values to NVRAM. Updates are done immediately to NVRAM as you enter them, i.e. there is no confirm changes step. If you make any incorrect changes, you simply need to enter a new command to set the Switch value correctly. Once a change has been made it is available, however it may not take effect until the next system reboot. This is dependent on the Switch itself. If no NVRAM is provided by your hardware, then running this application will just report the missing hardware and exit immediately. To exit from the application use the (Q)uit command.","title":"Basic Operation"},{"location":"Applications/#commands-and-syntax","text":"The following are the accepted commands, unless otherwise specified a \u201cSpace\u201d character is used to delimit parameters in the command. Command Argument(s) Description (P)rint -none- Display a list of the current switch value(s) (S)et {SW} {val},\u2026 Sets an Switch {SW} with specific values(s) (R)eset -none- Reset all setting to default (H)elp {SW} Provides help on the syntax (values) (Q)uit -none- Exit the application Where Argument Description {SW} Switch ID, typically this is 2 character name to identify the switch {val},\u2026 a \u201cComma\u201d separated list of values to set into the switch","title":"Commands and Syntax"},{"location":"Applications/#switch-options","text":"","title":"Switch Options"},{"location":"Applications/#auto-boot-ab","text":"This switch will define if the system will perform auto boot at the RomWBW boot prompt. Enabling this will not prevent a user from typing a boot command, so long as the timeout is not exceeded. When configured this replaces the ( AUTO_CMD ) variable defined in build configuration. Making changes to auto boot has no affect until the next reboot. Arguments Type Arguments Description Enable \u2018E\u2019 Auto Boot. eg. \u201cE,10\u201d will auto boot, after 10 seconds Timout Timeout in seconds in the range 0-15, 0 = immediate Disabled \u2018D\u2019 No Auto Boot. e.g. \u201cD\u201d will disable autoboot Examples Command Description S AB E,10 Enable Auto Boot with 10 second delay S AB D Disable Auto Boot","title":"Auto Boot (AB)"},{"location":"Applications/#boot-options-bo","text":"This switch will define the boot command to be executed when auto boot is enabled. When configured this replaces the ( AUTO_CMD ) variable defined in the ROM build configuration. Making changes to boot options has no affect until the next reboot. Arguments Type Arguments Description Disk \u2018D\u2019 Disk Boot. eg. \u201cD,2,14\u201d will boot, disk unit 2, slice 14 Disk Unit Number Unit number in the range 0-127 Disk Slice Slice in the range 0-255, use 0 for floppy boot ROM \u2018R\u2019 ROM App. e.g. \u201cR,M\u201d will boot the Monitor App Rom App Name single character used on the Menu to identify the app Examples Command Description S BO D,2,14 Set the default boot from Disk; Unit 2, Slice 14 S BO R,M Set the default boot to be the (M)onitor Rom Application","title":"Boot Options (BO)"},{"location":"Applications/#cpm-22","text":"This option will boot the CP/M 2.2 disk operating system from an image contained within the ROM. Please refer to the CPM User Manual in the Doc/CPM folder of the distribution for CP/M usage. There are also many online resources. During the build process the system will create a ROM disk containing a number of curated CP/M applications, and also a RAM drive. The capacity of each will depend upon the size of the ROM and RAM available to the system. A more complete set of utilities are provided within the disk image files provided as part of RomWBW. A number of the applications provided are generic to CP/M, while others rely on particular hardware or aspects of RomWBW itself. Those that are written specific to RomWBW include: ASSIGN, CPUSPD, FDU, FORMAT, FLASH, FDISK80, MODE, REBOOT, RTC, SYSCOPY, TALK, TIMER, XM, and COPYSL. The CP/M utilities supplied with RomWBW warrant more detailed descriptions, and so are described in some detail in their own section of this user guide. In summary they provide the initial capability to manage and update your RomWBW system, to create other bootable media (hardware dependent) and to write/debug code using assembler and BASIC.","title":"CP/M 2.2"},{"location":"Applications/#z-system","text":"Z-System is a complete alternative, but entirely compatible, disk operating system to CP/M. Z-System is comprised of ZSDOS 1.1 which is a replacement for CP/M\u2019s Basic Disk Operating System (BDOS), and ZCPR which is a replacement for the Console Command Processor (CCP). Either or both may be used, although using both together will allow ZCPR to make use of specific ZSDOS features. Documentation for Z-System may be found in the Doc/CPM folder of the RomWBW distribution and the reader is referred to those.","title":"Z-System"},{"location":"Applications/#basic","text":"For those who are not familiar with BASIC, it stands for Beginners All Purpose Symbolic Instruction Code. RomWBW contains two versions of ROM BASIC, a full implementation and a \u201ctiny\u201d BASIC. The full implementation is a version of Microsoft BASIC from the NASCOM Computer. A comprehensive instruction manual is available in the Doc/Contrib directory.","title":"BASIC"},{"location":"Applications/#romwbw-specific-features","text":"Sound Graphics Terminal Support","title":"RomWBW specific features"},{"location":"Applications/#romwbw-unsupported-features","text":"Cassette loading Cassette saving","title":"RomWBW unsupported features"},{"location":"Applications/#tastybasic","text":"TastyBASIC offers a minimal implementation of BASIC that is only 2304 bytes in size. It originates from Li-Chen Wang\u2019s Palo Alto Tiny BASIC from around 1976. It\u2019s small size is suited the tiny memory capacities of the time. This implementation is by Dimitri Theulings and his original source can be found at https://github.com/dimitrit/tastybasic .","title":"TastyBASIC"},{"location":"Applications/#features-limitations","text":"Integer arithmetic, numbers -32767 to 32767 Singles letter variables A-Z 1-dimensional array support Strings are not supported","title":"Features / Limitations"},{"location":"Applications/#direct-commands","text":"LIST , RUN , NEW , CLEAR , BYE","title":"Direct Commands"},{"location":"Applications/#statements","text":"LET , IF , GOTO , GOSUB RETURN , REM , FOR TO NEXT STEP , INPUT , PRINT , POKE , END","title":"Statements"},{"location":"Applications/#functions","text":"PEEK , RND , ABS , USR , SIZE","title":"Functions"},{"location":"Applications/#operators","text":">= , # , > , = , <= , < Operator precedence is supported. Type BYE to return to the boot menu.","title":"Operators"},{"location":"Applications/#forth","text":"CamelForth is the version of Forth included as part of the boot ROM in RomWBW. It has been converted from the Z80 CP/M version published at https://www.camelforth.com/page.php?5 . The author is Brad Rodriguez who is a prolific Forth enthusiast, whose work can be found here: https://www.bradrodriguez.com/papers . For those are who are not familiar with Forth, I recommend the wikipedia article https://en.wikipedia.org/wiki/Forth_(programming_language) and the Forth Interest Group website https://www.forth.org/ .","title":"FORTH"},{"location":"Applications/#important-things-to-know","text":"Forth is case sensitive. To exit back to the boot loader type bye To get a list of available words type WORDS To reset Forth to its initial state type COLD Most of the code you find on the internet will not run unless modified or additional Forth words are added to the dictionary. This implementation does not support loading or saving of programs. All programs need to be typed in. Additionally, screen editing and code blocks are not supported. A CP/M version is not provided with RomWBW, this is only a ROM application. If you need to run it under CP/M you would need to download it from the camelforth web site, the link is above.","title":"Important things to know"},{"location":"Applications/#structure-of-forth-source-files","text":"File Description camel80.azm Code Primitives camel80d.azm CPU Dependencies camel80h.azm High Level words camel80r.azm RomWBW additions glosshi.txt Glossary of high level words glosslo.txt Glossary of low level words glossr.txt Glossary of RomWBW additions","title":"Structure of Forth source files"},{"location":"Applications/#romwbw-additions","text":"Extensions and changes to this implementation compared to the original distribution are: The source code has been converted from Z80mr assembler to Hector Peraza\u2019s zsm. An additional file camel80r.azm has been added for including additional words to the dictionary at build time. However, as currently configured there is very little space allocated for addition words. Exceeding the allocated ROM space will generate an error message when building. James Bowman\u2019s double precision words have been added from his RC2014 version: https://github.com/jamesbowman/camelforth-z80 . Word Syntax Description D+ d1 d2 \u2013 d1+d2 Add double numbers 2>R d \u2013 2 to R 2R> d \u2013 fetch 2 from R M*/ d1 n2 u3 \u2013 d=(d1*n2)/u3 double precision mult. div SVC hl de bc n \u2013 hl de bc af Execute a RomWBW function P! n p \u2013 Write a byte to a I/O port P@ p \u2013 n Read a byte from and I/O port","title":"RomWBW Additions"},{"location":"Applications/#play-a-game","text":"","title":"Play a Game"},{"location":"Applications/#2048","text":"2048 is a puzzle game that can be both mindless and challenging. It appears deceptively simple but failure can creep up on you suddenly. It requires an ANSI/VT-100 compatible colour terminal to play. 2048 is like a sliding puzzle game except the puzzle tiles are numbers instead of pictures. Instead of moving a single tile all tiles are moved simultaneously in the same direction. Where two tiles of the same number collide, they are reduced to one tile with the combined value. After every move a new tile is added with a starting value of 2. The goal is to create a tile of 2048 before all tile locations are occupied. Reaching the highest points score, which is the sum of all the tiles is a secondary goal. The game will automatically end when there are no more possible moves. Play consists of entering a direction to move. Directions can be entered using any of three different keyboard direction sets. Direction | Keys ----------|---------- Up | w ^E 8 Down | s ^X 2 Left | a ^S 4 Right | d ^D 6 The puzzle board is a 4x4 grid. At start, the grid will be populated with two 2 tiles. An example game sequence is shown below with new tiles to the game shown in brackets. Start Move 1 - Up Move 2 - Left Move 3 - Left +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | |(2)| | | | | 4 | | 4 | | | | | 4 | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | | | | | | | | | | | |(4)| | 4 | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | |(2)| | | | | | | | | | | | | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | | | | | |(2)| | | 2 | | | | | 2 | |(2)| | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ Move 4 - Left Move 5 - Up Move 6 - Right Move 7 - Up +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | 4 | | | | | 8 | | | 4 | | | | 8 | 4 | | | | 8 | 8 | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | 4 | | |(4)| | 4 | | | | | | | | 4 | | | | | 2 | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | | | | | | | | | | | | | | | | | | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ | 4 | | | | |(2)| | | | |(2)| | | 2 | |(2)| | | | +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ +---+---+---+---+ This is how I lost this game: +---+---+---+---+ | 4 | 2 | 16| 4 | +---+---+---+---+ | 32| 64| 8 | 2 | +---+---+---+---+ | 4 | 8 |128| 32| +---+---+---+---+ |(2)| 16| 8 | 4 | +---+---+---+---+ Press Q at any time to bring up the option to Quit or Restart the game.","title":"2048"},{"location":"Applications/#network-boot","text":"If your RomWBW system is equipped with an RCBus MT011 module, it is possible to boot into CP/M 2.2 directly from a CP/NET network server. This means that the operating system will be loaded directly from the network server and all of your drive letters will be provided by the network server. This function requires substantial knowledge of CP/NET and it\u2019s implementation within RomWBW. Section 10 of the RomWBW User Guide provides complete instructions for setting up a CP/NET based network under RomWBW including a section on network booting.","title":"Network Boot"},{"location":"Applications/#xmodem-flash-updater","text":"The RomWBW Xmodem flash updater provides the capability to update RomWBW from the boot loader using an x-modem file transfer. It offers similar capabilities to Will Sowerbutts FLASH4 utility except that the flashing process occurs during the file transfer. These are the key differences between the two methods are: Xmodem Flash Updater FLASH.COM (aka FLASH4) Available from the boot loader Well proven and tested Xmodem transfer is integrated Wider range of supported chips and hardware Integrated checksum utilities Wider range of supported platforms Capability to copy a ROM image Only reprograms sectors that have changed More convenient one step process Ability save and verify ROM images No intermediate storage required Progress display while flashing . Displays chip identification information . Faster file transfer The major disadvantages of the Updater is that it is new and relatively untested. There is the risk that a failed transfer will result in a partially flashed and unbootable ROM. There are some limitations on serial transfer speeds. The updater utility was initially intended to support the Retrobrew SBC-V2-005 platform using Atmel 39SF040 flash chips but has now been extended to be more generic in operation. Supported flash chips are 39SF040, 29F040, AT49F040, AT29C040, M29F040 , MX29F040, A29010B, A29040B The Atmel 39SF040 chip is recommended as it can erase and write 4Kb sectors. Other chips require the whole chip to be erased.","title":"Xmodem Flash Updater"},{"location":"Applications/#usage","text":"In most cases, completing a ROM update is a simple as: Booting to the boot loader prompt Selecting option X - Xmodem Flash Updater Selecting option U - Update Initiating an X-modem transfer of your ROM image on your console device Selecting option R - Reboot If your console device is not able to transfer a ROM image i.e. your console is a VDU then you will have to use the console options to identify which character-input/output device is to be used as the serial device for transfer. When your console is the serial device used for the transfer, no progress information is displayed as this would disrupt the x-modem file transfer. If you use an alternate character-input/output devices as the serial device for the transfer then progress information will be displayed on the console device. Due to different platform processor speeds, serials speeds and flow control capabilities the default console or serial device speed may need to be reduced for a successful transfer and flash to occur. The Set Console Interface/Baud code option at the Boot Loader can be used to change the speed if required. Additionally, the Updater has options to set to and revert from a recommended speed. See the RomWBW Applications guide for additional information on performing upgrades.","title":"Usage"},{"location":"Applications/#console-options","text":"Option ( C ) - Set Console Device Option ( S ) - Set Serial Device By default the updater assumes that the current console is a serial device and that the ROM file to be flashed will also be transferred across this device, so the Console and Serial device are both the same. Either device can be can be change to another character-input/output device but the updater will always expect to receive the x-modem transfer on the Serial Device The advantage of transferring on a different device to the console is that progress information can be displayed during the transfer. Option ( > ) - Set Recommended Baud Rate Option ( \\< ) - Revert to Original Baud Rate","title":"Console Options"},{"location":"Applications/#programming-options","text":"Option ( U ) - Begin Update The will begin the update process. The updater will expect to start receiving an x-modem file on the serial device unit. X-modem sends the file in packets of 128 bytes. The updater will cache 32 packets which is 1 flash sector and then write that sector to the flash device. If using separate console, bank and sector progress information will shown BANK 00 s00 s01 s02 s03 s04 s05 s06 s06 s07 BANK 01 s00 s01 s02 s03 s04 s05 s06 s06 s07 BANK 02 s00 s01 s02 s03 s04 s05 s06 s06 s07 etc The x-modem file transfer protocol does not provide any filename or size information for the transfer so the updater does not perform any checks on the file suitability. The updater expects the file size to be a multiple of 4 kilobytes and will write all data received to the flash device. A system update file (128kb .img) or complete ROM can be received and written (512kb or 1024kb .rom) If the update fails it is recommended that you retry before rebooting or exiting to the Boot loader as your machine may not be bootable. Option ( D ) - Duplicate flash #1 to flash #2 This option will make a copy of flash #1 onto flash #2. The purpose of this is to enable making a backup copy of the current flash. Intended for systems using 2x512Kb Flash devices. Option ( V ) - Toggle Write Verify By default each flash sector will be verified after being written. Slight performance improvements can be gained if turned off and could be used if you are experiencing reliable transfers and flashing.","title":"Programming options"},{"location":"Applications/#exit-options","text":"Option ( R ) - Reboot Execute a cold reboot. This should be done after a successful update. If you perform a cold reboot after a failed update then it is likely that your system will be unusable and removing and reprogramming the flash will be required. Option ( Q ) - Quit to boot loader. The SBC Boot Loader is reloaded from ROM and executed. After a successful update a Reboot should be performed. However, in the case of a failed update this option could be used to attempt to load CP/M and perform the normal x-modem / flash process to recover.","title":"Exit options"},{"location":"Applications/#crc-utility-options","text":"Option ( 1 ) and ( 2 ) - Calculate and display CRC32 of 1st or 2nd 512k ROM. Option ( 3 ) - Calculate and display CRC32 of a 1024k (2x512Kb) ROM. Can be used to verify if a ROM image has been transferred and flashed correctly. Refer to the Tera Term section below for details on configuring the automatic display of a files CRC after it has been transferred. In Windows, right clicking on a file should also give you a context menu option CRC SHA which will allow you to select a CRC32 calculation to be done on the selected file.","title":"CRC Utility options"},{"location":"Applications/#tera-term-macro-configuration","text":"Macros are a useful tool for automatic common tasks. There are a number of instances where using macros to facilitate the update process could be worthwhile if you are: Following the RomWBW development builds. Doing lots of configuration changes. Doing development on RomWBW drivers Macros can be used to automate sending ROM updates or images and for my own purposed I have set up a separate macro for transferring each of the standard build ROM, my own custom configuration ROM and update ROM. An example macro file to send an *.upd file, using checksum mode and display the crc32 value of the transmitted file: Xmodem send, checksum, display crc32 xmodemsend '\\\\desktop\\users\\phillip\\documents\\github\\romwbw\\binary\\sbc_std_cust.upd' 1 crc32file crc '\\\\desktop\\users\\phillip\\documents\\github\\romwbw\\binary\\sbc_std_cust.rom' sprintf '0x%08x' crc messagebox inputstr 'crc32'","title":"Tera Term macro configuration"},{"location":"Applications/#serial-speed-guidelines","text":"As identified in the introduction, there are limitations on serial speed depending on processor speed and flow control settings. Listed below are some of the results identified during testing. Configuration Processor Speed Maximum Serial Speed UART no flow control 2MHz 9600 UART no flow control 4MHz 19200 UART no flow control 5MHz 19200 UART no flow control 8MHz 38400 UART no flow control 10MHz 38400 USB-fifo 2MHz+ n/a ASCI no flow control 18.432MHz 9600 ASCI with flow control 18.432MHz 38400 The Set Recommend Baud Rate option in the Updater menu follows the following guidelines. Processor Speed Baud Rate 1MHz 4800 2-3MHz 9600 4-7MHz 19200 8-20MHz 38400 These can be customized in the updater.asm source code in the CLKTBL table if desired. Feedback to the RomWBW developers on these guidelines would be appreciated.","title":"Serial speed guidelines"},{"location":"Applications/#notes","text":"All testing was done with Tera Term x-modem, Forcing checksum mode using macros was found to give the most reliable transfer. Partial writes can be completed with 39SF040 chips. Other chips require entire flash to be erased before being written. An SBC V2-005 MegaFlash or Z80 MBC required for 1mb flash support. The Updater assumes both chips are same type Failure handling has not been tested. Timing broadly calibrated on a Z80 SBC-v2 Unabios not supported","title":"Notes"},{"location":"Applications/#user-application","text":"RomWBW provides the facility for a user to build, include and execute their own custom application directly from the applications menu at boot-up. All that\u2019s needed is for the user to create their custom code ready for inclusion, recognising that there are certain constraints in doing this. In order to build properly, the build process requires that the file usrrom.asm be found in the /Source/HBIOS folder of the RomWBW tree. This source file needs to assemble using TASM and it must start at (ORG) address 00100H as the RomWBW HBIOS reserves locations 00000H to 000FFH for internal use. Further, the user application must assemble to a maximum of USR-SIZ bytes. During execution, the user application may make use of HBIOS calls as necessary, and at exit it should return to the RomWBW boot loader using the HBIOS warm reset. Note that no disk operating system (eg CP/M) functions will be available as no disk operating system will have been loaded. There is a sample usrrom.asm supplied in Source/HBIOS and it is recommended that, at least initially, users create their own application based on this as a template because it already creates the necessary variables, starts at (ORG) 00100H, and ensures that the assembled file is padded to create a file USR-SIZ in length. Equally, should the the user\u2019s application prove too large for the space available then assembly will be terminated with an error. Users should not remove this check from the templated code. If required, the user application may make use of the Z80 interrupt system but if the user application wishes to rely on HBIOS functionality then it must adhere to the HBIOS framework for managing interupts. Alternatively, if the user appliction has no need for the HBIOS then it may use its own custom code for handling interrupts. In that case, a hard reset, rather than an HBIOS warm start, would be necessary to return control to RomWBW.","title":"User Application"},{"location":"Applications/#cpm-applications-rom-based-disk-based","text":"There now follows a more detailed guide to using the small suite of custom applications included with RomWBW. In general, these applications are operating system agnostic \u2013 they run under any of the included operating systems. However, they all require RomWBW \u2013 they are not generic CP/M applications. Most of the applications are custom written for RomWBW. However, some are standard CP/M applications that have been adapted to run under RomWBW (e.g. XM/XModem). The applications are generally matched to the version of RomWBW they are distributed with. So, if you upgrade the version of RomWBW in your system ROM, you will want to copy the corresponding applications to any storage devices you are using. Most of the applications are included on the RomWBW ROM disk, so they are easy to access. The applications are also included with all of the operating system disk images provided with RomWBW. So, a simple way to ensure you have matching applications is to write the disk images onto your disk media when upgrading your ROM. Of course, this will destroy any existing data on your disk media, so don\u2019t do this if you are saving any data on the media. Most of the applications are included as source code in the RomWBW distribution and are built during the normal build process. The source code is found in the Source/Apps directory of the distribution. The binary executable applications are found in the Binary/Apps directory. The table below clarifies where each of the applications may be found. It is not an exhaustive list, with further applications existing on both the ROM-based and disk-based versions of CP/M. All of the Applications included within RomWBW may be found within the Binary/Apps directory. Application ROM Disk Boot Disks ASSIGN Yes Yes BBCBASIC No Yes CLRDIR Yes Yes COPYSL No Yes CPUSPD Yes Yes FAT No Yes FDISK80 Yes Yes FDU Yes Yes FLASH Yes Yes FORMAT Yes Yes HTALK Yes Yes MODE Yes Yes REBOOT Yes Yes RTC Yes Yes SURVEY Yes Yes SYSCOPY Yes Yes TALK Yes Yes TBASIC No Yes TIMER Yes Yes TUNE No Yes VGMPLAY No Yes WDATE No Yes XM Yes Yes ZMD No Yes ZMP No Yes All of the CP/M applications may be found in the RomWBW Binary/Apps directory and a user may copy those they need to their own customized disk/slice. Independently of whether the CP/M system was started from ROM or a boot disk, such as a floppy disk or a slice on a CF or uSD memory card, applications may be located on and executed from either the ROM-disk itself or from other media. There are multiple disk images available for CP/M (eg floppy, legacy hard-disk and new hard-disk formats) and they all contain essentially the same set of applications. There are particular advantages for each method of booting into CP/M. ROM-based CP/M: A clean and reliable copy of CP/M with no possibility of corruption No additional hardware required Fast to boot Rolled forward with new releases of RomWBW Disk-based CP/M: Greater capacity allows for a larger number of applications Allows for user-customisation of applications available Allows individual disks to be tailored to a particular purpose, eg word processor For systems starting CP/M from a disk created from an image file, there are a small number of additional applications stored in the USER 2 area of the disk. These applications do not form part of CP/M, but rather are small utilities used for test purposes during develpment work. They may, or may not, fuction correctly with any given hardware or software configuration. Documentation for these untilities is very limited, though the source files maybe found in the /Source folder. Note that these utiltites are not available when starting CP/M from the ROM image or from a floppy disk. A number of the CP/M applications available are described in more detail in the following sections, each with an indication as to whether that application may be found on the ROM-disk, a boot-disk, or both.","title":"CP/M Applications - ROM-Based & Disk-Based"},{"location":"Applications/#assign","text":"ASSIGN ROM-based Yes Disk-based Yes RomWBW includes a flexible mechanism for associating the operating system drive letters (A: - P:) to the physical devices in the system. Drive letter assignments can be changed on a running operating system without rebooting. The ASSIGN command facilitates this by allowing you to display, assign, reassign, or remove the drive letter assignments.","title":"ASSIGN"},{"location":"Applications/#syntax","text":"ASSIGN /? ASSIGN /L ASSIGN = ASSIGN ASSIGN [ ],... ASSIGN =[ :[ ]],... ASSIGN = ,... ASSIGN /B='*''*'['*' '*'['*' '*'...]]","title":"Syntax"},{"location":"Applications/#usage_1","text":"ASSIGN /? will display brief command usage and version information. ASSIGN /L will display a list of all the devices available to be used in drive assignments in the running system. The devices listed may or may not contain media. Although some device types support the use of slices, the list does not indicate this. ASSIGN A: just specifying the drive letter will display the assignment for the drive letter ASSIGN with no parameters will list all of the current drive assignments.","title":"Usage"},{"location":"Applications/#usage-specific","text":"The following describes how to assign drive specifically by identifing each drive by its unique device and slice id\u2019s ASSIGN will display the assignment for the specific drive For example, ASSIGN C: will display the assignment for drive C:. ASSIGN = [: ] will assign (or reassign) a drive letter to a new device and (optionally) slice. If no slice is specified, then slice 0 is assumed. For example, ASSIGN C:=IDE0 will assign drive letter C: to device IDE0, slice 0. ASSIGN D:=IDE0:3 will assign drive letter D: to device IDE0 slice 3. The ASSIGN command will not allow you to specify a slice (other than zero) for devices that do not support slices. A slice should only be specified for hard disk devices (SD, IDE, PPIDE). Floppy disk drives and RAM/ROM drives do not have slices. ASSIGN = can be used to remove the assignment from a drive letter. So, ASSIGN E:= will remove the association of drive letter E: from any previous device. ASSIGN = is used to swap the assignments of two drive letters. For example, ASSIGN C:=D: will swap the device assignments of C: and D:. The ASSIGN command supports \u201cstacking\u201d of instructions. For example, ASSIGN C:=IDE0:0,D:=IDE0:1,E:= will assign C: and D: to the first two slices of IDE 0 and will unassign E:. When the command runs it will echo the resultant assignments to the console to confirm its actions. It will also display the remaining space available in disk buffers.","title":"Usage (Specific)"},{"location":"Applications/#usage-bulk","text":"The following describes how to assign drives in bulk without having to specify the identifiers of each drive being mapped. Instead bulk mode has a predefined set options (identified by single letter) which will map drives. Bulk mode works by assigning drives sequentially starting at A: until all drives are used, or there are no more options to process. Each option will typically map between 0 and N drives depending on the option and the available hardware in your system. ASSIGN /B= \u2026 will perform bulk assignment . The following options will assign a small number of devices, typically you would place at beginning of an option list. Option Name Description Assigned B Boot The boot device 1 A RAM Ram drive 0,1 O ROM Rom drive 0,1 F Floppy All floppy devices, with/without media 0,1,2,.. P Preserve Skip and preserve the next drive assignment 1 X Exclude Un-assign / Exclude the next drive 1 A drive e.g. RAM, ROM, FLOPPY can only be assigned if it exists. if you system doesn\u2019t have the hardware that supports the device, then no devices will be assigned, and the next option will be processed. B assigns the boot device. If used the B oot drive should typically be assigned first. P will not make any changes to the next drive, it will skip over it. While the X option will un-assign the next drive, leaving a gap. The remaining options will fill drives mostly to end, from hard drive slices, generally choose 1 of the following: Option Name Description Assigned S Slices Assign slices from boot hard drive \u2026max H Hard Drive Assign slices evenly from all hard drives \u2026max L Legacy HD Assign slices from all hard drives (legacy) 6,\u2026max Z Exclude All Un-assign all remaining drives \u2026max S lices assignment will map all remaining drives to slices from the boot device. If I have other hard drives present these will not be mapped by this option. e.g. ASSIGN /B=BAOS Will first assign drives A:(Boot), B:(RAM), C:(ROM) this leaves 13 drives which will be assigned to slices from the boot hard drive (D: thru P:), leaving no unused drives. \u2019H\u2019ard drive assignment will attempt to fill all remaining drive letters by splitting the number of drives remaining evenly across all. e.g. ASSIGN /B=BAOH Will first assign drives A:(Boot), B:(RAM), C:(ROM) this leaves 13 drives available. If I have 3 hard disks then (13/3) = 4 slices from each hard drive will be assigned to drives (D: thru O:), leaving a single unused drive (P:). L egacy hard drive assignment is identical to how the startup hard disk assignment works. ie. Attempt to assign up to 8 hard drives split across hard drives detected at boot. e.g. ASSIGN /B=BAOL Will first assign drives A:(Boot), B:(RAM), C:(ROM) . If I have 3 hard disks then (8/3) = 2 slices from each hard drive will be assigned to drives (D: thru I:), leaving 7 unused drives (J: thru P:).","title":"Usage (Bulk)"},{"location":"Applications/#notes_1","text":"If the ASSIGN command encounters any rule violations or errors, it will abort with an error and none of the drive assignments will be implemented. In other words, the command is atomic and will either completely succeed or completely fail. All assigned drives utilize disk buffer space from a limited pool. The ASSIGN command will display the amount of buffer space remaining after an assign command is executed. Buffer space is freed if a drive is unassigned. If the total assignments exceed the available disk buffer space available, the command will abort with an error message. The ASSIGN command does not check to see if the device and slice being assigned actually contains readable media. If the assigned device has no media, you will receive an I/O error when you attempt to use the drive letter. The ASSIGN command does not check that the media is large enough to support the slice you specify. In other words, you could potentially assign a drive letter to a slice that is beyond the end of the media in a device. In this case, subsequent attempts to use that drive letter will result in an I/O error. Additionally, the ASSIGN command does not check to see if the slice specified refers to an area on your media that is occupied by other data (such as a FAT filesystem). You will not be allowed to assign multiple drive letters to a single device and slice. In other words, only one drive letter may refer to a single filesystem at a time. Attempts to assign a duplicate drive letter will fail and display an error. If you wish to assign a different drive letter to a device/unit/slice, unassign the existing drive letter first. Drive letter A: must always be assigned to a device and slice. The ASSIGN command will enforce this. The changes made by this command are not permanent. The assignments will persist through a warm start, but when you reboot your system, all drive letters will return to their default assignments. A SUBMIT batch file can be used to setup desired drive assignments automatically at boot. Be aware that this command will allow you to reassign or remove the assignment of your system drive letter. This can cause your operating system to fail and force you to reboot. The ASSIGN command does not prevent you from assigning a drive letter to a slice that does not fit on the physical media. However, any subsequent attempt to refer to that drive letter will result in an immediate OS error of \u201cno disk\u201d. Refer to \u201cHard Disk Capacity\u201d in the RomWBW User Guide for a discussion of the exact number of slices that will fit on a specific physical disk size. This command is particularly sensitive to being matched to the appropriate version of the RomWBW ROM you are using. Be very careful to keep all copies of ASSIGN.COM up to date with your ROM. Additionally, the ASSIGN command must be able to adjust to CP/M 2.2 vs. CP/M 3. If you utilize an RSX that modifies the BDOS version returned, you are likely to have serious problems. In this case, be sure to use ASSIGN prior to loading the RSX or after it is unloaded.","title":"Notes"},{"location":"Applications/#etymology","text":"The ASSIGN command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#bbcbasic-bbc-basic","text":"BBCBASIC ROM-based No Disk-based Yes BBC BASIC is an interpreted version of the BASIC programming language originally developed by Acorn Computers for the 6502 CPU. Compared to other BASIC implementations, BBC BASIC adds structured programming as well as a built-in Z80 assembler.","title":"BBCBASIC (BBC BASIC)"},{"location":"Applications/#syntax_1","text":"BBCBASIC [ \\ ]","title":"Syntax"},{"location":"Applications/#usage_2","text":"The full documentation for BBC BASIC (Z80) is found online at https://www.bbcbasic.co.uk/bbcbasic/mancpm/index.html .","title":"Usage"},{"location":"Applications/#notes_2","text":"The cursor and screen management assumes the use of an ANSI/VT-100 terminal which is generally correct for RomWBW. Support for a hardware system timer is also implemented. If your system does not have a hardware timer, the TIME function will always return 0 and the timeout parameter of the INKEY(n) function will not be observed (will never timeout).","title":"Notes"},{"location":"Applications/#etymology_1","text":"This is a RomWBW HBIOS adaptation of BBCBASIC v5.00 by R.T.Russell. This implementation was adapted from the source code found at https://github.com/rtrussell/BBCZ80 . The adaptation to RomWBW was minimal and includes: VT100 terminal control TIME function","title":"Etymology"},{"location":"Applications/#clrdir-clear-directory","text":"CLRDIR ROM-based Yes Disk-based Yes The CLRDIR command is used to initialise the directory area of a drive.","title":"CLRDIR (Clear Directory)"},{"location":"Applications/#syntax_2","text":"CLRDIR ","title":"Syntax"},{"location":"Applications/#usage_3","text":"CLRDIR will initialise the directory area of the specified drive. The drive may take any form - eg floppy disk, hard-disk, CF, uSD etc. The use of FDISK80 to reserve space, or slices, for CP/M use as drives will not initialise the directory areas of those slices. The resultant directory areas will contain garbage left over from a previous use of the disk (or media) and using them in this state with CP/M will very likely lead to failed or corrupted data storage. Use CLRDIR to initialise the directory properly. FDU will initialise the directory of a floppy disk as part of the formatting process and so CLRDIR is unnecessary for a floppy disk. CLRDIR is, therefore, primarily used with other types such as hard-disk, CF and uSD. The CLRDIR command may also be used to effectively \u2018reformat\u2019 a used disk by reinitialising its directory area and effectively making it blank again. Use CLRDIR with caution as changes made to disks by CLRDIR cannot be undone.","title":"Usage"},{"location":"Applications/#notes_3","text":"If CLRDIR is used on disk containing data then the directory area will be reinitialised and the data previously stored will be lost.","title":"Notes"},{"location":"Applications/#cpuspd-cpu-speed","text":"CPUSPD ROM-based Yes Disk-based Yes The CPUSPD application is used to change the running speed and wait states of a RomWBW system. It can also be used to invoke a warm or cold reboot of the system. The functionality is highly dependent on the capabilities of your system.","title":"CPUSPD (CPU Speed)"},{"location":"Applications/#syntax_3","text":"CPUSPD [ [,[ ][,[ ]]] CPUSPD (W)armBoot CPUSPD (C)oldBoot is one of (H)alf, (F)ull, (D)ouble, or (Q)uad. is a number specifying the desired memory wait states. is a number specifying the desired I/O wait states.","title":"Syntax"},{"location":"Applications/#usage_4","text":"Entering CPUSPD with no parameters will display the current CPU speed and wait state information of the running system. Wait state information is not available for all systems. To modify the running speed of a system, you can specify the * * parameter. To modify either or both of the wait states, you can enter the desired number. Either or both of the wait state parameters may be omitted and the current wait state settings will remain in effect.","title":"Usage"},{"location":"Applications/#notes_4","text":"The ability to modify the running speed and wait states of a system varies widely depending on the hardware capabilities and the HBIOS configuration settings. Note that it is frequently impossible to tell if a system is capable of dynamic speed changes. This function makes the changes blindly. If an attempt is made to change the speed of a system that is definitely incapable of doing so, then an error result is returned. Z180-based systems will be able to adjust their CPU speed depending on the specific variant of the Z180 chip being used: Z180 Variant Capability Z80180 (original) Half Z8S180 Rev. K Half, Full Z8S180 Rev. N Half, Full, Double SBC and MBC systems may be able to change their CPU speed if the hardware supports it and it is enabled in the HBIOS configuration. The CPUSPD command makes no attempt to ensure that the new CPU speed will actually work on the current hardware. Setting a CPU speed that exceeds the capabilities of the system will result in unstable operation or a system stall. In the case of Z180 CPUs, it is frequently necessary to add memory wait states when increasing the CPU speed. Some peripherals are dependent on the CPU speed. For example, the Z180 ASCI baud rate and system timer are derived from the CPU speed. The CPUSPD application will attempt to adjust these peripherals for correct operation after modifying the CPU speed. However, in some cases this may not be possible. The baud rate of ASCI ports have a limited set of divisors. If there is no satisfactory divisor to retain the existing baud rate under the new CPU speed, then the baud rate of the ASCI port(s) will be affected.","title":"Notes"},{"location":"Applications/#etymology_2","text":"The CPUSPD application was custom written for RomWBW. All of the hardware interface code is specific to RomWBW and the application will not operate correctly on non-RomWBW systems. The source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#copysl-copy-slice","text":"COPYSL ROM-based No Disk-based Yes The purpose of this utility is to allow the copying of whole disk slices from one disk slice to another slice This tool is only supported by RomWBW HBIOS, it uses HDIOS for all its disk IO. UNA UBIOS is not supported by this tool. This tool is running on CP/M 2.2 or 3.0 and has access to full 64kb of RAM, with a minimum of 48kb TPA This tool only works with hard disk devices, other media types like floppy, are not supported at this time. This tool works across different hard disk device types, even of different physical type Both hd1k and hd512 are fully supported, however copying from one layout type to the other is not supported. During operation data is copied in a single read/write pass, data is not verified by default. If there is a write error, it will be reported, and operation will stop.","title":"COPYSL (Copy Slice)"},{"location":"Applications/#syntax_4","text":"This tool operates at the disk level via RomWBW, thus all disk identifiers are in the RomWBW \\.\\ format. The syntax (similar to copy) for the command is: COPYSL \\ [ . \\ ] = \\ [ . \\ ] [ / \\ ] E.g. COPYSL 3.3=2.10 /U Means copy from slice 10 on disk 2, onto disk 3 slice 3. This is in unattended mode, so you will not be asked to confirm the copy operation.","title":"Syntax"},{"location":"Applications/#options","text":"F - Full disk copy. Copies the complete disk slice, all sectors. U - Unattended. Will complete copy without confirmation from the user. V - Verify. Does an additional read and verify after write.","title":"Options"},{"location":"Applications/#usage_5","text":"When run COPYSL will perform command line argument validation and display an error if they are illegal. Also any disk IO errors will cause COPYSL to exit. When specifying slice number(s) a check is made that the slice number is valid, i.e. not too large that it would extend past the end of the partition (hd1k), or the end of the media (hd512). For hd512 a check is also performed to ensure that the slice would not extend into the first defined partition. The copy operation will be faster if the source disk has been formatted with the CP/M file system, since during copy the CP/M directory is scanned, and unused blocks are not copied. If a filesystem is not found, (or the /F option is chosen) all data is copied. Verification (if option chosen) will do an aditional read (after write) and compare the data read matches what was written. This compare is only on every 32\u2019nd byte. This is done for efficiency. During copy dots \u201c.\u201d will be displayed to indicate progress of the copy. Each \u201c.\u201d represents 16 kBytes of data. Each line of \u201c.\u201d \u2019s is 1 mBytes.","title":"Usage"},{"location":"Applications/#notes_5","text":"This tool has been tested on both SD and CF media types and with hd1k and hd512 formatted media. You cannot copy slices between different hard disk formats (hd512 and hd1k) because the slices are incompatible.","title":"Notes"},{"location":"Applications/#etymology_3","text":"The COPYSL application was custom written for RomWBW and contributed by Mark Pruden.","title":"Etymology"},{"location":"Applications/#fat-fat-utility","text":"FAT ROM-based Yes Disk-based Yes The operating systems included with RomWBW do not have any native ability to access MS-DOS FAT filesystems. The FAT application can be used overcome this. It will allow you to transfer files between CP/M and FAT filesystems (wildcards supported). It can also erase files, format, and list directories of FAT filesystems.","title":"FAT (FAT Utility)"},{"location":"Applications/#syntax_5","text":"FAT DIR FAT COPY FAT REN FAT DEL [|] FAT MD FAT FORMAT is a FAT path , are FAT or CP/M filenames , are FAT filenames is a FAT filename is a FAT directory name is a RomWBW disk unit number CP/M filespec: :FILENAME.EXT ( is CP/M drive letter A-P) FAT filespec: :/DIR/FILENAME.EXT ( is RomWBW disk unit #)","title":"Syntax"},{"location":"Applications/#usage_6","text":"The FAT application determines whether you are referring to a CP/M filesystem or a FAT filesystem based on the way you specify the file or path. If the file or path is prefixed with a number (n:), then it is assumed this is a FAT filesystem reference and is referring to the FAT filesystem on RomWBW disk unit \u2018n\u2019. Otherwise, the file specification is assumed to be a normal CP/M file specification. If you wanted to list the directory of the FAT filesystem on RomWBW disk unit 2, you would use FAT DIR 2: . If you only wanted to see the \u201c.TXT\u201d files, you would use FAT DIR 2:*.TXT . If you wanted to copy all of the files on CP/M drive B: to the FAT filesystem on RomWBW disk unit 4, you would use the command FAT COPY B:*.* 4: If you wanted to copy the files to the \u201cFOO\u201d directory, then you would use FAT COPY B:*.* 4:\\FOO . To copy files in the opposite direction, you just reverse the parameters. To rename the file \u201cXXX.DAT\u201d to \u201cYYY.DAT\u201d on a FAT filesystem, you could use a command like \u201cFAT REN 2:XXX.DAT 2:YYY.DAT\u201d. To delete a file \u201cXXX.DAT\u201d on a FAT filesystem in directory \u201cFOO\u201d, you would use a command like FAT DEL 2:\\FOO\\XXX.DAT . To make a directory called \u201cFOO2\u201d on a FAT filesystem, you would use a command line FAT MD 2:\\FOO2 . To format the filesystem on a FAT partition, you would use a command like FAT FORMAT 2: . Use this with caution because it will destroy all data on any pre-existing FAT filesystem on disk unit 2.","title":"Usage"},{"location":"Applications/#notes_6","text":"Partitioned or non-partitioned media is handled automatically. A floppy drive is a good example of a non-partitioned FAT filesystem and will be recognized. Larger media will typically have a partition table which will be recognized by the application to find the FAT filesystem. Although RomWBW-style CP/M media does not know anything about partition tables, it is entirely possible to have media that has both CP/M and FAT file systems on it. This is accomplished by creating a FAT filesystem on the media that starts on a track beyond the last track used by CP/M. Each CP/M slice can occupy up to 8MB. So, make sure to start your FAT partition beyond (slice count) * 9MB. The application infers whether you are attempting to reference a FAT or CP/M filesystem via the drive specifier (char before \u2018:\u2019). A numeric drive character specifies the HBIOS disk unit number for FAT access. An alpha (A-P) character indicates a CP/M file system access targeting the specified drive letter. If there is no drive character specified, the current CP/M filesystem and current CP/M drive is assumed. For example: 2:README.TXT refers to FAT file \u201cREADME.TXT\u201d on disk unit #2 C:README.TXT refers to CP/M file \u201cREADME.TXT\u201d on CP/M drive C README.TXT refers to CP/M file \u201cREADME.TXT\u201d on the current CP/M drive Files with SYS, HIDDEN, or R/O only attributes are not given any special treatment. Such files are found and processed like any other file. However, any attempt to write to a read-only file will fail and the application will abort. It is not currently possible to reference CP/M user areas other than the current user. To copy files to alternate user areas, you must switch to the desired user number first or use an additional step to copy the file to the desired user area. Accessing FAT filesystems on a floppy requires the use of RomWBW HBIOS v2.9.1-pre.13 or greater. Only the first 8 RomWBW disk units (0-7) can be referenced. Files written are not verified. Wildcard matching in FAT filesystems is a bit unusual as implemented by FatFs. See FatFs documentation.","title":"Notes"},{"location":"Applications/#etymology_4","text":"The FAT application is an original RomWBW work, but utilizes the FsFat library for all of the FAT filesystem work. This application is written in C and requires SDCC to compile. As such it is not part of the RomWBW build process. However, the full project and source code is found in the FAT GitHub Repository .","title":"Etymology"},{"location":"Applications/#known-issues","text":"CP/M (and workalike) OSes have significant restrictions on filename characters. The FAT application will block any attempt to create a file on the CP/M filesystem containing any of these prohibited characters: < > . , ; : ? * [ ] |/ \\ The operation will be aborted with \u201c Error: Invalid Path Name \u201d if such a filename character is encountered. Since MS-DOS does allow some of these characters, you can have issues when copying files from MS-DOS to CP/M if the MS-DOS filenames use these characters. Unfortunately, FAT is not yet smart enough to substitute illegal characters with legal ones. So, you will need to clean the filenames before trying to copy them to CP/M. The FAT application does try to detect the scenario where you are copying a file to itself. However, this detection is not perfect and can corrupt a file if it occurs. Be careful to avoid this.","title":"Known Issues"},{"location":"Applications/#fdisk80","text":"FDISK80 ROM-based Yes Disk-based Yes FDISK80 allows you to create and manage traditional partitions on your hard disk media. Depending on the hard disk format and features you are using, RomWBW may need hard disk partitions defined. Please refer to the RomWBW User Guide for more information on the use of partitions within RomWBW. It is very important to understand that RomWBW slices are completely different from disk partitions. This application is provided by John Coffman. The primary documentation is in the file \u201cFDisk Manual.pdf\u201d found in the Doc directory of the RomWBW distribution.","title":"FDISK80"},{"location":"Applications/#usage_7","text":"FDISK80 is an interactive application. At startup it will ask you for the disk unit that you want to partition. When your RomWBW system boots, it will display a table with the disk unit numbers. Use the disk unit numbers from that table to enter the desired disk unit to partition. FDISK80 operates very much like other FDISK disk partitioning applications. Please refer to the file called \u201cFDisk Manual.pdf\u201d in the Doc directory of the RomWBW distribution for further instructions. If \u2018slices\u2019 for CP/M have been created using FDISK80 , then these will need to have their directory areas initialised properly using CLRDIR . Failure to do this will likely result in corrupted data. There is also more information on using FAT partitions with RomWBW in the RomWBW User Guide document in the Doc directory of the distribution.","title":"Usage"},{"location":"Applications/#notes_7","text":"Hard disk partition tables allow a maximum of 1024 cylinders when defining partitions. However, RomWBW uses exclusively Logical Block Addressing (LBA) which does not have this limitation. When defining partitions is usually best to define the start and size of of the partition using bytes or sectors.","title":"Notes"},{"location":"Applications/#etymology_5","text":"The source for this application was provided directly by John Coffman. It is a C program and requires a build environment that includes the SDCC compiler. As such, it is not included in the RomWBW build process, only the binary executable is included. Please contact John Coffman if you would like a copy of the source.","title":"Etymology"},{"location":"Applications/#fdu-floppy-disk-utility","text":"FDU ROM-based Yes Disk-based Yes The FDU application is a Floppy Disk Utility that provides functions to format and test floppy disk media.","title":"FDU (Floppy Disk Utility)"},{"location":"Applications/#syntax_6","text":"FDU","title":"Syntax"},{"location":"Applications/#usage_8","text":"This application has an interactive user interface. At startup, you will be prompted to select the floppy interface hardware in your system. Following this, you will see the main menu of the program with many functions to manage floppy disk drives. The primary documentation for this application is in a file called \u201cFDU.txt\u201d in the Doc directory of the RomWBW distribution. Please consult this file for usage information.","title":"Usage"},{"location":"Applications/#notes_8","text":"This application interfaces directly to the floppy hardware in your system. It does not use the RomWBW HBIOS. This means that even if your system is not configured for floppy drives, you can still use FDU to test your floppy drives and format floppy media. This also means it is critical that you choose the correct hardware interface from the initial selection when starting the application.","title":"Notes"},{"location":"Applications/#etymology_6","text":"The FDU command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#flash-flash-eeprom","text":"FLASH ROM-based Yes Disk-based Yes Most of the hardware platforms that run RomWBW support the use of EEPROMs \u2013 Electronically Erasable Programmable ROMs. The FLASH application can be used to reprogram such ROMS in-situ (in-place), thus making it possible to upgrade ROMs without a programmer or even removing the ROM from your system. This application is provided by Will Sowerbutts.","title":"FLASH (Flash EEPROM)"},{"location":"Applications/#syntax_7","text":"FLASH READ [options] FLASH VERIFY [options] FLASH WRITE [options] is the filename of the ROM image file FLASH4 will auto-detect most parameters so additional options should not normally be required. Options: /V : Enable verbose output (one line per sector) /P or /PARTIAL : Allow flashing a large ROM from a smaller image file /ROM : Allow read-only use of unknown chip types /Z180DMA : Force Z180 DMA engine /UNABIOS : Force UNA BIOS bank switching /ROMWBW : Force RomWBW (v2.6+) bank switching /ROMWBWOLD : Force RomWBW (v2.5 and earlier) bank switching /P112 : Force P112 bank switching /N8VEMSBC : Force N8VEM SBC (v1, v2), Zeta (v1) SBC bank switching","title":"Syntax"},{"location":"Applications/#usage_9","text":"To program your EEPROM ROM chip, first transfer the file to your RomWBW system. Then use the command FLASH WRITE * `*. The application will auto-detect the type of EEPROM chip you have, program it, and verify it. You can use the FLASH READ form of the command to read the ROM image from your system into a file. This is useful if you want to save a copy of your current ROM before reprogramming it. Although FLASH WRITE automatically performs a verification, you can manually perform a verification function with the FLASH VERIFY form of the command. The author\u2019s documentation for the application is found in the RomWBW distribution in the Doc/Contrib directory.","title":"Usage"},{"location":"Applications/#notes_9","text":"The application supports a significant number of EEPROM parts. It should automatically detect your part. If it does not recognize your chip, make sure that you do not have a write protect jumper set \u2013 this jumper can prevent the ROM chip from being recognized. Reprogramming a ROM chip in-place is inherently dangerous. If anything goes wrong, you will be left with a non-functional system and no ability to run the FLASH application again. Use this application with caution and be prepared to use a hardware ROM programmer to restore your system if needed.","title":"Notes"},{"location":"Applications/#etymology_7","text":"This application was written and provided by Will Sowerbutts. He provides it in binary format and is included in the RomWBW distribution as a binary file. The source code for this application can be found at the FLASH4 GitHub repository .","title":"Etymology"},{"location":"Applications/#format","text":"FORMAT ROM-based Yes Disk-based Yes This application is just a placeholder for a future version that will make it simpler to format media including floppy disks.","title":"FORMAT"},{"location":"Applications/#syntax_8","text":"FORMAT","title":"Syntax"},{"location":"Applications/#notes_10","text":"This application currently just displays a few lines of information briefly instructing a user how to format media. It performs no actual function beyond this display currently.","title":"Notes"},{"location":"Applications/#etymology_8","text":"The FORMAT command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#htalk-hbios-talk","text":"HTALK ROM-based Yes Disk-based Yes HTALK is a variation of the TALK utility, but it works directly against HBIOS Character Units.","title":"HTALK (HBIOS Talk)"},{"location":"Applications/#syntax_9","text":"HTALK COMn:","title":"Syntax"},{"location":"Applications/#usage_10","text":"HTALK operates at the HBIOS level. The parameter to TALK refers to a HBIOS character unit. Upon execution all characters typed at the console will be sent to the device specified and all characters received by the specified device will be echoed on the console. Press Control+Z on the console to terminate the application.","title":"Usage"},{"location":"Applications/#notes_11","text":"","title":"Notes"},{"location":"Applications/#etymology_9","text":"The TALK command was created and donated to RomWBW by Tom Plano. It is an original product designed specifically for RomWBW.","title":"Etymology"},{"location":"Applications/#mode","text":"MODE ROM-based Yes Disk-based Yes The MODE command allows you to adjust the operating characteristics such as baud rate, data bits, stop bits, and parity bits of serial ports dynamically.","title":"MODE"},{"location":"Applications/#syntax_10","text":"MODE /? MODE COM : [ [, [, [, ]]]] [/P] /? displays command usage and version information is the character device unit number is numerical baudrate is (N)one, (O)dd, (E)ven, (M)ark, or (S)pace is number of data bits, typically 7 or 8 is number of stop bits, typically 1 or 2 /P prompts user prior to setting new configuration","title":"Syntax"},{"location":"Applications/#usage_11","text":"MODE /? will display basic command usage and version information. MODE with no parameters will list all devices and their current configuration. MODE < n > will display the current configuration of the specified character device unit. MODE COM : [ [, [, [, ]]]] [/P] requests that the specified configuration be set on the character device unit. You can use commas with no values to leave some values unchanged. As an example, MODE COM0: 9600,,,2 will setup character device unit 0 for 9600 baud and 2 stop bits while leaving data bits and stop bits as is. Appending /P in a command specifying a new configuration will cause the terminal output to pause and wait for the user to press a key. This allows the user to change the local terminal setup before continuing.","title":"Usage"},{"location":"Applications/#notes_12","text":"Specified baud rate and line characteristics must be supported by the serial unit. Any parameters not specified will remain unchanged. Changes are not persisted and will revert to system defaults at next system boot. Not all character devices support all MODE options. Some devices (notably ASCI devices) have limited baud rate divisors. An attempt to set a baud rate that the device cannot support will fail with an error message.","title":"Notes"},{"location":"Applications/#etymology_10","text":"The MODE command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#reboot","text":"REBOOT ROM-based Yes Disk-based Yes The REBOOT application is used to restart a running system from an operating system prompt. It can invoke either a warm or cold restart via command line switches.","title":"REBOOT"},{"location":"Applications/#syntax_11","text":"REBOOT /W REBOOT /C REBOOT /? /C initiates a cold restart /W initiates a warm restart /? displays command line usage","title":"Syntax"},{"location":"Applications/#usage_12","text":"Entering REBOOT with no parameters will display the usage and version information. Use /C or /W to immediately initiate a cold or warm restart.","title":"Usage"},{"location":"Applications/#notes_13","text":"A warm restart just returns to the Boot Loader menu. A cold restart will reinitialize the system as though power had been recycled.","title":"Notes"},{"location":"Applications/#etymology_11","text":"The REBOOT application was custom written for RomWBW by MartinR. All of the hardware interface code is specific to RomWBW and the application will not operate correctly on non-RomWBW systems. The source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#rtc-real-time-clock","text":"RTC ROM-based Yes Disk-based yes Many RomWBW systems provide real time clock hardware. The RTC application is a simple, interactive program allowing you to display and set the time and registers of the RTC.","title":"RTC (Real Time Clock)"},{"location":"Applications/#syntax_12","text":"RTC","title":"Syntax"},{"location":"Applications/#usage_13","text":"After startup, the application provides the following options: Option Function E)xit will terminate the application. T)ime will display the time as read from the RTC hardware. st(A)rt will restart the clock running if it is stopped. S)et will program the RTC clock with the date/time previously entered using the I)nit option. R)aw will read the minute/second of the RTC clock iteratively every time the space key is pressed. Press enter to end. L)oop will read the full date/time of the RTC clock iteratively every time the space key is pressed. Press enter to end. C)harge will enable the battery charging function of the RTC. N)ocharge will disable the battery charging function of the RTC. D)elay allows you to test the built-in timing delay in the program. It is not unusual for it to be wrong. I)nit allows you to enter a date/time value for subsequent programming of the RTC using the S)et option. G)et allows you to read the value of a non-volatile register in the RTC. P)ut allows you to write the value of a non-volatile register in the RTC. B)oot will reboot your system. H)elp displays brief help.","title":"Usage"},{"location":"Applications/#notes_14","text":"When using Get and Put options, the register number to read/write is entered in hex. The non-volatile ram register numbers are 0x20-0x3F. When entering values, you must enter exactly two hex characters. The backspace key is not supported. You do not use enter after entering the two hex characters. Yes, this should be improved. The RTC application interacts directly with the RTC hardware bypassing HBIOS.","title":"Notes"},{"location":"Applications/#etymology_12","text":"The RTC application was originally written by Andrew Lynch as part of the original ECB SBC board development. It has since been modified to support most of the hardware variations included with RomWBW.","title":"Etymology"},{"location":"Applications/#slabel-slice-label","text":"SLABEL ROM-based No Disk-based Yes Display or change the label of a disk slice. The label applied is only used as informational purposes, displayed by RomWBW when an OS is booted. It has no correlation with any OS volume label scheme that may exist. i.e. It does not affect the CP/M 3 disk label as applied by the SET command","title":"SLABEL (Slice Label)"},{"location":"Applications/#syntax_13","text":"SLABEL [unit.slice=label] [/?] unit.slice the disk unit and slice number to apply the new label to. This is in the same format as when booting the system to a disk label is the new disk label to apply to the disk","title":"Syntax"},{"location":"Applications/#usage_14","text":"SLABEL with no arguments will list All existing labels across All disks SLABEL 2.5=MYDRIVE will set the disk label of the 6th slice of disk unit 2 SLABEL /? (or other unrecognised parameters) will display a usage message.","title":"Usage"},{"location":"Applications/#notes_15","text":"There is no capability to update a label onto media that currently does not have existing media information in the third sector, typically this means only bootable media. This will only display labels for the first 64 slices of any device. Slices higher than this are currently ignored. Only bootable RomWBW disk images have a label, which is defined by the OS which is booted. i.e. NZ-COM has a label of \u201cZSDOS 1.1\u201d since that is the booted OS. Prior to RomWBW 3.5 all disk images were defined with the label \u201cUnlabeled\u201d.","title":"Notes"},{"location":"Applications/#etymology_13","text":"The SLABEL application was custom written for RomWBW and contributed by Mark Pruden.","title":"Etymology"},{"location":"Applications/#survey","text":"SURVEY ROM-based Yes Disk-based Yes The SURVEY command interrogates the system for information on disk usage, memory usage and I/O ports used, and reports it to the user.","title":"SURVEY"},{"location":"Applications/#syntax_14","text":"The SURVEY command takes no arguments. SURVEY","title":"Syntax"},{"location":"Applications/#usage_15","text":"The results presented by SURVEY include: Information about any drives, within the first eight (ie A: to H:), which have been logged by the system. This includes: the total number of files; the storage capacity occupied by those files; and the capacity remaining on that drive. Information about the the 64KByte CP/M memory map, which is shown diagramatically, and includes: locations and sizes of the TPA (Transient Program Area), CP/M\u2019s CCP (Console Command Processor),and BDOS (Basic Disk Operating System). The addresses of active CPU I/O ports.","title":"Usage"},{"location":"Applications/#notes_16","text":"The mechanism by which SURVEY discovers I/O ports is very conservative and therefore the list returned may not be exhaustive. In particular, it may fail to discover ports that are \u2018write-only\u2019.","title":"Notes"},{"location":"Applications/#syscopy-system-copy","text":"SYSCOPY ROM-based Yes Disk-based Yes To make disk media bootable, you must write a system boot image onto the system tracks of the of the media. The SYSCOPY allows you to read or write the system boot image of disk media.","title":"SYSCOPY (System Copy)"},{"location":"Applications/#syntax_15","text":"SYSCOPY = is the drive to receive the operating system image or alternatively a filename to save the operating system image is the drive containing an operating system image or alternatively a filename containing the system image to be placed on the destination","title":"Syntax"},{"location":"Applications/#usage_16","text":"Both and can refer to either a drive letter or a file. If a drive letter is specified, the system boot image will be read or written to the system tracks of the drive. If a filename is specified, the system boot image will be read or written to the specified filename. SYSCOPY C:=ZSYS.SYS will read a system boot image from the file ZSYS.SYS and write it onto the system tracks of drive C:. SYSCOPY A:OS.SYS=C: will capture the system boot image from the system tracks of drive C: and store it in the file A:OS.SYS. SYSCOPY D:=C: will copy the system tracks from drive C: onto the system tracks of drive D:.","title":"Usage"},{"location":"Applications/#notes_17","text":"The RomWBW ROM disk contains files with the system boot image for Z-System and CP/M 2.2. These files are called CPM.SYS and ZSYS.SYS respectively. These files can be used as the source of a SYSCOPY command to make a disk bootable with the corresponding operating system. CP/M 3 uses a two phase boot process. To make a CP/M 3 drive bootable, you need to put \u201cCPMLDR.SYS\u201d on the boot tracks of the disk and be sure that the drive also contains the \u201cCPM.SYS\u201d file. The \u201cCPMLDR.SYS\u201d file is not included on the ROM disk, but is found on the CP/M 3 disk image. ZPM3 is similar to CP/M 3. You also put \u201cCPMLDR.SYS\u201d on the system tracks of the drive to make it bootable. The ZPM3 operating system is in the file called \u201cCPM3.SYS\u201d on the ZPM3 disk image. It may seem confusing that ZPM3 is in the file called CPM3.SYS, but it is normal for ZPM3. For the purposes of booting an operating system, each disk slice is considered its own operating system. Each slice can be made bootable with its own system tracks. SYSCOPY uses drive letters to specify where to read/write the system boot images. However, at startup, the boot loaded will require you to enter the actual disk device and slice to boot from. So, you need to be careful to pay attention to the device and slice that is assigned to a drive letter so you will know what to enter at the boot loader prompt. By way of explanation, the boot loader does not know about drive letters because the operating system is not loaded yet. If you want to put a boot system image on a device and slice that is not currently assigned to a drive letter, you will need to assign a drive letter first. Not all disk formats include space for system tracks. Such disk formats cannot contains a system boot image and, therefore, cannot be made bootable. The best example of such disk formats are the ROM and RAM disks. To maximize usable file space on these drives, they do not have system tracks. Obviously, ROM operating system is supported by choosing a ROM operating system at the boot loader prompt. Any attempt to write a system boot image to disk media with no system tracks will cause SYSCOPY to fail with an error message. The system boot images are paired with the ROM version in your system. So, you must take care to update the system tracks of any bootable disk when you upgrade your ROM firmware. The system boot images are not tied to specific hardware configurations. System boot images and operating systems provided with RomWBW will work with any supported RomWBW platform or hardware as long as they are the same version as the RomWBW firmware.","title":"Notes"},{"location":"Applications/#etymology_14","text":"The SYSCOPY command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#talk","text":"TALK ROM-based Yes Disk-based Yes It is sometimes useful to direct your console input/output to a designated serial port. For example, if you were to connect a modem to your second serial port, you might want to connect directly to it and have everything you type sent to it and everything it sends be shown on your console. The TALK application does this.","title":"TALK"},{"location":"Applications/#syntax_16","text":"TALK [TTY:|CRT:|BAT:UC1:]","title":"Syntax"},{"location":"Applications/#usage_17","text":"TALK operates at the operating system level (not HBIOS). The parameter to TALK refers to logical CP/M serial devices. Upon execution all characters typed at the console will be sent to the device specified and all characters received by the specified device will be echoed on the console. Press Control+Z on the console to terminate the application.","title":"Usage"},{"location":"Applications/#notes_18","text":"This application is designed for CP/M 2.2 or Z-System. Use on later operating systems such as CP/M 3 is not supported.","title":"Notes"},{"location":"Applications/#etymology_15","text":"The TALK command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#tbasic-tasty-basic","text":"TBASIC ROM-based No Disk-based Yes Tasty Basic is a basic interpreter for CP/M and RomWBW based on the Z80 port of Palo Alto Tiny Basic.","title":"TBASIC (Tasty BASIC)"},{"location":"Applications/#syntax_17","text":"TBASIC [ \\ ]","title":"Syntax"},{"location":"Applications/#usage_18","text":"","title":"Usage"},{"location":"Applications/#notes_19","text":"Tasty Basic is provided on RomWBW as both a ROM implementation and as a CP/M application. The CP/M version should be used if you wish to save Tasty Basic files.","title":"Notes"},{"location":"Applications/#etymology_16","text":"The implementation of Tasty Basic included in RomWBW is the work of Dimitri Theulings. The primary distribution site for this work is https://github.com/dimitrit/tastybasic .","title":"Etymology"},{"location":"Applications/#timer","text":"TIMER ROM-based Yes Disk-based Yes Most RomWBW systems have a 50Hz periodic system timer. A counter is incremented every time a timer tick occurs. The TIMER application displays the value of the counter.","title":"TIMER"},{"location":"Applications/#syntax_18","text":"TIMER TIMER /? TIMER /C","title":"Syntax"},{"location":"Applications/#usage_19","text":"Use TIMER to display the current value of the counter. Use TIMER /C to display the value of the counter continuously. The display of the counter will be something like this: 13426 Ticks 268.52 Seconds The first number is the total number of ticks since system startup, where there are 50 ticks per second. The second number is the total number of seconds since system startup. Numbers are displayed in decimal format.","title":"Usage"},{"location":"Applications/#notes_20","text":"The seconds value is displayed with a fractional value which is not a an actual fraction, but rather the number of ticks past the seconds rollover. All values are in hex. The primary use of the TIMER application is to test the system timer functionality of your system. In theory, you could capture the value before and after some process you want to time.","title":"Notes"},{"location":"Applications/#etymology_17","text":"The TIMER command is an original product and the source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#tune","text":"TUNE ROM-based No Disk-based Yes If your RomWBW system has a sound card based on either an AY-3-8190 or YM2149F sound chip, you can use the TUNE application to play PT or MYM sound files. Note: TUNE will detect an AY-3-8910/YM2149 Sound Module re-gardless of whether support for it is included in the RomWBW HBIOS configuration","title":"TUNE"},{"location":"Applications/#syntax_19","text":"TUNE * * is the name of a sound file ending in .PT2, .PT3, or .MYM Option Description -MSX Force MSX port addresses A0H/A1H (no PSG detection) -RC Force RCBus port addresses D8H/D0H (no PSG detection) --HBIOS Utilise HBIOS\u2019 sound driver -DELAY Force delay mode (don\u2019t use hardware timer) +T1 Play tune an octave higher +T2 Play tune two octaves higher -T1 Play tune an octave lower -T2 Play tune two octaves lower The +t and -t options apply only to HBIOS mode operation. The -MSX , -RC , and --HBIOS options are mutually exclusive. See Notes below.","title":"Syntax"},{"location":"Applications/#usage_20","text":"The TUNE application supports PT and YM sound file formats. It determines the format of the file from the extension of the file, so your tune filenames should end in .PT2, .PT3, or .MYM. To play a sound file, just use the command and specify the file to play after the command. So, for example, TUNE ATTACK.PT2 will immediately begin playing the PT sound file \u201cATTACK.PT2\u201d.","title":"Usage"},{"location":"Applications/#notes_21","text":"The TUNE application automatically probes for compatible hardware at well known port addresses at startup. It will auto-configure itself for the hardware found. If no hardware is detected, it will abort with an error message. Some hardware (notably Why-Em-Ulator) cannot be detected due limitations of the emulation. In such cases, you can force the use of the two most common port addresses using the -MSX or -RC options. On Z180 systems, I/O wait states are added when writing to the sound chip to avoid exceeding its speed limitations. On Z80 systems, you will need to ensure that the CPU clock speed of your system does not exceed the timing limitations of your sound chip. The application probes for an active system timer and uses it to accurately pace the sound file playback. If no system timer is available, a delay loop is calculated instead. The delay loop will not be as accurate as the system timer. If the -DELAY options is specified on the command line, then the delay loop will be used regardless of whether the system has a hardware timer. This is useful if the hardware timer does not run at the 50Hz desired for sound playback. There are two modes of operation. A direct hardware interface for the AY-3-8910 or YM2149 chips, or a compatibility layer thru HBIOS supporting both the AY-3-8910 and the SN76489 chip. By default the application will attempt to interface directly to the sound chip. The optional argument --HBIOS supplied after the filename, will enable the application to use the HBIOS sound driver. The following summarizes the different modes of operation for the application: If you use TUNE with no options, it will use it\u2019s original behavior of searching for and detecting a sound chip. TUNE will play sound files directly to the PSG hardware. In this mode it does not matter if HBIOS does or does not know about the sound chip. If you use TUNE with the --HBIOS option, it will not detect a sound chip and will use the RomWBW HBIOS interface. This will only work if HBIOS was configured for the installed sound card and HBIOS detects the sound chip. If you use TUNE with -RC or -MSX , it will play tunes directly to the PSG hardware (not via HBIOS) and will bypass detection. In this mode it does not matter if HBIOS does or does not know about the sound chip. Note that the HBIOS API for sound cards is pretty good, but does not implement everything that the sound card can do. For best fidelity, use TUNE without the --HBIOS option. All RomWBW operating system boot disks include a selection of sound files in user area 3.","title":"Notes"},{"location":"Applications/#etymology_18","text":"The TUNE application was custom written for RomWBW. All of the hardware interface code is specific to RomWBW. The sound file decoding software was adapted and embedded from pre-existing sources. The YM player code is from MYMPLAY 0.4 by Lieves!Tuore and the PT player code is (c)2004-2007 S.V.Bulba vorobey@mail.khstu.ru . The source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#vgmplay-video-game-music-play","text":"VGMPLAY ROM-based No Disk-based Yes This application will allow you to play Video Game Music files. VGM files contain music samples from a range of different sound chips that were used in arcade games, game consoles and personal computer systems. Video Game Music files have a .VGM file extension and each file contains an embedded header that identifies the hardware it is intended for and also the title of the music. All RomWBW operating system boot disks include a selection of sound files in user area 3. Additional music files can be found at: VGMRIPS website PROJECT2612 website Sound files are loaded into memory for playback, so the maximum size file that can be played is around 52Kb. Sound chips currently supported are: AY-3-8190 (and equivalent YM2149) YM2612 (and equivalent YM3848) SN76489 (single chip mono and dual chip stereo) YM2151 VGMPLAY supports playback of files with multiple combinations of these chips.","title":"VGMPLAY (Video Game Music Play)"},{"location":"Applications/#syntax_20","text":"VGMPLAY is the name of a sound file ending in .VGM","title":"Syntax"},{"location":"Applications/#usage_21","text":"VGMPLAY does not automatically detect the hardware platform or sound hardware that you are using. This means a version customized for your system must be assembled before use. However, the version as distributed will work with ECB bus SBC systems. To play a sound file, just use the VGMPLAY command and specify the file to play after the command. So, for example, VGMPLAY TEDDY will load the TEDDY.VGM sound file into memory and begin playing it. Playback can be stopped by pressing a key. There may be a delay before playback stops.","title":"Usage"},{"location":"Applications/#notes_22","text":"The default build configuration for VGMPLAY is: CPU speed: Autodetected chip number port notes AY-3-8910 1st 09ah stereo AY-3-8910 2nd not set stereo YM2612 1st 0c0h stereo YM2612 2nd 0c4h stereo SN76489 1st 0c8h mono/left SN76489 2nd 0c9h mono/right YM2151 1st 0cah stereo YM2151 2nd 0cbh stereo Inconsistant, garbled or distorted playback can be an indication that your CPU clock speed is too high for your sound chip. In this case, if your platform supports speed switching, then the CPUSPD application can be used to reduce your processor speed. VGMPLAY is still under development. The source code is provided in the RomWBW distribution.","title":"Notes"},{"location":"Applications/#wdate-wbw-date","text":"WDATE ROM-based No Disk-based Yes wdate is a utility for CP/M systems that have Wayne Warthen\u2019s RomWBW firmware. It reads or sets the real-time clock, using function calls in the BIOS. It should work on any RTC device that is supported by RomWBW, including the internal interrupt-driven timer that is is available on some systems. wdate differs from the rtc.com utility that is provided with the RomWBW version of CP/M in that it only gets and sets the date/time. rtc.com can also manipulate the nonvolatile RAM in certain clock devices, and modify the charge controller. However, wdate is (I would argue) easier to use, as it takes its input from the command line, which can be edited, and it\u2019s less fussy about the format. It doesn\u2019t require the date to be set if you only want to change the time, for example. In addition, wdate has at least some error checking. wdate displays the day-of-week and month as English text, not numbers. It calculates the day-of-week from the year, month, and day. RTC chips usually store a day-of-week value, but it\u2019s useless in this application for two reasons: first, the BIOS does not expose it. Second, there is no universally-accepted way to interpret it (which day does the week start on? Is \u20180\u2019 a valid day of the week?)","title":"WDATE (WBW DATE)"},{"location":"Applications/#syntax_21","text":"WDATE WDATE WDATE WDATE ","title":"Syntax"},{"location":"Applications/#usage_22","text":"A> wdate Saturday 27 May 13:14:39 2023 With no arguments, displays the current date and time. A> wdate hr min With two arguments, sets the time in hours and minutes, without changing date or seconds A> wdate hr min sec With three arguments, sets the time in hours, minutes, and seconds, without changing date A> wdate year month day hr min sec With six arguments, sets date and time. All numbers are one or two digits. The two-digit year starts at 2000. A> wdate /? Show a summary of the command-line usage.","title":"Usage"},{"location":"Applications/#notes_23","text":"I\u2019ve tested this utility with the DS1302 clock board designed by Ed Brindly, and on the interrupt-driven timer built into my Z180 board. However, it does not interact with hardware, only BIOS; I would expect it to work with other hardware. wdate checks for the non-existence of RomWBW, and also for failing operations on the RTC. It will display the terse \u201cNo RTC\u201d message in both cases. The RomWBW functions that manipulate the date and time operate on BCD numbers, as RTC chips themselves usually do. wdate works in decimal, so that it can check that the user input makes sense. A substantial part of the program\u2019s code is taken up by number format conversion and range checking.","title":"Notes"},{"location":"Applications/#etymology_19","text":"The WDATE application was written and contributed by Kevin Boone. The source code is available on GitHub at https://github.com/kevinboone/wdate-cpm .","title":"Etymology"},{"location":"Applications/#xm-x-modem","text":"XM ROM-based Yes Disk-based Yes An adaptation of Ward Christensen\u2019s X-Modem protocol for transferring files between systems using a serial port.","title":"XM (X-Modem)"},{"location":"Applications/#syntax_22","text":"XM S XM SK XM L XM LK XM R The following may be added to the action codes: | S : Send a file | L : Send a file from a library | R : Receive a file | K : Use 1K blocksize (send operations) | C : Force use of checksum (receive operations) | X : Force 128-byte protocol (receive operations) | 0 - 9 : Specifies HBIOS character unit for transfers is the name of a file to send or receive is the name of a library (.lbr) to extract a file to send For example, the following command will receive a file using checksums on HBIOS character unit 3 and will name the received file MYFILE.TXT . XM RC3 MYFILE.TXT","title":"Syntax"},{"location":"Applications/#usage_23","text":"To transfer a file from your host computer to your RomWBW computer, do the following: Enter one of the XM receive commands specifying the name you want to give to the received file. On your host computer select a file to send and initiate the XModem send operation. To transfer a file from your RomWBW computer to your host computer, do the following: Enter one of the XM send commands specifying the name of the file to be sent. On your host computer, specify the name to assign to the received file and initiate and XModem receive operation. Please refer to the documentation of your host computer\u2019s terminal emulation software for specific instructions on how to use XModem.","title":"Usage"},{"location":"Applications/#notes_24","text":"The XModem adaptation that comes with RomWBW will default to using the current HBIOS console port for transfers. Note that if you change your console port at the OS level (e.g., STAT CON:=UC1:), this does not change the HBIOS console. XM attempts to determine the best way to drive the serial port based on your hardware configuration. When possible, it will bypass the HBIOS for faster operation. However, in many cases, it will use HBIOS so that flow control can be used. XM is dependent on a reliable communications channel. You must ensure that the serial port can be serviced fast enough by either using a baud rate that is low enough or ensuring that hardware flow control is fully functional (end to end).","title":"Notes"},{"location":"Applications/#etymology_20","text":"The XM application provided in RomWBW is an adaptation of a pre-existing XModem application. Based on the source code comments, it was originally adapted from Ward Christensen\u2019s MODEM2 by Keith Petersen and is labeled version 12.5. The original source of the application was found on the Walnut Creek CD-ROM and is called XMDM125.ARK dated 7/15/86. The actual application is virtually untouched in the RomWBW adaptation. The majority of the work was in the modem driver which was enhanced to detect the hardware being used and dynamically choose the appropriate driver. The source code is provided in the RomWBW distribution.","title":"Etymology"},{"location":"Applications/#zmd-z-modem","text":"ZMD ROM-based No Disk-based Yes An adaptation of Robert Kramer\u2019s Remote CP/M File Transfer Program with support for XModem and YModem transfers. NOTE : ZMD does not do ZModem transfers. The Z in ZMD refers to Z-System compatibility.","title":"ZMD (Z-Modem)"},{"location":"Applications/#syntax_23","text":"ZMD \\\\\\ [ \\ ] where \\ can be: S - Send file from BBS SP - Send from private area A - Send ARK/ARC/LBR member R - Receive file from YOU RP - Receive in private area RW - Receive without description(s) F - Displays available upload space \\ can be: X - Xmodem 128 byte blocks (CRC) C - Xmodem 128 byte blocks (Checksum) K - Ymodem 1024 byte blocks (CRC only) and \\ can specify a single digit (0-9) that specifies the RomWBW Character Unit to use for the file transfer.","title":"Syntax"},{"location":"Applications/#usage_24","text":"To transfer a file from your host computer to your RomWBW computer, do the following: Enter one of the ZMD receive commands specifying the name you want to give to the received file (no filename required for ZModem transfers). On your host computer select a file to send and initiate an XModem or YModem send operation. To transfer a file from your RomWBW computer to your host computer, do the following: Enter one of the ZMD send commands specifying the name of the file to be sent. On your host computer, specify the name to assign to the received file and initiate an XModem or YModem receive operation. Please refer to the documentation of your host computer\u2019s terminal emulation software for specific instructions on how to use XModem.","title":"Usage"},{"location":"Applications/#notes_25","text":"The ZMP adaptation that comes with RomWBW will default to using the current HBIOS console port for transfers. Note that if you change your console port at the OS level (e.g., STAT CON:=UC1:), this does not change the HBIOS console. ZMP attempts to determine the best way to drive the serial port based on your hardware configuration. When possible, it will bypass the HBIOS for faster operation. However, in many cases, it will use HBIOS so that flow control can be used. ZMP is dependent on a reliable communications channel. You must ensure that the serial port can be serviced fast enough by either using a baud rate that is low enough or ensuring that hardware flow control is fully functional (end to end).","title":"Notes"},{"location":"Applications/#etymology_21","text":"ZMD v1.50 was produced by Robert Kramer. The RomWBW adaptation just uses the RomWBW HBIOS serial API.","title":"Etymology"},{"location":"Applications/#zmp-z-modem-program","text":"ZMP ROM-based No Disk-based Yes ZMP is a terminal program for interacting with a modem attached to your system. It includes X/Y/ZModem file transfer protocols. An actual modem is not required, but you must have a port for ZMP to use that is independent of the console running ZMP .","title":"ZMP (Z-Modem Program)"},{"location":"Applications/#syntax_24","text":"ZMD [\\] \\ can specify a single digit (0-9) indicating the RomWBW Character Unit to use for the modem port.","title":"Syntax"},{"location":"Applications/#usage_25","text":"Refer to the file ZMP.DOC found on all disk images that include the ZMP application.","title":"Usage"},{"location":"Applications/#notes_26","text":"ZMP requires access to multiple overlay and configuration files to run. It will look for these on the default driver and user area. Depending the operating system used, you may be able to set up a search path and locate these files in other locations. The files used by ZMP are: ZMP.HLP ZMP.DOC ZMP.CFG ZMP.FON ZMXFER.OVR ZMTERM.OVR ZMINIT.OVR ZMCONFIG.OVR The ZMP console is always the active OS console. If no \\ is specified on the command line, ZMP will default to using HBIOS Character Unit 1 as the modem port. Take care to avoid using the same HBIOS Character Unit as both the console and the modem or various strangeness will occur. ZMP is a full screen application and is configured to use ANSI/VT-100 screen control. ZMP does not support the range of port configurations provided by RomWBW. The RomWBW adaptation of ZMP ignores the port configuration options within ZMP . Instead, you should configure the HBIOS Character Unit using the RomWBW MODE command before launching ZMP . ZMP is written in C. As a result, file transfers will be noticeably slower than other assembly language file transfer tools.","title":"Notes"},{"location":"Applications/#etymology_22","text":"ZMP was produced by Ron Murray and was based on HMODEM II. Wayne Hortensius updated the source to compile with the latest version of Hi-Tech C and implemented a few enhancements. The RomWBW overlay was developed by Phil Summers.","title":"Etymology"},{"location":"Catalog/","text":"RomWBW Disk Catalog \\ Version 3.6 \\ Mark Pruden \\& Mykl Orders ( ) \\ 31 May 2025 RomWBW Distribution File Catalog This document is a reference to the files found on the disk media distributed with RomWBW. Specifically, RomWBW provides a set of floppy and hard disk images in the Binary directory of the distribution. The contents of these images is listed here. The files on the disk images were sourced from a variety of locations. The primary sources of these files are listed below. Note that the primary documentation for each of these sources is listed. You are strongly encouraged to refer to this documentation for more information on using the applications and files listed. This document primarily describes to contents of the hard disk images. Floppy disk images may contain a cut down (sub-set) of the files on a hard disk. This is of course to conserve disk space Note: This document received a major update in October 2024, when while still not fully complete, most of the core operating system disks should now be fully described. Sources RomWBW : RomWBW Custom Applications Documentation: RomWBW Applications.pdf These files are custom applications built exclusively to enhance the functionality of RomWBW. In some cases they are built from scratch while others are customized versions of well known CP/M tools. CPM22 : Digital Research CP/M-80 2.2 Distribution Files Documentation: CPM Manual.pdf These files are from the official Digital Research distribution of CP/M 2.2. Applications have been patched according to the DRI patch list. ZSDOS : ZSDOS 1.1 Disk Operating System Distribution Files Documentation: ZSDOS Manual.pdf These files are from the official ZSDOS 1.1 distribution. Some of the files are redistributions of applications from other sources. ZCPR : ZCPR 1.0 Command Processor Distribution Files Documentation: ZCPR Manual.pdf These files are from the ZCPR 1.0 distribution. NZCOM : NZCOM Automatic Z-System Distribution Files Documentation: NZCOM Users Manual.pdf These files are from the last official release of NZCOM. CPM3 : Digital Research CP/M 3 Distribution Files Documentation: CPM3 Users Guide.pdf , CPM3 System Guide.pdf , CPM3 Programmers Guide.pdf , CPM3 Command Summary.pdf These files are from the official Digital Research distribution of CP/M 3. Applications have been patched according to the DRI patch list. ZPM3 : Digital Research CP/M-80 2.2 Distribution Files Documentation: CPM Manual.pdf These files are from Simeon Cran\u2019s ZPM3 operating system distribution. Operating System Boot Disks RomWBW contains several ready-to-run disks, that have been adapted for RomWBW. Theses disks are bootable as is (the operating system image is already embedded in the system tracks) and can be launched from the RomWBW Loader prompt. Each Disk contains the following file File Description README.TXT Information about the Operating System CP/M 2.2 A vanilla distribution of DRI\u2019s CP/M-80 2.2 adapted for RomWBW. Floppy Disk Image: fd_cpm22.img Hard Disk Image: hd_cpm22.img Combo Disk Image: Slice 0 CP/M 2.2 OS Files These are built and provide the OS. CP/M 2.2 Typically has no boot files stored on the disk. It entirely boots from the system track The following files appear in User Area 0 File Source Description CPM.SYS RomWBW DRI CPM 2.2 Boot Image for SYSCOPY CP/M 2.2 Files The following CP/M 2.2 files were distributed by DRI with the operating system or as supplemental add-on programs. They are documented in the \u201cCP/M Manual.pdf\u201d document in the Doc/CPM directory of the Rom WBW distribution. The following files appear in User Area 0 File Description ASM.COM DRI 8080 assembler DDT.COM 8080 dynamic debugger DUMP.COM DRI type contents of file in hex ED.COM DRI line editor HELP.COM CP/M 3 derived HELP display HELP.HLP CP/M 3 derived HELP data file LIB.COM DRI object file library manager LINK.COM DRI object file linker LOAD.COM DRI loader for Intel hex files MAC.COM DRI 8080 macro assembler PIP.COM DRI periperal interchange program RMAC.COM DRI 8080 relocating macro assembler STAT.COM DRI file/disk/device info & config SUBMIT.COM DRI batch file submission tool XREF.COM DRI assembler cross reference listing utility XSUB.COM DRI batch file resident extension ZSID.COM DRI Z80 symbolic debugger NOTE: The above files are also included in the NZCOM disk image. MAC, RMAC, XREF, and ZSID are supplemental programs from DRI with separate standalone documentation which is not included in the RomWBW package (but easily found on the Internet via Google search). Additional Files File Documentation User Area OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13 ZSDOS 1.1 It contains a customized version of ZSDOS 1.1 for RomWBW. The disk is bootable as is (the operating system image is already embedded in the system tracks) and can be launched from the RomWBW Loader prompt. The starting point for the disk content was the final public release of ZSDOS which is generally available on the Internet. Floppy Disk Image: fd_zsdos.img Hard Disk Image: hd_zsdos.img Combo Disk Image: Slice 1 ZSDOS 1.1 OS Files These are built and provide the OS. ZSDOS Typically has no boot files stored on the disk. It entirely boots from the system track The following files appear in User Area 0 File Source Description ZSYS.SYS RomWBW ZSDOS Boot Image for SYSCOPY ZSDOS 1.1 Files The following files came from the official ZSDOS distribution. These are generally documented in the \u201cZSDOS Manual.pdf\u201d document in the Doc/CPM directory of the RomWBW distribution. Note: Some of the files included in the ZSDOS distribution are not listed below because they have been superseded by more recent versions listed in other sections below. The following files appear in User Area 0 File Description BGPATCH.HEX Patches BackGrounder II for ZSDOS 1.1 compatibility CLOCKS.DAT Library of clock drivers COPY.UPD Document describing updates to COPY program DATSWEEP.COM Comprehensive file management w/ date stamp awareness DSCONFIG.COM Program to configure DATSWEEP FA16.CFG ZCNFG configuration file for FILEATTR.COM FA16.DOC Documentation for FILEATTR.COM FA16A.FOR Summary Information for FILEATTR.COM FA16CFG.TXT describes configuration options for FILEATTR.COM FILEATTR.COM Set and/or display file attributes FILEDATE.COM Date/time stamping aware disk directory utility FILEDATE.CFG ZCNFG configuration fie for FILEDATE INITDIR.COM Prepare disk for P2DOS date/time stamping INITDIR.CFG ZCNFG configuration file for INITDIR LDDS.COM Load DateStamper date/time stamping resident extension LDNZT.COM Load NZT date/time stamping resident extension LDP2D.COM Load P2DOS date/time stamping resident extension PUTBG.COM Updated replacement for BackGrounder II PUTBG program PUTDS.COM Prepare disk for datestamper date/time stamping RELOG.COM Clear fixed disk login vector in ZSDOS SETTERM.COM Terminal configuration utility for DATSWEEP & DSCONFIG SETUPZST.COM Creates date/time stamping resident extensions STAMPS.DAT Library of date/time stamping modules for SETUPZST TD.COM Read and set system real-time clock TD.CFG ZCNFG Configuration file for TD.COM TERMBASE.DAT Library of terminals used by SETTERM TESTCLOK.COM Test a selected clock driver ZCAL.COM Display a small one-month calendar to the screen ZPATH.COM Set or display ZSDOS and ZCPR search paths ZSCONFIG.COM Configure features of ZSDOS operating systems ZSVSTAMP.COM Preserves file date/time stamp across modifications ZSVSTAMP.DOC Document describes the use and operation of ZSVSTAMP NOTE: The above files are also included in the NZ-COM disk image distribution Additional Files Documentation User Area CP/M 2.2 Files 0 OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 SIMH Simulator 13 NZCOM This disk contains NZ-COM, which is an implementation of the Z-System. You may also see NZ-COM referred to as ZCPR 3.4. This is a powerful replacement for CP/M 2.2 w/ full backward compatibility. NZ-COM is extremely configurable and far more powerful than DRI CP/M. It is almost mandatory that you read the NZ-COM manual to use the system effectively. Floppy Disk Image: fd_nzcom.img Hard Disk Image: hd_nzcom.img Combo Disk Image: Slice 2 NZ-COM OS Files NZ-COM is not designed to load directly from the boot tracks of a disk. Instead, it expects to be loaded from an already running OS. This disk has been configured to boot using ZSDOS with a PROFILE.SUB command file that automatically loads NZ-COM. So, NZ-COM will load completely without any intervention, but you may notice that ZSDOS loads first, then ZSDOS loads NZ-COM. The following files appear in User Area 0 File Source Description !(C)1988 NZCOM Original copyright (since placed in public domain) !NZ-COM NZCOM Software marker directory entry (empty file) !VERS--1.2H NZCOM Version marker directory entry (empty file) NZCOM.COM NZCOM Loads and launches NZ-COM system NZCOM.ENV RomWBW Z-System environment descriptor NZCOM.LBR NZCOM Library of NZCOM system modules NZCOM.ZCM RomWBW Environment descriptor (alternate format) NZCPR.LBR NZCOM Library of alternative ZCPR modules PROFILE.SUB RomWBW Command file to auto-start NZ-COM at system boot RCP.LBR NZCOM Library of alternative RCP modules STARTZCM.COM RomWBW Commands to execute after NZ-COM is launched ZRDOS.ZRL ZRDOS Relocatable version of ZRDOS BDOS module ZSDOS.ZRL ZSDOS Relocatable version of ZSDOS 1.1 BDOS module ZSYS.SYS RomWBW ZSDOS Boot Image for SYSCOPY NZ-COM Files The following files came from the official NZ-COM distribution. These are generally documented in the \u201cNZCOM Users Manual.pdf\u201d document in the Doc/CPM directory of the RomWBW distribution. NOTE: It may appear theat there are not many files, this is because most of the OS files are shared with Z3PLUS. See here for a list NZ-COM Z3PLUS OS Files The following file are in User Area 15, and where noted 10 for help files, or 14 for config files. File Description ALIAS.CMD Sample alias definitions for use with ARUNZ BGZRDS19.LBR Patch for Backgrounder II (U10) CMDRUN.COM Extended Command Processor (copied from ARUNZ) MKZCM.COM Create/update NZ-COM load environment NZBLITZ.COM Rapid coldboot of complete NZ-COM system image NZBLTZ14.CFG ZCNFG configuration file for NZBLITZ. (U14) NZBLTZ14.HZP Help file for NZBLITZ (U10) NZ-DBASE.INF dBase II application note regarding SUBMIT files (U10) PUBLIC.COM Specify ZRDOS public directories/user areas RELEASE.NOT Update information on NZ-COM (U10) SUB.COM Enhanced version of SUBMIT Additional Files Documentation User Area Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13 CP/M 2.2 Files 15 ZSDOS 1.1 Files 15, 14, 10 NZ-COM Z3PLUS OS Files 15, 14, 10 OS General Files 15, 14, 10 General Purpose Applications 15, 10 CP/M 3 A vanilla distribution of DRI\u2019s CP/M 3, also known as CP/M Plus adapted for RomWBW. Floppy Disk Image: fd_cpm3.img Hard Disk Image: hd_cpm3.img Combo Disk Image: Slice 3 CP/M 3 OS Files The following files appear in User Area 0 File Source Description BDOS3.SPR CPM3 DRI CPM+ GENCPM input file for the non-banked BDOS BIOS3.SPR RomWBW DRI CPM+ GENCPM input file for non-banked BIOS BNKBIOS3.SPR RomWBW DRI CPM+ GENCPM input file for banked BIOS BNKBDOS3.SPR CPM3 DRI CPM+ GENCPM input file for banked BDOS CCP.COM CPM3 DRI CPM+ Console Command Processor CPM3.SYS RomWBW DRI CPM+ (non-banked) memory image CPM3RES.SYS RomWBW DRI CPM+ (non-banked) memory image CPM3BNK.SYS RomWBW DRI CPM+ (banked) memory image CPM3FIX.PAT CPM3 DRI CPM+ patch list CPMLDR.COM RomWBW DRI CPM 3.0 Boot Loader Application CPMLDR.SYS RomWBW DRI CPM 3.0 Boot Loader for SYSCOPY GENBNK.DAT RomWBW GENCPM config data file (banked) GENRES.DAT RomWBW GENCPM config data file (non-banked) GENCPM.DAT RomWBW Current GENCPM config data file GENCPM.COM CPM3 DRI CPM+ Create a memory image of CPM3.SYS RESBDOS3.SPR CPM3 DRI CPM+ GENCPM input file for resident BDOS CP/M 3 Files The following CP/M 3 files were distributed by DRI with the operating system or as supplemental add-on programs. They are documented in the \u201cCPM3 Command Summary.pdf\u201d document in the Doc/CPM directory of the Rom WBW distribution. The following files appear in User Area 0 File Description DATE.COM DRI CPM+ Set or display the date and time DEVICE.COM DRI CPM+ Assign logical devices with one or more physical devices DIR.COM DRI CPM+ DIR with options DUMP.COM DRI type contents of disk file in hex ED.COM DRI CPM+ line editor ERASE.COM DRI CPM+ file deletion GENCOM.COM DRI CPM+ Generate special COM file with attached RSX files GET.COM DRI CPM+ Temporarily get console input form a disk file HELP.COM DRI CPM+ Display information on how to use commands HELP.HLP DRI CPM+ Databse of help information for HELP.COM HEXCOM.COM DRI CPM+ Create a COM file from a hex file (replaces LOAD.COM) INITDIR.COM DRI CPM+ Initializes a disk to allow time and date stamping LIB.COM DRI object file library manager LINK.COM DRI object file linker MAC.COM DRI 8080 macro assembler PATCH.COM DRI CPM+ Display or install patch to the CPM+ system or command files PIP.COM DRI CPM+ Periperal Interchange Program PUT.COM DIR CPM+ Temporarily redirect printer or console output to a disk file RENAME.COM DRI CPM+ Rename a file RMAC.COM DRI 8080 relocating macro assembler SAVE.COM DRI CPM+ Copy the contents of memory to a file SET.COM DIR CPM+ Set file options SETDEF.COM DIR CPM+ Set system options including the drive search chain SHOW.COM DIR CPM+ Display disk and drive statistics SUBMIT.COM DRI CPM+ batch processor TYPE.COM DRI CPM+ Display the contents of an ASCII character file XREF.COM DRI assembler cross reference listing utility ZSID.COM DRI Z80 symbolic instruction debugger NOTE: The above files are also included in the ZPM3 and Z3PLUS disk images. ZSID is a supplemental program from DRI with separate standalone documentation which is not included in the RomWBW package (but easily found on the Internet via Google search). Additional Files Documentation User Area OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13 Z3PLUS Z3PLUS OS Files Z3PLUS is not designed to load directly from the boot tracks of a disk. Instead, it expects to be loaded from an already running OS. This disk has been configured to boot using CP/M 3 with a PROFILE.SUB command file that automatically loads Z3PLUS. So, Z3PLUS will load completely without any intervention, but you may notice that CP/M 3 loads first. The following Z3PLUS files appear in User Area 0 File Source Description !(C)1988 Z3PLUS Original copyright (since placed in public domain) !VERS--1.02F Z3PLUS Version marker directory entry (empty file) !Z3PLUS Z3PLUS Software marker directory entry (empty file) NAMES.NDR RomWBW Default Directory Names loaded at boot RCP.LBR Z3PLUS Library of alternative RCP modules PROFILE.SUB RomWBW Command file to auto-start Z3PLUS at system boot STARTZ3P.COM RomWBW Commands to execute after Z3PLUS is launched Z3PLUS.COM Z3PLUS Loads and launches Z3PLUS system Z3PLUS.LBR Z3PLUS Library of Z3PLUS system modules Z3PLUS Files The following files came from the official Z3PLUS distribution. These are generally documented in the \u201cZ3PLUS Users Manual.pdf\u201d document in the Doc/CPM directory of the RomWBW distribution. Note: NOTE: It may appear theat there are not many files, this is because most of the OS files are shared with NZCOM. See here for a list NZ-COM Z3PLUS OS Files The following file are in User Area 15, and where noted 10 for help files. File Description ALIAS.CMD Sample alias definitions for use with ARUNZ PATCHSK.SUB Patch smartkey II v. 1.0A (U10) PATCH4SK.HEX Patch smartkey II v. 1.0A - Hex File (U10) RELEASE.NOT Update information on Z3PLUS (U10) Additional Files Documentation User Area Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13 CP/M 3 Files 15 NZ-COM Z3PLUS OS Files 15, 14, 10 OS General Files 15, 14, 10 General Purpose Applications 15, 10 ZPM3 This is a generic ZPM3 adaptation for RomWBW. Floppy Disk Image: fd_zpm3.img Hard Disk Image: hd_zpm3.img Combo Disk Image: Slice 4 Per ZPM3 standard, files are distributed across different user areas depending on their usage. Normal applications are in user area 15. Help files in user area 10. Configuration files in user area 14. ZPM3 OS Files The following files appear in User Area 0 File Source Description BNKBIOS3.SPR RomWBW Banked BIOS BNKBDOS3.SPR ZPM3 Banked BDOS CPM3.SYS RomWBW ZPM3 system file (See Note) GENCPM.DAT RomWBW DRI CPM+ System generation tool data file HELP.HLP ZPM3 System Help File MAKEDOS.COM ZPM3 Utility to overlay your system file with ZPM3 STARTZPM.COM RomWBW Commands to execute after ZPM is launched RESBDOS3.SPR ZPM3 Resident BDOS ZCCP.COM ZPM3 ZCCP replacement for CCP.COM ZINSTAL.ZPM ZPM3 Segment containing environment information ZPMLDR.COM RomWBW ZPM3 Boot Loader Application ZPMLDR.SYS RomWBW ZPM3 Boot Loader for SYSCOPY NOTE: Currently GENCPM.COM is located in User Area 15 NOTE: The ZPM3 system file is called CPM3.SYS. This is the ZPM3 default configuration. It is done to maximize compatibility with CP/M 3. Either ZPMLDR or CPMLDR can be used to launch ZPM3. CPMLDR is equivalent to ZPMLDR. The following files appear in User Area 15 File Source Description AUTOTOG.COM ZPM3 CLRHIST.COM ZPM3 SETZ3.COM ZPM3 ZPM3 Files This is a generic ZPM3 adaptation for RomWBW. File User Area Description ARUNZ.COM 15 Alias-RUN-forZ-System command alias exec (v1.1 Type3) DEV.COM 15 DISKINFO.COM 15 ZCPR utility which gives information about your disks. DU.COM 15 ERASE.CFG 14 GENCPM.COM 15 DRI CPM3 Utility to Create a memory image of CPM3.SYS GOTO.COM 15 HELPC15.CFG 14 IF.COM 15 Extended flow control tester for FCP (v1.6 Type 3) IF.HLP 10 LOADSEG.COM 15 ZCCP Utility to Load RSXes, TCAPs and Named Directory files. MENU.HLP 10 NAMES.NDR 15 Default Directory Names loaded at boot REMOVE.COM 15 RSXDIR.COM 15 ZCPR Utility which displays RSXes in memory SETPATH.COM 15 used to set the command search path. VERROR.COM 15 Installs a resident error handler VLU.COM 15 Video Library Utility views or extracts files from libraries VLU.HLP 10 XREF.COM 15 ZERASE.COM 15 ZFHIST.HLP 10 ZFILER.COM 15 File management shell, with GUI. ZFILER.HLP 10 Help file for ZFILER.COM ZF11.CFG 14 ZFMACRO.HLP 10 ZHELP.COM 15 ZSHOW.COM 15 displays amount of information about your Z-System Additional Files Documentation User Area Testing Applications 2 Sample Audio Files 3 SIMH Simulator 13 CP/M 3 Files 15 OS General Files 15, 14, 10 General Purpose Applications 15, 10 QPM 2.7 The following files came from from Microcode Consulting. The official distribution files can be found on the Microcode Consulting website at [https://www.microcodeconsulting.com/z80/qpm.htm]. Also included in this image are debugz, and linkz frm the same company. This disk includes the standard DRI CP/M 2.2 files in addition to the QP/M files. QP/M generally assumes you already had DRI CP/M 2.2 prior to adding QP/M features. QPM 2.7 OS Files These are built and provide the OS. QPM Typically has no boot files stored on the disk. It entirely boots from the system track The following files appear in User Area 0 File Description QPM.SYS RomWBW configured QP/M system image (for use with SYSCOPY) The qpm.sys file and the QP/M image on the system tracks was created using QINSTALL with default settings EXCEPT for the two settings described under Notes (current drive/user storage address and TIMDAT vector). QPM 2.7 Files The following files appear in User Area 0 File Description D.COM Directory lister DBGINST.COM Configures DEBUGZ debugger DEBUGZ.COM Symbolic debugger for Z80 DEBUGZ.HLP Symbolic debugger help file DHORIZ.COM Version of directory lister for horizontal file sorting HELLO.QPM Text file with QP/M version information LZ.COM Z80 Linking Loader QBACKUP.COM Data backup application QINSTALL.COM QP/M installer / configurator QPATCH.COM Patches (customizes) a few QP/M applications QPIP.COM QP/M enhanced version of CP/M 2.2 PIP application QPMCLK.MAC Example of QP/M clock assembler routine QPMCMDS.TXT Brief summary of QP/M commands QPMUTILS.TXT Brief summary of QP/M utilities QSTAMP.COM Initializes disk for date/time stamping QSTAMPV.COM Initializes disk for date/time stamping (vertical sort) QSTAMPX.COM Initializes disk for date/time stamping (horizontal sort) QSTAT.COM QP/M enhanced version of CP/M 2.2 STAT application QSUB.COM QP/M batch file submission program - Like SUBMIT QSWEEP.COM QP/M directory sweep utility QTERM.DAT Terminal control codes used by DEBUGZ QTERMS.LIB Library of available terminal definitions SETQTERM.COM Configures QTERM.DAT TDCNFG.COM Configures date/time directory display preferences There are two text files (QPMCMDS.TXT and QPMUTILS.TXT) included. These files have escape sequences imbedded in them which makes them look a little strange depending on the terminal emulation you are using. Additional Files Documentation User Area CP/M 2.2 Files 0 OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 SIMH Simulator 13 Common Disk Contents CP/NET 1.2 User area 4 contains a full implementation of the CP/NET 1.2 client provided by Doug Miller. Please refer to [https://github.com/durgadas311/cpnet-z80] for more information, complete documentation and the latest source code. Please refer to the RomWBW User Guide for instructions on installing and using these these packages. Either the MT011 RCBus module or the Duodyne Disk I/O board is required. In general, to use CP/NET on RomWBW, it is intended that you will extract the appropriate set of files into your default directory in user area 0. The following are found in /Binary/CPNET File CP/NET Version OS Hardware CPN12MT.LBR CP/NET 1.2 CP/M 2.2 RCBus w/ MT011 CPN3MT.LBR CP/NET 3 CP/M 3 RCBus w/ MT011 CPN12DUO.LBR CP/NET 1.2 CP/M 2.2 Duodyne w/ Disk I/O CPN3DUO.LBR CP/NET 3 CP/M 3 Duodyne w/ Disk I/O CPN12SER.LBR CP/NET 1.2 CP/M 2.2 RomWBW Serial Port CPN3SER.LBR CP/NET 3 CP/M 3 RomWBW Serial Port General Purpose Applications The following files are general purpose an provided in (mostly) all OS images The following files are found in /Source/Apps/* /Source/Images/Common/All /Source/TastyBasic The following files provide specific functionality enabled by RomWBW enhancements. These applications are typically documented in the \u201cRomWBW Applications.pdf\u201d document in the Doc directory of the RomWBW Distribution. File Source Description ASSIGN.COM RomWBW Assign,remove,swap drive letters of RomWBW disk slices CLRDIR.COM Max Scane Initializes the directory area of a disk COPYSL.COM M.Pruden Copy CPM Hard Disk Slices COPYSL.DOC M.Pruden Documentation for COPYSL.COM CPUSPD.COM RomWBW CPU Speed FAT.COM RomWBW MS-DOS FAT filesystem tool (list, copy, delete, format, etc.) FDISK80.COM John Coffman Hard disk partitioning tool FDU.COM RomWBW Floppy Disk Utility, Test and format floppy disks FDU.DOC RomWBW Documentation for FDU FLASH.COM Will Sowerbutts Program FLASH chips in-situ FLASH.DOC Will Sowerbutts Documentation for FLASH FORMAT.COM RomWBW Placeholder application with formatting instructions HTALK.COM Tom Plano Terminal utility talking directly to HBIOS Character Units MODE.COM RomWBW Change serial line characteristics (baud rate, etc.) REBOOT.COM MartinR Cold or Warm Boot the RomWBW System RTC.COM Andrew Lynch Test real time clock hardware on your system SURVEY.COM RomWBW Display system resources summary SYSCOPY.COM RomWBW Copy system tracks to disks (make bootable) TALK.COM RomWBW Route console I/O to & from specified serial port TIMER.COM RomWBW Test and display system timer ticks TUNE.COM RomWBW Play .PT2, .PT3, and .MYM audio files on supported hardware VGMPLAY.COM Simple player for VGM (Video Game Music) files. WDATE.COM Kevin Boone Utility to configure RTC Date. XM.COM RomWBW XModem file transfer application Then we have some more general purpose applications. In general, there is no documentation for these applications included with the RomWBW distribution. Some provide command line help themselves. Some are fairly obvious. File Source Description BBCBASIC.COM R.T.Russell BBC BASIC CP/M Version BBCBASIC.TXT R.T.Russell Help file for BBC BASIC COMPARE.COM Compare content of two files (binary) CRUNCH.COM Compress file(s) using Crunch algorithmn CRUNCH28.CFG ZCNFG configuration file for CRUNCH & UNCR DDTZ.COM Z80 debug tool (modified to use RST 6) DDTZ.DOC Documentation for DDTZ EX.COM Batch file processor (alternative to DRI SUBMIT) FIND.COM Jay Cotton Search all drives for a file () GENHEX.COM Generates an Intel Hex file from the input file LS.COM An alternative file listing to DIR LSWEEP.COM Extract and view member files of an .LBR archive MBASIC.COM Microsoft Microsoft BASIC language interpreter NULU.COM NZCOM new library utility (.LBR) management tool PMARC.COM Create or add file(s) to LHA .PMA archive PMEXT.COM Extract file(s) from .PMA/.LZH/.LHA archive RMXSUB1.COM Lars Nelson Remove XSUB1 RSX from memory SUPERSUB.COM Enhanced replacement for DRI SUBMIT SUPERSUB.DOC Documentation for SUPERSUB SYSGEN.COM DRI Copy system tracks to disks TBASIC.COM Dimitri Theulings Tasty Basic. This also exists as a Rom appication TDLBASIC.COM TDL Zapple 12K BASIC language interpreter TE.COM Ladislau Szilagyi RomWBW enhanced version of TE editor TE.DOC Ladislau Szilagyi TE Editor Documentation UNARC.COM Extract file(s) from .ARC or .ARK archive UNARC.DOC Documentation for UNARC UNCR.COM Decompress Crunched file(s). See CRUNCH.COM UNZIP.COM Lars Nelson UNZIP extracts from MS-DOS ZIP files UNZIP.DOC Documentation for UNZIP XSUB1.COM Lars Nelson Replacement for DRI XSUB ZAP.COM Interactive disk & file utility ZDE.COM Compact WordStar-like editor ZDE.DOC ZDE Documentation ZDENST.COM Installation/configuration tool for ZDE ZMRX.COM ZMTX.COM ZMD.COM R.W.K Z80 RCP/M File Transfer Program (Robert W. Kramer III) ZMP.COM ZModem communications program (dedicated port) ZMP.DOC Documentation for ZMP ZMP.HLP Help file for ZMP ZMXFER.OVR Overlay file for ZMP ZMTERM.OVR Overlay file for ZMP ZMINIT.OVR Overlay file for ZMP ZMCONFIG.OVR Overlay file for ZMP OS General Files The following files are spcific files share across several OS\u2019s. In general, there is no documentation for these applications included with the RomWBW distribution. Some provide command line help themselves. Some are fairly obvious. The following files are found in /Source/Images/Common/CPM22 /Source/Images/Common/CPM3 /Source/Images/Common/Z /Source/Images/Common/Z3 File Applicability Description ALIAS.COM Z3 Create an Alias (v1.1) ALIAS.HLP Z3 Help File for ALIAS.COM COPY.COM Z File copier with ZSDOS date stamping awareness COPY.CFG Z ZCNFG configuration file for COPY application EDITNDR.COM Z3 Edit named directory register in memory. HP-RPN.HLP Z3 Help File for ZP.COM - HP RPN Calculators HP-ZP.HLP Z3 Help File for ZP.COM - HP ZP Calculators KERCPM22.COM CPM22 Kermit communication application KERCPM3.COM CPM3 Kermit communication application LBREXT.COM Z Extract file from .LBR libraries LBREX36.CFG Z ZCNFG configuration file for LBREXT RZ.COM CPM3 Receive files with X/Y/ZModem (experimental) RZSC.FOR CPM3 Description of RZ/SZ programs SAINST.COM Z3 Install/configure SALIAS. SALIAS.COM Z3 Screen oriented alias editor. (v1.6) SAVENDR.COM Z3 Writes the named directory to disk. SDZ.COM Z3 Enhanced directory lister. SCOPY.COM Z3 Screen-oriented file copy for ZCPR3 SCOPY10.CFG Z3 ZCNFG configuration file for SCOPY SCOPY.HLP Z3 Primary help file for SCOPY SCOPY10F.HLP Z3 Secondary help file for SCOPY SZ.COM CPM3 Send files with X/Y/ZModem (experimental) TCAP.Z3T Z3 Terminal capabilities for ZCPR3 (VT100) TCSELECT.COM Z3 NZCOM Create terminal capability file (newer version) TCVIEW.COM Z3 View zcpr3 terminal capabilities UMAP.COM Z3 Shows directory usage UMAP18.CFG Z3 ZCNFG configuration file for UMAP program UNARCU1.CFG Z ZCNFG configuration file for UNARC program ZCNFG.COM Z Configuration tool for programs with .CFG files ZCNFG24.CFG Z Configuration file for ZCNFG.COM ZEX.COM Z3 A memory-based command file processor, like SUBMIT ZEX.CFG Z3 ZCNFG configuration file for ZEX program ZP.COM Z3 Screen-oriented file/disk/memory record patcher (ZAP) ZP.HLP Z3 Help File for ZP.COM ZP17.CFG Z3 Configuration file for ZP.COM ZXD.CFG Z Configuration file for ZXD.COM ZXD.COM Z Extended directory utility w/ date/time stamp support Z3LOC.COM Z3 Display info of the ZCPR3 CCP, BDOS, and BIOS Z3TCAP.LBR Z3 Database of terminal descriptions Applicability: CPM22 - Included in all CP/M 2.2 OS\u2019s (CPM2.2, ZSDOS, NZ-COM, QPM) CPM3 - Included in all CP/M 3 OS\u2019s (CPM3, Z3PLUS, ZPM3) Z - Included in All Z OS\u2019s (ZSDOS, NZ-COM, Z3PLUS, ZPM3) Z3 - Included in ZCPR3 OS\u2019s (NZ-COM, Z3PLUS, ZPM3) NZ-COM Z3PLUS OS Files The following files are specific files share across two operating systems. NZ-COM - The Automatic Z-System - Alpha Systems Z3PLUS - The Z-System for CP/M-Plus - Plu*Perfect Systems These 2 operating systems are identical in all respects, except for the underlying operating system that they run on. The following files are found in /Source/Images/Common/NZ3PLUS The following file are in User Area 15, and where noted 14 for config files. File Description ARUNZ.COM Alias-RUN-forZ-System command alias exec (v0.9u Type4) CLEDINST.COM Command line editing and history shell installer CLEDSAVE.COM Save RCP-resident command line editor history CONFIG.LBR Various configuration files for use with ZCNFG. (U14) CPSET.COM Displays/defines CRT/PRT characteristics FCP.LBR Library of alternative FCP modules FF.COM File finder utility IF.COM Extended flow control tester for FCP (v1.5 Type4) JETLDR.COM Z-System General-purpose module loader LBRHELP.COM Help file viewer for use with help file libraries (.LBR) LDIR.COM Directory lister for libraries (.LBR) LPUT.COM Puts file(s) into a library (.LBR) LSH.COM Command history shell and command line editor LSH-HELP.COM Display LSH help when LSH is running LSHINST.COM LSH configuration editor LX.COM Execute programs directly from a library (.LBR) NAME.COM Quickly add or remove a name for a single directory PATH.COM Set/display command search path PWD.COM Displays DU and Directory Names with paging TY3ERA.COM Type-3 program to erase a file TY3REN.COM Type-3 program to rename a file TY4ERA.COM Type-4 program to erase a file TY4REN.COM Type-4 program to rename a file TY4SAVE.COM Type-4 program to save memory to a file TY4SP.COM Type-4 program to display disk space VIEW.COM Quad directional file viewer XTCAP.COM Interactive Extended TCAP Installer ZERR.COM Z34 Error Handler ZF-DIM.COM ZFILER shell for dim-video terminals ZF-REV.COM ZFILER shell for reverse-video terminals ZFILER.CMD Macro script file for ZFILER ZHELP.COM (HELPC14) is an improved version of the help utility ZLT.COM File lister with support for compressed files ZSHOW.COM Display Z-System configuration information The following documentation files are in User Area 10 File Description DOCFILES.LBR Documentation and help files collected into an LBR file HLPFILES.LBR Various app help files for use with LBRHELP LSH.WZ User manual for LSH TCJ.INF Subscription information for The Computer Journal TCJ*.WZ Selected articles from The Computer Journal ZFILEB38.LZT Brief listing of Z-System support programs ZHELPERS.LZT List of volunteers who will help installing Z-System ZNODES66.LZT List of Z-Node remote access systems ZSYSTEM.IZF Information on Z-System and related products Sample Audio Files User area 3 contains sample audio files that can be played using the TUNE or VGMPLAY applications. NOTE These files are NOT present on floppy disk images The following files are found in /Binary/Apps/Tunes File File File File ATTACK.PT3 DEMO4.MYM NAMIDA.PT3 VICTORY.PT3 BACKUP.PT3 ENDING.VGM RECOLL.PT3 WICKED.PT3 BADMICE.PT3 HOWRU.PT3 SANXION.PT3 WONDER01.VGM DEMO.MYM INCHINA.VGM SHIRAKAW.VGM YEOLDE.PT3 DEMO1.MYM ITERATN.PT3 STARTDEM.VGM YEOVIL.PT3 DEMO3.MYM LOOKBACK.PT3 SYNCH.PT3 DEMO3MIX.MYM LOUBOUTN.PT3 TOSTAR.PT3 SIMH Simulator Files for use with the SIMH Simulator The following files are found in /Source/Images/Common/SIMH File Description HDIR.COM R.COM transfer files between the simulator and host file system RSETSIMH.COM \u2013 TIMER.COM \u2013 URL.COM \u2013 W.COM transfer files between the simulator and host file system Testing Applications User area 2 contains a variety of hardware testing applications. These are generally user contributed and have no documentation. These applications are frequently not compatible with all RomWBW hardware. They are included here as a convenience. If applicable, your hardware documentation should refer to them and provide usage instructions. NOTE These files are NOT present on floppy disk images The following files are found in /Binary/Apps/Test /Source/Images/Common/Test File Description 2PIOTST.COM ECB-ZILOG PERIPHERALS BOARD TEST 2 PIO\u2019s AY-TEST.COM AY-3-8910 Sound Test Program (SOUND) BANKTEST.COM Test RomWBW bank management API DMAMON.COM Verify operation of the Z80 MBC DMA board I2CLCD.COM PCF8584 HD44780 I2C LCD UTILITY I2CSCAN.COM I2C BUS SCANNER INTTEST.COM Test HBIOS interrupt API functions KBDTEST.COM test program to work with the Z80 KBDMSE board PIOMON.COM Zilog PIO Monitor & Hardware Testing Application PORTSCAN.COM Reads all ports and displays values read PPIDETST.COM PPI IDE test for checkout of all 8255 IDE drives PS2INFO.COM PS/2 Keyboard/Mouse Information Utility RAMTEST.COM RAM_TEST_PROGRAM RTCDS7.COM PCF8584/DS1307 I2C DATE AND TIME UTILITY (I2C) RZ.COM Receive Zmodem disassembly of CP/M 3 binaries SOUND.COM RomWBW HBIOS Sound Device Test Tool (SOUND) SROM.COM I2C Serial ROM Read/Write Utility (I2C) SZ.COM Send Zmodem is a disassembly of CP/M 3 binaries TESTH8P.COM H8 Panel Test TSTDSKNG.COM DSKY NEXT GENERATION TEST APPLICATION VDCONLY.COM COLOR VDU TEST VDCTEST.COM COLOR VDU TEST ZEXALL.COM Z80 Instruction Set Exerciser ZEXDOC.COM Z80 Instruction Set Exerciser And The following CPU Tests - Which are probably originally from this source. [https://github.com/raxoft/z80test] File Description Z80CCF.COM tests flags after executing CCF after each instruction. Z80DOC.COM tests registers, but only officially documented flags Z80DOCF.COM Z80FLAGS.COM tests flags, ignores registers. Z80FULL.COM tests flags and registers Z80MPTR.COM tests flags after executing BIT N,(HL) after each instruction Application Standalone Disks Aztec C Compiler Floppy Disk Image: fd_aztecc.img Hard Disk Image: hd_aztecc.img Aztec C is a discontinued programming language for a variety of platforms including MS-DOS, Apple II DOS 3.3 and PRoDOS, Commodore 64, Macintosh and Amiga. This disk contains the CP/M version of that compiler. A cross-compiler for MS-DOS or Windows XP is also available. For full documentation, see [https://www.aztecmuseum.ca] The user manual is available in the Doc/Language directory Aztec_C_1.06_User_Manual_Mar84.pdf The following files are found in /Source/Images/d_aztec File Description \u2013 \u2013 NOTE : The above is incomplete Microsoft Basic Compiler Floppy Disk Image: fd_bascomp.img Hard Disk Image: hd_bascomp.img The Microsoft BASIC Compiler is a highly efficient programming tool that converts BASIC programs from BASIC source code into machine code. This provides much faster BASIC program execution than has previously been possible. It can make programs run an average of 3 to 10 times faster than programs run under BASIC-80. Compiled programs can be up to 30 times faster than interpreted programs if maximum use of integer variables is made. View BASCOM.HLP included in the disk image using HELP.COM for documentation. The following files are found in /Source/Images/d_bascomp File Description \u2013 \u2013 NOTE : The above is incomplete Cowgol Compiler Floppy Disk Image: fd_cowgol.img Hard Disk Image: hd_cowgol.img The Cowgol 2.0 compiler and related tools. These files were provided by Ladislau Szilagyi and were sourced from his GitHub repository at [https://github.com/Laci1953/Cowgol_on_CP_M]. The primary distribution site for Cowgol 2.0 is at [https://github.com/davidgiven/cowgol]. The user manual is available in the Doc/Language directory Cowgol Language.pdf The following files are found in /Source/Images/d_cowgol File Description ADVENT.COW Adventure game program source ADVENT.SUB Submit file to build ADVENT ADVENT?.TXT Adventure game program resource ADVMAIN.COW Adventure game program source RAND.AS Assembler Library File COWBE.COM COWFE.COM RomWBW specific (Memory Manage) version COWLINK.COM DYNMSORT.COW demonstrates a sort algorithm DYNMSORT.SUB Submit file to build DYNMSORT HEXDUMP.COW a simple hex dump utility, purely a Cowgol HEXDUMP.SUB Submit file to build HEXDUMP HMERGES.C C Library File XRND.AS Assembler Library File - - NOTE : The above is incomplete Microsoft Fortran 80 (Fortran) Floppy Disk Image: fd_fortran.img Hard Disk Image: hd_fortran.img This is Microsoft\u2019s implementation of the FORTRAN scientific-oriented high level programming language. It was one of their early core languages developed for the 8-bit computers and later brought to the 8086 and IBM PC. In 1993 Microsoft rebranded the product as Microsoft Fortran Powerstation. (Note: -80 refers to the 8080/Z80 platform, not the language specification version) The user manual is available in the Doc/Language directory, Microsoft_FORTRAN-80_Users_Manual_1977.pdf The following files are found in /Source/Images/d_fortram File Description \u2013 \u2013 NOTE : The above is incomplete Games Floppy Disk Image: fd_games.img Hard Disk Image: hd_games.img This disk contains several games for CP/M including the Infocom games Zork 1 through 3, Planetfall and Hitchhiker\u2019s Guide to the Galaxy. Nemesis and Dungeon Master is a Rogue-like game released in 1981. It is playable on a text terminal using ASCII graphics to represent the dungeon. Only a few thousand copies of the game were ever made, making it very rare. See [http://crpgaddict.blogspot.com/2019/03/game-322-nemesis-1981.html] Colossal Cave Adventure is a CP/M port of the 1976 classic game originally written by Will Crowther for the PDP-10 mainframe. See [https://en.wikipedia.org/wiki/Colossal_Cave_Adventure] and [https://if50.substack.com/p/1976-adventure] The following files are found in /Source/Images/d_games File Description \u2013 \u2013 NOTE : The above is incomplete HI-TECH C Compiler Floppy Disk Image: fd_hitechc.img Hard Disk Image: hd_hitechc.img The HI-TECH C Compiler is a set of software which translates programs written in the C language to executable machine code programs. Versions are available which compile programs for operation under the host operating system, or which produce programs for execution in embedded systems without an operating system. This is the Mar 21, 2023 update 17 released by Tony Nicholson who currently maintains HI-TECH C at [https://github.com/agn453/HI-TECH-Z80-C] The manual is available in the Doc/Language directory, HI-TECH Z80 C Compiler Manual.txt A good blog post about the HI-TECH C Compiler is available at [https://techtinkering.com/2008/10/22/installing-the-hi-tech-z80-c-compiler-for-cpm] The following files are found in /Source/Images/d_hitechc File Description \u2013 \u2013 NOTE : The above is incomplete MSX ROMS Hard Disk Image: hd_msxroms1.img Hard Disk Image: hd_msxroms2.img The collection of MSX ROMs (2 disks) as provided by Les Bird. These ROMs are \u201crun\u201d by using the appropriate variant of Les\u2019 MSX8 ROM loader. You can download the loader binaries from [https://github.com/lesbird/MSX8]. You will need appropriate hardware to run the loader. Please review the file ROMLIST.TXT for information on the current operational status of the ROM and it\u2019s long file name/description. This disk (RomWBW slice) is not automatically included with the RomWBW \u201ccombo\u201d disk images. You can simply add it to a combo image by appending it to the end. After booting your system, you can use the ASSIGN command to map the slice to a drive letter. Refer to the RomWBW User Guide for more information on this process. The ROM files are found in /Source/Images/d_msxroms1 /Source/Images/d_msxroms2 Turbo Pascal Compiler Floppy Disk Image: fd_tpascal.img Hard Disk Image: hd_tpascal.img The Borland Turbo Pascal Compiler. Pascal is a general-purpose, high level programming language originally designed by Professor Niklaus Wirth of the Technical University of Zurich, Switzerland and named in honor of Blise Pascal, the famous French philosopher and mathematician. Turbo Pascal closely follows the definition of Standard Pascal as defined in the Pascal User Manual and Report with a few minor differences. The manual can be found in the Docs/Language directory, Turbo_Pascal_Version_3.0_Reference_Manual_1986.pdf A good overview of using Turbo Pascal in CP/M is available at [https://techtinkering.com/2013/03/05/turbo-pascal-a-great-choice-for-programming-under-cpm] The following files are found in /Source/Images/d_tpascal File Description ART.TXT Part of the Example program SA.PAS Example Program TINST.COM Installation and Configuration TINST.DTA Part of TINST TINST.MSG Part of TINST TURBO.COM The main Turbo Pascal program TURBO.MSG Part of TURBO tascal TURBO.OVR Part of TURBO tascal TURBOMSG.OVR Part of TURBO tascal WordStar 4 Floppy Disk Image: fd_ws4.img Hard Disk Image: hd_ws4.img Combo Disk Image: Slice 5 The following files are found in /Source/Images/d_ws4 File Description ANAGRAM.COM CHAPTER1.DOC CHAPTER2.DOC CHAPTER3.DOC DIARY.DOC DICTSORT.COM FIND.COM HOMONYMS.TXT HYEXCEPT.TXT HYPHEN.COM LOOKUP.COM MAINDICT.CMP MARKFIX.COM MOVEPRN.COM PATCH.LST PRINT.TST READ.ME README. REVIEW.COM RULER.DOC SAMPLE1.DOC SAMPLE2.DOC SAMPLE3.DOC SPELL.COM TABLE.DOC TEXT.DOC TW.COM WC.COM WINSTALL.COM WORDFREQ.COM WS.COM WS.OVR WSCHANGE.COM WSCHANGE.OVR WSCHHELP.OVR WSHELP.OVR WSINDEX.XCL WSMSGS.OVR WSPRINT.OVR WSSHORT.OVR Also contained on this image in User Area 1 are. File Description SAMPKEY.DOC ZDE Distribution File SAMPKEY.ZDK ZDE Distribution File SAMPKEY.ZDT ZDE Distribution File ZDE10.DOC ZDE Distribution File ZDE10.FOR ZDE Distribution File ZDE10.NEW ZDE Distribution File ZDE10.QRF ZDE Distribution File ZDE10.TOC ZDE Distribution File ZDE13.FOR ZDE Distribution File ZDE13.NEW ZDE Distribution File ZDE16.COM ZDE Distribution File ZDE16.DIR ZDE Distribution File ZDE16.FIX ZDE Distribution File ZDE16.FOR ZDE Distribution File ZDE16.NEW ZDE Distribution File ZDE16A.COM ZDE Distribution File ZDE16A.PAT ZDE Distribution File ZDENST16.COM ZDE Distribution File ZDEPROP.DOC ZDE Distribution File ZDEPROP.Z80 ZDE Distribution File ZDKCOM13.COM ZDE Distribution File ZDKCOM13.DOC ZDE Distribution File Z80ASM Macro Assembler Floppy Disk Image: fd_z80asm.img Hard Disk Image: hd_z80asm.img This disk contains 6 major components Z80ASM is a relocating macro assembler for CP/M. It takes assembly language source statements from a disk file, converts them into their binary equivalent, and stores the output in either a core-image, Intel hex format, or relocatable object file. The mnemonics recognized are those of Zilog/Mostek. The optional listing output may be sent to a disk file, the console and/or the printer, in any combination. Output files may also be generated containing cross-reference information on each symbol used. Z80ASMP (Z80ASM Plus). Referred to as the \u201cVirtual Memory\u201d version which uses disk for working storage, thus not constrained by RAM. SLR180 is a powerful relocating macro assembler for Z80 compatible CP/M systems. It takes assembly language source statements from a disk file, converts them into their binary equivalent, and stores the output in either a core-image, Intel hex format, or relocatable object file. The mnemonics recognized are those of Zilog (Z180)/Hitachi. The optional listing output may be sent to a disk file, the console and/or the printer, in any combination. Output files may also be generated containing cross-reference information on each symbol used. SLRMAC relocating macro assembler for Intel 8080 mnemonics SLRNK is a powerful linking loader for Z80-based CP/M systems. It takes relocatable binary information in either Microsoft or SLR Systems format from a disk file, resolves external and entry point references, and stores the output in memory for execution or outputs it to a disk file. SLRNKP (SLRNK Plus). Referred to as the \u201cVirtual Memory\u201d version which uses disk for working storage, thus not constrained by RAM. Z80DIS is an entirely new disassembler for Z80 based CP/M sys- tems. Z80DIS is written in TURBO PASCAL. Z80DIS generates Z80 mnemonics and prepares an assembly language file with many special features for ease of understanding the intent of the code. The program and documantation are Copyright 1985, by Kenneth Gielow, Palo Alto, CA. All rights are reserved. The manual(s) are available in the Doc/Language directory, z80asm (SLR Systems).pdf SL180 (SLR Systems 1985).pdf SLRNK (SLR Systems 1984).pdf Z80DIS User Manual (1985).pdf A run through of using the assembler is available at [https://8bitlabs.ca/Posts/2023/05/20/learning-z80-asm] And another shorter, but shows linker usage guide [https://pollmyfinger.wordpress.com/2022/01/10/modular-retro-z80-assembly-language-programming-using-slr-systems-z80asm-and-srlnk/] The following files are found in /Source/Images/d_z80asm User Area 0 - Assembler File Description 180FIG.COM Configuration utility for SLR180.COM 8080.MAC ? CONFIG.COM Configuration utility for Z80ASM.COM CONFIGP.COM Configuration utility for Z80ASMP.COM DUMP.* Sample Program MAKESYM.COM Symbol File .SYM file generation MAKESYM.DOC Documentation for MAKESYM.COM SLR180.COM HD64180 (Z180) Relocating Macro Assembler SLR180.DOC Release Notes for SLR180.COM SLRMAC.COM 8080 Relocating Macro Assembler SYNTAX.HLP Documentation basic usage for all SLR Tools SYNTAX.TXT Documentation basic usage for all SLR Tools TEST.* Sample Program Z80ASM.COM Z80 Relocating Macro Assembler Z80ASMP.COM Z80 Relocating Macro Assembler (PLUS) Z80ASM.DOC Release Notes for Z80ASM.COM User Area 1 - Linker and Library Management File Description LNKFIG.COM Configuration utility for SLRNK.COM NZLNKFIX.ZEX ? SLRIB.COM SuperLibrarian, library manager SLRNK.COM SuperLinker, the main linker tool SLRNKP.COM SuperLinker (PLUS) SLRNK.DOC Release Notes for SLRNK.COM SLRNKFIX.ZEX ? SYNTAX.HLP Documentation basic usage for all SLR Tools SYNTAX.TXT Documentation basic usage for all SLR Tools SYSSLR.REL SYSLIB (older) Library compatible with SLR VSLR.REL VLIB (older) Library compatible with SLR Z3SLR.REL Z3LIB (older) Library compatible with SLR User Area 2 - Disassembler File Description README.22 Documentation for Z80DIS Z80DIS.000 Overlay File for Z80DIS.COM Z80DIS.001 Overlay File for Z80DIS.COM Z80DIS.002 Overlay File for Z80DIS.COM Z80DIS.COM Z80DIS Disassembler main program Z80DIS22.DOC Main Documentation for Z80DIS ZDINSTAL.COM Instal and Config for Z80DIS.COM ZDINSTAL.DTA Overlay file for ZDINSTAL.COM ZDINSTAL.MSG Overlay file for ZDINSTAL.COM","title":"Catalog"},{"location":"Catalog/#romwbw-distribution-file-catalog","text":"This document is a reference to the files found on the disk media distributed with RomWBW. Specifically, RomWBW provides a set of floppy and hard disk images in the Binary directory of the distribution. The contents of these images is listed here. The files on the disk images were sourced from a variety of locations. The primary sources of these files are listed below. Note that the primary documentation for each of these sources is listed. You are strongly encouraged to refer to this documentation for more information on using the applications and files listed. This document primarily describes to contents of the hard disk images. Floppy disk images may contain a cut down (sub-set) of the files on a hard disk. This is of course to conserve disk space Note: This document received a major update in October 2024, when while still not fully complete, most of the core operating system disks should now be fully described.","title":"RomWBW Distribution File Catalog"},{"location":"Catalog/#sources","text":"RomWBW : RomWBW Custom Applications Documentation: RomWBW Applications.pdf These files are custom applications built exclusively to enhance the functionality of RomWBW. In some cases they are built from scratch while others are customized versions of well known CP/M tools. CPM22 : Digital Research CP/M-80 2.2 Distribution Files Documentation: CPM Manual.pdf These files are from the official Digital Research distribution of CP/M 2.2. Applications have been patched according to the DRI patch list. ZSDOS : ZSDOS 1.1 Disk Operating System Distribution Files Documentation: ZSDOS Manual.pdf These files are from the official ZSDOS 1.1 distribution. Some of the files are redistributions of applications from other sources. ZCPR : ZCPR 1.0 Command Processor Distribution Files Documentation: ZCPR Manual.pdf These files are from the ZCPR 1.0 distribution. NZCOM : NZCOM Automatic Z-System Distribution Files Documentation: NZCOM Users Manual.pdf These files are from the last official release of NZCOM. CPM3 : Digital Research CP/M 3 Distribution Files Documentation: CPM3 Users Guide.pdf , CPM3 System Guide.pdf , CPM3 Programmers Guide.pdf , CPM3 Command Summary.pdf These files are from the official Digital Research distribution of CP/M 3. Applications have been patched according to the DRI patch list. ZPM3 : Digital Research CP/M-80 2.2 Distribution Files Documentation: CPM Manual.pdf These files are from Simeon Cran\u2019s ZPM3 operating system distribution.","title":"Sources"},{"location":"Catalog/#operating-system-boot-disks","text":"RomWBW contains several ready-to-run disks, that have been adapted for RomWBW. Theses disks are bootable as is (the operating system image is already embedded in the system tracks) and can be launched from the RomWBW Loader prompt. Each Disk contains the following file File Description README.TXT Information about the Operating System","title":"Operating System Boot Disks"},{"location":"Catalog/#cpm-22","text":"A vanilla distribution of DRI\u2019s CP/M-80 2.2 adapted for RomWBW. Floppy Disk Image: fd_cpm22.img Hard Disk Image: hd_cpm22.img Combo Disk Image: Slice 0","title":"CP/M 2.2"},{"location":"Catalog/#cpm-22-os-files","text":"These are built and provide the OS. CP/M 2.2 Typically has no boot files stored on the disk. It entirely boots from the system track The following files appear in User Area 0 File Source Description CPM.SYS RomWBW DRI CPM 2.2 Boot Image for SYSCOPY","title":"CP/M 2.2 OS Files"},{"location":"Catalog/#cpm-22-files","text":"The following CP/M 2.2 files were distributed by DRI with the operating system or as supplemental add-on programs. They are documented in the \u201cCP/M Manual.pdf\u201d document in the Doc/CPM directory of the Rom WBW distribution. The following files appear in User Area 0 File Description ASM.COM DRI 8080 assembler DDT.COM 8080 dynamic debugger DUMP.COM DRI type contents of file in hex ED.COM DRI line editor HELP.COM CP/M 3 derived HELP display HELP.HLP CP/M 3 derived HELP data file LIB.COM DRI object file library manager LINK.COM DRI object file linker LOAD.COM DRI loader for Intel hex files MAC.COM DRI 8080 macro assembler PIP.COM DRI periperal interchange program RMAC.COM DRI 8080 relocating macro assembler STAT.COM DRI file/disk/device info & config SUBMIT.COM DRI batch file submission tool XREF.COM DRI assembler cross reference listing utility XSUB.COM DRI batch file resident extension ZSID.COM DRI Z80 symbolic debugger NOTE: The above files are also included in the NZCOM disk image. MAC, RMAC, XREF, and ZSID are supplemental programs from DRI with separate standalone documentation which is not included in the RomWBW package (but easily found on the Internet via Google search).","title":"CP/M 2.2 Files"},{"location":"Catalog/#additional-files","text":"File Documentation User Area OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13","title":"Additional Files"},{"location":"Catalog/#zsdos-11","text":"It contains a customized version of ZSDOS 1.1 for RomWBW. The disk is bootable as is (the operating system image is already embedded in the system tracks) and can be launched from the RomWBW Loader prompt. The starting point for the disk content was the final public release of ZSDOS which is generally available on the Internet. Floppy Disk Image: fd_zsdos.img Hard Disk Image: hd_zsdos.img Combo Disk Image: Slice 1","title":"ZSDOS 1.1"},{"location":"Catalog/#zsdos-11-os-files","text":"These are built and provide the OS. ZSDOS Typically has no boot files stored on the disk. It entirely boots from the system track The following files appear in User Area 0 File Source Description ZSYS.SYS RomWBW ZSDOS Boot Image for SYSCOPY","title":"ZSDOS 1.1 OS Files"},{"location":"Catalog/#zsdos-11-files","text":"The following files came from the official ZSDOS distribution. These are generally documented in the \u201cZSDOS Manual.pdf\u201d document in the Doc/CPM directory of the RomWBW distribution. Note: Some of the files included in the ZSDOS distribution are not listed below because they have been superseded by more recent versions listed in other sections below. The following files appear in User Area 0 File Description BGPATCH.HEX Patches BackGrounder II for ZSDOS 1.1 compatibility CLOCKS.DAT Library of clock drivers COPY.UPD Document describing updates to COPY program DATSWEEP.COM Comprehensive file management w/ date stamp awareness DSCONFIG.COM Program to configure DATSWEEP FA16.CFG ZCNFG configuration file for FILEATTR.COM FA16.DOC Documentation for FILEATTR.COM FA16A.FOR Summary Information for FILEATTR.COM FA16CFG.TXT describes configuration options for FILEATTR.COM FILEATTR.COM Set and/or display file attributes FILEDATE.COM Date/time stamping aware disk directory utility FILEDATE.CFG ZCNFG configuration fie for FILEDATE INITDIR.COM Prepare disk for P2DOS date/time stamping INITDIR.CFG ZCNFG configuration file for INITDIR LDDS.COM Load DateStamper date/time stamping resident extension LDNZT.COM Load NZT date/time stamping resident extension LDP2D.COM Load P2DOS date/time stamping resident extension PUTBG.COM Updated replacement for BackGrounder II PUTBG program PUTDS.COM Prepare disk for datestamper date/time stamping RELOG.COM Clear fixed disk login vector in ZSDOS SETTERM.COM Terminal configuration utility for DATSWEEP & DSCONFIG SETUPZST.COM Creates date/time stamping resident extensions STAMPS.DAT Library of date/time stamping modules for SETUPZST TD.COM Read and set system real-time clock TD.CFG ZCNFG Configuration file for TD.COM TERMBASE.DAT Library of terminals used by SETTERM TESTCLOK.COM Test a selected clock driver ZCAL.COM Display a small one-month calendar to the screen ZPATH.COM Set or display ZSDOS and ZCPR search paths ZSCONFIG.COM Configure features of ZSDOS operating systems ZSVSTAMP.COM Preserves file date/time stamp across modifications ZSVSTAMP.DOC Document describes the use and operation of ZSVSTAMP NOTE: The above files are also included in the NZ-COM disk image distribution","title":"ZSDOS 1.1 Files"},{"location":"Catalog/#additional-files_1","text":"Documentation User Area CP/M 2.2 Files 0 OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 SIMH Simulator 13","title":"Additional Files"},{"location":"Catalog/#nzcom","text":"This disk contains NZ-COM, which is an implementation of the Z-System. You may also see NZ-COM referred to as ZCPR 3.4. This is a powerful replacement for CP/M 2.2 w/ full backward compatibility. NZ-COM is extremely configurable and far more powerful than DRI CP/M. It is almost mandatory that you read the NZ-COM manual to use the system effectively. Floppy Disk Image: fd_nzcom.img Hard Disk Image: hd_nzcom.img Combo Disk Image: Slice 2","title":"NZCOM"},{"location":"Catalog/#nz-com-os-files","text":"NZ-COM is not designed to load directly from the boot tracks of a disk. Instead, it expects to be loaded from an already running OS. This disk has been configured to boot using ZSDOS with a PROFILE.SUB command file that automatically loads NZ-COM. So, NZ-COM will load completely without any intervention, but you may notice that ZSDOS loads first, then ZSDOS loads NZ-COM. The following files appear in User Area 0 File Source Description !(C)1988 NZCOM Original copyright (since placed in public domain) !NZ-COM NZCOM Software marker directory entry (empty file) !VERS--1.2H NZCOM Version marker directory entry (empty file) NZCOM.COM NZCOM Loads and launches NZ-COM system NZCOM.ENV RomWBW Z-System environment descriptor NZCOM.LBR NZCOM Library of NZCOM system modules NZCOM.ZCM RomWBW Environment descriptor (alternate format) NZCPR.LBR NZCOM Library of alternative ZCPR modules PROFILE.SUB RomWBW Command file to auto-start NZ-COM at system boot RCP.LBR NZCOM Library of alternative RCP modules STARTZCM.COM RomWBW Commands to execute after NZ-COM is launched ZRDOS.ZRL ZRDOS Relocatable version of ZRDOS BDOS module ZSDOS.ZRL ZSDOS Relocatable version of ZSDOS 1.1 BDOS module ZSYS.SYS RomWBW ZSDOS Boot Image for SYSCOPY","title":"NZ-COM OS Files"},{"location":"Catalog/#nz-com-files","text":"The following files came from the official NZ-COM distribution. These are generally documented in the \u201cNZCOM Users Manual.pdf\u201d document in the Doc/CPM directory of the RomWBW distribution. NOTE: It may appear theat there are not many files, this is because most of the OS files are shared with Z3PLUS. See here for a list NZ-COM Z3PLUS OS Files The following file are in User Area 15, and where noted 10 for help files, or 14 for config files. File Description ALIAS.CMD Sample alias definitions for use with ARUNZ BGZRDS19.LBR Patch for Backgrounder II (U10) CMDRUN.COM Extended Command Processor (copied from ARUNZ) MKZCM.COM Create/update NZ-COM load environment NZBLITZ.COM Rapid coldboot of complete NZ-COM system image NZBLTZ14.CFG ZCNFG configuration file for NZBLITZ. (U14) NZBLTZ14.HZP Help file for NZBLITZ (U10) NZ-DBASE.INF dBase II application note regarding SUBMIT files (U10) PUBLIC.COM Specify ZRDOS public directories/user areas RELEASE.NOT Update information on NZ-COM (U10) SUB.COM Enhanced version of SUBMIT","title":"NZ-COM Files"},{"location":"Catalog/#additional-files_2","text":"Documentation User Area Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13 CP/M 2.2 Files 15 ZSDOS 1.1 Files 15, 14, 10 NZ-COM Z3PLUS OS Files 15, 14, 10 OS General Files 15, 14, 10 General Purpose Applications 15, 10","title":"Additional Files"},{"location":"Catalog/#cpm-3","text":"A vanilla distribution of DRI\u2019s CP/M 3, also known as CP/M Plus adapted for RomWBW. Floppy Disk Image: fd_cpm3.img Hard Disk Image: hd_cpm3.img Combo Disk Image: Slice 3","title":"CP/M 3"},{"location":"Catalog/#cpm-3-os-files","text":"The following files appear in User Area 0 File Source Description BDOS3.SPR CPM3 DRI CPM+ GENCPM input file for the non-banked BDOS BIOS3.SPR RomWBW DRI CPM+ GENCPM input file for non-banked BIOS BNKBIOS3.SPR RomWBW DRI CPM+ GENCPM input file for banked BIOS BNKBDOS3.SPR CPM3 DRI CPM+ GENCPM input file for banked BDOS CCP.COM CPM3 DRI CPM+ Console Command Processor CPM3.SYS RomWBW DRI CPM+ (non-banked) memory image CPM3RES.SYS RomWBW DRI CPM+ (non-banked) memory image CPM3BNK.SYS RomWBW DRI CPM+ (banked) memory image CPM3FIX.PAT CPM3 DRI CPM+ patch list CPMLDR.COM RomWBW DRI CPM 3.0 Boot Loader Application CPMLDR.SYS RomWBW DRI CPM 3.0 Boot Loader for SYSCOPY GENBNK.DAT RomWBW GENCPM config data file (banked) GENRES.DAT RomWBW GENCPM config data file (non-banked) GENCPM.DAT RomWBW Current GENCPM config data file GENCPM.COM CPM3 DRI CPM+ Create a memory image of CPM3.SYS RESBDOS3.SPR CPM3 DRI CPM+ GENCPM input file for resident BDOS","title":"CP/M 3 OS Files"},{"location":"Catalog/#cpm-3-files","text":"The following CP/M 3 files were distributed by DRI with the operating system or as supplemental add-on programs. They are documented in the \u201cCPM3 Command Summary.pdf\u201d document in the Doc/CPM directory of the Rom WBW distribution. The following files appear in User Area 0 File Description DATE.COM DRI CPM+ Set or display the date and time DEVICE.COM DRI CPM+ Assign logical devices with one or more physical devices DIR.COM DRI CPM+ DIR with options DUMP.COM DRI type contents of disk file in hex ED.COM DRI CPM+ line editor ERASE.COM DRI CPM+ file deletion GENCOM.COM DRI CPM+ Generate special COM file with attached RSX files GET.COM DRI CPM+ Temporarily get console input form a disk file HELP.COM DRI CPM+ Display information on how to use commands HELP.HLP DRI CPM+ Databse of help information for HELP.COM HEXCOM.COM DRI CPM+ Create a COM file from a hex file (replaces LOAD.COM) INITDIR.COM DRI CPM+ Initializes a disk to allow time and date stamping LIB.COM DRI object file library manager LINK.COM DRI object file linker MAC.COM DRI 8080 macro assembler PATCH.COM DRI CPM+ Display or install patch to the CPM+ system or command files PIP.COM DRI CPM+ Periperal Interchange Program PUT.COM DIR CPM+ Temporarily redirect printer or console output to a disk file RENAME.COM DRI CPM+ Rename a file RMAC.COM DRI 8080 relocating macro assembler SAVE.COM DRI CPM+ Copy the contents of memory to a file SET.COM DIR CPM+ Set file options SETDEF.COM DIR CPM+ Set system options including the drive search chain SHOW.COM DIR CPM+ Display disk and drive statistics SUBMIT.COM DRI CPM+ batch processor TYPE.COM DRI CPM+ Display the contents of an ASCII character file XREF.COM DRI assembler cross reference listing utility ZSID.COM DRI Z80 symbolic instruction debugger NOTE: The above files are also included in the ZPM3 and Z3PLUS disk images. ZSID is a supplemental program from DRI with separate standalone documentation which is not included in the RomWBW package (but easily found on the Internet via Google search).","title":"CP/M 3 Files"},{"location":"Catalog/#additional-files_3","text":"Documentation User Area OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13","title":"Additional Files"},{"location":"Catalog/#z3plus","text":"","title":"Z3PLUS"},{"location":"Catalog/#z3plus-os-files","text":"Z3PLUS is not designed to load directly from the boot tracks of a disk. Instead, it expects to be loaded from an already running OS. This disk has been configured to boot using CP/M 3 with a PROFILE.SUB command file that automatically loads Z3PLUS. So, Z3PLUS will load completely without any intervention, but you may notice that CP/M 3 loads first. The following Z3PLUS files appear in User Area 0 File Source Description !(C)1988 Z3PLUS Original copyright (since placed in public domain) !VERS--1.02F Z3PLUS Version marker directory entry (empty file) !Z3PLUS Z3PLUS Software marker directory entry (empty file) NAMES.NDR RomWBW Default Directory Names loaded at boot RCP.LBR Z3PLUS Library of alternative RCP modules PROFILE.SUB RomWBW Command file to auto-start Z3PLUS at system boot STARTZ3P.COM RomWBW Commands to execute after Z3PLUS is launched Z3PLUS.COM Z3PLUS Loads and launches Z3PLUS system Z3PLUS.LBR Z3PLUS Library of Z3PLUS system modules","title":"Z3PLUS OS Files"},{"location":"Catalog/#z3plus-files","text":"The following files came from the official Z3PLUS distribution. These are generally documented in the \u201cZ3PLUS Users Manual.pdf\u201d document in the Doc/CPM directory of the RomWBW distribution. Note: NOTE: It may appear theat there are not many files, this is because most of the OS files are shared with NZCOM. See here for a list NZ-COM Z3PLUS OS Files The following file are in User Area 15, and where noted 10 for help files. File Description ALIAS.CMD Sample alias definitions for use with ARUNZ PATCHSK.SUB Patch smartkey II v. 1.0A (U10) PATCH4SK.HEX Patch smartkey II v. 1.0A - Hex File (U10) RELEASE.NOT Update information on Z3PLUS (U10)","title":"Z3PLUS Files"},{"location":"Catalog/#additional-files_4","text":"Documentation User Area Testing Applications 2 Sample Audio Files 3 CP/NET 1.2 4 SIMH Simulator 13 CP/M 3 Files 15 NZ-COM Z3PLUS OS Files 15, 14, 10 OS General Files 15, 14, 10 General Purpose Applications 15, 10","title":"Additional Files"},{"location":"Catalog/#zpm3","text":"This is a generic ZPM3 adaptation for RomWBW. Floppy Disk Image: fd_zpm3.img Hard Disk Image: hd_zpm3.img Combo Disk Image: Slice 4 Per ZPM3 standard, files are distributed across different user areas depending on their usage. Normal applications are in user area 15. Help files in user area 10. Configuration files in user area 14.","title":"ZPM3"},{"location":"Catalog/#zpm3-os-files","text":"The following files appear in User Area 0 File Source Description BNKBIOS3.SPR RomWBW Banked BIOS BNKBDOS3.SPR ZPM3 Banked BDOS CPM3.SYS RomWBW ZPM3 system file (See Note) GENCPM.DAT RomWBW DRI CPM+ System generation tool data file HELP.HLP ZPM3 System Help File MAKEDOS.COM ZPM3 Utility to overlay your system file with ZPM3 STARTZPM.COM RomWBW Commands to execute after ZPM is launched RESBDOS3.SPR ZPM3 Resident BDOS ZCCP.COM ZPM3 ZCCP replacement for CCP.COM ZINSTAL.ZPM ZPM3 Segment containing environment information ZPMLDR.COM RomWBW ZPM3 Boot Loader Application ZPMLDR.SYS RomWBW ZPM3 Boot Loader for SYSCOPY NOTE: Currently GENCPM.COM is located in User Area 15 NOTE: The ZPM3 system file is called CPM3.SYS. This is the ZPM3 default configuration. It is done to maximize compatibility with CP/M 3. Either ZPMLDR or CPMLDR can be used to launch ZPM3. CPMLDR is equivalent to ZPMLDR. The following files appear in User Area 15 File Source Description AUTOTOG.COM ZPM3 CLRHIST.COM ZPM3 SETZ3.COM ZPM3","title":"ZPM3 OS Files"},{"location":"Catalog/#zpm3-files","text":"This is a generic ZPM3 adaptation for RomWBW. File User Area Description ARUNZ.COM 15 Alias-RUN-forZ-System command alias exec (v1.1 Type3) DEV.COM 15 DISKINFO.COM 15 ZCPR utility which gives information about your disks. DU.COM 15 ERASE.CFG 14 GENCPM.COM 15 DRI CPM3 Utility to Create a memory image of CPM3.SYS GOTO.COM 15 HELPC15.CFG 14 IF.COM 15 Extended flow control tester for FCP (v1.6 Type 3) IF.HLP 10 LOADSEG.COM 15 ZCCP Utility to Load RSXes, TCAPs and Named Directory files. MENU.HLP 10 NAMES.NDR 15 Default Directory Names loaded at boot REMOVE.COM 15 RSXDIR.COM 15 ZCPR Utility which displays RSXes in memory SETPATH.COM 15 used to set the command search path. VERROR.COM 15 Installs a resident error handler VLU.COM 15 Video Library Utility views or extracts files from libraries VLU.HLP 10 XREF.COM 15 ZERASE.COM 15 ZFHIST.HLP 10 ZFILER.COM 15 File management shell, with GUI. ZFILER.HLP 10 Help file for ZFILER.COM ZF11.CFG 14 ZFMACRO.HLP 10 ZHELP.COM 15 ZSHOW.COM 15 displays amount of information about your Z-System","title":"ZPM3 Files"},{"location":"Catalog/#additional-files_5","text":"Documentation User Area Testing Applications 2 Sample Audio Files 3 SIMH Simulator 13 CP/M 3 Files 15 OS General Files 15, 14, 10 General Purpose Applications 15, 10","title":"Additional Files"},{"location":"Catalog/#qpm-27","text":"The following files came from from Microcode Consulting. The official distribution files can be found on the Microcode Consulting website at [https://www.microcodeconsulting.com/z80/qpm.htm]. Also included in this image are debugz, and linkz frm the same company. This disk includes the standard DRI CP/M 2.2 files in addition to the QP/M files. QP/M generally assumes you already had DRI CP/M 2.2 prior to adding QP/M features.","title":"QPM 2.7"},{"location":"Catalog/#qpm-27-os-files","text":"These are built and provide the OS. QPM Typically has no boot files stored on the disk. It entirely boots from the system track The following files appear in User Area 0 File Description QPM.SYS RomWBW configured QP/M system image (for use with SYSCOPY) The qpm.sys file and the QP/M image on the system tracks was created using QINSTALL with default settings EXCEPT for the two settings described under Notes (current drive/user storage address and TIMDAT vector).","title":"QPM 2.7 OS Files"},{"location":"Catalog/#qpm-27-files","text":"The following files appear in User Area 0 File Description D.COM Directory lister DBGINST.COM Configures DEBUGZ debugger DEBUGZ.COM Symbolic debugger for Z80 DEBUGZ.HLP Symbolic debugger help file DHORIZ.COM Version of directory lister for horizontal file sorting HELLO.QPM Text file with QP/M version information LZ.COM Z80 Linking Loader QBACKUP.COM Data backup application QINSTALL.COM QP/M installer / configurator QPATCH.COM Patches (customizes) a few QP/M applications QPIP.COM QP/M enhanced version of CP/M 2.2 PIP application QPMCLK.MAC Example of QP/M clock assembler routine QPMCMDS.TXT Brief summary of QP/M commands QPMUTILS.TXT Brief summary of QP/M utilities QSTAMP.COM Initializes disk for date/time stamping QSTAMPV.COM Initializes disk for date/time stamping (vertical sort) QSTAMPX.COM Initializes disk for date/time stamping (horizontal sort) QSTAT.COM QP/M enhanced version of CP/M 2.2 STAT application QSUB.COM QP/M batch file submission program - Like SUBMIT QSWEEP.COM QP/M directory sweep utility QTERM.DAT Terminal control codes used by DEBUGZ QTERMS.LIB Library of available terminal definitions SETQTERM.COM Configures QTERM.DAT TDCNFG.COM Configures date/time directory display preferences There are two text files (QPMCMDS.TXT and QPMUTILS.TXT) included. These files have escape sequences imbedded in them which makes them look a little strange depending on the terminal emulation you are using.","title":"QPM 2.7 Files"},{"location":"Catalog/#additional-files_6","text":"Documentation User Area CP/M 2.2 Files 0 OS General Files 0 General Purpose Applications 0 Testing Applications 2 Sample Audio Files 3 SIMH Simulator 13","title":"Additional Files"},{"location":"Catalog/#common-disk-contents","text":"","title":"Common Disk Contents"},{"location":"Catalog/#cpnet-12","text":"User area 4 contains a full implementation of the CP/NET 1.2 client provided by Doug Miller. Please refer to [https://github.com/durgadas311/cpnet-z80] for more information, complete documentation and the latest source code. Please refer to the RomWBW User Guide for instructions on installing and using these these packages. Either the MT011 RCBus module or the Duodyne Disk I/O board is required. In general, to use CP/NET on RomWBW, it is intended that you will extract the appropriate set of files into your default directory in user area 0. The following are found in /Binary/CPNET File CP/NET Version OS Hardware CPN12MT.LBR CP/NET 1.2 CP/M 2.2 RCBus w/ MT011 CPN3MT.LBR CP/NET 3 CP/M 3 RCBus w/ MT011 CPN12DUO.LBR CP/NET 1.2 CP/M 2.2 Duodyne w/ Disk I/O CPN3DUO.LBR CP/NET 3 CP/M 3 Duodyne w/ Disk I/O CPN12SER.LBR CP/NET 1.2 CP/M 2.2 RomWBW Serial Port CPN3SER.LBR CP/NET 3 CP/M 3 RomWBW Serial Port","title":"CP/NET 1.2"},{"location":"Catalog/#general-purpose-applications","text":"The following files are general purpose an provided in (mostly) all OS images The following files are found in /Source/Apps/* /Source/Images/Common/All /Source/TastyBasic The following files provide specific functionality enabled by RomWBW enhancements. These applications are typically documented in the \u201cRomWBW Applications.pdf\u201d document in the Doc directory of the RomWBW Distribution. File Source Description ASSIGN.COM RomWBW Assign,remove,swap drive letters of RomWBW disk slices CLRDIR.COM Max Scane Initializes the directory area of a disk COPYSL.COM M.Pruden Copy CPM Hard Disk Slices COPYSL.DOC M.Pruden Documentation for COPYSL.COM CPUSPD.COM RomWBW CPU Speed FAT.COM RomWBW MS-DOS FAT filesystem tool (list, copy, delete, format, etc.) FDISK80.COM John Coffman Hard disk partitioning tool FDU.COM RomWBW Floppy Disk Utility, Test and format floppy disks FDU.DOC RomWBW Documentation for FDU FLASH.COM Will Sowerbutts Program FLASH chips in-situ FLASH.DOC Will Sowerbutts Documentation for FLASH FORMAT.COM RomWBW Placeholder application with formatting instructions HTALK.COM Tom Plano Terminal utility talking directly to HBIOS Character Units MODE.COM RomWBW Change serial line characteristics (baud rate, etc.) REBOOT.COM MartinR Cold or Warm Boot the RomWBW System RTC.COM Andrew Lynch Test real time clock hardware on your system SURVEY.COM RomWBW Display system resources summary SYSCOPY.COM RomWBW Copy system tracks to disks (make bootable) TALK.COM RomWBW Route console I/O to & from specified serial port TIMER.COM RomWBW Test and display system timer ticks TUNE.COM RomWBW Play .PT2, .PT3, and .MYM audio files on supported hardware VGMPLAY.COM Simple player for VGM (Video Game Music) files. WDATE.COM Kevin Boone Utility to configure RTC Date. XM.COM RomWBW XModem file transfer application Then we have some more general purpose applications. In general, there is no documentation for these applications included with the RomWBW distribution. Some provide command line help themselves. Some are fairly obvious. File Source Description BBCBASIC.COM R.T.Russell BBC BASIC CP/M Version BBCBASIC.TXT R.T.Russell Help file for BBC BASIC COMPARE.COM Compare content of two files (binary) CRUNCH.COM Compress file(s) using Crunch algorithmn CRUNCH28.CFG ZCNFG configuration file for CRUNCH & UNCR DDTZ.COM Z80 debug tool (modified to use RST 6) DDTZ.DOC Documentation for DDTZ EX.COM Batch file processor (alternative to DRI SUBMIT) FIND.COM Jay Cotton Search all drives for a file () GENHEX.COM Generates an Intel Hex file from the input file LS.COM An alternative file listing to DIR LSWEEP.COM Extract and view member files of an .LBR archive MBASIC.COM Microsoft Microsoft BASIC language interpreter NULU.COM NZCOM new library utility (.LBR) management tool PMARC.COM Create or add file(s) to LHA .PMA archive PMEXT.COM Extract file(s) from .PMA/.LZH/.LHA archive RMXSUB1.COM Lars Nelson Remove XSUB1 RSX from memory SUPERSUB.COM Enhanced replacement for DRI SUBMIT SUPERSUB.DOC Documentation for SUPERSUB SYSGEN.COM DRI Copy system tracks to disks TBASIC.COM Dimitri Theulings Tasty Basic. This also exists as a Rom appication TDLBASIC.COM TDL Zapple 12K BASIC language interpreter TE.COM Ladislau Szilagyi RomWBW enhanced version of TE editor TE.DOC Ladislau Szilagyi TE Editor Documentation UNARC.COM Extract file(s) from .ARC or .ARK archive UNARC.DOC Documentation for UNARC UNCR.COM Decompress Crunched file(s). See CRUNCH.COM UNZIP.COM Lars Nelson UNZIP extracts from MS-DOS ZIP files UNZIP.DOC Documentation for UNZIP XSUB1.COM Lars Nelson Replacement for DRI XSUB ZAP.COM Interactive disk & file utility ZDE.COM Compact WordStar-like editor ZDE.DOC ZDE Documentation ZDENST.COM Installation/configuration tool for ZDE ZMRX.COM ZMTX.COM ZMD.COM R.W.K Z80 RCP/M File Transfer Program (Robert W. Kramer III) ZMP.COM ZModem communications program (dedicated port) ZMP.DOC Documentation for ZMP ZMP.HLP Help file for ZMP ZMXFER.OVR Overlay file for ZMP ZMTERM.OVR Overlay file for ZMP ZMINIT.OVR Overlay file for ZMP ZMCONFIG.OVR Overlay file for ZMP","title":"General Purpose Applications"},{"location":"Catalog/#os-general-files","text":"The following files are spcific files share across several OS\u2019s. In general, there is no documentation for these applications included with the RomWBW distribution. Some provide command line help themselves. Some are fairly obvious. The following files are found in /Source/Images/Common/CPM22 /Source/Images/Common/CPM3 /Source/Images/Common/Z /Source/Images/Common/Z3 File Applicability Description ALIAS.COM Z3 Create an Alias (v1.1) ALIAS.HLP Z3 Help File for ALIAS.COM COPY.COM Z File copier with ZSDOS date stamping awareness COPY.CFG Z ZCNFG configuration file for COPY application EDITNDR.COM Z3 Edit named directory register in memory. HP-RPN.HLP Z3 Help File for ZP.COM - HP RPN Calculators HP-ZP.HLP Z3 Help File for ZP.COM - HP ZP Calculators KERCPM22.COM CPM22 Kermit communication application KERCPM3.COM CPM3 Kermit communication application LBREXT.COM Z Extract file from .LBR libraries LBREX36.CFG Z ZCNFG configuration file for LBREXT RZ.COM CPM3 Receive files with X/Y/ZModem (experimental) RZSC.FOR CPM3 Description of RZ/SZ programs SAINST.COM Z3 Install/configure SALIAS. SALIAS.COM Z3 Screen oriented alias editor. (v1.6) SAVENDR.COM Z3 Writes the named directory to disk. SDZ.COM Z3 Enhanced directory lister. SCOPY.COM Z3 Screen-oriented file copy for ZCPR3 SCOPY10.CFG Z3 ZCNFG configuration file for SCOPY SCOPY.HLP Z3 Primary help file for SCOPY SCOPY10F.HLP Z3 Secondary help file for SCOPY SZ.COM CPM3 Send files with X/Y/ZModem (experimental) TCAP.Z3T Z3 Terminal capabilities for ZCPR3 (VT100) TCSELECT.COM Z3 NZCOM Create terminal capability file (newer version) TCVIEW.COM Z3 View zcpr3 terminal capabilities UMAP.COM Z3 Shows directory usage UMAP18.CFG Z3 ZCNFG configuration file for UMAP program UNARCU1.CFG Z ZCNFG configuration file for UNARC program ZCNFG.COM Z Configuration tool for programs with .CFG files ZCNFG24.CFG Z Configuration file for ZCNFG.COM ZEX.COM Z3 A memory-based command file processor, like SUBMIT ZEX.CFG Z3 ZCNFG configuration file for ZEX program ZP.COM Z3 Screen-oriented file/disk/memory record patcher (ZAP) ZP.HLP Z3 Help File for ZP.COM ZP17.CFG Z3 Configuration file for ZP.COM ZXD.CFG Z Configuration file for ZXD.COM ZXD.COM Z Extended directory utility w/ date/time stamp support Z3LOC.COM Z3 Display info of the ZCPR3 CCP, BDOS, and BIOS Z3TCAP.LBR Z3 Database of terminal descriptions Applicability: CPM22 - Included in all CP/M 2.2 OS\u2019s (CPM2.2, ZSDOS, NZ-COM, QPM) CPM3 - Included in all CP/M 3 OS\u2019s (CPM3, Z3PLUS, ZPM3) Z - Included in All Z OS\u2019s (ZSDOS, NZ-COM, Z3PLUS, ZPM3) Z3 - Included in ZCPR3 OS\u2019s (NZ-COM, Z3PLUS, ZPM3)","title":"OS General Files"},{"location":"Catalog/#nz-com-z3plus-os-files","text":"The following files are specific files share across two operating systems. NZ-COM - The Automatic Z-System - Alpha Systems Z3PLUS - The Z-System for CP/M-Plus - Plu*Perfect Systems These 2 operating systems are identical in all respects, except for the underlying operating system that they run on. The following files are found in /Source/Images/Common/NZ3PLUS The following file are in User Area 15, and where noted 14 for config files. File Description ARUNZ.COM Alias-RUN-forZ-System command alias exec (v0.9u Type4) CLEDINST.COM Command line editing and history shell installer CLEDSAVE.COM Save RCP-resident command line editor history CONFIG.LBR Various configuration files for use with ZCNFG. (U14) CPSET.COM Displays/defines CRT/PRT characteristics FCP.LBR Library of alternative FCP modules FF.COM File finder utility IF.COM Extended flow control tester for FCP (v1.5 Type4) JETLDR.COM Z-System General-purpose module loader LBRHELP.COM Help file viewer for use with help file libraries (.LBR) LDIR.COM Directory lister for libraries (.LBR) LPUT.COM Puts file(s) into a library (.LBR) LSH.COM Command history shell and command line editor LSH-HELP.COM Display LSH help when LSH is running LSHINST.COM LSH configuration editor LX.COM Execute programs directly from a library (.LBR) NAME.COM Quickly add or remove a name for a single directory PATH.COM Set/display command search path PWD.COM Displays DU and Directory Names with paging TY3ERA.COM Type-3 program to erase a file TY3REN.COM Type-3 program to rename a file TY4ERA.COM Type-4 program to erase a file TY4REN.COM Type-4 program to rename a file TY4SAVE.COM Type-4 program to save memory to a file TY4SP.COM Type-4 program to display disk space VIEW.COM Quad directional file viewer XTCAP.COM Interactive Extended TCAP Installer ZERR.COM Z34 Error Handler ZF-DIM.COM ZFILER shell for dim-video terminals ZF-REV.COM ZFILER shell for reverse-video terminals ZFILER.CMD Macro script file for ZFILER ZHELP.COM (HELPC14) is an improved version of the help utility ZLT.COM File lister with support for compressed files ZSHOW.COM Display Z-System configuration information The following documentation files are in User Area 10 File Description DOCFILES.LBR Documentation and help files collected into an LBR file HLPFILES.LBR Various app help files for use with LBRHELP LSH.WZ User manual for LSH TCJ.INF Subscription information for The Computer Journal TCJ*.WZ Selected articles from The Computer Journal ZFILEB38.LZT Brief listing of Z-System support programs ZHELPERS.LZT List of volunteers who will help installing Z-System ZNODES66.LZT List of Z-Node remote access systems ZSYSTEM.IZF Information on Z-System and related products","title":"NZ-COM Z3PLUS OS Files"},{"location":"Catalog/#sample-audio-files","text":"User area 3 contains sample audio files that can be played using the TUNE or VGMPLAY applications. NOTE These files are NOT present on floppy disk images The following files are found in /Binary/Apps/Tunes File File File File ATTACK.PT3 DEMO4.MYM NAMIDA.PT3 VICTORY.PT3 BACKUP.PT3 ENDING.VGM RECOLL.PT3 WICKED.PT3 BADMICE.PT3 HOWRU.PT3 SANXION.PT3 WONDER01.VGM DEMO.MYM INCHINA.VGM SHIRAKAW.VGM YEOLDE.PT3 DEMO1.MYM ITERATN.PT3 STARTDEM.VGM YEOVIL.PT3 DEMO3.MYM LOOKBACK.PT3 SYNCH.PT3 DEMO3MIX.MYM LOUBOUTN.PT3 TOSTAR.PT3","title":"Sample Audio Files"},{"location":"Catalog/#simh-simulator","text":"Files for use with the SIMH Simulator The following files are found in /Source/Images/Common/SIMH File Description HDIR.COM R.COM transfer files between the simulator and host file system RSETSIMH.COM \u2013 TIMER.COM \u2013 URL.COM \u2013 W.COM transfer files between the simulator and host file system","title":"SIMH Simulator"},{"location":"Catalog/#testing-applications","text":"User area 2 contains a variety of hardware testing applications. These are generally user contributed and have no documentation. These applications are frequently not compatible with all RomWBW hardware. They are included here as a convenience. If applicable, your hardware documentation should refer to them and provide usage instructions. NOTE These files are NOT present on floppy disk images The following files are found in /Binary/Apps/Test /Source/Images/Common/Test File Description 2PIOTST.COM ECB-ZILOG PERIPHERALS BOARD TEST 2 PIO\u2019s AY-TEST.COM AY-3-8910 Sound Test Program (SOUND) BANKTEST.COM Test RomWBW bank management API DMAMON.COM Verify operation of the Z80 MBC DMA board I2CLCD.COM PCF8584 HD44780 I2C LCD UTILITY I2CSCAN.COM I2C BUS SCANNER INTTEST.COM Test HBIOS interrupt API functions KBDTEST.COM test program to work with the Z80 KBDMSE board PIOMON.COM Zilog PIO Monitor & Hardware Testing Application PORTSCAN.COM Reads all ports and displays values read PPIDETST.COM PPI IDE test for checkout of all 8255 IDE drives PS2INFO.COM PS/2 Keyboard/Mouse Information Utility RAMTEST.COM RAM_TEST_PROGRAM RTCDS7.COM PCF8584/DS1307 I2C DATE AND TIME UTILITY (I2C) RZ.COM Receive Zmodem disassembly of CP/M 3 binaries SOUND.COM RomWBW HBIOS Sound Device Test Tool (SOUND) SROM.COM I2C Serial ROM Read/Write Utility (I2C) SZ.COM Send Zmodem is a disassembly of CP/M 3 binaries TESTH8P.COM H8 Panel Test TSTDSKNG.COM DSKY NEXT GENERATION TEST APPLICATION VDCONLY.COM COLOR VDU TEST VDCTEST.COM COLOR VDU TEST ZEXALL.COM Z80 Instruction Set Exerciser ZEXDOC.COM Z80 Instruction Set Exerciser And The following CPU Tests - Which are probably originally from this source. [https://github.com/raxoft/z80test] File Description Z80CCF.COM tests flags after executing CCF after each instruction. Z80DOC.COM tests registers, but only officially documented flags Z80DOCF.COM Z80FLAGS.COM tests flags, ignores registers. Z80FULL.COM tests flags and registers Z80MPTR.COM tests flags after executing BIT N,(HL) after each instruction","title":"Testing Applications"},{"location":"Catalog/#application-standalone-disks","text":"","title":"Application Standalone Disks"},{"location":"Catalog/#aztec-c-compiler","text":"Floppy Disk Image: fd_aztecc.img Hard Disk Image: hd_aztecc.img Aztec C is a discontinued programming language for a variety of platforms including MS-DOS, Apple II DOS 3.3 and PRoDOS, Commodore 64, Macintosh and Amiga. This disk contains the CP/M version of that compiler. A cross-compiler for MS-DOS or Windows XP is also available. For full documentation, see [https://www.aztecmuseum.ca] The user manual is available in the Doc/Language directory Aztec_C_1.06_User_Manual_Mar84.pdf The following files are found in /Source/Images/d_aztec File Description \u2013 \u2013 NOTE : The above is incomplete","title":"Aztec C Compiler"},{"location":"Catalog/#microsoft-basic-compiler","text":"Floppy Disk Image: fd_bascomp.img Hard Disk Image: hd_bascomp.img The Microsoft BASIC Compiler is a highly efficient programming tool that converts BASIC programs from BASIC source code into machine code. This provides much faster BASIC program execution than has previously been possible. It can make programs run an average of 3 to 10 times faster than programs run under BASIC-80. Compiled programs can be up to 30 times faster than interpreted programs if maximum use of integer variables is made. View BASCOM.HLP included in the disk image using HELP.COM for documentation. The following files are found in /Source/Images/d_bascomp File Description \u2013 \u2013 NOTE : The above is incomplete","title":"Microsoft Basic Compiler"},{"location":"Catalog/#cowgol-compiler","text":"Floppy Disk Image: fd_cowgol.img Hard Disk Image: hd_cowgol.img The Cowgol 2.0 compiler and related tools. These files were provided by Ladislau Szilagyi and were sourced from his GitHub repository at [https://github.com/Laci1953/Cowgol_on_CP_M]. The primary distribution site for Cowgol 2.0 is at [https://github.com/davidgiven/cowgol]. The user manual is available in the Doc/Language directory Cowgol Language.pdf The following files are found in /Source/Images/d_cowgol File Description ADVENT.COW Adventure game program source ADVENT.SUB Submit file to build ADVENT ADVENT?.TXT Adventure game program resource ADVMAIN.COW Adventure game program source RAND.AS Assembler Library File COWBE.COM COWFE.COM RomWBW specific (Memory Manage) version COWLINK.COM DYNMSORT.COW demonstrates a sort algorithm DYNMSORT.SUB Submit file to build DYNMSORT HEXDUMP.COW a simple hex dump utility, purely a Cowgol HEXDUMP.SUB Submit file to build HEXDUMP HMERGES.C C Library File XRND.AS Assembler Library File - - NOTE : The above is incomplete","title":"Cowgol Compiler"},{"location":"Catalog/#microsoft-fortran-80-fortran","text":"Floppy Disk Image: fd_fortran.img Hard Disk Image: hd_fortran.img This is Microsoft\u2019s implementation of the FORTRAN scientific-oriented high level programming language. It was one of their early core languages developed for the 8-bit computers and later brought to the 8086 and IBM PC. In 1993 Microsoft rebranded the product as Microsoft Fortran Powerstation. (Note: -80 refers to the 8080/Z80 platform, not the language specification version) The user manual is available in the Doc/Language directory, Microsoft_FORTRAN-80_Users_Manual_1977.pdf The following files are found in /Source/Images/d_fortram File Description \u2013 \u2013 NOTE : The above is incomplete","title":"Microsoft Fortran 80 (Fortran)"},{"location":"Catalog/#games","text":"Floppy Disk Image: fd_games.img Hard Disk Image: hd_games.img This disk contains several games for CP/M including the Infocom games Zork 1 through 3, Planetfall and Hitchhiker\u2019s Guide to the Galaxy. Nemesis and Dungeon Master is a Rogue-like game released in 1981. It is playable on a text terminal using ASCII graphics to represent the dungeon. Only a few thousand copies of the game were ever made, making it very rare. See [http://crpgaddict.blogspot.com/2019/03/game-322-nemesis-1981.html] Colossal Cave Adventure is a CP/M port of the 1976 classic game originally written by Will Crowther for the PDP-10 mainframe. See [https://en.wikipedia.org/wiki/Colossal_Cave_Adventure] and [https://if50.substack.com/p/1976-adventure] The following files are found in /Source/Images/d_games File Description \u2013 \u2013 NOTE : The above is incomplete","title":"Games"},{"location":"Catalog/#hi-tech-c-compiler","text":"Floppy Disk Image: fd_hitechc.img Hard Disk Image: hd_hitechc.img The HI-TECH C Compiler is a set of software which translates programs written in the C language to executable machine code programs. Versions are available which compile programs for operation under the host operating system, or which produce programs for execution in embedded systems without an operating system. This is the Mar 21, 2023 update 17 released by Tony Nicholson who currently maintains HI-TECH C at [https://github.com/agn453/HI-TECH-Z80-C] The manual is available in the Doc/Language directory, HI-TECH Z80 C Compiler Manual.txt A good blog post about the HI-TECH C Compiler is available at [https://techtinkering.com/2008/10/22/installing-the-hi-tech-z80-c-compiler-for-cpm] The following files are found in /Source/Images/d_hitechc File Description \u2013 \u2013 NOTE : The above is incomplete","title":"HI-TECH C Compiler"},{"location":"Catalog/#msx-roms","text":"Hard Disk Image: hd_msxroms1.img Hard Disk Image: hd_msxroms2.img The collection of MSX ROMs (2 disks) as provided by Les Bird. These ROMs are \u201crun\u201d by using the appropriate variant of Les\u2019 MSX8 ROM loader. You can download the loader binaries from [https://github.com/lesbird/MSX8]. You will need appropriate hardware to run the loader. Please review the file ROMLIST.TXT for information on the current operational status of the ROM and it\u2019s long file name/description. This disk (RomWBW slice) is not automatically included with the RomWBW \u201ccombo\u201d disk images. You can simply add it to a combo image by appending it to the end. After booting your system, you can use the ASSIGN command to map the slice to a drive letter. Refer to the RomWBW User Guide for more information on this process. The ROM files are found in /Source/Images/d_msxroms1 /Source/Images/d_msxroms2","title":"MSX ROMS"},{"location":"Catalog/#turbo-pascal-compiler","text":"Floppy Disk Image: fd_tpascal.img Hard Disk Image: hd_tpascal.img The Borland Turbo Pascal Compiler. Pascal is a general-purpose, high level programming language originally designed by Professor Niklaus Wirth of the Technical University of Zurich, Switzerland and named in honor of Blise Pascal, the famous French philosopher and mathematician. Turbo Pascal closely follows the definition of Standard Pascal as defined in the Pascal User Manual and Report with a few minor differences. The manual can be found in the Docs/Language directory, Turbo_Pascal_Version_3.0_Reference_Manual_1986.pdf A good overview of using Turbo Pascal in CP/M is available at [https://techtinkering.com/2013/03/05/turbo-pascal-a-great-choice-for-programming-under-cpm] The following files are found in /Source/Images/d_tpascal File Description ART.TXT Part of the Example program SA.PAS Example Program TINST.COM Installation and Configuration TINST.DTA Part of TINST TINST.MSG Part of TINST TURBO.COM The main Turbo Pascal program TURBO.MSG Part of TURBO tascal TURBO.OVR Part of TURBO tascal TURBOMSG.OVR Part of TURBO tascal","title":"Turbo Pascal Compiler"},{"location":"Catalog/#wordstar-4","text":"Floppy Disk Image: fd_ws4.img Hard Disk Image: hd_ws4.img Combo Disk Image: Slice 5 The following files are found in /Source/Images/d_ws4 File Description ANAGRAM.COM CHAPTER1.DOC CHAPTER2.DOC CHAPTER3.DOC DIARY.DOC DICTSORT.COM FIND.COM HOMONYMS.TXT HYEXCEPT.TXT HYPHEN.COM LOOKUP.COM MAINDICT.CMP MARKFIX.COM MOVEPRN.COM PATCH.LST PRINT.TST READ.ME README. REVIEW.COM RULER.DOC SAMPLE1.DOC SAMPLE2.DOC SAMPLE3.DOC SPELL.COM TABLE.DOC TEXT.DOC TW.COM WC.COM WINSTALL.COM WORDFREQ.COM WS.COM WS.OVR WSCHANGE.COM WSCHANGE.OVR WSCHHELP.OVR WSHELP.OVR WSINDEX.XCL WSMSGS.OVR WSPRINT.OVR WSSHORT.OVR Also contained on this image in User Area 1 are. File Description SAMPKEY.DOC ZDE Distribution File SAMPKEY.ZDK ZDE Distribution File SAMPKEY.ZDT ZDE Distribution File ZDE10.DOC ZDE Distribution File ZDE10.FOR ZDE Distribution File ZDE10.NEW ZDE Distribution File ZDE10.QRF ZDE Distribution File ZDE10.TOC ZDE Distribution File ZDE13.FOR ZDE Distribution File ZDE13.NEW ZDE Distribution File ZDE16.COM ZDE Distribution File ZDE16.DIR ZDE Distribution File ZDE16.FIX ZDE Distribution File ZDE16.FOR ZDE Distribution File ZDE16.NEW ZDE Distribution File ZDE16A.COM ZDE Distribution File ZDE16A.PAT ZDE Distribution File ZDENST16.COM ZDE Distribution File ZDEPROP.DOC ZDE Distribution File ZDEPROP.Z80 ZDE Distribution File ZDKCOM13.COM ZDE Distribution File ZDKCOM13.DOC ZDE Distribution File","title":"WordStar 4"},{"location":"Catalog/#z80asm-macro-assembler","text":"Floppy Disk Image: fd_z80asm.img Hard Disk Image: hd_z80asm.img This disk contains 6 major components Z80ASM is a relocating macro assembler for CP/M. It takes assembly language source statements from a disk file, converts them into their binary equivalent, and stores the output in either a core-image, Intel hex format, or relocatable object file. The mnemonics recognized are those of Zilog/Mostek. The optional listing output may be sent to a disk file, the console and/or the printer, in any combination. Output files may also be generated containing cross-reference information on each symbol used. Z80ASMP (Z80ASM Plus). Referred to as the \u201cVirtual Memory\u201d version which uses disk for working storage, thus not constrained by RAM. SLR180 is a powerful relocating macro assembler for Z80 compatible CP/M systems. It takes assembly language source statements from a disk file, converts them into their binary equivalent, and stores the output in either a core-image, Intel hex format, or relocatable object file. The mnemonics recognized are those of Zilog (Z180)/Hitachi. The optional listing output may be sent to a disk file, the console and/or the printer, in any combination. Output files may also be generated containing cross-reference information on each symbol used. SLRMAC relocating macro assembler for Intel 8080 mnemonics SLRNK is a powerful linking loader for Z80-based CP/M systems. It takes relocatable binary information in either Microsoft or SLR Systems format from a disk file, resolves external and entry point references, and stores the output in memory for execution or outputs it to a disk file. SLRNKP (SLRNK Plus). Referred to as the \u201cVirtual Memory\u201d version which uses disk for working storage, thus not constrained by RAM. Z80DIS is an entirely new disassembler for Z80 based CP/M sys- tems. Z80DIS is written in TURBO PASCAL. Z80DIS generates Z80 mnemonics and prepares an assembly language file with many special features for ease of understanding the intent of the code. The program and documantation are Copyright 1985, by Kenneth Gielow, Palo Alto, CA. All rights are reserved. The manual(s) are available in the Doc/Language directory, z80asm (SLR Systems).pdf SL180 (SLR Systems 1985).pdf SLRNK (SLR Systems 1984).pdf Z80DIS User Manual (1985).pdf A run through of using the assembler is available at [https://8bitlabs.ca/Posts/2023/05/20/learning-z80-asm] And another shorter, but shows linker usage guide [https://pollmyfinger.wordpress.com/2022/01/10/modular-retro-z80-assembly-language-programming-using-slr-systems-z80asm-and-srlnk/] The following files are found in /Source/Images/d_z80asm User Area 0 - Assembler File Description 180FIG.COM Configuration utility for SLR180.COM 8080.MAC ? CONFIG.COM Configuration utility for Z80ASM.COM CONFIGP.COM Configuration utility for Z80ASMP.COM DUMP.* Sample Program MAKESYM.COM Symbol File .SYM file generation MAKESYM.DOC Documentation for MAKESYM.COM SLR180.COM HD64180 (Z180) Relocating Macro Assembler SLR180.DOC Release Notes for SLR180.COM SLRMAC.COM 8080 Relocating Macro Assembler SYNTAX.HLP Documentation basic usage for all SLR Tools SYNTAX.TXT Documentation basic usage for all SLR Tools TEST.* Sample Program Z80ASM.COM Z80 Relocating Macro Assembler Z80ASMP.COM Z80 Relocating Macro Assembler (PLUS) Z80ASM.DOC Release Notes for Z80ASM.COM User Area 1 - Linker and Library Management File Description LNKFIG.COM Configuration utility for SLRNK.COM NZLNKFIX.ZEX ? SLRIB.COM SuperLibrarian, library manager SLRNK.COM SuperLinker, the main linker tool SLRNKP.COM SuperLinker (PLUS) SLRNK.DOC Release Notes for SLRNK.COM SLRNKFIX.ZEX ? SYNTAX.HLP Documentation basic usage for all SLR Tools SYNTAX.TXT Documentation basic usage for all SLR Tools SYSSLR.REL SYSLIB (older) Library compatible with SLR VSLR.REL VLIB (older) Library compatible with SLR Z3SLR.REL Z3LIB (older) Library compatible with SLR User Area 2 - Disassembler File Description README.22 Documentation for Z80DIS Z80DIS.000 Overlay File for Z80DIS.COM Z80DIS.001 Overlay File for Z80DIS.COM Z80DIS.002 Overlay File for Z80DIS.COM Z80DIS.COM Z80DIS Disassembler main program Z80DIS22.DOC Main Documentation for Z80DIS ZDINSTAL.COM Instal and Config for Z80DIS.COM ZDINSTAL.DTA Overlay file for ZDINSTAL.COM ZDINSTAL.MSG Overlay file for ZDINSTAL.COM","title":"Z80ASM Macro Assembler"},{"location":"Hardware/","text":"RomWBW Hardware \\ Version 3.6 \\ Wayne Warthen ( wwarthen@gmail.com ) \\ 31 May 2025 Overview Supported Platforms This section contains a summary of the system configuration target for each of the pre-built ROM images included in the RomWBW distribution. It is intended to help you select the correct ROM image and understand the basic hardware components supported. Detailed hardware system configuration information should be obtained from your system provider/designer. The table below summarizes the hardware platforms currently supported by RomWBW along with the standard pre-built ROM image(s). RCBUS - General Configurations RCBus refers to Spencer Owen\u2019s RC2014 bus specification and derivatives including RC26, RC40, RC80, and BP80. Description Bus ROM Image File Baud Rate RCBus Z80 CPU Module , 512K RAM/ROM RCBus RCZ80_std.rom 115200 RCBus Z80 CPU Module (KIO) , 512K w/KIO RCBus RCZ80_kio_std.rom 115200 RCBus Z180 CPU Module (External) RCBus RCZ180_ext_std.rom 115200 RCBus Z180 CPU Module (Native) RCBus RCZ180_nat_std.rom 115200 RCBus Z280 CPU Module (External) RCBus RCZ280_ext_std.rom 115200 RCBus Z280 CPU Module (Native) RCBus RCZ280_nat_std.rom 115200 KIO refers to a Zilog specific Serial/Parallel Counter/Timer (Z84C90). The RCBus Z180 & Z280 require a separate RAM/ROM memory module. There are two types of these modules, you must pick the correct ROM for your type of memory module: The first type of RAM/ROM module includes Z2 style memory bank switching on the memory module itself. This is called \u201cExternal\u201d (ext) because the bank switching is external from the CPU itself. The second type of RAM/ROM module has no bank switching logic on the memory module. Bank switching is implemented via the Z180 or Z280 MMU \u2013 this is called \u201cNative\u201d (nat) because the CPU itself provides the bank switching logic. Only Z180 and Z280 CPUs have the ability to do bank switching in the CPU, so the ext/nat selection only applies to them. Z80 CPUs have no built-in bank switching logic, so they always require a RAM/ROM module with Z2 style bank switching and the ROMs are always configured for external bank switching. Custom / Specific Configurations Andrew Lynch Description Bus ROM Image File Baud Rate RetroBrew Z80 SBC V2 ECB SBC_std.rom 38400 RetroBrew Z80 SimH - SBC_simh.rom 38400 Duodyne Z80 System Duo DUO_std.rom 38400 Nhyodyne Z80 MBC MBC MBC_std.rom 38400 Rhyophyre Z180 SBC - RPH_std.rom 38400 N8 Z180 SBC (date >= 2312) ECB N8_std.rom 38400 Bill Shen Description Bus ROM Image File Baud Rate EaZy80-512 Z80 CPU Module RCBus RCZ80_ez512_std.rom 115200 K80W Z80 CPU Module RCBus RCZ80_k80w_std.rom 115200 ZRC Z80 CPU Module RCBus RCZ80_zrc_std.rom 115200 ZRC Z80 CPU Module (RAM) RCBus RCZ80_zrc_ram_std.rom 115200 ZRC512 Z80 CPU Module RCBus RCZ80_zrc512_std.rom 115200 Z1RCC Z180 CPU Module RCBus RCZ180_z1rcc_std.rom 115200 ZZRCC Z280 CPU Module RCBus RCZ280_zzrcc_std.rom 115200 ZZRCC Z280 CPU Module (RAM) RCBus RCZ280_zzrcc_ram_std.rom 115200 ZZ80MB Z280 SBC RCBus RCZ280_zz80mb_std.rom 115200 Sergey Kiselev Description Bus ROM Image File Baud Rate Easy Z80 SBC RCBus EZZ80_easy_std.rom 115200 Tiny Z80 SBC RCBus EZZ80_tiny_std.rom 115200 Z80-512K CPU/RAM/ROM Module RCBus RCZ80_skz_std.rom 115200 Zeta Z80 SBC , ParPortProp - ZETA_std.rom 38400 Zeta V2 Z80 SBC , ParPortProp - ZETA2_std.rom 38400 Stephen Cousins Description Bus ROM Image File Baud Rate SC126 Z180 SBC BP80 SCZ180_sc126_std.rom 115200 SC130 Z180 SBC RCBus SCZ180_sc130_std.rom 115200 SC131 Z180 Pocket Comp - SCZ180_sc131_std.rom 115200 SC140 Z180 CPU Module Z50 SCZ180_sc140_std.rom 115200 SC503 Z180 CPU Module Z50 SCZ180_sc503_std.rom 115200 SC700 Z180 CPU Module RCBus SCZ180_sc700_std.rom 115200 Others Description Bus ROM Image File Baud Rate Dyno Z180 SBC 6 Dyno DYNO_std.rom 38400 EP Mini-ITX Z180 11 UEXT EPITX_std.rom 115200 eZ80 for RCBus Module 13 , 512K RAM/ROM RCBus RCEZ80_std.rom 115200 Genesis Z180 System 12 STD GMZ180_std.rom 115200 Heath H8 Z80 System 10 H8 HEATH_std.rom 115200 NABU w/ RomWBW Option Board 10 NABU NABU_std.rom 115200 S100 Computers Z180 SBC 9 S100 S100_std.rom 57600 S100 Computers FPGA Z80 SBC 9 S100 FZ80_std.rom 9600 UNA Hardware BIOS 3 - UNA_std.rom - Z80-Retro SBC 8 - Z80RETRO_std.rom 38400 Z180 Mark IV SBC 3 ECB MK4_std.rom 38400 3 Designed by John Coffman 6 Designed by Steve Garcia 8 Designed by Peter Wilson 9 Designed by John Monahan 10 Designed by Les Bird 11 Designed by Alan Cox 12 Designed by Doug Jackson 13 Designed by Dean Netherton General Guidance The standard ROM images will detect and install support for certain devices and peripherals that are on-board or frequently used with each platform. If the device or peripheral is not detected at boot, the ROM will simply bypass support appropriately. Each ROM will support a single memory manager. This is determined by the build configuration and is not dynamically selected. The use of the term Memory Manager is generally synonymous with Memory Management Unit (MMU). In some cases, support for multiple hardware components with potentially conflicting resource usage are handled by a single ROM image. It is up to the user to ensure that no conflicting hardware is in use. CPU speed will be dynamically measured at startup if DSRTC is present All pre-built ROM images are pure binary files (they are not \u201chex\u201d files). They are intended to be programmed starting at the very start of the ROM chip (address 0). Most of the pre-built images are 512KB in size. If your system utilizes a larger ROM, you can just program the image into the first 512KB of the ROM for now. For this document port addresses IO=xxx are represented in decimal. The PropIO support is based on RomWBW specific firmware. Be sure to program/update your PropIO firmware with the corresponding firmware image provided in the Binary directory of the RomWBW distribution. The use of high density floppy disks requires a CPU speed of 8 MHz or greater. Platform Configurations Duodyne Z80 System Duodyne is a third generation ROMWBW focused retrocomputer incorporating lessons learned and improvements from my original ECB Z80 SBC (aka N8VEM) and the nhyodyne modular computer. It is literally designed around ROMWBW from the start for a robust OS and software environment. Duodyne is a new design which integrates many functions into larger, modular boards on a backplane. The intent is to create a powerful and capable system like an SBC, but with modularity and an expandable backplane. Creator: Andrew Lynch Retrobrew Forums: Introducing duodyne retrocomputer Github: DuoDyne ROM Image File: DUO_std.rom Bus Duo Default CPU Speed 8.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 38400 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=66, SWIO=66 DSRTC: MODE=STD, IO=148 PCF: IO=86 UART: IO=88 UART: IO=168 UART: IO=112 UART: IO=120 SIO MODE=ZP, IO=96, CHANNEL A, INTERRUPTS ENABLED SIO MODE=ZP, IO=96, CHANNEL B, INTERRUPTS ENABLED LPT: MODE=SPP, IO=72 DMA: MODE=DUO, IO=64 CH: IO=78 CHUSB: IO=78 CHSD: IO=78 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DUO, IO=128, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DUO, IO=128, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=136, MASTER PPIDE: IO=136, SLAVE SD: MODE=MT, IO=140, UNITS=1 SPK: IO=148 CTC: IO=96, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED Dyno Z180 SBC The Dyno Computer is a Zilog Z180-based computer initially designed to run Wayne Warthen\u2019s ROMWBW Creator: Steve Garc\u00eda Google Groups: An Introduction Website: Dyno Computer ROM Image File: DYNO_std.rom Bus Dyno\u2022Bus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 38400 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware BQRTC: IO=80 ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DYNO, IO=132, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DYNO, IO=132, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=76, MASTER PPIDE: IO=76, SLAVE EP Mini-ITX Z180 EtchedPixels Z180 Mini-ITX. The SC126 was almost my ideal retrobrew Z80/Z180 system but with a couple of niggles and lack of a convenient case option. This is the same core Z180 CPU/RAM/ROM design taken the other direction, of expandability. Creator: Alan Cox Google Groups: Another new board Github: Z180MiniITX ROM Image File: EPITX_std.rom Bus RCBus + UEXT Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=160 UART: IO=168 TMS: MODE=MSX, IO=152, SCREEN=40X24, KEYBOARD=NONE MD: TYPE=RAM MD: TYPE=ROM FD: MODE=EPFDC, IO=72, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=EPFDC, IO=72, DRIVE 1, TYPE=3.5\u201d HD SD: MODE=EPITX, IO=66, UNITS=1 Easy/Tiny Z80 Easy Z80 SBC This project is a simple, easy to understand, yet capable single board computer. It reuses the same memory paging mechanism I\u2019ve implemented in Zeta SBC V2. It uses Zilog Z80 SIO/O and Z80 CTC peripheral ICs and implements daisy chain mode 2 interrupt configuration (Not to be confused with EaZy80) Creator: Sergey Kiselev Google Groups: Easy Z80 - Single Board Computer Github: Easy_Z80 ROM Image File: EZZ80_easy_std.rom Bus RCBus Default CPU Speed 10.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 CTC: IO=136, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED Tiny Z80 SBC Tiny Z80 is a business card sized (size?!) single board computer (SBC). It is mostly compatible with Easy Z80, and offers similar capabilities Tiny Z80 includes a USB to Serial converter IC on board connected to one of the SIO ports, for ease of use with modern computers. Creator: Sergey Kiselev Github: Tiny_Z80 ROM Image File: EZZ80_tiny_std.rom Bus RCBus Default CPU Speed 16.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=24, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=24, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=144, MASTER IDE: MODE=RC, IO=144, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 CTC: IO=16, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED S100 Computers FPGA Z80 SBC An FPGA Z80 based S100 SBC Creator: John Monahan | Website: S100 Computers FPGA Z80 SBC ROM Image File: FZ80_std.rom Bus S100 Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 9600 Baud Memory Manager Z2 ROM Size 0 KB RAM Size 512 KB Supported Hardware FP: LEDIO=255 DS5RTC: RTCIO=104, IO=104 SSER: IO=52 LPT: MODE=S100, IO=199 FV: IO=192, KBD MODE=FV, KBD IO=3 KBD: ENABLED SCON: IO=0 MD: TYPE=RAM PPIDE: IO=48, MASTER PPIDE: IO=48, SLAVE SD: MODE=FZ80, IO=108, UNITS=2 Notes: Requires matching FPGA code Genesis Z180 System A Z180 based board with 512k ram, 512k rom, dual serial / parallel, RTC and SD Card, based on the STD bus. This was inspired on Pulsar Little Big board and some designs of Stephen Cousins Creator: Doug Jackson Specific Links not Available ROM Image File: GMZ180_std.rom Bus STD Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware GM7303: IO=48 DSRTC: MODE=STD, IO=132 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM IDE: MODE=GIDE, IO=32, MASTER IDE: MODE=GIDE, IO=32, SLAVE SD: MODE=GM, IO=132, UNITS=1 Heath H8 Z80 System Turn your H8 into a RomWBW CP/M computer Creator: Les Bird Github Wiki: H8-Z80-ROMWBW-V1.0 ROM Image File: HEATH_std.rom Bus H8 Default CPU Speed 16.384 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware H8P: IO=240 INTRTC: ENABLED UART: IO=232 UART: IO=224 UART: IO=216 UART: IO=208 TMS: MODE=MSX, IO=152, SCREEN=80X24, KEYBOARD=NONE MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE AY38910: MODE=MSX, IO=160, CLOCK=1789772 HZ Z180 Mark IV SBC The Z180 Mark IV is a single board computer, meaning it may run stand-alone. It also has an interface to the RetroBrew bus (ECB) for access to additional peripheral boards. Creator: John Coffman Retrobrew Wiki: Z180 Mark IV ROM Image File: MK4_std.rom Bus ECB Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 38400 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=138 ASCI: IO=64, INTERRUPTS ENABLED ASCI: IO=65, INTERRUPTS ENABLED UART: IO=24 UART: IO=128 UART: IO=192 UART: IO=200 UART: IO=208 UART: IO=216 VGA: IO=224, KBD MODE=PS/2, KBD IO=224 CVDU: MODE=ECB, IO=224, KBD MODE=PS/2, KBD IO=226 KBD: ENABLED PRP: IO=168 PRPCON: ENABLED PRPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DIDE, IO=42, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DIDE, IO=42, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=MK4, IO=128, MASTER IDE: MODE=MK4, IO=128, SLAVE SD: MODE=MK4, IO=137, UNITS=1 NABU w/ RomWBW Option Board No modifications to the NABU motherboard needed. Leave the standard NABU ROM in its socket on the motherboard, no need to remove it. You can switch back to standard NABU mode by changing one jumper on the Option Card Creator: Les Bird Github Wiki: NABU RomWBW Option Card ROM Image File: NABU_std.rom Bus NABU Default CPU Speed 3.580 MHz Interrupts Mode 2 System Timer TMS Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware NABU: IO=64 INTRTC: ENABLED UART: IO=72 TMS: MODE=NABU, IO=160, SCREEN=80X24, KEYBOARD=NABU, INTERRUPTS ENABLED NABUKB: IO=144 MD: TYPE=RAM MD: TYPE=ROM PPIDE: IO=96, MASTER PPIDE: IO=96, SLAVE AY38910: MODE=NABU, IO=65, CLOCK=1789772 HZ Notes: TMS video assumes F18A replacement for TMS9918 Nhyodyne Z80 MBC Nhyodyne: A Modular Backplane Computer (MBC). The purpose of this project is to revisit the design concepts behind my original Z80 SBC (aka test prototype) which has evolved into the SBC V2-005 over several years. Attempt to introduce some new concepts to make the design more modular, flexible, and less expensive. The MBC consists of four core boards: Z80 backplane, Z80 processor, Z80 clock, and Z80 ROM. These are sufficient to build a working system of minimum capability. Creator: Andrew Lynch Retrobrew Forums: Z80 Multi Board Computer Github: NhyoDyne Retrobrew Wiki: Z80 Modular Backplane Computer ROM Image File: MBC_std.rom Bus MBC Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager MBC ROM Size 512 KB RAM Size 512 KB Supported Hardware PKD: IO=96, SIZE=8X1 DSRTC: MODE=STD, IO=112 UART: IO=104 UART: IO=128 UART: IO=136 SIO MODE=ZP, IO=176, CHANNEL A SIO MODE=ZP, IO=176, CHANNEL B PIO: IO=184, CHANNEL A PIO: IO=184, CHANNEL B PIO: IO=188, CHANNEL A PIO: IO=188, CHANNEL B LPT: MODE=SPP, IO=232 CVDU: MODE=MBC, IO=224, KBD MODE=PS/2, KBD IO=226 TMS: MODE=MBC, IO=152, SCREEN=80X24, KEYBOARD=KBD KBD: ENABLED ESP: IO=156 ESPCON: ENABLED ESPSER: DEVICE=0 ESPSER: DEVICE=1 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=MBC, IO=48, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=MBC, IO=48, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=96, MASTER PPIDE: IO=96, SLAVE SPK: IO=112 RetroBrew Z80 RetroBrew Z80 SBC V2 The SBC V2 is a Zilog Z80 processor board. It\u2019s a 100x160mm board that is capable of functioning both as a standalone SBC or as attached to the ECB bus. Previously known as the N8VEM SBC, after Andrews Ham radio call sign, development began in 2006 wth V1 and is currently still in development, it launched a tsunami of developments based on the Euro Card Bus (ECB) standard. Creator: Andrew Lynch Github: SBC-V2-005 (May not be official) Github: SBC-V2-004 Retrobrew Wiki: SBC V2 Blog: Building the SBCV2 Z80 ROM Image File: SBC_std.rom Bus ECB Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager SBC ROM Size 512 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=112 UART: MODE=SBC, IO=104 UART: MODE=CAS, IO=128 UART: MODE=MFP, IO=104 UART: MODE=4UART, IO=192 UART: MODE=4UART, IO=200 UART: MODE=4UART, IO=208 UART: MODE=4UART, IO=216 VGA: IO=224, KBD MODE=PS/2, KBD IO=224 CVDU: MODE=ECB, IO=224, KBD MODE=PS/2, KBD IO=226 CVDU occupies 905 bytes. KBD: ENABLED PRP: IO=168 PRPCON: ENABLED PRPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DIO, IO=54, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DIO, IO=54, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=96, MASTER PPIDE: IO=96, SLAVE RetroBrew Z80 SimH Image for Altair Z80 SimH emulator ROM Image File: SBC_simh.rom Bus - Default CPU Speed 8.000 MHz Interrupts Mode 1 System Timer SimH Serial Default 38400 Baud Memory Manager SBC ROM Size 512 KB RAM Size 512 KB Supported Hardware SIMRTC: IO=254 SSER: IO=109 MD: TYPE=RAM MD: TYPE=ROM HDSK: IO=253, DEVICE COUNT=2 Notes: CPU speed and Serial configuration not relevant in emulator N8 Z180 SBC The N8 is intended to be a \u201chome brew\u201d style computer in the style of early 1980\u2019s all-in-one home computers with a usable set of features such as color graphics, audio, an assortment of mass storage options, a variety of ports, etc. Although a bus expansion is supported no additional boards are required. This configuration is for the N8-2312 and latter (4314) revisions Creator: Andrew Lynch Retrobrew Wiki: The N8 Blog: A Z180 based SBC ROM Image File: N8_std.rom Bus ECB Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 38400 Baud Memory Manager N8 ROM Size 512 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=136 ASCI: IO=64, INTERRUPTS ENABLED ASCI: IO=65, INTERRUPTS ENABLED TMS: MODE=N8, IO=152, SCREEN=40X24, KEYBOARD=PPK PPK: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=N8, IO=140, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=N8, IO=140, DRIVE 1, TYPE=3.5\u201d HD SD: MODE=CSIO, IO=136, UNITS=1 AY38910: MODE=N8, IO=156, CLOCK=1789772 HZ Notes: SD Card interface is configured for CSIO (N8 date code >= 2312) RCBus Z80 RCBus Z80 CPU Module Generic Rom Image. ROM Image File: RCZ80_std.rom Bus RCBus Default CPU Speed 7.372 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 RCBus Z80 CPU Module (KIO) Generic Rom Image. SIO Serial baud rate managed by CTC ROM Image File: RCZ80_kio_std.rom Bus RCBus Default CPU Speed 7.372 MHz Interrupts Mode 2 System Timer CTC Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=136, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=136, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 KIO: IO=128 CTC: IO=132, TIMER MODE=TIMER/16, DIVISOR=9216, HI=256, LO=36, INTERRUPTS ENABLED Z80-512K CPU/RAM/ROM Module Z80-512K is an RCBus and RC2014* compatible module, designed to run RomWBW firmware including CP/M, ZSDOS, and various applications under these OSes. Z80-512K combines functionality of CPU, RAM, and ROM on a single module, thus saving space on the backplane. Creator: Sergey Kiselev Google Groups: Z80-512K Github: Z80-512K ROM Image File: RCZ80_skz_std.rom Bus RCBus Default CPU Speed 7.372 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 ZRC Z80 CPU Module ZRC is derived from the ZoRC experiment. The basic notion is that large RAM and fast serial upload enable a diskless CP/M SBC. However, just in case that idea didn\u2019t work out, ZRC has an optional compact flash interface. The targeted software for ZRC is ROMWBW. ZRC physically contains no ROM and 2MB of RAM. In the STD configuration the first 512KB of RAM is loaded with a ROM image from disk storage and then handled like ROM. Essentially, an area of the RAM is reserved to act as ROM. Creator: Bill Shen Retrobrew Wiki: ZRC, Z80 RAM CPLD for ROMWBW Google Groups: ZRC, Z80/RAM/CPLD, minimal CP/M-ready, Z80 SBC ROM Image File: RCZ80_zrc_std.rom Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager ZRC ROM Size 512 KB RAM Size 1536 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 ZRC Z80 CPU Module (RAM) This profile differs (from STD) only in how the system boots, and how RAM is configured. Boot occurs directly to RAM, loading HBIOS directly from disk storage rather than via a pseudo ROM image copied into RAM. A RAM disk is configured preloaded with files that would normally be on the ROM disk. There is no ROM disk in this configuration. The RAM config is the newer approach and provides a more efficient bank layout. The intent to replace the STD config with the RAM config. Creator: Bill Shen ROM Image File: RCZ80_zrc_ram_std.rom Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager ZRC ROM Size 0 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 ZRC512 Z80 CPU Module ZRC512 is a faster and hobbyist-friendly variant of ZRC. It is designed specifically for ROM-less RomWBW. HBIOS is loaded from disk at boot Creator: Bill Shen Google Groups: Bill Shen\u2019s ZRC512 SBC / RC2014 board Retrobrew Wiki: ZRC512, A Hobbyist-friendly Z80 SBC for ROM-less RomWBW ROM Image File: RCZ80_zrc512_std.rom Bus RCBus Default CPU Speed 22.000 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager ZRC ROM Size 0 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 EaZy80-512 Z80 CPU Module Eazy80-512 is Eazy80 rev2 pc board configured with 512K RAM to run RomWBW. The design was derived from modifications to Eazy80 Rev1 that supported RomWBW. HBIOS is loaded from disk at boot by ROM monitor (Not to be confused with EasyZ80) Creator: Bill Shen VCF Forums: Eazy80, a glue-less, CP/M capable Z80 SBC Retrobrew Wiki: Eazy80 Rev2, Glue-less Configuration Google Groups: EaZy80, A Simple80 with KIO ROM Image File: RCZ80_ez512_std.rom Bus RCBus Default CPU Speed 22.000 MHz Interrupts Mode 2 System Timer None Serial Default 115200 Baud Memory Manager EZ512 ROM Size 0 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=192 SIO MODE=STD, IO=8, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=8, CHANNEL B, INTERRUPTS ENABLED MD: TYPE=RAM MD occupies 409 bytes. SD: MODE=EZ512, IO=2, UNITS=1 KIO: IO=0 CTC: IO=4 K80W Z80 CPU Module K80W is similar to K80. It is a 22MHz Z80 SBC with KIO (Z84C90) as the I/O device. It is designed to run RomWBW. The current version is rev 2.1 replacing the older K80W rev 1 Creator: Bill Shen Retrobrew Wiki: K80W Rev2.1, A RomWBW-capable Z80 SBC ROM Image File: RCZ80_k80w_std.rom Bus RCBus Default CPU Speed 22.000 MHz Interrupts Mode 2 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=K80W, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=136, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=136, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=EZ512, IO=130, UNITS=1 KIO: IO=128 CTC: IO=132 RCBus Z180 RCBus Z180 CPU Module (External) Generic Rom Image. For use with Z2 bank switched memory board (Z2 external memory management) ROM Image File: RCZ180_ext_std.rom Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 RCBus Z180 CPU Module (Native) Generic Rom Image. For use with linear memory board (Z180 native memory management) ROM Image File: RCZ180_nat_std.rom Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 Z1RCC Z180 CPU Module Z1RCC is a 2\u201cx4\u201d RomWBW-capable Z180 SBC. Z1RCC has no flash memory on board but has a small (64 bytes) bootstrap ROM in CPLD so that Z180 boots from this bootstrap ROM, copies a loader from CF disk to top 32K of RAM, runs the loader to bring in the 480K RomWBW image from CF disk, then start RomWBW from 0x0 Creator: Bill Shen Google Groups: RomWBW for Z80 with 512K RAM 0K ROM Retrobrew Wiki: Z1RCC, A RC2014-Compatible, RomWBW-Capable Z180 SBC ROM Image File: RCZ180_z1rcc_std.rom Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 0 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 RCBus Z280 RCBus Z280 CPU Module (External) Generic Rom Image. For use with Z2 bank switched memory board (Z2 external memory management) ROM Image File: RCZ280_ext_std.rom Bus RCBus Default CPU Speed 12.000 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 RCBus Z280 CPU Module (Native) Generic Rom Image. For use with linear memory board (Z280 native memory management) ROM Image File: RCZ280_nat_std.rom Bus RCBus Default CPU Speed 12.000 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 ZZRCC Z280 CPU Module ZZRCC follows the basic concept of ZRCC that uses a small CPLD to bootstrap from CF disk. Because Z280 has a native serial-bootstrap capability, the CPLD is even simpler than that of ZRCC. ZZRCC is Z280 operating in Z80-compatible mode. It is designed for RC2014 bus ZZRCC actually contains no ROM and 512KB of RAM. In the STD configuration the first 256KB of RAM is loaded with a ROM image from disk storage and then handled like ROM. Essentially, an area of the RAM is reserved to act as ROM. Creator: Bill Shen Retrobrew Wiki: ZZRCC, a SBC for RC2014 based on Z280 Google Groups: ZZRCC, Z280 SBC replacing ZZ80RC and ZZ80CF Google Groups: Help porting ROMWBW to ZZRCC ROM Image File: RCZ280_zzrcc_std.rom Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 256 KB RAM Size 256 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE ZZRCC Z280 CPU Module (RAM) This profile differs (from STD) only in how the system boots, and how RAM is configured. Boot occurs directly to RAM, loading HBIOS directly from disk storage rather than via a pseudo ROM image copied into RAM. A RAM disk is configured preloaded with files that would normally be on the ROM disk. There is no ROM disk in this configuration. The RAM config is the newer approach and provides a more efficient bank layout. The intent to replace the STD config with the RAM config. Creator: Bill Shen ROM Image File: RCZ280_zzrcc_ram_std.rom Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 0 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE ZZ80MB Z280 SBC ZZ80MB is a Z280-based motherboard with RC2014 expansion slots. It is based on the ZZ80RC-CF design, but with two additional expansion slots added. ZZ80MB is designed with an EPROM programmer function such that it can boot from serial port, load EPROM programming image through the serial port and program an EPROM. This feature can be used to program EPROM for other computers Creator: Bill Shen Retrobrew Wiki: ZZ80MB, A Z280-based SBC with RC2014 Expansion ROM Image File: RCZ280_zz80mb_std.rom Bus RCBus Default CPU Speed 12.000 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE eZ80 for RCBus Module The eZ80 for RCBus/RC2014 is a module designed for the RCBus and RC2014 backplanes. Its designed as a \u2018compatible upgrade\u2019 to the stock Z80 CPU. The eZ80 is a CPU that was first released by Zilog about 20 years ago, and still available from the manufacturer today Creator: Dean Netherton Github: eZ80 for the RCBus/RC2014 Hackaday: eZ80 CPU for RC2014 and other backplanes ROM Image File: RCEZ80_std.rom Bus RCBus Default CPU Speed 20.000 MHz Interrupts Mode 1 System Timer EZ80 Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE EZ80: CPU DRIVER EZ80: SYS TIMER DRIVER EZ80: RTC DRIVER EZ80: UART DRIVER Rhyophyre Z180 SBC Single Board Computer featuring Zilog Z180 processor and NEC \u00b5PD7220 Graphics Display Controller Creator: Andrew Lynch Retrobrew Forums: Z180 upd7220 GDC SBC Github: rhyophyre ROM Image File: RPH_std.rom Bus - Default CPU Speed 18.432 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager RPH ROM Size 512 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=132 ASCI: IO=64 ASCI: IO=65 GDC: MODE=RPH, DISPLAY=EGA, IO=144 KBD: ENABLED MD: TYPE=RAM MD: TYPE=ROM PPIDE: IO=136, MASTER PPIDE: IO=136, SLAVE S100 Computers Z180 SBC A Z180 board which contains a flash RAM, a USB port interface and an SD Card that can immediately boot up CPM. While it is on an S100 Bus board, initially that board has only 8 significant chips and works as a self contained computer outside the bus with a simple 9V power supply. Later on it can be built up further with more chips, placed in an S100 bus and one by one programed to interface with the 100\u2019s of S100 bus cards that are out there. It can in fact behave as a S100 bus master or slave as defined by the IEEE-696 specs. Creator: John Monahan | Website: S100 Computers Z180 SBC ROM Image File: S100_std.rom Bus S100 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 57600 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED SCON: IO=0 MD: TYPE=RAM MD: TYPE=ROM SD: MODE=SC, IO=12, UNITS=1 Notes: Z180 SBC SW2 (IOBYTE) Dip Switches: Bit Setting Function 0 Off Use Z180 ASCI Channel A for console On Use Propeller Console 1 Off Boot to RomWBW Boot Loader On Boot to S100 Monitor Small Computer Central Z180 Small Computer Central provides an extensive range hardware based around the Zilog ecosystem. This section lists configurations specifically for the Z180 processor If you are using a Z80 processor you will probably be using the general RCZ80_std configuration - RCBus Z80 CPU Module . However, please consult Firmware, RomWBW, RCZ80_std for further information and to ensure compatibility with your Z80 system. Creator: Stephen Cousins Website: Small Computer Central SC126 Z180 SBC SC126 is a Z180 Motherboard. Website: SC126 \u2013 Z180 Motherboard ROM Image File: SCZ180_sc126_std.rom Bus BP80 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=13, SWIO=0 DSRTC: MODE=STD, IO=12 ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1 Notes: When disabled, watchdog requires /IM to be pulsed. If an RCBus module holds the CPU in WAIT for more than this, the watchdog will fire when disabled with random consequences. The Pico SD does this at power-on. SC130 Z180 SBC SC130 is an entry-level Z180 Motherboard designed primarily to run RomWBW (and CP/M) Website: SC130 \u2013 Z180 Motherboard ROM Image File: SCZ180_sc130_std.rom Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1 SC131 Z180 Pocket Comp SC131 is a pocket-sized Z180 RomWBW CP/M computer. Website: SC131 \u2013 Z180 Pocket Computer ROM Image File: SCZ180_sc131_std.rom Bus - Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM SD: MODE=SC, IO=12, UNITS=1 SC140 Z180 CPU Module SC140 is a Z180 SBC / Z50Bus Card card. Website: SC140 \u2013 Z180 SBC / Z50Bus Card ROM Image File: SCZ180_sc140_std.rom Bus Z50 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=160, SWIO=160 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=144, MASTER IDE: MODE=RC, IO=144, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1 SC503 Z180 CPU Module SC503 is a Z180 Processor card designed for Z50Bus. Website: SC503 \u2013 Z180 Processor (Z50Bus) ROM Image File: SCZ180_sc503_std.rom Bus Z50 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=160, SWIO=160 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=144, MASTER IDE: MODE=RC, IO=144, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1 SC700 Z180 CPU Module This configuration is specifically for systems based on the Z180 CPU (eg. SC722) with 1MB linear memory (eg. SC721) Website: SC700 Series Website: SC721 \u2013 RCBus Memory Module Website: SC722 \u2013 RCBus Z180 CPU Module ROM Image File: SCZ180_sc700_std.rom Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB Supported Hardware FP: LEDIO=0 LCD: IO=170, SIZE=20X4 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1 `{=latex} Z80-Retro SBC The system comprises a Z80 retro computer board, and optonal VGA text video card, and PIO Keyboard and Sound Card. The system uses a custom 60 pin bus on a standard header. (Not to be confused with a similar named project by John Winans presented by John\u2019s Basement on youTube) Creator: Peter Wilson Github: Z80-Retro Github Wiki: Welcome to the Z80-Retro wiki! OSHWLab: Simple Z80 SBC ROM Image File: Z80RETRO_std.rom Bus 60 pin Default CPU Speed 14.745 MHz Interrupts Mode 2 System Timer None Serial Default 38400 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware SIO MODE=Z80R, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=Z80R, IO=128, CHANNEL B, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM SD: MODE=Z80R, IO=104, UNITS=1 Zeta Z80 SBC Zeta SBC is an Zilog Z80 based single board computer. It is inspired by Ampro Little Board Z80 and N8VEM project. Zeta SBC is software compatible with N8VEM SBC and Disk I/O boards. Creator: Sergey Kiselev Retrobrew Wiki: Zeta SBC ROM Image File: ZETA_std.rom Bus - Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager SBC ROM Size 512 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=112 UART: IO=104 PPP: IO=96 PPPCON: ENABLED PPPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DIO, IO=54, DRIVE 0, TYPE=3.5\u201d HD Notes: If ParPortProp is installed, initial console output is determined by JP1: Shorted: console to on-board serial port Open: console to ParPortProp video and keyboard Zeta V2 Z80 SBC Zeta SBC V2 is a redesigned version of Zeta SBC. Compared to the first version this version features updated MMU with four banks, each one of those banks can be mapped to any 16 KiB page in 1 MiB on-board memory. It adds Z80 CTC which is used for generating periodic interrupts and as a vectored interrupt controller for UART and PPI. The FDC is replaced with 37C65. Compared to FDC9266 used in Zeta SBC it integrates input/output buffers and floppy disk control latch. Additionally 37C65 FDC is easier to obtain than FDC9266. And lastly it is made using CMOS technology and more power efficient than FDC9266 Creator: Sergey Kiselev Github: Zeta SBC V2 Retrobrew Wiki: Zeta SBC V2 ROM Image File: ZETA2_std.rom Bus - Default CPU Speed 8.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 38400 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB Supported Hardware DSRTC: MODE=STD, IO=112 UART: IO=104 PPP: IO=96 PPPCON: ENABLED PPPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=ZETA2, IO=48, DRIVE 0, TYPE=3.5\u201d HD CTC: IO=32, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED Notes: If ParPortProp is installed, initial console output is determined by JP1: Shorted: console to on-board serial port Open: console to ParPortProp video and keyboard Device Drivers This section briefly describes each of the possible devices that may be discovered by RomWBW in your system. Character ID Description ACIA MC68B50 Asynchronous Communications Interface Adapter ASCI Zilog Z180 CPU Built-in Serial Ports DUART SCC2681 or compatible Dual UART ESPCON ESP32 Firmware-based Video Console ESPSER ESP32 Firmware-based Serial Interface EZ80UART eZ80 Serial Interface LPT Parallel I/O Controller PIO Zilog Parallel Interface Controller PPPCON ParPortProp Serial Console Interface PRPCON PropIO Serial Console Interface SCON S100 Console SIO Zilog Serial Port Interface SSER Simple Serial Interface UART 16C550 Family Serial Interface USB-FIFO FT232H-based ECB USB FIFO Z2U Zilog Z280 CPU Built-in Serial Ports By default, RomWBW will use the first available character device it discovers for the initial console. The following character devices are scanned in the order shown. The available character devices depend on the active platform and configuration. SSER: Simple Serial Interface ASCI: Zilog Z180 CPU Built-in Serial Ports Z2U: Zilog Z280 CPU Built-in Serial Ports UART: 16C550 Family Serial Interface DUART: SCC2681 or compatible Dual UART SIO: Zilog Serial Port Interface EZ80UART: eZ80 Serial Port Interface ACIA: MC68B50 Asynchronous Communications Interface Adapter USB-FIFO: FT232H-based ECB USB FIFO Disk ID Description CHSD CH37x SD Card Interface CHUSB CH37x USB Drive Interface FD Intel 8272 or compatible Floppy Disk Controller HDSK SIMH Simulator Hard Disk IDE IDE/ATA/ATAPI Hard Disk Interface IMM Zip Drive on PPI (IMM variant) MD ROM/RAM Disk PPA Zip Drive on PPI (PPA variant) PPIDE 8255 IDE/ATA/ATAPI Hard Disk Interface PPPSD ParPortProp SD Card Interface PRPSD PropIO SD Card Interface RF RAM Floppy Disk Interface SD SD Card Interface SYQ Iomega SparQ Drive on PPI Video ID Description CVDU MC8563-based Video Display Controller EF EF9345 Video Display Controller FV S100 FPGA Z80 Onboard VGA/Keyboard GDC uPD7220 Video Display Controller TMS TMS9918/38/58 Video Display Controller VDU MC6845 Family Video Display Controller (*) VGA HD6445CP4-based Video Display Controller VRC VGARC Video Display Controller Note: Reading bytes from the video memory of the VDU board (not Color VDU) appears to be problematic. This is only an issue when the driver needs to scroll a portion of the screen which is done by applications such as WordStar or ZDE. You are likely to see screen corruption in this case. Keyboard ID Description KBD 8242 PS/2 Keyboard Controller MSXKYB MSX Compliant Matrix Keyboard NABUKB NABU Keyboard PPK Matrix Keyboard Audio ID Description AY AY-3-8910/YM2149 Programmable Sound Generator SN76489 SN76489 Programmable Sound Generator SPK Bit-bang Speaker YM YM2612 Programmable Sound Generator RTC (RealTime Clock) ID Description BQRTC BQ4845P Real Time Clock DS5RTC Maxim DS1305 SPI Real-Time Clock w/ NVRAM DS7RTC Maxim DS1307 PCF I2C Real-Time Clock w/ NVRAM DS1501RTC Maxim DS1501/DS1511 Watchdog Real-Time Clock DSRTC Maxim DS1302 Real-Time Clock w/ NVRAM EZ80RTC eZ80 Real-Time Clock INTRTC Interrupt-based Real Time Clock PCF PCF8584-based I2C Real-Time Clock RP5C01 Ricoh RPC01A Real-Time Clock w/ NVRAM SIMRTC SIMH Simulator Real-Time Clock DsKy (DiSplay KeYpad) ID Description FP Simple LED & Switch Front Panel GM7303 Prolog 7303 derived Display/Keypad H8P Heath H8 Display/Keypad ICM ICM7218-based Display/Keypad on PPI LCD Hitachi HD44780-based LCD Display PKD P8279-based Display/Keypad on PPI System ID Description CH CH375/376 USB Interface Controller CTC Zilog Clock/Timer DMA Zilog DMA Controller ESP ESP32 Firmware-based interface EZ80TIMER eZ80 System Timer KIO Zilog Serial/ Parallel Counter/Timer (Z84C90) PPP ParPortProp Host Interface Controller PRP PropIO Host Interface Controller UNA Hardware BIOS John Coffman has produced a new generation of hardware BIOS called UNA. The standard RomWBW distribution includes its own hardware BIOS. However, RomWBW can alternatively be constructed with UNA as the hardware BIOS portion of the ROM. If you wish to use the UNA variant of RomWBW, then just program your ROM with the ROM image called \u201cUNA_std.rom\u201d in the Binary directory. This one image is suitable on all of the platforms and hardware UNA supports. UNA is customized dynamically using a ROM based setup routine and the setup is persisted in the system NVRAM of the RTC chip. This means that the single UNA-based ROM image can be used on most of the RetroBrew platforms and is easily customized. UNA also supports FAT file system access that can be used for in-situ ROM programming and loading system images. While John is likely to enhance UNA over time, there are currently a few things that UNA does not support: Floppy Drives Terminal Emulation Zeta 1, N8, RCBus, Easy Z80, and Dyno Systems Some older support boards The UNA version embedded in RomWBW is the latest production release of UNA. RomWBW will be updated with John\u2019s upcoming UNA release with support for VGA3 as soon as it reaches production status. Please refer to the UNA BIOS Firmware Page for more information on UNA. UNA Usage Notes At startup, UNA will display a prompt similar to this: Boot UNA unit number or ROM? [R,X,0..3] (R): You generally want to choose \u2018R\u2019 which will then launch the RomWBW loader. Attempting to boot from a disk using a number at the UNA prompt will only work for the legacy (hd512) disk format. However, if you go to the RomWBW loader, you will be able to perform a disk boot on either disk format. The disk images created and distributed with RomWBW do not have the correct system track code for UNA. In order to boot to disk under UNA, you must first use SYSCOPY to update the system track of the target disk. The UNA ROM disk has the correct system track files for UNA: CPM.SYS and ZSYS.SYS . So, you can boot a ROM OS and then use one of these files to update the system track. The only operating systems supported at this time are CP/M 2 and ZSDOS. NZ-COM is also supported because it uses the ZSDOS CBIOS. None of the other RomWBW operating systems are supported such as CP/M 3, ZPM3, and p-System. Some of the RomWBW-specific applications are not UNA compatible.","title":"Hardware"},{"location":"Hardware/#overview","text":"","title":"Overview"},{"location":"Hardware/#supported-platforms","text":"This section contains a summary of the system configuration target for each of the pre-built ROM images included in the RomWBW distribution. It is intended to help you select the correct ROM image and understand the basic hardware components supported. Detailed hardware system configuration information should be obtained from your system provider/designer. The table below summarizes the hardware platforms currently supported by RomWBW along with the standard pre-built ROM image(s).","title":"Supported Platforms"},{"location":"Hardware/#rcbus-general-configurations","text":"RCBus refers to Spencer Owen\u2019s RC2014 bus specification and derivatives including RC26, RC40, RC80, and BP80. Description Bus ROM Image File Baud Rate RCBus Z80 CPU Module , 512K RAM/ROM RCBus RCZ80_std.rom 115200 RCBus Z80 CPU Module (KIO) , 512K w/KIO RCBus RCZ80_kio_std.rom 115200 RCBus Z180 CPU Module (External) RCBus RCZ180_ext_std.rom 115200 RCBus Z180 CPU Module (Native) RCBus RCZ180_nat_std.rom 115200 RCBus Z280 CPU Module (External) RCBus RCZ280_ext_std.rom 115200 RCBus Z280 CPU Module (Native) RCBus RCZ280_nat_std.rom 115200 KIO refers to a Zilog specific Serial/Parallel Counter/Timer (Z84C90). The RCBus Z180 & Z280 require a separate RAM/ROM memory module. There are two types of these modules, you must pick the correct ROM for your type of memory module: The first type of RAM/ROM module includes Z2 style memory bank switching on the memory module itself. This is called \u201cExternal\u201d (ext) because the bank switching is external from the CPU itself. The second type of RAM/ROM module has no bank switching logic on the memory module. Bank switching is implemented via the Z180 or Z280 MMU \u2013 this is called \u201cNative\u201d (nat) because the CPU itself provides the bank switching logic. Only Z180 and Z280 CPUs have the ability to do bank switching in the CPU, so the ext/nat selection only applies to them. Z80 CPUs have no built-in bank switching logic, so they always require a RAM/ROM module with Z2 style bank switching and the ROMs are always configured for external bank switching.","title":"RCBUS - General Configurations"},{"location":"Hardware/#custom-specific-configurations","text":"Andrew Lynch Description Bus ROM Image File Baud Rate RetroBrew Z80 SBC V2 ECB SBC_std.rom 38400 RetroBrew Z80 SimH - SBC_simh.rom 38400 Duodyne Z80 System Duo DUO_std.rom 38400 Nhyodyne Z80 MBC MBC MBC_std.rom 38400 Rhyophyre Z180 SBC - RPH_std.rom 38400 N8 Z180 SBC (date >= 2312) ECB N8_std.rom 38400 Bill Shen Description Bus ROM Image File Baud Rate EaZy80-512 Z80 CPU Module RCBus RCZ80_ez512_std.rom 115200 K80W Z80 CPU Module RCBus RCZ80_k80w_std.rom 115200 ZRC Z80 CPU Module RCBus RCZ80_zrc_std.rom 115200 ZRC Z80 CPU Module (RAM) RCBus RCZ80_zrc_ram_std.rom 115200 ZRC512 Z80 CPU Module RCBus RCZ80_zrc512_std.rom 115200 Z1RCC Z180 CPU Module RCBus RCZ180_z1rcc_std.rom 115200 ZZRCC Z280 CPU Module RCBus RCZ280_zzrcc_std.rom 115200 ZZRCC Z280 CPU Module (RAM) RCBus RCZ280_zzrcc_ram_std.rom 115200 ZZ80MB Z280 SBC RCBus RCZ280_zz80mb_std.rom 115200 Sergey Kiselev Description Bus ROM Image File Baud Rate Easy Z80 SBC RCBus EZZ80_easy_std.rom 115200 Tiny Z80 SBC RCBus EZZ80_tiny_std.rom 115200 Z80-512K CPU/RAM/ROM Module RCBus RCZ80_skz_std.rom 115200 Zeta Z80 SBC , ParPortProp - ZETA_std.rom 38400 Zeta V2 Z80 SBC , ParPortProp - ZETA2_std.rom 38400 Stephen Cousins Description Bus ROM Image File Baud Rate SC126 Z180 SBC BP80 SCZ180_sc126_std.rom 115200 SC130 Z180 SBC RCBus SCZ180_sc130_std.rom 115200 SC131 Z180 Pocket Comp - SCZ180_sc131_std.rom 115200 SC140 Z180 CPU Module Z50 SCZ180_sc140_std.rom 115200 SC503 Z180 CPU Module Z50 SCZ180_sc503_std.rom 115200 SC700 Z180 CPU Module RCBus SCZ180_sc700_std.rom 115200 Others Description Bus ROM Image File Baud Rate Dyno Z180 SBC 6 Dyno DYNO_std.rom 38400 EP Mini-ITX Z180 11 UEXT EPITX_std.rom 115200 eZ80 for RCBus Module 13 , 512K RAM/ROM RCBus RCEZ80_std.rom 115200 Genesis Z180 System 12 STD GMZ180_std.rom 115200 Heath H8 Z80 System 10 H8 HEATH_std.rom 115200 NABU w/ RomWBW Option Board 10 NABU NABU_std.rom 115200 S100 Computers Z180 SBC 9 S100 S100_std.rom 57600 S100 Computers FPGA Z80 SBC 9 S100 FZ80_std.rom 9600 UNA Hardware BIOS 3 - UNA_std.rom - Z80-Retro SBC 8 - Z80RETRO_std.rom 38400 Z180 Mark IV SBC 3 ECB MK4_std.rom 38400 3 Designed by John Coffman 6 Designed by Steve Garcia 8 Designed by Peter Wilson 9 Designed by John Monahan 10 Designed by Les Bird 11 Designed by Alan Cox 12 Designed by Doug Jackson 13 Designed by Dean Netherton","title":"Custom / Specific Configurations"},{"location":"Hardware/#general-guidance","text":"The standard ROM images will detect and install support for certain devices and peripherals that are on-board or frequently used with each platform. If the device or peripheral is not detected at boot, the ROM will simply bypass support appropriately. Each ROM will support a single memory manager. This is determined by the build configuration and is not dynamically selected. The use of the term Memory Manager is generally synonymous with Memory Management Unit (MMU). In some cases, support for multiple hardware components with potentially conflicting resource usage are handled by a single ROM image. It is up to the user to ensure that no conflicting hardware is in use. CPU speed will be dynamically measured at startup if DSRTC is present All pre-built ROM images are pure binary files (they are not \u201chex\u201d files). They are intended to be programmed starting at the very start of the ROM chip (address 0). Most of the pre-built images are 512KB in size. If your system utilizes a larger ROM, you can just program the image into the first 512KB of the ROM for now. For this document port addresses IO=xxx are represented in decimal. The PropIO support is based on RomWBW specific firmware. Be sure to program/update your PropIO firmware with the corresponding firmware image provided in the Binary directory of the RomWBW distribution. The use of high density floppy disks requires a CPU speed of 8 MHz or greater.","title":"General Guidance"},{"location":"Hardware/#platform-configurations","text":"","title":"Platform Configurations"},{"location":"Hardware/#duodyne-z80-system","text":"Duodyne is a third generation ROMWBW focused retrocomputer incorporating lessons learned and improvements from my original ECB Z80 SBC (aka N8VEM) and the nhyodyne modular computer. It is literally designed around ROMWBW from the start for a robust OS and software environment. Duodyne is a new design which integrates many functions into larger, modular boards on a backplane. The intent is to create a powerful and capable system like an SBC, but with modularity and an expandable backplane. Creator: Andrew Lynch Retrobrew Forums: Introducing duodyne retrocomputer Github: DuoDyne","title":"Duodyne Z80 System"},{"location":"Hardware/#rom-image-file-duo_stdrom","text":"Bus Duo Default CPU Speed 8.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 38400 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: DUO_std.rom"},{"location":"Hardware/#supported-hardware","text":"FP: LEDIO=66, SWIO=66 DSRTC: MODE=STD, IO=148 PCF: IO=86 UART: IO=88 UART: IO=168 UART: IO=112 UART: IO=120 SIO MODE=ZP, IO=96, CHANNEL A, INTERRUPTS ENABLED SIO MODE=ZP, IO=96, CHANNEL B, INTERRUPTS ENABLED LPT: MODE=SPP, IO=72 DMA: MODE=DUO, IO=64 CH: IO=78 CHUSB: IO=78 CHSD: IO=78 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DUO, IO=128, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DUO, IO=128, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=136, MASTER PPIDE: IO=136, SLAVE SD: MODE=MT, IO=140, UNITS=1 SPK: IO=148 CTC: IO=96, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED","title":"Supported Hardware"},{"location":"Hardware/#dyno-z180-sbc","text":"The Dyno Computer is a Zilog Z180-based computer initially designed to run Wayne Warthen\u2019s ROMWBW Creator: Steve Garc\u00eda Google Groups: An Introduction Website: Dyno Computer","title":"Dyno Z180 SBC"},{"location":"Hardware/#rom-image-file-dyno_stdrom","text":"Bus Dyno\u2022Bus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 38400 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: DYNO_std.rom"},{"location":"Hardware/#supported-hardware_1","text":"BQRTC: IO=80 ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DYNO, IO=132, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DYNO, IO=132, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=76, MASTER PPIDE: IO=76, SLAVE","title":"Supported Hardware"},{"location":"Hardware/#ep-mini-itx-z180","text":"EtchedPixels Z180 Mini-ITX. The SC126 was almost my ideal retrobrew Z80/Z180 system but with a couple of niggles and lack of a convenient case option. This is the same core Z180 CPU/RAM/ROM design taken the other direction, of expandability. Creator: Alan Cox Google Groups: Another new board Github: Z180MiniITX","title":"EP Mini-ITX Z180"},{"location":"Hardware/#rom-image-file-epitx_stdrom","text":"Bus RCBus + UEXT Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: EPITX_std.rom"},{"location":"Hardware/#supported-hardware_2","text":"INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=160 UART: IO=168 TMS: MODE=MSX, IO=152, SCREEN=40X24, KEYBOARD=NONE MD: TYPE=RAM MD: TYPE=ROM FD: MODE=EPFDC, IO=72, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=EPFDC, IO=72, DRIVE 1, TYPE=3.5\u201d HD SD: MODE=EPITX, IO=66, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#easytiny-z80","text":"","title":"Easy/Tiny Z80"},{"location":"Hardware/#easy-z80-sbc","text":"This project is a simple, easy to understand, yet capable single board computer. It reuses the same memory paging mechanism I\u2019ve implemented in Zeta SBC V2. It uses Zilog Z80 SIO/O and Z80 CTC peripheral ICs and implements daisy chain mode 2 interrupt configuration (Not to be confused with EaZy80) Creator: Sergey Kiselev Google Groups: Easy Z80 - Single Board Computer Github: Easy_Z80","title":"Easy Z80 SBC"},{"location":"Hardware/#rom-image-file-ezz80_easy_stdrom","text":"Bus RCBus Default CPU Speed 10.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: EZZ80_easy_std.rom"},{"location":"Hardware/#supported-hardware_3","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 CTC: IO=136, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED","title":"Supported Hardware"},{"location":"Hardware/#tiny-z80-sbc","text":"Tiny Z80 is a business card sized (size?!) single board computer (SBC). It is mostly compatible with Easy Z80, and offers similar capabilities Tiny Z80 includes a USB to Serial converter IC on board connected to one of the SIO ports, for ease of use with modern computers. Creator: Sergey Kiselev Github: Tiny_Z80","title":"Tiny Z80 SBC"},{"location":"Hardware/#rom-image-file-ezz80_tiny_stdrom","text":"Bus RCBus Default CPU Speed 16.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: EZZ80_tiny_std.rom"},{"location":"Hardware/#supported-hardware_4","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=24, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=24, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=144, MASTER IDE: MODE=RC, IO=144, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 CTC: IO=16, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED","title":"Supported Hardware"},{"location":"Hardware/#s100-computers-fpga-z80-sbc","text":"An FPGA Z80 based S100 SBC Creator: John Monahan | Website: S100 Computers FPGA Z80 SBC","title":"S100 Computers FPGA Z80 SBC"},{"location":"Hardware/#rom-image-file-fz80_stdrom","text":"Bus S100 Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 9600 Baud Memory Manager Z2 ROM Size 0 KB RAM Size 512 KB","title":"ROM Image File: FZ80_std.rom"},{"location":"Hardware/#supported-hardware_5","text":"FP: LEDIO=255 DS5RTC: RTCIO=104, IO=104 SSER: IO=52 LPT: MODE=S100, IO=199 FV: IO=192, KBD MODE=FV, KBD IO=3 KBD: ENABLED SCON: IO=0 MD: TYPE=RAM PPIDE: IO=48, MASTER PPIDE: IO=48, SLAVE SD: MODE=FZ80, IO=108, UNITS=2","title":"Supported Hardware"},{"location":"Hardware/#notes","text":"Requires matching FPGA code","title":"Notes:"},{"location":"Hardware/#genesis-z180-system","text":"A Z180 based board with 512k ram, 512k rom, dual serial / parallel, RTC and SD Card, based on the STD bus. This was inspired on Pulsar Little Big board and some designs of Stephen Cousins Creator: Doug Jackson Specific Links not Available","title":"Genesis Z180 System"},{"location":"Hardware/#rom-image-file-gmz180_stdrom","text":"Bus STD Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: GMZ180_std.rom"},{"location":"Hardware/#supported-hardware_6","text":"GM7303: IO=48 DSRTC: MODE=STD, IO=132 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM IDE: MODE=GIDE, IO=32, MASTER IDE: MODE=GIDE, IO=32, SLAVE SD: MODE=GM, IO=132, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#heath-h8-z80-system","text":"Turn your H8 into a RomWBW CP/M computer Creator: Les Bird Github Wiki: H8-Z80-ROMWBW-V1.0","title":"Heath H8 Z80 System"},{"location":"Hardware/#rom-image-file-heath_stdrom","text":"Bus H8 Default CPU Speed 16.384 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: HEATH_std.rom"},{"location":"Hardware/#supported-hardware_7","text":"H8P: IO=240 INTRTC: ENABLED UART: IO=232 UART: IO=224 UART: IO=216 UART: IO=208 TMS: MODE=MSX, IO=152, SCREEN=80X24, KEYBOARD=NONE MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE AY38910: MODE=MSX, IO=160, CLOCK=1789772 HZ","title":"Supported Hardware"},{"location":"Hardware/#z180-mark-iv-sbc","text":"The Z180 Mark IV is a single board computer, meaning it may run stand-alone. It also has an interface to the RetroBrew bus (ECB) for access to additional peripheral boards. Creator: John Coffman Retrobrew Wiki: Z180 Mark IV","title":"Z180 Mark IV SBC"},{"location":"Hardware/#rom-image-file-mk4_stdrom","text":"Bus ECB Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 38400 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: MK4_std.rom"},{"location":"Hardware/#supported-hardware_8","text":"DSRTC: MODE=STD, IO=138 ASCI: IO=64, INTERRUPTS ENABLED ASCI: IO=65, INTERRUPTS ENABLED UART: IO=24 UART: IO=128 UART: IO=192 UART: IO=200 UART: IO=208 UART: IO=216 VGA: IO=224, KBD MODE=PS/2, KBD IO=224 CVDU: MODE=ECB, IO=224, KBD MODE=PS/2, KBD IO=226 KBD: ENABLED PRP: IO=168 PRPCON: ENABLED PRPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DIDE, IO=42, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DIDE, IO=42, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=MK4, IO=128, MASTER IDE: MODE=MK4, IO=128, SLAVE SD: MODE=MK4, IO=137, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#nabu-w-romwbw-option-board","text":"No modifications to the NABU motherboard needed. Leave the standard NABU ROM in its socket on the motherboard, no need to remove it. You can switch back to standard NABU mode by changing one jumper on the Option Card Creator: Les Bird Github Wiki: NABU RomWBW Option Card","title":"NABU w/ RomWBW Option Board"},{"location":"Hardware/#rom-image-file-nabu_stdrom","text":"Bus NABU Default CPU Speed 3.580 MHz Interrupts Mode 2 System Timer TMS Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: NABU_std.rom"},{"location":"Hardware/#supported-hardware_9","text":"NABU: IO=64 INTRTC: ENABLED UART: IO=72 TMS: MODE=NABU, IO=160, SCREEN=80X24, KEYBOARD=NABU, INTERRUPTS ENABLED NABUKB: IO=144 MD: TYPE=RAM MD: TYPE=ROM PPIDE: IO=96, MASTER PPIDE: IO=96, SLAVE AY38910: MODE=NABU, IO=65, CLOCK=1789772 HZ","title":"Supported Hardware"},{"location":"Hardware/#notes_1","text":"TMS video assumes F18A replacement for TMS9918","title":"Notes:"},{"location":"Hardware/#nhyodyne-z80-mbc","text":"Nhyodyne: A Modular Backplane Computer (MBC). The purpose of this project is to revisit the design concepts behind my original Z80 SBC (aka test prototype) which has evolved into the SBC V2-005 over several years. Attempt to introduce some new concepts to make the design more modular, flexible, and less expensive. The MBC consists of four core boards: Z80 backplane, Z80 processor, Z80 clock, and Z80 ROM. These are sufficient to build a working system of minimum capability. Creator: Andrew Lynch Retrobrew Forums: Z80 Multi Board Computer Github: NhyoDyne Retrobrew Wiki: Z80 Modular Backplane Computer","title":"Nhyodyne Z80 MBC"},{"location":"Hardware/#rom-image-file-mbc_stdrom","text":"Bus MBC Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager MBC ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: MBC_std.rom"},{"location":"Hardware/#supported-hardware_10","text":"PKD: IO=96, SIZE=8X1 DSRTC: MODE=STD, IO=112 UART: IO=104 UART: IO=128 UART: IO=136 SIO MODE=ZP, IO=176, CHANNEL A SIO MODE=ZP, IO=176, CHANNEL B PIO: IO=184, CHANNEL A PIO: IO=184, CHANNEL B PIO: IO=188, CHANNEL A PIO: IO=188, CHANNEL B LPT: MODE=SPP, IO=232 CVDU: MODE=MBC, IO=224, KBD MODE=PS/2, KBD IO=226 TMS: MODE=MBC, IO=152, SCREEN=80X24, KEYBOARD=KBD KBD: ENABLED ESP: IO=156 ESPCON: ENABLED ESPSER: DEVICE=0 ESPSER: DEVICE=1 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=MBC, IO=48, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=MBC, IO=48, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=96, MASTER PPIDE: IO=96, SLAVE SPK: IO=112","title":"Supported Hardware"},{"location":"Hardware/#retrobrew-z80","text":"","title":"RetroBrew Z80"},{"location":"Hardware/#retrobrew-z80-sbc-v2","text":"The SBC V2 is a Zilog Z80 processor board. It\u2019s a 100x160mm board that is capable of functioning both as a standalone SBC or as attached to the ECB bus. Previously known as the N8VEM SBC, after Andrews Ham radio call sign, development began in 2006 wth V1 and is currently still in development, it launched a tsunami of developments based on the Euro Card Bus (ECB) standard. Creator: Andrew Lynch Github: SBC-V2-005 (May not be official) Github: SBC-V2-004 Retrobrew Wiki: SBC V2 Blog: Building the SBCV2 Z80","title":"RetroBrew Z80 SBC V2"},{"location":"Hardware/#rom-image-file-sbc_stdrom","text":"Bus ECB Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager SBC ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SBC_std.rom"},{"location":"Hardware/#supported-hardware_11","text":"DSRTC: MODE=STD, IO=112 UART: MODE=SBC, IO=104 UART: MODE=CAS, IO=128 UART: MODE=MFP, IO=104 UART: MODE=4UART, IO=192 UART: MODE=4UART, IO=200 UART: MODE=4UART, IO=208 UART: MODE=4UART, IO=216 VGA: IO=224, KBD MODE=PS/2, KBD IO=224 CVDU: MODE=ECB, IO=224, KBD MODE=PS/2, KBD IO=226 CVDU occupies 905 bytes. KBD: ENABLED PRP: IO=168 PRPCON: ENABLED PRPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DIO, IO=54, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=DIO, IO=54, DRIVE 1, TYPE=3.5\u201d HD PPIDE: IO=96, MASTER PPIDE: IO=96, SLAVE","title":"Supported Hardware"},{"location":"Hardware/#retrobrew-z80-simh","text":"Image for Altair Z80 SimH emulator","title":"RetroBrew Z80 SimH"},{"location":"Hardware/#rom-image-file-sbc_simhrom","text":"Bus - Default CPU Speed 8.000 MHz Interrupts Mode 1 System Timer SimH Serial Default 38400 Baud Memory Manager SBC ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SBC_simh.rom"},{"location":"Hardware/#supported-hardware_12","text":"SIMRTC: IO=254 SSER: IO=109 MD: TYPE=RAM MD: TYPE=ROM HDSK: IO=253, DEVICE COUNT=2","title":"Supported Hardware"},{"location":"Hardware/#notes_2","text":"CPU speed and Serial configuration not relevant in emulator","title":"Notes:"},{"location":"Hardware/#n8-z180-sbc","text":"The N8 is intended to be a \u201chome brew\u201d style computer in the style of early 1980\u2019s all-in-one home computers with a usable set of features such as color graphics, audio, an assortment of mass storage options, a variety of ports, etc. Although a bus expansion is supported no additional boards are required. This configuration is for the N8-2312 and latter (4314) revisions Creator: Andrew Lynch Retrobrew Wiki: The N8 Blog: A Z180 based SBC","title":"N8 Z180 SBC"},{"location":"Hardware/#rom-image-file-n8_stdrom","text":"Bus ECB Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 38400 Baud Memory Manager N8 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: N8_std.rom"},{"location":"Hardware/#supported-hardware_13","text":"DSRTC: MODE=STD, IO=136 ASCI: IO=64, INTERRUPTS ENABLED ASCI: IO=65, INTERRUPTS ENABLED TMS: MODE=N8, IO=152, SCREEN=40X24, KEYBOARD=PPK PPK: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=N8, IO=140, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=N8, IO=140, DRIVE 1, TYPE=3.5\u201d HD SD: MODE=CSIO, IO=136, UNITS=1 AY38910: MODE=N8, IO=156, CLOCK=1789772 HZ","title":"Supported Hardware"},{"location":"Hardware/#notes_3","text":"SD Card interface is configured for CSIO (N8 date code >= 2312)","title":"Notes:"},{"location":"Hardware/#rcbus-z80","text":"","title":"RCBus Z80"},{"location":"Hardware/#rcbus-z80-cpu-module","text":"Generic Rom Image.","title":"RCBus Z80 CPU Module"},{"location":"Hardware/#rom-image-file-rcz80_stdrom","text":"Bus RCBus Default CPU Speed 7.372 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_std.rom"},{"location":"Hardware/#supported-hardware_14","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#rcbus-z80-cpu-module-kio","text":"Generic Rom Image. SIO Serial baud rate managed by CTC","title":"RCBus Z80 CPU Module (KIO)"},{"location":"Hardware/#rom-image-file-rcz80_kio_stdrom","text":"Bus RCBus Default CPU Speed 7.372 MHz Interrupts Mode 2 System Timer CTC Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_kio_std.rom"},{"location":"Hardware/#supported-hardware_15","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=136, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=136, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1 KIO: IO=128 CTC: IO=132, TIMER MODE=TIMER/16, DIVISOR=9216, HI=256, LO=36, INTERRUPTS ENABLED","title":"Supported Hardware"},{"location":"Hardware/#z80-512k-cpuramrom-module","text":"Z80-512K is an RCBus and RC2014* compatible module, designed to run RomWBW firmware including CP/M, ZSDOS, and various applications under these OSes. Z80-512K combines functionality of CPU, RAM, and ROM on a single module, thus saving space on the backplane. Creator: Sergey Kiselev Google Groups: Z80-512K Github: Z80-512K","title":"Z80-512K CPU/RAM/ROM Module"},{"location":"Hardware/#rom-image-file-rcz80_skz_stdrom","text":"Bus RCBus Default CPU Speed 7.372 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_skz_std.rom"},{"location":"Hardware/#supported-hardware_16","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#zrc-z80-cpu-module","text":"ZRC is derived from the ZoRC experiment. The basic notion is that large RAM and fast serial upload enable a diskless CP/M SBC. However, just in case that idea didn\u2019t work out, ZRC has an optional compact flash interface. The targeted software for ZRC is ROMWBW. ZRC physically contains no ROM and 2MB of RAM. In the STD configuration the first 512KB of RAM is loaded with a ROM image from disk storage and then handled like ROM. Essentially, an area of the RAM is reserved to act as ROM. Creator: Bill Shen Retrobrew Wiki: ZRC, Z80 RAM CPLD for ROMWBW Google Groups: ZRC, Z80/RAM/CPLD, minimal CP/M-ready, Z80 SBC","title":"ZRC Z80 CPU Module"},{"location":"Hardware/#rom-image-file-rcz80_zrc_stdrom","text":"Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager ZRC ROM Size 512 KB RAM Size 1536 KB","title":"ROM Image File: RCZ80_zrc_std.rom"},{"location":"Hardware/#supported-hardware_17","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#zrc-z80-cpu-module-ram","text":"This profile differs (from STD) only in how the system boots, and how RAM is configured. Boot occurs directly to RAM, loading HBIOS directly from disk storage rather than via a pseudo ROM image copied into RAM. A RAM disk is configured preloaded with files that would normally be on the ROM disk. There is no ROM disk in this configuration. The RAM config is the newer approach and provides a more efficient bank layout. The intent to replace the STD config with the RAM config. Creator: Bill Shen","title":"ZRC Z80 CPU Module (RAM)"},{"location":"Hardware/#rom-image-file-rcz80_zrc_ram_stdrom","text":"Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager ZRC ROM Size 0 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_zrc_ram_std.rom"},{"location":"Hardware/#supported-hardware_18","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#zrc512-z80-cpu-module","text":"ZRC512 is a faster and hobbyist-friendly variant of ZRC. It is designed specifically for ROM-less RomWBW. HBIOS is loaded from disk at boot Creator: Bill Shen Google Groups: Bill Shen\u2019s ZRC512 SBC / RC2014 board Retrobrew Wiki: ZRC512, A Hobbyist-friendly Z80 SBC for ROM-less RomWBW","title":"ZRC512 Z80 CPU Module"},{"location":"Hardware/#rom-image-file-rcz80_zrc512_stdrom","text":"Bus RCBus Default CPU Speed 22.000 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager ZRC ROM Size 0 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_zrc512_std.rom"},{"location":"Hardware/#supported-hardware_19","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#eazy80-512-z80-cpu-module","text":"Eazy80-512 is Eazy80 rev2 pc board configured with 512K RAM to run RomWBW. The design was derived from modifications to Eazy80 Rev1 that supported RomWBW. HBIOS is loaded from disk at boot by ROM monitor (Not to be confused with EasyZ80) Creator: Bill Shen VCF Forums: Eazy80, a glue-less, CP/M capable Z80 SBC Retrobrew Wiki: Eazy80 Rev2, Glue-less Configuration Google Groups: EaZy80, A Simple80 with KIO","title":"EaZy80-512 Z80 CPU Module"},{"location":"Hardware/#rom-image-file-rcz80_ez512_stdrom","text":"Bus RCBus Default CPU Speed 22.000 MHz Interrupts Mode 2 System Timer None Serial Default 115200 Baud Memory Manager EZ512 ROM Size 0 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_ez512_std.rom"},{"location":"Hardware/#supported-hardware_20","text":"DSRTC: MODE=STD, IO=192 SIO MODE=STD, IO=8, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=8, CHANNEL B, INTERRUPTS ENABLED MD: TYPE=RAM MD occupies 409 bytes. SD: MODE=EZ512, IO=2, UNITS=1 KIO: IO=0 CTC: IO=4","title":"Supported Hardware"},{"location":"Hardware/#k80w-z80-cpu-module","text":"K80W is similar to K80. It is a 22MHz Z80 SBC with KIO (Z84C90) as the I/O device. It is designed to run RomWBW. The current version is rev 2.1 replacing the older K80W rev 1 Creator: Bill Shen Retrobrew Wiki: K80W Rev2.1, A RomWBW-capable Z80 SBC","title":"K80W Z80 CPU Module"},{"location":"Hardware/#rom-image-file-rcz80_k80w_stdrom","text":"Bus RCBus Default CPU Speed 22.000 MHz Interrupts Mode 2 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ80_k80w_std.rom"},{"location":"Hardware/#supported-hardware_21","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=K80W, IO=192 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=STD, IO=136, CHANNEL A, INTERRUPTS ENABLED SIO MODE=STD, IO=136, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=EZ512, IO=130, UNITS=1 KIO: IO=128 CTC: IO=132","title":"Supported Hardware"},{"location":"Hardware/#rcbus-z180","text":"","title":"RCBus Z180"},{"location":"Hardware/#rcbus-z180-cpu-module-external","text":"Generic Rom Image. For use with Z2 bank switched memory board (Z2 external memory management)","title":"RCBus Z180 CPU Module (External)"},{"location":"Hardware/#rom-image-file-rcz180_ext_stdrom","text":"Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ180_ext_std.rom"},{"location":"Hardware/#supported-hardware_22","text":"FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#rcbus-z180-cpu-module-native","text":"Generic Rom Image. For use with linear memory board (Z180 native memory management)","title":"RCBus Z180 CPU Module (Native)"},{"location":"Hardware/#rom-image-file-rcz180_nat_stdrom","text":"Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ180_nat_std.rom"},{"location":"Hardware/#supported-hardware_23","text":"FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#z1rcc-z180-cpu-module","text":"Z1RCC is a 2\u201cx4\u201d RomWBW-capable Z180 SBC. Z1RCC has no flash memory on board but has a small (64 bytes) bootstrap ROM in CPLD so that Z180 boots from this bootstrap ROM, copies a loader from CF disk to top 32K of RAM, runs the loader to bring in the 480K RomWBW image from CF disk, then start RomWBW from 0x0 Creator: Bill Shen Google Groups: RomWBW for Z80 with 512K RAM 0K ROM Retrobrew Wiki: Z1RCC, A RC2014-Compatible, RomWBW-Capable Z180 SBC","title":"Z1RCC Z180 CPU Module"},{"location":"Hardware/#rom-image-file-rcz180_z1rcc_stdrom","text":"Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 0 KB RAM Size 512 KB","title":"ROM Image File: RCZ180_z1rcc_std.rom"},{"location":"Hardware/#supported-hardware_24","text":"FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#rcbus-z280","text":"","title":"RCBus Z280"},{"location":"Hardware/#rcbus-z280-cpu-module-external","text":"Generic Rom Image. For use with Z2 bank switched memory board (Z2 external memory management)","title":"RCBus Z280 CPU Module (External)"},{"location":"Hardware/#rom-image-file-rcz280_ext_stdrom","text":"Bus RCBus Default CPU Speed 12.000 MHz Interrupts Mode 1 System Timer None Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ280_ext_std.rom"},{"location":"Hardware/#supported-hardware_25","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16 UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED ACIA: IO=128, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#rcbus-z280-cpu-module-native","text":"Generic Rom Image. For use with linear memory board (Z280 native memory management)","title":"RCBus Z280 CPU Module (Native)"},{"location":"Hardware/#rom-image-file-rcz280_nat_stdrom","text":"Bus RCBus Default CPU Speed 12.000 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ280_nat_std.rom"},{"location":"Hardware/#supported-hardware_26","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=PIO, IO=105, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#zzrcc-z280-cpu-module","text":"ZZRCC follows the basic concept of ZRCC that uses a small CPLD to bootstrap from CF disk. Because Z280 has a native serial-bootstrap capability, the CPLD is even simpler than that of ZRCC. ZZRCC is Z280 operating in Z80-compatible mode. It is designed for RC2014 bus ZZRCC actually contains no ROM and 512KB of RAM. In the STD configuration the first 256KB of RAM is loaded with a ROM image from disk storage and then handled like ROM. Essentially, an area of the RAM is reserved to act as ROM. Creator: Bill Shen Retrobrew Wiki: ZZRCC, a SBC for RC2014 based on Z280 Google Groups: ZZRCC, Z280 SBC replacing ZZ80RC and ZZ80CF Google Groups: Help porting ROMWBW to ZZRCC","title":"ZZRCC Z280 CPU Module"},{"location":"Hardware/#rom-image-file-rcz280_zzrcc_stdrom","text":"Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 256 KB RAM Size 256 KB","title":"ROM Image File: RCZ280_zzrcc_std.rom"},{"location":"Hardware/#supported-hardware_27","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE","title":"Supported Hardware"},{"location":"Hardware/#zzrcc-z280-cpu-module-ram","text":"This profile differs (from STD) only in how the system boots, and how RAM is configured. Boot occurs directly to RAM, loading HBIOS directly from disk storage rather than via a pseudo ROM image copied into RAM. A RAM disk is configured preloaded with files that would normally be on the ROM disk. There is no ROM disk in this configuration. The RAM config is the newer approach and provides a more efficient bank layout. The intent to replace the STD config with the RAM config. Creator: Bill Shen","title":"ZZRCC Z280 CPU Module (RAM)"},{"location":"Hardware/#rom-image-file-rcz280_zzrcc_ram_stdrom","text":"Bus RCBus Default CPU Speed 14.745 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 0 KB RAM Size 512 KB","title":"ROM Image File: RCZ280_zzrcc_ram_std.rom"},{"location":"Hardware/#supported-hardware_28","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE","title":"Supported Hardware"},{"location":"Hardware/#zz80mb-z280-sbc","text":"ZZ80MB is a Z280-based motherboard with RC2014 expansion slots. It is based on the ZZ80RC-CF design, but with two additional expansion slots added. ZZ80MB is designed with an EPROM programmer function such that it can boot from serial port, load EPROM programming image through the serial port and program an EPROM. This feature can be used to program EPROM for other computers Creator: Bill Shen Retrobrew Wiki: ZZ80MB, A Z280-based SBC with RC2014 Expansion","title":"ZZ80MB Z280 SBC"},{"location":"Hardware/#rom-image-file-rcz280_zz80mb_stdrom","text":"Bus RCBus Default CPU Speed 12.000 MHz Interrupts Mode 3 System Timer Z280 Serial Default 115200 Baud Memory Manager Z280 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCZ280_zz80mb_std.rom"},{"location":"Hardware/#supported-hardware_29","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 DSRTC: MODE=STD, IO=192 INTRTC: ENABLED Z2U: IO=16, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED VRC: IO=0, KBD MODE=VRC, KBD IO=244 KBD: ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE","title":"Supported Hardware"},{"location":"Hardware/#ez80-for-rcbus-module","text":"The eZ80 for RCBus/RC2014 is a module designed for the RCBus and RC2014 backplanes. Its designed as a \u2018compatible upgrade\u2019 to the stock Z80 CPU. The eZ80 is a CPU that was first released by Zilog about 20 years ago, and still available from the manufacturer today Creator: Dean Netherton Github: eZ80 for the RCBus/RC2014 Hackaday: eZ80 CPU for RC2014 and other backplanes","title":"eZ80 for RCBus Module"},{"location":"Hardware/#rom-image-file-rcez80_stdrom","text":"Bus RCBus Default CPU Speed 20.000 MHz Interrupts Mode 1 System Timer EZ80 Serial Default 115200 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RCEZ80_std.rom"},{"location":"Hardware/#supported-hardware_30","text":"FP: LEDIO=0, SWIO=0 LCD: IO=218, SIZE=20X4 CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE EZ80: CPU DRIVER EZ80: SYS TIMER DRIVER EZ80: RTC DRIVER EZ80: UART DRIVER","title":"Supported Hardware"},{"location":"Hardware/#rhyophyre-z180-sbc","text":"Single Board Computer featuring Zilog Z180 processor and NEC \u00b5PD7220 Graphics Display Controller Creator: Andrew Lynch Retrobrew Forums: Z180 upd7220 GDC SBC Github: rhyophyre","title":"Rhyophyre Z180 SBC"},{"location":"Hardware/#rom-image-file-rph_stdrom","text":"Bus - Default CPU Speed 18.432 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager RPH ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: RPH_std.rom"},{"location":"Hardware/#supported-hardware_31","text":"DSRTC: MODE=STD, IO=132 ASCI: IO=64 ASCI: IO=65 GDC: MODE=RPH, DISPLAY=EGA, IO=144 KBD: ENABLED MD: TYPE=RAM MD: TYPE=ROM PPIDE: IO=136, MASTER PPIDE: IO=136, SLAVE","title":"Supported Hardware"},{"location":"Hardware/#s100-computers-z180-sbc","text":"A Z180 board which contains a flash RAM, a USB port interface and an SD Card that can immediately boot up CPM. While it is on an S100 Bus board, initially that board has only 8 significant chips and works as a self contained computer outside the bus with a simple 9V power supply. Later on it can be built up further with more chips, placed in an S100 bus and one by one programed to interface with the 100\u2019s of S100 bus cards that are out there. It can in fact behave as a S100 bus master or slave as defined by the IEEE-696 specs. Creator: John Monahan | Website: S100 Computers Z180 SBC","title":"S100 Computers Z180 SBC"},{"location":"Hardware/#rom-image-file-s100_stdrom","text":"Bus S100 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 57600 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: S100_std.rom"},{"location":"Hardware/#supported-hardware_32","text":"INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED SCON: IO=0 MD: TYPE=RAM MD: TYPE=ROM SD: MODE=SC, IO=12, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#notes_4","text":"Z180 SBC SW2 (IOBYTE) Dip Switches: Bit Setting Function 0 Off Use Z180 ASCI Channel A for console On Use Propeller Console 1 Off Boot to RomWBW Boot Loader On Boot to S100 Monitor","title":"Notes:"},{"location":"Hardware/#small-computer-central-z180","text":"Small Computer Central provides an extensive range hardware based around the Zilog ecosystem. This section lists configurations specifically for the Z180 processor If you are using a Z80 processor you will probably be using the general RCZ80_std configuration - RCBus Z80 CPU Module . However, please consult Firmware, RomWBW, RCZ80_std for further information and to ensure compatibility with your Z80 system. Creator: Stephen Cousins Website: Small Computer Central","title":"Small Computer Central Z180"},{"location":"Hardware/#sc126-z180-sbc","text":"SC126 is a Z180 Motherboard. Website: SC126 \u2013 Z180 Motherboard","title":"SC126 Z180 SBC"},{"location":"Hardware/#rom-image-file-scz180_sc126_stdrom","text":"Bus BP80 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SCZ180_sc126_std.rom"},{"location":"Hardware/#supported-hardware_33","text":"FP: LEDIO=13, SWIO=0 DSRTC: MODE=STD, IO=12 ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#notes_5","text":"When disabled, watchdog requires /IM to be pulsed. If an RCBus module holds the CPU in WAIT for more than this, the watchdog will fire when disabled with random consequences. The Pico SD does this at power-on.","title":"Notes:"},{"location":"Hardware/#sc130-z180-sbc","text":"SC130 is an entry-level Z180 Motherboard designed primarily to run RomWBW (and CP/M) Website: SC130 \u2013 Z180 Motherboard","title":"SC130 Z180 SBC"},{"location":"Hardware/#rom-image-file-scz180_sc130_stdrom","text":"Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SCZ180_sc130_std.rom"},{"location":"Hardware/#supported-hardware_34","text":"FP: LEDIO=0, SWIO=0 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#sc131-z180-pocket-comp","text":"SC131 is a pocket-sized Z180 RomWBW CP/M computer. Website: SC131 \u2013 Z180 Pocket Computer","title":"SC131 Z180 Pocket Comp"},{"location":"Hardware/#rom-image-file-scz180_sc131_stdrom","text":"Bus - Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SCZ180_sc131_std.rom"},{"location":"Hardware/#supported-hardware_35","text":"INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM SD: MODE=SC, IO=12, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#sc140-z180-cpu-module","text":"SC140 is a Z180 SBC / Z50Bus Card card. Website: SC140 \u2013 Z180 SBC / Z50Bus Card","title":"SC140 Z180 CPU Module"},{"location":"Hardware/#rom-image-file-scz180_sc140_stdrom","text":"Bus Z50 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SCZ180_sc140_std.rom"},{"location":"Hardware/#supported-hardware_36","text":"FP: LEDIO=160, SWIO=160 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=144, MASTER IDE: MODE=RC, IO=144, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#sc503-z180-cpu-module","text":"SC503 is a Z180 Processor card designed for Z50Bus. Website: SC503 \u2013 Z180 Processor (Z50Bus)","title":"SC503 Z180 CPU Module"},{"location":"Hardware/#rom-image-file-scz180_sc503_stdrom","text":"Bus Z50 Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SCZ180_sc503_std.rom"},{"location":"Hardware/#supported-hardware_37","text":"FP: LEDIO=160, SWIO=160 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=144, MASTER IDE: MODE=RC, IO=144, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#sc700-z180-cpu-module","text":"This configuration is specifically for systems based on the Z180 CPU (eg. SC722) with 1MB linear memory (eg. SC721) Website: SC700 Series Website: SC721 \u2013 RCBus Memory Module Website: SC722 \u2013 RCBus Z180 CPU Module","title":"SC700 Z180 CPU Module"},{"location":"Hardware/#rom-image-file-scz180_sc700_stdrom","text":"Bus RCBus Default CPU Speed 18.432 MHz Interrupts Mode 2 System Timer Z180 Serial Default 115200 Baud Memory Manager Z180 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: SCZ180_sc700_std.rom"},{"location":"Hardware/#supported-hardware_38","text":"FP: LEDIO=0 LCD: IO=170, SIZE=20X4 DSRTC: MODE=STD, IO=12 INTRTC: ENABLED ASCI: IO=192, INTERRUPTS ENABLED ASCI: IO=193, INTERRUPTS ENABLED UART: IO=128 UART: IO=136 UART: IO=160 UART: IO=168 SIO MODE=RC, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=128, CHANNEL B, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL A, INTERRUPTS ENABLED SIO MODE=RC, IO=132, CHANNEL B, INTERRUPTS ENABLED CH: IO=62 CH: IO=60 CHUSB: IO=62 CHUSB: IO=60 MD: TYPE=RAM MD: TYPE=ROM FD: MODE=RCWDC, IO=80, DRIVE 0, TYPE=3.5\u201d HD FD: MODE=RCWDC, IO=80, DRIVE 1, TYPE=3.5\u201d HD IDE: MODE=RC, IO=16, MASTER IDE: MODE=RC, IO=16, SLAVE PPIDE: IO=32, MASTER PPIDE: IO=32, SLAVE SD: MODE=SC, IO=12, UNITS=1 `{=latex}","title":"Supported Hardware"},{"location":"Hardware/#z80-retro-sbc","text":"The system comprises a Z80 retro computer board, and optonal VGA text video card, and PIO Keyboard and Sound Card. The system uses a custom 60 pin bus on a standard header. (Not to be confused with a similar named project by John Winans presented by John\u2019s Basement on youTube) Creator: Peter Wilson Github: Z80-Retro Github Wiki: Welcome to the Z80-Retro wiki! OSHWLab: Simple Z80 SBC","title":"Z80-Retro SBC"},{"location":"Hardware/#rom-image-file-z80retro_stdrom","text":"Bus 60 pin Default CPU Speed 14.745 MHz Interrupts Mode 2 System Timer None Serial Default 38400 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: Z80RETRO_std.rom"},{"location":"Hardware/#supported-hardware_39","text":"SIO MODE=Z80R, IO=128, CHANNEL A, INTERRUPTS ENABLED SIO MODE=Z80R, IO=128, CHANNEL B, INTERRUPTS ENABLED MD: TYPE=RAM MD: TYPE=ROM SD: MODE=Z80R, IO=104, UNITS=1","title":"Supported Hardware"},{"location":"Hardware/#zeta-z80-sbc","text":"Zeta SBC is an Zilog Z80 based single board computer. It is inspired by Ampro Little Board Z80 and N8VEM project. Zeta SBC is software compatible with N8VEM SBC and Disk I/O boards. Creator: Sergey Kiselev Retrobrew Wiki: Zeta SBC","title":"Zeta Z80 SBC"},{"location":"Hardware/#rom-image-file-zeta_stdrom","text":"Bus - Default CPU Speed 8.000 MHz Interrupts None System Timer None Serial Default 38400 Baud Memory Manager SBC ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: ZETA_std.rom"},{"location":"Hardware/#supported-hardware_40","text":"DSRTC: MODE=STD, IO=112 UART: IO=104 PPP: IO=96 PPPCON: ENABLED PPPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=DIO, IO=54, DRIVE 0, TYPE=3.5\u201d HD","title":"Supported Hardware"},{"location":"Hardware/#notes_6","text":"If ParPortProp is installed, initial console output is determined by JP1: Shorted: console to on-board serial port Open: console to ParPortProp video and keyboard","title":"Notes:"},{"location":"Hardware/#zeta-v2-z80-sbc","text":"Zeta SBC V2 is a redesigned version of Zeta SBC. Compared to the first version this version features updated MMU with four banks, each one of those banks can be mapped to any 16 KiB page in 1 MiB on-board memory. It adds Z80 CTC which is used for generating periodic interrupts and as a vectored interrupt controller for UART and PPI. The FDC is replaced with 37C65. Compared to FDC9266 used in Zeta SBC it integrates input/output buffers and floppy disk control latch. Additionally 37C65 FDC is easier to obtain than FDC9266. And lastly it is made using CMOS technology and more power efficient than FDC9266 Creator: Sergey Kiselev Github: Zeta SBC V2 Retrobrew Wiki: Zeta SBC V2","title":"Zeta V2 Z80 SBC"},{"location":"Hardware/#rom-image-file-zeta2_stdrom","text":"Bus - Default CPU Speed 8.000 MHz Interrupts Mode 2 System Timer CTC Serial Default 38400 Baud Memory Manager Z2 ROM Size 512 KB RAM Size 512 KB","title":"ROM Image File: ZETA2_std.rom"},{"location":"Hardware/#supported-hardware_41","text":"DSRTC: MODE=STD, IO=112 UART: IO=104 PPP: IO=96 PPPCON: ENABLED PPPSD: ENABLED MD: TYPE=RAM MD: TYPE=ROM FD: MODE=ZETA2, IO=48, DRIVE 0, TYPE=3.5\u201d HD CTC: IO=32, TIMER MODE=COUNTER, DIVISOR=18432, HI=256, LO=72, INTERRUPTS ENABLED","title":"Supported Hardware"},{"location":"Hardware/#notes_7","text":"If ParPortProp is installed, initial console output is determined by JP1: Shorted: console to on-board serial port Open: console to ParPortProp video and keyboard","title":"Notes:"},{"location":"Hardware/#device-drivers","text":"This section briefly describes each of the possible devices that may be discovered by RomWBW in your system.","title":"Device Drivers"},{"location":"Hardware/#character","text":"ID Description ACIA MC68B50 Asynchronous Communications Interface Adapter ASCI Zilog Z180 CPU Built-in Serial Ports DUART SCC2681 or compatible Dual UART ESPCON ESP32 Firmware-based Video Console ESPSER ESP32 Firmware-based Serial Interface EZ80UART eZ80 Serial Interface LPT Parallel I/O Controller PIO Zilog Parallel Interface Controller PPPCON ParPortProp Serial Console Interface PRPCON PropIO Serial Console Interface SCON S100 Console SIO Zilog Serial Port Interface SSER Simple Serial Interface UART 16C550 Family Serial Interface USB-FIFO FT232H-based ECB USB FIFO Z2U Zilog Z280 CPU Built-in Serial Ports By default, RomWBW will use the first available character device it discovers for the initial console. The following character devices are scanned in the order shown. The available character devices depend on the active platform and configuration. SSER: Simple Serial Interface ASCI: Zilog Z180 CPU Built-in Serial Ports Z2U: Zilog Z280 CPU Built-in Serial Ports UART: 16C550 Family Serial Interface DUART: SCC2681 or compatible Dual UART SIO: Zilog Serial Port Interface EZ80UART: eZ80 Serial Port Interface ACIA: MC68B50 Asynchronous Communications Interface Adapter USB-FIFO: FT232H-based ECB USB FIFO","title":"Character"},{"location":"Hardware/#disk","text":"ID Description CHSD CH37x SD Card Interface CHUSB CH37x USB Drive Interface FD Intel 8272 or compatible Floppy Disk Controller HDSK SIMH Simulator Hard Disk IDE IDE/ATA/ATAPI Hard Disk Interface IMM Zip Drive on PPI (IMM variant) MD ROM/RAM Disk PPA Zip Drive on PPI (PPA variant) PPIDE 8255 IDE/ATA/ATAPI Hard Disk Interface PPPSD ParPortProp SD Card Interface PRPSD PropIO SD Card Interface RF RAM Floppy Disk Interface SD SD Card Interface SYQ Iomega SparQ Drive on PPI","title":"Disk"},{"location":"Hardware/#video","text":"ID Description CVDU MC8563-based Video Display Controller EF EF9345 Video Display Controller FV S100 FPGA Z80 Onboard VGA/Keyboard GDC uPD7220 Video Display Controller TMS TMS9918/38/58 Video Display Controller VDU MC6845 Family Video Display Controller (*) VGA HD6445CP4-based Video Display Controller VRC VGARC Video Display Controller Note: Reading bytes from the video memory of the VDU board (not Color VDU) appears to be problematic. This is only an issue when the driver needs to scroll a portion of the screen which is done by applications such as WordStar or ZDE. You are likely to see screen corruption in this case.","title":"Video"},{"location":"Hardware/#keyboard","text":"ID Description KBD 8242 PS/2 Keyboard Controller MSXKYB MSX Compliant Matrix Keyboard NABUKB NABU Keyboard PPK Matrix Keyboard","title":"Keyboard"},{"location":"Hardware/#audio","text":"ID Description AY AY-3-8910/YM2149 Programmable Sound Generator SN76489 SN76489 Programmable Sound Generator SPK Bit-bang Speaker YM YM2612 Programmable Sound Generator","title":"Audio"},{"location":"Hardware/#rtc-realtime-clock","text":"ID Description BQRTC BQ4845P Real Time Clock DS5RTC Maxim DS1305 SPI Real-Time Clock w/ NVRAM DS7RTC Maxim DS1307 PCF I2C Real-Time Clock w/ NVRAM DS1501RTC Maxim DS1501/DS1511 Watchdog Real-Time Clock DSRTC Maxim DS1302 Real-Time Clock w/ NVRAM EZ80RTC eZ80 Real-Time Clock INTRTC Interrupt-based Real Time Clock PCF PCF8584-based I2C Real-Time Clock RP5C01 Ricoh RPC01A Real-Time Clock w/ NVRAM SIMRTC SIMH Simulator Real-Time Clock","title":"RTC (RealTime Clock)"},{"location":"Hardware/#dsky-display-keypad","text":"ID Description FP Simple LED & Switch Front Panel GM7303 Prolog 7303 derived Display/Keypad H8P Heath H8 Display/Keypad ICM ICM7218-based Display/Keypad on PPI LCD Hitachi HD44780-based LCD Display PKD P8279-based Display/Keypad on PPI","title":"DsKy (DiSplay KeYpad)"},{"location":"Hardware/#system","text":"ID Description CH CH375/376 USB Interface Controller CTC Zilog Clock/Timer DMA Zilog DMA Controller ESP ESP32 Firmware-based interface EZ80TIMER eZ80 System Timer KIO Zilog Serial/ Parallel Counter/Timer (Z84C90) PPP ParPortProp Host Interface Controller PRP PropIO Host Interface Controller","title":"System"},{"location":"Hardware/#una-hardware-bios","text":"John Coffman has produced a new generation of hardware BIOS called UNA. The standard RomWBW distribution includes its own hardware BIOS. However, RomWBW can alternatively be constructed with UNA as the hardware BIOS portion of the ROM. If you wish to use the UNA variant of RomWBW, then just program your ROM with the ROM image called \u201cUNA_std.rom\u201d in the Binary directory. This one image is suitable on all of the platforms and hardware UNA supports. UNA is customized dynamically using a ROM based setup routine and the setup is persisted in the system NVRAM of the RTC chip. This means that the single UNA-based ROM image can be used on most of the RetroBrew platforms and is easily customized. UNA also supports FAT file system access that can be used for in-situ ROM programming and loading system images. While John is likely to enhance UNA over time, there are currently a few things that UNA does not support: Floppy Drives Terminal Emulation Zeta 1, N8, RCBus, Easy Z80, and Dyno Systems Some older support boards The UNA version embedded in RomWBW is the latest production release of UNA. RomWBW will be updated with John\u2019s upcoming UNA release with support for VGA3 as soon as it reaches production status. Please refer to the UNA BIOS Firmware Page for more information on UNA.","title":"UNA Hardware BIOS"},{"location":"Hardware/#una-usage-notes","text":"At startup, UNA will display a prompt similar to this: Boot UNA unit number or ROM? [R,X,0..3] (R): You generally want to choose \u2018R\u2019 which will then launch the RomWBW loader. Attempting to boot from a disk using a number at the UNA prompt will only work for the legacy (hd512) disk format. However, if you go to the RomWBW loader, you will be able to perform a disk boot on either disk format. The disk images created and distributed with RomWBW do not have the correct system track code for UNA. In order to boot to disk under UNA, you must first use SYSCOPY to update the system track of the target disk. The UNA ROM disk has the correct system track files for UNA: CPM.SYS and ZSYS.SYS . So, you can boot a ROM OS and then use one of these files to update the system track. The only operating systems supported at this time are CP/M 2 and ZSDOS. NZ-COM is also supported because it uses the ZSDOS CBIOS. None of the other RomWBW operating systems are supported such as CP/M 3, ZPM3, and p-System. Some of the RomWBW-specific applications are not UNA compatible.","title":"UNA Usage Notes"},{"location":"Introduction/","text":"RomWBW Introduction \\ Version 3.6 \\ Wayne Warthen ( wwarthen@gmail.com ) \\ 31 May 2025 Overview RomWBW software provides a complete, commercial quality implementation of CP/M (and workalike) operating systems and applications for modern Z80/180/280 retro-computing hardware systems. A wide variety of platforms are supported including those produced by these developer communities: RetroBrew Computers ( https://www.retrobrewcomputers.org ) RC2014 ( https://rc2014.co.uk ), RC2014-Z80 ( https://groups.google.com/g/rc2014-z80 ) Retro Computing ( https://groups.google.com/g/retro-comp ) Small Computer Central ( https://smallcomputercentral.com/ ) A complete list of the currently supported platforms is found in RomWBW Hardware . Description Primary Features By design, RomWBW isolates all of the hardware specific functions in the ROM chip itself. The ROM provides a hardware abstraction layer such that all of the operating systems and applications on a disk will run on any RomWBW-based system. To put it simply, you can take a disk (or CF/SD/USB Card) and move it between systems transparently. Supported hardware features of RomWBW include: Z80 Family CPUs including Z80, Z180, and Z280 Banked memory services for several banking designs Disk drivers for RAM, ROM, Floppy, IDE ATA/ATAPI, CF, SD, USB, Zip, Iomega Serial drivers including UART (16550-like), ASCI, ACIA, SIO Video drivers including TMS9918, SY6545, MOS8563, HD6445 Keyboard (PS/2) drivers via VT8242 or PPI interfaces Real time clock drivers including DS1302, BQ4845 Support for CP/NET networking using Wiznet, MT011 or Serial Built-in VT-100 terminal emulation support A dynamic disk drive letter assignment mechanism allows mapping operating system drive letters to any available disk media. Additionally, mass storage devices (IDE Disk, CF Card, SD Card, etc.) support the use of multiple slices (up to 256 per device). Each slice contains a complete CP/M filesystem and can be mapped independently to any drive letter. This overcomes the inherent size limitations in legacy OSes and allows up to 2GB of addressable storage on a single device, with up to 128MB accessible at any one time. Included Software Multiple disk images are provided in the distribution. Most disk images contain a complete, bootable, ready-to-run implementation of a specific operating system. A \u201ccombo\u201d disk image contains multiple slices, each with a full operating system implementation. If you use this disk image, you can easily pick whichever operating system you want to boot without changing media. Some of the included software: Operating Systems (CP/M 2.2, ZSDOS, NZ-COM, CP/M 3, ZPM3, Z3PLUS, QPM ) Support for other operating systems, p-System, FreeRTOS, and FUZIX. Programming Tools (Z80ASM, Turbo Pascal, Forth, Cowgol) C Compiler\u2019s including Aztec-C, and HI-TECH C Microsoft Basic Compiler, and Microsoft Fortran Some games such as Colossal Cave, Zork, etc Wordstar Word processing software Some of the provided software can be launched directly from the ROM firmware itself: System Monitor Operating Systems (CP/M 2.2, ZSDOS) ROM BASIC (Nascom BASIC and Tasty BASIC) ROM Forth A tool is provided that allows you to access a FAT-12/16/32 filesystem. The FAT filesystem may be coresident on the same disk media as RomWBW slices or on stand-alone media. This makes exchanging files with modern OSes such as Windows, MacOS, and Linux very easy. ROM Distribution The RomWBW Repository ( https://github.com/wwarthen/RomWBW ) on GitHub is the official distribution location for all project source and documentation. RomWBW is distributed as both source code and pre-built ROM and disk images. The pre-built ROM images distributed with RomWBW are based on the default system configurations as determined by the hardware provider/designer. The pre-built ROM firmware images are generally suitable for most users. The fully-built distribution releases are available on the RomWBW Releases Page ( https://github.com/wwarthen/RomWBW/releases ) of the repository. On this page, you will normally see a Development Snapshot as well as recent stable releases. Unless you have a specific reason, I suggest you stick to the most recent stable release. The asset named RomWBW-vX.X.X-Package.zip includes all pre-built ROM and Disk images as well as full source code. The other assets contain only source code and do not have the pre-built ROM or disk images. Distribution Directory Layout The RomWBW distribution is a compressed zip archive file organized in a set of directories. Each of these directories has its own ReadMe.txt file describing the contents in detail. In summary, these directories are: Directory Description Binary The final output files of the build process are placed here. Most importantly, the ROM images with the file names ending in \u201c.rom\u201d and disk images ending in .img. Doc Contains various detailed documentation, both RomWBW specifically as well as the operating systems and applications. Source Contains the source code files used to build the software and ROM images. Tools Contains the programs that are used by the build process or that may be useful in setting up your system. Building from Source It is also very easy to modify and build custom ROM images that fully tailor the firmware to your specific preferences. All tools required to build custom ROM firmware under Windows are included \u2013 no need to install assemblers, etc. The firmware can also be built using Linux or MacOS after confirming a few standard tools have been installed. Installation & Operation In general, installation of RomWBW on your platform is very simple. You just need to program your ROM with the correct ROM image from the RomWBW distribution. Subsequently, you can write disk images on your disk drives (IDE disk, CF Card, SD Card, etc.) which then provides even more functionality. Complete instructions for installation and operation of RomWBW are found in the RomWBW User Guide . It is also a good idea to review the Release Notes for helpful release-specific information. Documentation There are several documents that form the core of the RomWBW documentation: RomWBW User Guide is the main user guide for RomWBW, it covers the major topics of how to install, manage and use RomWBW, and includes additional guidance to the use of some of the operating systems supported by RomWBW RomWBW Hardware contains a description of all the hardware platforms, and devices supported by RomWBW. RomWBW Applications is a reference for the ROM-hosted and OS-hosted applications created or customized to enhance the operation of RomWBW. RomWBW Disk Catalog is a reference for the contents of the disk images provided with RomWBW, with a description of many of the files on each image RomWBW System Guide discusses much of the internal design and construction of RomWBW. It includes a reference for the RomWBW HBIOS API functions. Each of the operating systems and ROM applications included with RomWBW are sophisticated tools in their own right. It is not reasonable to fully document their usage. However, you will find complete manuals in PDF format in the Doc directory of the distribution. The intention of this documentation is to describe the operation of RomWBW and the ways in which it enhances the operation of the included applications and operating systems. Since RomWBW is purely a software product for many different platforms, the documentation does not cover hardware construction, configuration, or troubleshooting \u2013 please see your hardware provider for this information. Support Getting Assistance The best way to get assistance with RomWBW or any aspect of the RetroBrew Computers projects is via one of the community forums: RetroBrew Computers Forum RC2014 Google Group retro-comp Google Group Submission of issues and bugs are welcome at the RomWBW GitHub Repository . Also feel free to email Wayne Warthen at wwarthen@gmail.com . I am happy to provide support adapting RomWBW to new or modified systems Contributions All source code and distributions are maintained on GitHub. Contributions of all kinds to RomWBW are very welcome. Acknowledgments I want to acknowledge that a great deal of the code and inspiration for RomWBW has been provided by or derived from the work of others in the RetroBrew Computers Community. I sincerely appreciate all of their contributions. The list below is probably missing many names \u2013 please let me know if I missed you! Andrew Lynch started it all when he created the N8VEM Z80 SBC which became the first platform RomWBW supported. Some of his original code can still be found in RomWBW. Dan Werner wrote much of the code from which RomWBW was originally derived and he has always been a great source of knowledge and advice. Douglas Goodall contributed code, time, testing, and advice in \u201cthe early days\u201d. He created an entire suite of application programs to enhance the use of RomWBW. Unfortunately, they have become unusable due to internal changes within RomWBW. As of RomWBW 2.6, these applications are no longer provided. Sergey Kiselev created several hardware platforms for RomWBW including the very popular Zeta. David Giles created support for the Z180 CSIO which is now included SD Card driver. Phil Summers contributed the Forth and BASIC adaptations in ROM, the AY-3-8910 sound driver, DMA support, and a long list of general code and documentation enhancements. Ed Brindley contributed some of the code that supports the RCBus platform. Spencer Owen created the RC2014 series of hobbyist kit computers which has exponentially increased RomWBW usage. Some of his kits include RomWBW. Stephen Cousins has likewise created a series of hobbyist kit computers at Small Computer Central and is distributing RomWBW with many of them. Alan Cox has contributed some driver code and has provided a great deal of advice. The CP/NET client files were developed by Douglas Miller. Phillip Stevens contributed support for FreeRTOS. Curt Mayer contributed the original Linux / MacOS build process. UNA BIOS and FDISK80 are the products of John Coffman. FLASH4 is a product of Will Sowerbutts. CLRDIR is a product of Max Scane. Tasty Basic is a product of Dimitri Theulings. Dean Netherton contributed eZ80 CPU support, the sound driver interface, and the SN76489 sound driver. The RomWBW Disk Catalog document was produced by Mykl Orders. Rob Prouse has created many of the supplemental disk images including Aztec C, HiTech C, SLR Z80ASM, Turbo Pascal, Microsoft BASIC Compiler, Microsoft Fortran Compiler, and a Games compendium. Martin R has provided substantial help reviewing and improving the User Guide and Applications documents. Mark Pruden has made a wide variety of contributions including: significant content in the Disk Catalog and User Guide creation of the Introduction and Hardware documents Z3PLUS operating system disk image COPYSL utility SLABEL utility a feature for RomWBW configuration by NVRAM the /B bulk mode of disk assignment to the ASSIGN utility Jacques Pelletier has contributed the DS1501 RTC driver code. Jose Collado has contributed enhancements to the TMS driver including compatibility with standard TMS register configuration. Kevin Boone has contributed a generic HBIOS date/time utility (WDATE). Matt Carroll has contributed a fix to XM.COM that corrects the port specification when doing a send. Dean Jenkins enhanced the build process to accommodate the Raspberry Pi 4. Tom Plano has contributed a new utility (HTALK) to allow talking directly to HBIOS COM ports. Lars Nelson has contributed several generic utilities such as a universal (OS agnostic) UNARC application. Dylan Hall added support for specifying a secondary console. Bill Shen has contributed boot loaders for several of his systems. Laszlo Szolnoki has contributed an EF9345 video display controller driver. Ladislau Szilagyi has contributed an enhanced version of CP/M Cowgol that leverages RomWBW memory banking. Les Bird has contributed support for the NABU w/ Option Board Related Projects Outside of the hardware platforms adapted to RomWBW, there are a variety of projects that either target RomWBW specifically or provide a RomWBW-specific variation. These efforts are greatly appreciated and are listed below. Please contact the author if there are any other such projects that are not listed. Z88DK Z88DK is a software powerful development kit for Z80 computers supporting both C and assembly language. This kit now provides specific library support for RomWBW HBIOS. The Z88DK project is hosted at https://github.com/z88dk/z88dk . Paleo Editor Steve Garcia has created a Windows-hosted IDE that is tailored to development of RomWBW. The project can be found at https://github.com/alloidian/PaleoEditor . Z80 fig-FORTH Dimitri Theulings\u2019 implementation of fig-FORTH for the Z80 has a RomWBW-specific variant. The project is hosted at https://github.com/dimitrit/figforth . Assembly Language Programming for the RC2014 Zed Bruce Hall has written a very nice document that describes how to develop assembly language applications on RomWBW. It begins with the setup and configuration of a new RC2014 Zed system running RomWBW. It describes not only generic CP/M application development, but also RomWBW HBIOS programming and bare metal programming. The latest copy of this document is hosted at http://w8bh.net/Assembly for RC2014Z.pdf . Licensing License Terms RomWBW is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. RomWBW is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with RomWBW. If not, see https://www.gnu.org/licenses/ . Portions of RomWBW were created by, contributed by, or derived from the work of others. It is believed that these works are being used in accordance with the intentions and/or licensing of their creators. If anyone feels their work is being used outside of its intended licensing, please notify: Wayne Warthen wwarthen@gmail.com RomWBW is an aggregate work. It is composed of many individual, standalone programs that are distributed as a whole to function as a cohesive system. Each program may have its own licensing which may be different from other programs within the aggregate. In some cases, a single program (e.g., CP/M Operating System) is composed of multiple components with different licenses. It is believed that in all such cases the licenses are compatible with GPL version 3. RomWBW encourages code contributions from others. Contributors may assert their own copyright in their contributions by annotating the contributed source code appropriately. Contributors are further encouraged to submit their contributions via the RomWBW source code control system to ensure their contributions are clearly documented. All contributions to RomWBW are subject to this license.","title":"Introduction"},{"location":"Introduction/#overview","text":"RomWBW software provides a complete, commercial quality implementation of CP/M (and workalike) operating systems and applications for modern Z80/180/280 retro-computing hardware systems. A wide variety of platforms are supported including those produced by these developer communities: RetroBrew Computers ( https://www.retrobrewcomputers.org ) RC2014 ( https://rc2014.co.uk ), RC2014-Z80 ( https://groups.google.com/g/rc2014-z80 ) Retro Computing ( https://groups.google.com/g/retro-comp ) Small Computer Central ( https://smallcomputercentral.com/ ) A complete list of the currently supported platforms is found in RomWBW Hardware .","title":"Overview"},{"location":"Introduction/#description","text":"","title":"Description"},{"location":"Introduction/#primary-features","text":"By design, RomWBW isolates all of the hardware specific functions in the ROM chip itself. The ROM provides a hardware abstraction layer such that all of the operating systems and applications on a disk will run on any RomWBW-based system. To put it simply, you can take a disk (or CF/SD/USB Card) and move it between systems transparently. Supported hardware features of RomWBW include: Z80 Family CPUs including Z80, Z180, and Z280 Banked memory services for several banking designs Disk drivers for RAM, ROM, Floppy, IDE ATA/ATAPI, CF, SD, USB, Zip, Iomega Serial drivers including UART (16550-like), ASCI, ACIA, SIO Video drivers including TMS9918, SY6545, MOS8563, HD6445 Keyboard (PS/2) drivers via VT8242 or PPI interfaces Real time clock drivers including DS1302, BQ4845 Support for CP/NET networking using Wiznet, MT011 or Serial Built-in VT-100 terminal emulation support A dynamic disk drive letter assignment mechanism allows mapping operating system drive letters to any available disk media. Additionally, mass storage devices (IDE Disk, CF Card, SD Card, etc.) support the use of multiple slices (up to 256 per device). Each slice contains a complete CP/M filesystem and can be mapped independently to any drive letter. This overcomes the inherent size limitations in legacy OSes and allows up to 2GB of addressable storage on a single device, with up to 128MB accessible at any one time.","title":"Primary Features"},{"location":"Introduction/#included-software","text":"Multiple disk images are provided in the distribution. Most disk images contain a complete, bootable, ready-to-run implementation of a specific operating system. A \u201ccombo\u201d disk image contains multiple slices, each with a full operating system implementation. If you use this disk image, you can easily pick whichever operating system you want to boot without changing media. Some of the included software: Operating Systems (CP/M 2.2, ZSDOS, NZ-COM, CP/M 3, ZPM3, Z3PLUS, QPM ) Support for other operating systems, p-System, FreeRTOS, and FUZIX. Programming Tools (Z80ASM, Turbo Pascal, Forth, Cowgol) C Compiler\u2019s including Aztec-C, and HI-TECH C Microsoft Basic Compiler, and Microsoft Fortran Some games such as Colossal Cave, Zork, etc Wordstar Word processing software Some of the provided software can be launched directly from the ROM firmware itself: System Monitor Operating Systems (CP/M 2.2, ZSDOS) ROM BASIC (Nascom BASIC and Tasty BASIC) ROM Forth A tool is provided that allows you to access a FAT-12/16/32 filesystem. The FAT filesystem may be coresident on the same disk media as RomWBW slices or on stand-alone media. This makes exchanging files with modern OSes such as Windows, MacOS, and Linux very easy.","title":"Included Software"},{"location":"Introduction/#rom-distribution","text":"The RomWBW Repository ( https://github.com/wwarthen/RomWBW ) on GitHub is the official distribution location for all project source and documentation. RomWBW is distributed as both source code and pre-built ROM and disk images. The pre-built ROM images distributed with RomWBW are based on the default system configurations as determined by the hardware provider/designer. The pre-built ROM firmware images are generally suitable for most users. The fully-built distribution releases are available on the RomWBW Releases Page ( https://github.com/wwarthen/RomWBW/releases ) of the repository. On this page, you will normally see a Development Snapshot as well as recent stable releases. Unless you have a specific reason, I suggest you stick to the most recent stable release. The asset named RomWBW-vX.X.X-Package.zip includes all pre-built ROM and Disk images as well as full source code. The other assets contain only source code and do not have the pre-built ROM or disk images.","title":"ROM Distribution"},{"location":"Introduction/#distribution-directory-layout","text":"The RomWBW distribution is a compressed zip archive file organized in a set of directories. Each of these directories has its own ReadMe.txt file describing the contents in detail. In summary, these directories are: Directory Description Binary The final output files of the build process are placed here. Most importantly, the ROM images with the file names ending in \u201c.rom\u201d and disk images ending in .img. Doc Contains various detailed documentation, both RomWBW specifically as well as the operating systems and applications. Source Contains the source code files used to build the software and ROM images. Tools Contains the programs that are used by the build process or that may be useful in setting up your system.","title":"Distribution Directory Layout"},{"location":"Introduction/#building-from-source","text":"It is also very easy to modify and build custom ROM images that fully tailor the firmware to your specific preferences. All tools required to build custom ROM firmware under Windows are included \u2013 no need to install assemblers, etc. The firmware can also be built using Linux or MacOS after confirming a few standard tools have been installed.","title":"Building from Source"},{"location":"Introduction/#installation-operation","text":"In general, installation of RomWBW on your platform is very simple. You just need to program your ROM with the correct ROM image from the RomWBW distribution. Subsequently, you can write disk images on your disk drives (IDE disk, CF Card, SD Card, etc.) which then provides even more functionality. Complete instructions for installation and operation of RomWBW are found in the RomWBW User Guide . It is also a good idea to review the Release Notes for helpful release-specific information.","title":"Installation & Operation"},{"location":"Introduction/#documentation","text":"There are several documents that form the core of the RomWBW documentation: RomWBW User Guide is the main user guide for RomWBW, it covers the major topics of how to install, manage and use RomWBW, and includes additional guidance to the use of some of the operating systems supported by RomWBW RomWBW Hardware contains a description of all the hardware platforms, and devices supported by RomWBW. RomWBW Applications is a reference for the ROM-hosted and OS-hosted applications created or customized to enhance the operation of RomWBW. RomWBW Disk Catalog is a reference for the contents of the disk images provided with RomWBW, with a description of many of the files on each image RomWBW System Guide discusses much of the internal design and construction of RomWBW. It includes a reference for the RomWBW HBIOS API functions. Each of the operating systems and ROM applications included with RomWBW are sophisticated tools in their own right. It is not reasonable to fully document their usage. However, you will find complete manuals in PDF format in the Doc directory of the distribution. The intention of this documentation is to describe the operation of RomWBW and the ways in which it enhances the operation of the included applications and operating systems. Since RomWBW is purely a software product for many different platforms, the documentation does not cover hardware construction, configuration, or troubleshooting \u2013 please see your hardware provider for this information.","title":"Documentation"},{"location":"Introduction/#support","text":"","title":"Support"},{"location":"Introduction/#getting-assistance","text":"The best way to get assistance with RomWBW or any aspect of the RetroBrew Computers projects is via one of the community forums: RetroBrew Computers Forum RC2014 Google Group retro-comp Google Group Submission of issues and bugs are welcome at the RomWBW GitHub Repository . Also feel free to email Wayne Warthen at wwarthen@gmail.com . I am happy to provide support adapting RomWBW to new or modified systems","title":"Getting Assistance"},{"location":"Introduction/#contributions","text":"All source code and distributions are maintained on GitHub. Contributions of all kinds to RomWBW are very welcome.","title":"Contributions"},{"location":"Introduction/#acknowledgments","text":"I want to acknowledge that a great deal of the code and inspiration for RomWBW has been provided by or derived from the work of others in the RetroBrew Computers Community. I sincerely appreciate all of their contributions. The list below is probably missing many names \u2013 please let me know if I missed you! Andrew Lynch started it all when he created the N8VEM Z80 SBC which became the first platform RomWBW supported. Some of his original code can still be found in RomWBW. Dan Werner wrote much of the code from which RomWBW was originally derived and he has always been a great source of knowledge and advice. Douglas Goodall contributed code, time, testing, and advice in \u201cthe early days\u201d. He created an entire suite of application programs to enhance the use of RomWBW. Unfortunately, they have become unusable due to internal changes within RomWBW. As of RomWBW 2.6, these applications are no longer provided. Sergey Kiselev created several hardware platforms for RomWBW including the very popular Zeta. David Giles created support for the Z180 CSIO which is now included SD Card driver. Phil Summers contributed the Forth and BASIC adaptations in ROM, the AY-3-8910 sound driver, DMA support, and a long list of general code and documentation enhancements. Ed Brindley contributed some of the code that supports the RCBus platform. Spencer Owen created the RC2014 series of hobbyist kit computers which has exponentially increased RomWBW usage. Some of his kits include RomWBW. Stephen Cousins has likewise created a series of hobbyist kit computers at Small Computer Central and is distributing RomWBW with many of them. Alan Cox has contributed some driver code and has provided a great deal of advice. The CP/NET client files were developed by Douglas Miller. Phillip Stevens contributed support for FreeRTOS. Curt Mayer contributed the original Linux / MacOS build process. UNA BIOS and FDISK80 are the products of John Coffman. FLASH4 is a product of Will Sowerbutts. CLRDIR is a product of Max Scane. Tasty Basic is a product of Dimitri Theulings. Dean Netherton contributed eZ80 CPU support, the sound driver interface, and the SN76489 sound driver. The RomWBW Disk Catalog document was produced by Mykl Orders. Rob Prouse has created many of the supplemental disk images including Aztec C, HiTech C, SLR Z80ASM, Turbo Pascal, Microsoft BASIC Compiler, Microsoft Fortran Compiler, and a Games compendium. Martin R has provided substantial help reviewing and improving the User Guide and Applications documents. Mark Pruden has made a wide variety of contributions including: significant content in the Disk Catalog and User Guide creation of the Introduction and Hardware documents Z3PLUS operating system disk image COPYSL utility SLABEL utility a feature for RomWBW configuration by NVRAM the /B bulk mode of disk assignment to the ASSIGN utility Jacques Pelletier has contributed the DS1501 RTC driver code. Jose Collado has contributed enhancements to the TMS driver including compatibility with standard TMS register configuration. Kevin Boone has contributed a generic HBIOS date/time utility (WDATE). Matt Carroll has contributed a fix to XM.COM that corrects the port specification when doing a send. Dean Jenkins enhanced the build process to accommodate the Raspberry Pi 4. Tom Plano has contributed a new utility (HTALK) to allow talking directly to HBIOS COM ports. Lars Nelson has contributed several generic utilities such as a universal (OS agnostic) UNARC application. Dylan Hall added support for specifying a secondary console. Bill Shen has contributed boot loaders for several of his systems. Laszlo Szolnoki has contributed an EF9345 video display controller driver. Ladislau Szilagyi has contributed an enhanced version of CP/M Cowgol that leverages RomWBW memory banking. Les Bird has contributed support for the NABU w/ Option Board","title":"Acknowledgments"},{"location":"Introduction/#related-projects","text":"Outside of the hardware platforms adapted to RomWBW, there are a variety of projects that either target RomWBW specifically or provide a RomWBW-specific variation. These efforts are greatly appreciated and are listed below. Please contact the author if there are any other such projects that are not listed.","title":"Related Projects"},{"location":"Introduction/#z88dk","text":"Z88DK is a software powerful development kit for Z80 computers supporting both C and assembly language. This kit now provides specific library support for RomWBW HBIOS. The Z88DK project is hosted at https://github.com/z88dk/z88dk .","title":"Z88DK"},{"location":"Introduction/#paleo-editor","text":"Steve Garcia has created a Windows-hosted IDE that is tailored to development of RomWBW. The project can be found at https://github.com/alloidian/PaleoEditor .","title":"Paleo Editor"},{"location":"Introduction/#z80-fig-forth","text":"Dimitri Theulings\u2019 implementation of fig-FORTH for the Z80 has a RomWBW-specific variant. The project is hosted at https://github.com/dimitrit/figforth .","title":"Z80 fig-FORTH"},{"location":"Introduction/#assembly-language-programming-for-the-rc2014-zed","text":"Bruce Hall has written a very nice document that describes how to develop assembly language applications on RomWBW. It begins with the setup and configuration of a new RC2014 Zed system running RomWBW. It describes not only generic CP/M application development, but also RomWBW HBIOS programming and bare metal programming. The latest copy of this document is hosted at http://w8bh.net/Assembly for RC2014Z.pdf .","title":"Assembly Language Programming for the RC2014 Zed"},{"location":"Introduction/#licensing","text":"","title":"Licensing"},{"location":"Introduction/#license-terms","text":"RomWBW is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. RomWBW is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with RomWBW. If not, see https://www.gnu.org/licenses/ . Portions of RomWBW were created by, contributed by, or derived from the work of others. It is believed that these works are being used in accordance with the intentions and/or licensing of their creators. If anyone feels their work is being used outside of its intended licensing, please notify: Wayne Warthen wwarthen@gmail.com RomWBW is an aggregate work. It is composed of many individual, standalone programs that are distributed as a whole to function as a cohesive system. Each program may have its own licensing which may be different from other programs within the aggregate. In some cases, a single program (e.g., CP/M Operating System) is composed of multiple components with different licenses. It is believed that in all such cases the licenses are compatible with GPL version 3. RomWBW encourages code contributions from others. Contributors may assert their own copyright in their contributions by annotating the contributed source code appropriately. Contributors are further encouraged to submit their contributions via the RomWBW source code control system to ensure their contributions are clearly documented. All contributions to RomWBW are subject to this license.","title":"License Terms"},{"location":"SystemGuide/","text":"RomWBW System Guide \\ Version 3.6 \\ Wayne Warthen ( wwarthen@gmail.com ) \\ 31 May 2025 Overview The objective of RomWBW is to provide firmware, operating systems, and applications targeting the Z80 family of CPUs. The firmware, in the form of a ROM module, acts as the hardware interface layer with a well-defined API (the HBIOS). The associated operating systems and applications are adapted to the HBIOS API, not specific hardware. The HBIOS is modular and configurable. New hardware interfaces can be added in the form of straightforward driver modules. Within certain constraints, new hardware platforms can be supported by simply adjusting values in a build configuration file. RomWBW is geared toward hardware being developed in modern retro-computing hobbyist communities, not as replacement software for legacy hardware. As a result, RomWBW requires at least 128KB of bank switched RAM. The CP/M family of operating systems has been adapted to run under RomWBW including CP/M 2.2, Z-System, CP/M 3, and several other variants. RomWBW firmware (ROM) includes: System startup code (bootstrap) and bootloader A basic system/debug monitor HBIOS (Hardware BIOS) with support for most typical hardware components used in Z80 family computers Diagnostics and customizable debugging information. ROM-hosted operating systems (both CP/M 2.2 and Z-System) A ROM disk containing the standard OS applications and a RAM disk for working storage. It is appropriate to note that much of the code and components that make up a complete RomWBW package are derived from pre-existing work. Most notably, the embedded operating systems are simply ROM-based copies of generic CP/M or ZSDOS. Much of the hardware support code was originally produced by other members of the RetroBrew Computers Community. The remainder of this document focuses on RomWBW HBIOS which is the fundamental basis of RomWBW. Background The Z80 CPU architecture has a limited, 64K address range. In general, this address space must accommodate a running application, disk operating system, and hardware support code. Modern retro-computing Z80 CPU platforms provide a physical address space that is much larger than the CPU address space (typically 512K or 1MB of physical RAM). This additional memory can be made available to the CPU using a technique called bank switching. To achieve this, the physical memory is divided up into chunks (banks) of 32K each. A designated area of the CPU\u2019s 64K address space is then reserved to \u201cmap\u201d any of the physical memory chunks. You can think of this as a window that can be adjusted to view portions of the physical memory in 32K blocks. In the case of RomWBW, the lower 32K of the CPU address space is used for this purpose (the window). The upper 32K of CPU address space is assigned a fixed 32K area of physical memory that never changes. The lower 32K can be \u201cmapped\u201d on the fly to any of the 32K banks of physical memory at a time. The primary constraint is that the CPU cannot be executing code in the lower 32K of CPU address space at the time that a bank switch is performed. By utilizing the pages of physical RAM for specific purposes and swapping in the correct page when needed, it is possible to utilize substantially more than 64K of RAM. Because the retro-computing community has now produced a very large variety of hardware, it has become extremely important to implement a bank switched solution to accommodate the maximum range of hardware devices and desired functionality. General Design Strategy The design goal is to locate as much of the hardware dependent code as possible out of normal 64KB CP/M address space and into a bank switched area of memory. A very small code shim (proxy) is located in the top 512 bytes of CPU memory. This proxy is responsible for redirecting all hardware BIOS (HBIOS) calls by swapping the \u201cdriver code\u201d bank of physical RAM into the lower 32K and completing the request. The operating system is unaware this has occurred. As control is returned to the operating system, the lower 32KB of memory is switched back to the original memory bank. The HBIOS functions are invoked simply by placing function parameters in Z80 registers and calling an address within the HBIOS proxy. Additionally, HBIOS implements a complete hardware interrupt management framework. When a hardware interrupt occurs, control vectors through the HBIOS proxy which saves the machine state, selects the HBIOS driver bank into memory, and transfers control to the registered driver\u2019s interrupt handler. Upon completion of interrupt processing, control returns via the HBIOS proxy, machine state is restored, and normal processing resumes. The interrupt management framework supports Z80 interrupt modes 1, 2, and 3 (Z280). HBIOS is completely agnostic with respect to the operating system (it does not know or care what operating system is using it). The operating system makes simple calls to HBIOS to access any desired hardware functions. Since the HBIOS proxy occupies only 512 bytes at the top of memory, the vast majority of the CPU memory is available to the operating system and the running application. As far as the operating system is concerned, all of the hardware driver code has been magically implemented inside of the small 512 byte area at the top of the CPU address space. Unlike some other Z80 bank switching schemes, there is no attempt to build bank switching into the operating system itself. This is intentional so as to ensure that any operating system can easily be adapted without requiring invasive modifications to the operating system itself. This also keeps the complexity of memory management completely away from the operating system and applications. There are some operating systems that have built-in support for bank switching (e.g., CP/M 3). These operating systems are allowed to make use of the bank switched memory and are compatible with HBIOS. However, it is necessary that the customization of these operating systems take into account the banks of memory used by HBIOS and not attempt to use those specific banks. Note that all code and data are located in RAM memory during normal execution. While it is possible to use ROM memory to run code, it would require that more upper memory be reserved for data storage. It is simpler and more memory efficient to keep everything in RAM. At startup (boot) all required code is copied to RAM (shadowed) for subsequent execution. Runtime Memory Layout RomWBW divides the standard 64KB Z80 address space into 2 sections. The lower 32KB is the \u201cbanked\u201d area. This is the area that will contain any of the 32KB chunks of physical RAM based on which bank is currently selected. The upper 32KB is \u201cfixed\u201d. This area of memory is never swapped out and is used to contain software and operating systems that must remain in the Z80 address space. Throughout this document, this mechanism of selecting banks of memory into the lower 32K is referred to as memory management. Achieving this functionality requires some type of hardware which is generally referred to as the system\u2019s Memory Management Unit (MMU). RomWBW supports a variety of MMUs \u2013 but they all perform the same function of swapping in/out banks of memory in the lower 32K of CPU address space. Figure 4.1 depicts the memory layout for a system running the CP/M operating system. Applications residing in TPA invoke BDOS services of CP/M, BDOS invokes the custom CBIOS APIs, and finally CBIOS invokes HBIOS functions as needed by calling into the HBIOS proxy. The HBIOS proxy swaps in the HBIOS bank as needed to perform the requested function. Additional banks of RAM are used to create a virtual disk drive. Bank Switched Memory Layout Bank Id RomWBW utilizes a specific assignment of memory banks for dedicated purposes. A numeric Bank Id is used to refer to the memory banks. The Bank Id is a single byte. In general, the Bank Id simply refers to each of the 32K banks in sequential order. In other words, Bank Id 0 is the first physical 32K, Bank Id 1 is the second, etc. However, the high order bit of the Bank Id has a special meaning. If it is 0, it indicates a ROM bank is being referred to. If it is 1, it indicates a RAM bank is being referred to. For example, let\u2019s say we have a typical system with 512KB of ROM and 512KB of RAM. The following table demonstrates how Bank Ids represent areas of physical memory. Physical Memory Type Physical Bank Bank Id 0x000000-0x007FFF ROM 0 0x00 0x008000-0x00FFFF ROM 1 0x01 0x010000-0x07FFFF ROM 2-15 0x02-0x0F 0x080000-0x087FFF RAM 16 0x80 0x088000-0x08FFFF RAM 17 0x81 0x090000-0x0FFFFF RAM 18-31 0x82-0x8F Note that Bank Id 0x00 is always the first bank of ROM and 0x80 is always the first bank of RAM. If there were more banks of physical ROM, they would be assigned Bank Ids starting with 0x10. Likewise, additional bank of physical RAM would be assigned Bank Ids starting with 0x90. The Bank Id is used in all RomWBW API functions when referring to the mapping of banks to the lower 32K bank area of the processor. In this way, all RomWBW functions can refer to a generic Bank Id without needing to understand how a specific hardware platform accesses the physical memory areas. A single routine within the HBIOS is implemented for each memory manager that maps Bank Ids to physical memory. Bank Assignments RomWBW requires dedicated banks of memory for specific purposes. It uses Bank Ids via an algorithm to make these assignments. The following table describes the way the banks are assigned. The Typical column shows the specific values that would be assigned for a common system with 512KB of ROM and 512KB of RAM (nROM=16, nRAM=16). Bank Id Identity Typical Purpose 0x00 BID_BOOT 0x00 Boot Bank (HBIOS image) 0x01 BID_IMG0 0x01 Boot Loader, Monitor, ROM OSes, ROM Apps 0x02 BID_IMG1 0x02 ROM Apps 0x03 BID_IMG2 0x03 \\ 0x04 BID_ROMD0 0x04 First ROM Disk Bank nROM - 1 0x0F Last ROM Disk Bank 0x80 BID_BIOS 0x80 HBIOS (working copy) 0x81 BID_RAMD0 0x81 First RAM Disk Bank 0x80 + nRAM - 8 0x88 Last RAM Disk Bank 0x80 + nRAM - 7 BID_APP0 0x89 First Application Bank 0x80 + nRAM - 5 0x8B Last Application Bank 0x80 + nRAM - 4 BID_BUF 0x8C OS Disk Buffers 0x80 + nRAM - 3 BID_AUX 0x8D OS Code Bank 0x80 + nRAM - 2 BID_USR 0x8E User Bank (CP/M TPA) 0x80 + nRAM - 1 BID_COM 0x8F Common Bank In this table, nROM and nRAM refer to the number of corresponding ROM and RAM banks in the the system. The contents of the banks referred to above are described in more detail below: Boot Bank: The Boot Bank receives control when a system is first powered on. It contains a ROM (read-only) copy of the HBIOS. At boot, it does minimal hardware initialization, then copies itself to the HBIOS bank in RAM, then resumes execution from the RAM bank. Boot Loader: The application that handles loading of ROM or Disk based applications including operating systems. It copies itself to a RAM bank at the start of it\u2019s execution. Monitor: The application that implements the basic system monitor functions. It copies itself to a RAM bank at the start of it\u2019s execution. ROM OSes: Code images of CP/M 2.2 and Z-System which are copied to RAM and executed when a ROM-based operating system is selected in the Boot Loader. ROM Applications: Various ROM-based application images such as BASIC, FORTH, etc. They can be selected in the Boot Loader. The Boot Loader will copy the application image to a RAM bank, then transfer control to it. ROM Disk: A sequential series of banks assigned to provide the system ROM Disk contents. HBIOS: This bank hosts the running copy of the RomWBW HBIOS. RAM Disk: A sequential series of banks assigned to provide the system RAM Disk. Application Bank: A sequential series of banks that are available for use by applications that wish to utilize banked memory. OS Disk Buffers: This bank is used by CP/M 3 and ZPM3 for disk buffer storage. OS Code Bank: This bank is used by CP/M 3 and ZPM3 as an alternate bank for code. This allows these operating systems to make additional TPA space available for applications. User Bank: This is the default bank for applications to use. This includes the traditional TPA space for CP/M. Common Bank: This bank is mapped to the upper 32K of the processors memory space. It is a fixed mapping that is never changed in normal RomWBW operation hence the name \u201cCommon\u201d. Memory Managers The following hardware memory managers are supported by RomWBW. The operation of these memory managers is not documented here \u2013 please refer to the documentation of your hardware provider for that. Z2: Memory memory manager introduced by Sergey Kiselv in the Zeta 2 SBC. Popular in many RCBus systems. Z180: Memory manager built into the Z180 CPU Z280: Memory manager built into the Z280 CPU ZRC: Memory manager onboard the ZRC series of computers by Bill Shen. SBC: Memory manager onboard the N8VEM SBC series of computers by Andrew Lynch. MBC: Memory manager onboard the Nhyodyne computer system by Andrew Lynch. N8: Memory manager onboard the N8 SBC computer by Andrew Lynch. EZ512: Memory manager onboard the EaZy80-512 Z80 CPU Module by Bill Shen. RPH: Memory manager onboard the Rhyophyre computer system by Andrew Lynch. The memory manager used is determined by the configuration choices that are part of a RomWBW build process. A given ROM can only have a single memory manager \u2013 it is not selected dynamically. Disk Layout Floppy Disk Layout RomWBVW generally handles floppy disks in the same physical formats as MS-DOS. However, the filesystem will normally be CP/M. The following table lists the floppy disk formats used by RomWBW. In all cases, the sector size is 512 bytes. HBIOS Media ID Capacity Tracks Heads Sectors MID_FD720 720KB 80 2 9 MID_FD144 1440KB 80 2 18 MID_FD360 360KB 40 2 9 MID_FD120 1200KB 80 2 15 MID_FD111 1155KB 77 2 15 Hard Disk Layout RomWBW supports the use of PC MBR hard disk partitioning (see https://en.wikipedia.org/wiki/Disk_partitioning ). When accessing a hard disk device, HBIOS will look for a partition with type id 0x2E and will use that partition exclusively for all storage. If a hard disk does not have a valid partition table with a partition of type 0x2E, the HBIOS will treat the hard disk as dedicated storage and will store data starting at the first sector of the disk. The use of a partition of type 0x2E is preferred for RomWBW and is referred to as a \u201cModern\u201d disk layout. If there is no RomWBW partition on the disk, then the disk is designated as having a \u201cClassic\u201d disk layout. When a disk uses a RomWBW partition (type 0x2E) for storage (Modern layout), the CP/M filesystems on that disk will utilize a format with 1,024 directory entries per filesystem. If there is no RomWBW partition, the CP/M filesystems will have 512 directory entries per filesystem. As a result, the Modern disk layout with a RomWBW partition is also referred to as the \u201chd1k\u201d layout indicating 1024 directory entries. Similarly, the Classic disk layout (no partition of type 0x2E) is also referred to as the \u201chd512\u201d layout indicating 512 directory entries. The layout type of any hard disk is simply dictated by the existence of a RomWBW partition. This also means that if you add or remove a partition table entry of type 0x2E on existing hard disk media, you will lose access to any pre-existing CP/M data on the disk. If used, partitioning should be done before putting any data on the disk. WARNING: You can not mix the two hard disk layouts on one hard disk device. You can use different layouts on different hard disk devices in a single system though. Regardless of whether a disk is Modern or Classic, RomWBW supports the concept of CP/M filesystem slices. In general, CP/M filesystems are limited to 8MB. Since current disk media is dramatically larger than this, RomWBW implements a mechanism to put many (up to 256) CP/M filesystems on a single disk. Each such filesystem is called a slice referring to the idea that the disk has been sliced into many independent CP/M filesystems. RomWBW allows the disk slices to be mapped to the limited (16) drive letters of CP/M. The mapping can be modified on-the-fly on a running system as desired. If the case of a Modern disk layout (with a RomWBW partition), the slices are contained within the defined partition area and the number of slices is dictated by the size of the partition. In the case of a Classic disk layout (no RomWBW partition), the slices are located at the start of the disk (first sector). In either case, the slices are just sequential areas of space on the hard disk. RomWBW accesses all hard disks using Logical Block Addressing (pure sector offset). When necessary, RomWBW simulates the following disk geometry for operating systems: Sector = 512 Bytes Track = 16 Sectors (8KB per Track) Cylinder = 16 Tracks (256 Sectors per Cylinder, 128KB per Cylinder) If one is used, the FAT Partition must not overlap the CP/M slices. The FAT partition does not need to start immediately after the CP/M slices nor does it need to extend to the end of the hard disk. Its location and size are entirely determined by its corresponding partition table entry. Drive letters in CP/M are ASSIGNed to the numbered slices as desired. At boot, RomWBW automatically assigns up to 8 slices to drive letters starting with the first available drive letter (typically C:). Microsoft Windows will assign a single drive letter to the FAT partition when the CF/SD Card is inserted. The drive letter assigned has no relationship to the CP/M drive letters assigned to CP/M slices. In general, Windows, MacOS, or Linux know nothing about the CP/M slices and CP/M knows nothing about the FAT partition. However, the FAT application can be run under CP/M to access the FAT partition programmatically. Before being used, A CP/M slice must be (re)initialized using the CP/M command CLRDIR. A CP/M slice can be made bootable by copying a system image to the System Area using SYSCOPY. The FAT partition can be created from CP/M using the FDISK80 application. The FAT partition can be initialized using the FAT application from CP/M using the command FAT FORMAT n: where n is the RomWBW disk unit number containing the FAT partition to be formatted. Modern Hard Disk Layout (hd1k) Modern Disk Layout The CP/M filesystem on a Modern disk will accommodate 1,024 directory entries. The CP/M slices reside entirely within a hard disk partition of type 0x2E. The number of slices is determined by the number of slices that fit within the partition spaces allocated up to the maximum of 256. Classic Hard Disk Layout (hd512) Classic Disk Layout The CP/M filesystem on a Classic disk will accommodate 512 directory entries. The CP/M slices reside on the hard disk starting at the first sector of the hard disk. The number of CP/M slices is not explicitly recorded anywhere on the hard disk. It is up to the system user to know how many slices are being used based on the size of the hard disk media and/or the start of a FAT partition. A partition table may exist within the first sector of the first slice. For Classic disks, the partition table defines only the location and size of the FAT partition. The Partition Table does not control the location or number of CP/M slices in any way. The Partition Table resides in a sector that is shared with the System Area of CP/M Slice 0. However, the RomWBW implementation of CP/M takes steps to avoid changing or corrupting the Partition Table area. The FAT partition can be created from CP/M using the FDISK80 application. The user is responsible for ensuring that the start of the FAT partition does not overlap with the area they intend to use for CP/M slices. FDISK80 has a Reserve option to assist with this. Mapping to Media ID HBIOS has a definition of \u201cMedia ID\u201d, which defines the type and physical properties of disk media provided by an underlying storage device. For a complete list of Media ID\u2019s please see Disk Input/Output (DIO) . There are two important Media ID\u2019s relating to Hard Disk Layouts: Media ID Format / Meaning MID_HD 4 Classic Disk Layout (hd512) \u2013and\u2013 HBIOS Hard Disk Drive MID_HDNEW 10 Modern Disk Layout (hd1k) HBIOS typically does not understand the format of data on a device, instead just treating all hard disks as raw sectors. MID_HD is the typical Media ID used by HBIOS to describe high capacity hard disk media When the Modern Disk Layout was added, the MID_HDNEW , was added to differentiate (at the operating system level) between the Classic and Modern layouts. However HBIOS itself typically does NOT make this distinction, since the use of these two formats is determined by the operating system based on the partition table on the media. There are two important HBIOS functions that deal with Media ID. Function 0x18 \u2013 Disk Media (DIOMEDIA) Function 0xE0 \u2013 Calculate Slice (EXTSLICE) System Boot Process A multi-phase boot strategy is employed. This is necessary because at cold start, the CPU is executing code from ROM in lower memory which is the same area that is bank switched. RomWBW supports multiple boot techniques as described below. The most common of these is the ROM boot. ROM Boot The ROM boot process normally begins with a system cold start (power on or hardware reset). The hardware is responsible for ensuring that the lower 32K of CPU memory (bank window) is mapped to the initial 32K of the ROM. The Z80 CPU begins execution at address zero which will be address zero of the ROM. The following steps occur during the ROM boot process: The ROM code performs basic hardware initialization and ensures that the top 32K of CPU memory is mapped to the proper RAM bank. The ROM code installs the HBIOS proxy code into the top 512 bytes of the CPU memory (0xFE00-0xFFFF). Using the proxy code services, the full HBIOS code is copied from the ROM bank to the RAM bank that it will use for normal processing. Again using the proxy code services, the RAM copy of HBIOS is activated in the bank window and execution transitions to the RAM copy of HBIOS. The HBIOS initializes the system console so that output can now be displayed to the user. The HBIOS now performs the full hardware discovery and initialization process while displaying it\u2019s progress. The HBIOS displays a final summary of the hardware device unit assignments and various configuration information. The HBIOS loads the RomWBW Boot Loader from ROM into RAM and jumps to it. At this point, the user would normally use Boot Loader commands to select and launch an operating system or applications from either ROM or disk. Note that the boot process is entirely operating system agnostic. It is unaware of the operating system being loaded. The Boot Loader prompts the user for the location of the binary image to load, but does not know anything about what is being loaded (the image is usually an operating system, but could be any executable code image). Once the Boot Loader has loaded the image at the selected location, it will transfer control to it. Assuming the typical situation where the image was an operating system, the loaded operating system will then perform its own initialization and begin normal operation. Application Boot Once the system is running (operating system loaded), it is possible to reboot the system from a system image (file) contained on the OS file system. This is referred to as an \u201cApplication Boot\u201d. The process is similar to a ROM boot, but the HBIOS code is loaded from an image file instead of ROM. This boot technique is useful to: 1) test a new build of a system image before programming it to the ROM; or 2) easily switch between system images on the fly. During the RomWBW build process, one of the output files produced is an actual CP/M application (an executable .COM program file). Like the normal .ROM files, this file is placed in the Binary directory with the same name as the ROM file, but with the file extension of .ROM. Once you have a running CP/M (or compatible) system, you can upload/copy this application file to the filesystem. By executing this file, you will initiate an Application Boot using the system image contained in the application file itself. Upon execution, the Application Boot program is loaded into memory by the previously running operating system starting at \\$0100. Note that the program image contains a full copy of the HBIOS to be installed and run. Once the Application Boot program is loaded by the previous operating system, control is passed to it and it performs a system initialization similar to the ROM Boot, but using the image loaded in RAM. Once the new HBIOS completes its initialization, it will launch the Boot Loader just like a ROM boot. The Application Boot program actually contains two other components beyond the new HBIOS. It has a copy of the Boot Loader and a copy of the Z-System OS. This is done in case the new HBIOS requires updated versions of the Boot Loader or OS to run. The Boot Loader is aware of this boot mode and automatically adapts it\u2019s menu appropriately. If you restart your system, then it will revert to a ROM Boot from the currently installed ROM. RAM Boot Some hardware supported by RomWBW has a special mechanism for loading the boot and HBIOS code. These systems have no ROM chips. However, they have a small hardware bootstrap that loads a chunk of code from a disk device directly into RAM at system startup. The startup then proceeds very much like the Application Boot process described above. HBIOS is installed in its operating bank and control is passed to the Boot Loader. Boot Recovery To assist users when driver faults or mis-configuration causes a boot failure, RomWBW supports a limited recovery capability. This is achieved by allowing the user to reboot their machine, loading a minimal driver set. Implementation of this feature requires a hardware input \u201cBOOT RECOVERY\u201d button to be available and appropriate software configuration to be completed in the HBIOS. When implemented, holding the \u201cBOOT RECOVERY\u201d button in after a reset or power cycle will cause the normal driver load process to be skipped in preference to a minimal set of drivers being loaded. Typically this would be: Serial communication, RAM disk and parallel port IDE interface drivers. Platforms supporting this option currently are the MBC, Duodyne and latter version of the SBC. Configuration RomWBW NVRAM Configuration On systems with RTC devices (that have Non-Volatile RAM), RomWBW supports storing some limited configuration option options inside this RAM. Several configuration options are currently supported; these are known as Switches. The following switch ID\u2019s are defined, and described in sections below. Switch Number Name Description 0x00 -reserved- Reserved 0x01 Boot Options ROM or Disk Boot Settings 0x02 -n/a- -n/a- high order byte of previous switch 0x03 Auto Boot Automatically boot enabled without user input 0x04 - 0xFE -future- Future general usage 0xFF Status Reset Get Status or Reset Switches to Default RomWBW uses bytes located at the start of RTC NVRAM, and includes a Parity check of the bytes in NVRAM to check for authenticity before using the configuration. NVRAM Byte Name Description 0x00 Header Byte Header Signature Byte \u2018W\u2019 0x01 - 0x03 Switch Data Actual Switch Data 0x04 Parity Check Checksum byte to check integrity The above data is copied into the HBIOS Configuration Block (HCB) at startup at the location starting at CB_SWITCHES. Boot Options (NVSW_BOOTOPTS) 16 bit Switch defining the ROM application or Disk device to boot if automatic booting is enabled. Bit 15 Bits 14-8 Bits 7-0 1 = ROM App -undefined- App to Boot (Char) 0 = Disk Disk Unit (0-127) Disk Slice (0-255) Auto Boot (NVSW_AUTOBOOT) 8 bit Switch defining if the system should auto boot at startup. Bits 7-6 Bit 5 Bit 4 Bits 3-0 -unused- 1 = Auto Boot Enabled -unused- 0 = Immediate Boot with no delay -unused- 1 = Auto Boot Enabled -unused- (1-15) Timeout (seconds) before boot -unused- 0 = Auto Boot Disabled -unused- -undefined- Status Reset (0xFF) The Status Reset switch is not a general purpose switch, it is a control mechanism to allow the global status of all switches to be determined. The meaning of the switch is different for Read (Get Status) and Write (Reset NVRAM) GET (Get Status) The read Get Status of switches. This returns very specific values from the function call. Status A Register Z / NZ Flag NVRAM does not exist A=0 NZ flag set NVRAM exists, but has not been initialised A=1 NZ flag set NVRAM exists, and has been fully initialised A=\u2018W\u2019 Z flag set SET (Reset NVRAM) Reset NVRAM to default values. This will wipe any existing data and set default values into NVRAM. Driver Model The framework code for bank switching also allows hardware drivers to be implemented mostly without concern for memory management. Drivers are coded to simply implement the HBIOS functions appropriate for the type of hardware being supported. When the driver code gets control, it has already been mapped to the CPU address space and simply performs the requested function based on parameters passed in registers. Upon return, the bank switching framework takes care of restoring the original memory layout expected by the operating system and application. Drivers do need to be aware of the bank switching if a buffer address is being used in the function call. If the buffer address is in the lower 32K of RAM, then the memory it points to will be from the User Bank, not the HBIOS bank which is now active. In this case, the driver must use an inter-bank copy to access the data. If the buffer address is in the top 32K of RAM, then the driver will have access to it directly even after a bank switch, so no special steps are required. For some functions, the location of the buffer is required to be in the top 32K of RAM to simplify the operation of the driver. It is usually better if the OS or application calling a buffered function places the buffer in the top 32K because this may avoid a double-copy operation. If driver code must make calls to other code, drivers, or utilities in the HBIOS bank, it must make those calls directly (it must not use RST 08). This is to avoid a nested bank switch which is not supported at this time. Character / Emulation / Video Services In addition to a generic set of routines to handle typical character input/output, HBIOS also includes functionality for managing built-in video display adapters. To start with there is a basic set of character input/output functions, the CIOXXX functions, which allow for simple character data streams. These functions fully encompass routing byte stream data to/from serial ports. Note that there is a special character pseudo-device called \u201cCRT\u201d. When characters are read/written to/from the CRT character device, the data is actually passed to a built-in terminal emulator which, in turn, utilizes a set of VDA (Video Display Adapter) functions (such as cursor positioning, scrolling, etc.). Figure 9.1 depicts the relationship between these components of HBIOS video processing: Character / Emulation / Video Services Normally, the operating system will simply utilize the CIOXXX functions to send and receive character data. The Character I/O Services will route I/O requests to the specified physical device which is most frequently a serial port (such as UART or ASCI). As shown above, if the CRT device is targeted by a CIOXXX function, it will actually be routed to the Emulation Services which implement TTY, ANSI, etc. escape sequences. The Emulation Services subsequently rely on the Video Display Adapter Services as an additional layer of abstraction. This allows the emulation code to be completely unaware of the actual physical device (device independent). Video Display Adapter (VDA) Services contains drivers as needed to handle the available physical video adapters. Note that the Emulation and VDA Services API functions are available to be called directly. Doing so must be done carefully so as to not corrupt the \u201cstate\u201d of the emulation logic. Before invoking CIOXXX functions targeting the CRT device, it is necessary that the underlying layers (Emulation and VDA) be properly initialized. The Emulation Services must be initialized to specify the desired emulation and specific physical VDA device to target. Likewise, the VDA Services may need to be initialized to put the specific video hardware into the proper mode, etc. HBIOS Reference Invocation HBIOS functions are invoked by placing the required parameters in CPU registers and executing an RST 08 instruction. Note that HBIOS does not preserve register values that are unused. However, the values of the Z80 alternate registers and IX/IY will be preserved (these registers may be used within HBIOS, but will be saved and restored internally). An alternate method of invoking HBIOS functions is to use CALL $FFF0 . Since the RST 08 vector exists in page zero of the CPU address space, it may be paged out when alternate memory banks are selected. If this may be true when you are invoking a function, you should use the CALL method. Normally, applications will not call HBIOS functions directly. It is intended that the operating system makes all HBIOS function calls. Applications that are considered system utilities may use HBIOS, but must be careful not to modify the operating environment in any way that the operating system does not expect. In general, the desired function is placed in the B register. Register C is frequently used to specify a sub-function or a target device unit number. Additional registers are used as defined by the specific function. Register A should be used to return function result information. See below for result code definitions. The character, disk, and video device functions all refer to target devices using a logical device unit number that is passed in the C register. Keep in mind that these unit numbers are assigned dynamically at HBIOS initialization during the device discovery process. The assigned unit numbers are displayed on the console at the conclusion of device initialization. The unit assignments will never change after HBIOS initialization. However, they can change at the next boot if there have been hardware or BIOS customization changes. Code using HBIOS functions should not assume fixed unit assignments. Some functions utilize pointers to memory buffers. Unless otherwise stated, such buffers can be located anywhere in the Z80 CPU 64K address space. However, performance sensitive buffers (primarily disk I/O buffers) will require double-buffering if the caller\u2019s buffer is in the lower 32K of CPU address space. For optimal performance, such buffers should be placed in the upper 32K of CPU address space. HBIOS also implements a small number of core functions in the HBIOS proxy area at the top of RAM. These exist primarily to facilitate the operation of normal HBIOS function calls. However, they are available to be used by OSes and applications. These functions can only be invoked by calling into a jump table in upper RAM. Result Codes The following function result codes are defined generically for all HBIOS functions. Most function calls will return a result in register A. Code Definition 0 function succeeded -1 undefined error -2 function not implemented -3 invalid function -4 invalid unit number -5 out of memory -6 parameter out of range -7 media not present -8 hardware not present -9 I/O error -10 write request to read-only media -11 device timeout -12 invalid configuration Character Input/Output (CIO) Character Input/Output functions require that a Character Unit number be specified in register C. This is the logical device unit number assigned during the boot process that identifies all character devices uniquely. A special value of 0x80 can be used for the Character Unit to refer to the current console device. All character units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver CIODEV_UART 0x00 16C550 Family Serial Interface uart.asm CIODEV_ASCI 0x01 Z180 Built-in Serial Ports asci.asm CIODEV_TERM 0x02 Terminal ansi.asm CIODEV_PRPCON 0x03 PropIO Serial Console Interface prp.asm CIODEV_PPPCON 0x04 ParPortProp Serial Console Interface ppp.asm CIODEV_SIO 0x05 Zilog Serial Port Interface sio.asm CIODEV_ACIA 0x06 MC68B50 Asynchronous Interface acia.asm CIODEV_PIO 0x07 Zilog Parallel Interface Controller pio.asm CIODEV_UF 0x08 FT232H-based ECB USB FIFO uf.asm CIODEV_DUART 0x09 SCC2681 Family Dual UART duart.asm CIODEV_Z2U 0x0A Zilog Z280 Built-in Serial Ports z2u.asm CIODEV_LPT 0x0B Parallel I/O Controller lpt.asm CIODEV_ESPCON 0x0C ESP32 VGA Console esp.asm CIODEV_ESPSER 0x0D ESP32 Serial Port esp.asm CIODEV_SCON 0x0E S100 Console scon.asm CIODEV_SSER 0x0F Simple Serial Console sser.asm CIODEV_EZ80UART 0x10 eZ80 Built-in UART0 Interface ez80uart.asm Character devices can usually be configured with line characteristics such as speed, framing, etc. A word value (16 bit) is used to describe the line characteristics as indicated below: Bits Characteristic 15-14 Reserved (set to 0) 13 RTS 12-8 Baud Rate (see below) 7 DTR 6 XON/XOFF Flow Control 5 1 = Stick Parity(Mark/Space), 0 = Normal Parity (odd/even) 4 1 = Even/Space, 0 = Odd/Mark 3 Parity Enable (set for true) 2 Stop Bits (set for true) 1-0 Data Bits (5-8 encoded as 0-3) The 5-bit Baud Rate value (V) is encoded as V = 75 * 2^X * 3^Y. The bits are defined as YXXXX. Actual character values are a single byte (8 bits). The Character I/O functions do not modify or interpret the values being sent/received so they can be used to pass 8-bit binary data without corruption. Note that some OSes will modify character data (truncate to 7 bits, etc.). Function 0x00 \u2013 Character Input (CIOIN) Entry Parameters Returned Values B: 0x00 A: Status C: Character Unit E: Character Read and return a Character (E) from the specified Character Unit (C). If no character(s) are available in the unit\u2019s input buffer, this function will wait indefinitely. The returned Status (A) is a standard HBIOS result code. Function 0x01 \u2013 Character Output (CIOOUT) Entry Parameters Returned Values B: 0x01 A: Status (0-OK, else error) C: Character Unit E: Character Send a Character (E) via the specified Character Unit (C). If there is no space available in the unit\u2019s output buffer, the function will wait indefinitely. The returned Status (A) is a standard HBIOS result code. Function 0x02 \u2013 Character Input Status (CIOIST) Entry Parameters Returned Values B: 0x02 A: Status / Characters Pending C: Character Unit Return the count of Characters Pending (A) in the input buffer of the specified Character Unit (C). If the unit has no input buffer or the buffer utilization is not available, the function may return simply 0 or 1 where 0 means there is no character available and 1 means there is at least one character available. The value returned in register A is used as both a Status (A) code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the number of characters in the input buffer. Function 0x03 \u2013 Character Output Status (CIOOST) Entry Parameters Returned Values B: 0x03 A: Status / Space Free C: Character Unit Return the count of buffer Space Free (A) for the specified Character Unit (C). For example, if a 16 byte output buffer contains 6 characters waiting to be sent out the unit\u2019s serial interface, this function would return 10; the number of positions available in the output buffer. If the port has no output buffer or the buffer utilization is not available, the function may return simply 0 or 1 where 0 means there is no buffer space available and 1 means there is space in the output buffer for at least one character. The return value in register A is used as both a status code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the buffer space available. Function 0x04 \u2013 Character I/O Initialization (CIOINIT) Entry Parameters Returned Values B: 0x04 A: Status C: Character Unit DE: Line Characteristics Condition the interface of the specified Character Unit (C) according to the specified Line Characteristics (DE). The definition of the line characteristics value is described above. If DE contains -1 (0xFFFF), then the device will be reinitialized with the previous line characteristics used (a reset) and any buffer contents will be flushed. The Status (A) is a standard HBIOS result code. Not all line characteristics are supported by all character interfaces. It is up to the driver of the character unit to decide how to deal with characteristics that are not available. For example, many character drivers do not allow flow control settings (RTS/CTS, XON/XOFF) to be modified dynamically. In most cases, these settings are ignored by the driver in this function call. Function 0x05 \u2013 Character I/O Query (CIOQUERY) Entry Parameters Returned Values B: 0x05 A: Status C: Character Unit DE: Line Characteristics Returns the current Line Characteristics (DE) of the specified Character Unit (C). The definition of the line characteristics value is described above. The returned status (A) is a standard HBIOS result code. Function 0x06 \u2013 Character I/O Device (CIODEVICE) Entry Parameters Returned Values B: 0x06 A: Status C: Character Unit C: Device Attributes D: Device Type E: Device Number H: Device Mode L: Device I/O Base Address Returns device information for the specified Character Unit (C). The status (A) is a standard HBIOS result code. The two high bits of Device Attribute (C) are: 00 = RS/232, 01 = Terminal, 10 = Parallel. The remaining bits should be ignored and are used internally. Device Type (D) indicates the specific hardware driver that handles the specified Character Unit. Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. For example, a Device Type of 0x50 with a Device Number of 2 refers to the third port being handled by the SIO driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. For example, for a UART, the value indicates the chip variant. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used. Disk Input/Output (DIO) Disk Input/Output functions require that a Disk Unit number be specified in register C. This is the logical device unit number assigned during the boot process that identifies all disk devices uniquely. All character units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates their values. Device Type ID Description Driver DIODEV_MD 0x00 Memory Disk md.asm DIODEV_FD 0x01 Floppy Disk fd.asm DIODEV_RF 0x02 RAM Floppy rf.asm DIODEV_IDE 0x03 IDE Disk ide.asm DIODEV_ATAPI 0x04 ATAPI Disk (not implemented) DIODEV_PPIDE 0x05 PPIDE Disk ppide.asm DIODEV_SD 0x06 SD Card sd.asm DIODEV_PRPSD 0x07 PropIO SD Card prp.asm DIODEV_PPPSD 0x08 ParPortProp SD Card ppp.asm DIODEV_HDSK 0x09 SIMH HDSK Disk hdsk.asm DIODEV_PPA 0x0A Iomega PPA Disk ppa.asm DIODEV_IMM 0x0B Iomega IMM Disk imm.asm DIODEV_SYQ 0x0C Syquest Sparq Disk syq.asm DIODEV_CHUSB 0x0D CH375/376 USB Disk ch.asm DIODEV_CHSD 0x0E CH375/376 SD Card ch.asm A fixed set of media types are defined. The currently defined media types identifiers are listed below. Each driver will support one or more of the defined media types. Media ID Format MID_NONE 0 No media installed MID_MDROM 1 ROM Drive MID_MDRAM 2 RAM Drive MID_RF 3 RAM Floppy (LBA) MID_HD 4 Hard Disk (LBA) w/ 512 directory entries MID_FD720 5 3.5\u201d 720K Floppy MID_FD144 6 3.5\u201d 1.44M Floppy MID_FD360 7 5.25\u201d 360K Floppy MID_FD120 8 5.25\u201d 1.2M Floppy MID_FD111 9 8\u201d 1.11M Floppy MID_HDNEW 10 Hard Disk (LBA) w/ 1024 directory entries NOTE : HBIOS typically does not actually differentiate between MID_HD and MID_HDNEW, it will generally only use MID_HD. See the section Mapping to Media ID for information on this. HBIOS supports both Cylinder/Head/Sector (CHS) and Logical Block Addresses (CHS) when locating a sector for I/O (see DIOSEEK function). For devices that are natively CHS (e.g., floppy disk), the HBIOS driver can convert LBA values to CHS values according to the geometry of the current media. For devices that are natively LBA (e.g., hard disk), the HBIOS driver simulates CHS using a fictitious geometry provided by the driver (typically 16 sectors per track and 16 heads per cylinder). Function 0x10 \u2013 Disk Status (DIOSTATUS) Entry Parameters Returned Values B: 0x10 A: Status C: Disk Unit Returns the driver specific Status (A) of the specified disk device unit (C) based on the last operation performed. The return value in register A is used as both a device status and a standard HBIOS result code. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents a driver-specific device status. In all cases, the value 0 means OK. Function 0x11 \u2013 Disk Reset (DIORESET) Entry Parameters Returned Values B: 0x11 A: Status C: Disk Unit This function performs a device dependent reset operation on the Disk Unit specified (C). The driver will clear any error status on the disk unit, attempt to reset the interface, and flag the disk unit for initialization on the next I/O function call. Any prior media identification will be cleared. The returned Status (A) is a standard HBIOS result code. If the specified disk unit (C) is one of multiple units on a single hardware bus, then all units on that bus will be reset. For example, if the master disk on an IDE bus is reset, then the slave disk will also be reset. Function 0x12 \u2013 Disk Seek (DIOSEEK) Entry Parameters Returned Values B: 0x12 A: Status C: Disk Unit DEHL: Sector Address This function will set the desired sector to be used for the next I/O operation on the specified Disk Unit (C). The returned Status (A) is a standard HBIOS result code. An actual seek operation is generally not performed on the disk hardware by this function. The function typically just records the sector address for subsequent I/O function calls. The double-word Sector Address (DEHL) can represent either a Logical Block Address (LBA) or a Cylinder/Head/Sector (CHS). Bit 7 of D is set (1) for LBA mode and cleared (0) for CHS mode. For LBA mode operation, the high bit is set and the rest of the double-word is then treated as the logical sector address. For CHS mode operation, the Sector Address (DEHL) registers are interpreted as: D=Head, E=Sector, and HL=Track. All values (including sector) are 0 relative. Prior versions of the floppy driver did not accept LBA mode addresses. However, this restriction has been removed as of HBIOS v3.1. At this point, all disk drivers support both LBA and CHS addressing. Function 0x13 \u2013 Disk Read (DIOREAD) Entry Parameters Returned Values B: 0x13 A: Status C: Disk Unit E: Sectors Read D: Buffer Bank ID E: Sector Count HL: Buffer Address Read Sector Count (E) sectors into the buffer located in Buffer Bank ID (D) at Buffer Address (HL) starting at the Current Sector. The returned Status (A) is a standard HBIOS result code. The Current Sector is established by a prior DIOSEEK function call; however, multiple read/write/verify function calls can be made after a seek function. The Current Sector is incremented after each sector successfully read. On error, the Current Sector will be the sector where the error occurred. Sectors Read (E) indicates the number of sectors successfully read. The caller must ensure that the Buffer Address is large enough to contain all sectors requested. Disk data transfers will be faster if the buffer resides in the top 32K of memory because it avoids a double buffer copy. Also for buffers in the top 32K of memory the Bank ID is not strictly required as this memory is alway mapped to the common bank. For buffers in the bottom 32KB ram, the Bank ID is used to identify the bank to use for the buffer. If you do not wih to use banked memory you will need to provide the current Bank ID, which can be obtained using Function 0xF3 \u2013 System Get Bank (SYSGETBNK) Function 0x14 \u2013 Disk Write (DIOWRITE) Entry Parameters Returned Values B: 0x14 A: Status C: Disk Unit E: Sectors Written D: Buffer Bank ID E: Sector Count HL: Buffer Address Write Sector Count (E) sectors from the buffer located in Buffer Bank ID (D) at Buffer Address (HL) starting at the Current Sector. The returned Status (A) is a standard HBIOS result code. The Current Sector is established by a prior DIOSEEK function call; however, multiple read/write/verify function calls can be made after a seek function. The Current Sector is incremented after each sector successfully written. On error, the Current Sector will be the sector where the error occurred. Sectors Written (E) indicates the number of sectors successfully written. Disk data transfers will be faster if the buffer resides in the top 32K of memory because it avoids a double copy. Function 0x15 \u2013 Disk Verify (DIOVERIFY) Entry Parameters Returned Values B: 0x15 A: Status C: Disk Unit E: Sectors Verified E: Sector Count *** Function Not Implemented *** Function 0x16 \u2013 Disk Format (DIOFORMAT) Entry Parameters Returned Values B: 0x16 A: Status C: Disk Unit D: Head E: Fill Byte HL: Cylinder *** Function Not Implemented *** Function 0x17 \u2013 Disk Device (DIODEVICE) Entry Parameters Returned Values B: 0x17 A: Status C: Disk Unit C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Reports device information about the specified Disk Unit (C). The Status (A) is a standard HBIOS result code. The Device Attribute (C) value returned indicates various feature indicators related to the device being referenced by the specified Disk Unit (C). The high 3 bits apply to all devices. The definition of the low 5 bits depends on whether the device is a Floppy (indicated by bit 5). The common bits are: Bits Definition 7 Floppy 6 Removable 5 High Capacity (>8 MB) The Floppy specific bits are: Bits Definition 4-3 Form Factor: 0=8\u201d, 1=5.25\u201d, 2=3.5\u201d, 3=Other 2 Sides: 0=SS, 1=DS 1-0 Density: 0=SD, 1=DD, 2=HD, 3=ED The non-Floppy specific bits are: Bits Definition 4 LBA Capable 3-0 Media Type: 0=Hard Disk, 1=CF, 2=SD, 3=USB, 4=ROM, 5=RAM, 6=FLASH, 7=RAMF, 8=CD-ROM, 9=Cartridge Device Type (D) indicates the specific hardware driver that handles the specified Disk Unit (C). Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. For example, a Device Type of 0x30 with a Device Number of 1 refers to the second disk being handled by the IDE driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. For example, for an IDE unit, the value indicates the IDE circuit variant. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used. Function 0x18 \u2013 Disk Media (DIOMEDIA) Entry Parameters Returned Values B: 0x18 A: Status C: Disk Unit E: Media ID E: Flags Report the Media ID (E) for the for media in the specified Disk Unit (C). If bit 0 of Flags (E) is set, then media discovery or verification will be performed. The Status (A) is a standard HBIOS result code. If there is no media in device, function will return an error status. NOTE : This function will always return MID_HD for hard disk devices. See the section Mapping to Media ID for information on this. To determine if an HD1K formatted partition exists on the hard disk please see the following function. Function 0xE0 \u2013 Calculate Slice (EXTSLICE) Function 0x19 \u2013 Disk Define Media (DIODEFMED) Entry Parameters Returned Values B: 0x19 A: Status C: Disk Unit E: Media ID *** Function Not Implemented *** Function 0x1A \u2013 Disk Capacity (DIOCAPACITY) Entry Parameters Returned Values B: 0x1A A: Status C: Disk Unit DEHL: Sector Count BC: Block Size Report the current media capacity information for the specified Disk Unit (C). The Sector Count (DEHL) is a double-word number representing the total number of blocks on the device. Block Size (BC) contains the block size in bytes. The Status (A) is a standard HBIOS result code. If the media is unknown, an error will be returned. This function will not attempt to discover or verify the media loaded in the unit specified. You can use precede this function with the DIOMEDIA function to force this if desired. Function 0x1B \u2013 Disk Geometry (DIOGEOMETRY) Entry Parameters Returned Values B: 0x1B A: Status C: Disk Unit D: Heads / LBA E: Sectors HL: Cylinder Count BC: Block Size Report the geometry for the media in the specified Disk Unit (C). If a device uses LBA mode addressing natively, then the drivers simulated geometry will be returned. The Status (A) is a standard HBIOS result code. If the media is unknown, an error will be returned. LBA capability is indicated by D:7. When set, the device is capable of LBA addressing. Refer to Function 0x12 \u2013 Disk Seek (DIOSEEK) for more information on specifying LBA vs. CHS addresses. Heads (D:6-0) refers to the number of heads per cylinder. Sectors (E) refers to the number of sectors per track. Cylinder Count (HL) is the total number of cylinders addressable for the media. Block Size (BC) is the number of bytes in one sector. Real Time Clock (RTC) The Real Time Clock functions provide read/write access to the clock and related Non-Volatile RAM. HBIOS only supports a single RTC device since there is no reason to have more than one at a time. The RTC unit is assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver RTCDEV_DS 0x00 Maxim DS1302 Real-Time Clock w/ NVRAM dsrtc.asm RTCDEV_BQ 0x01 BQ4845P Real Time Clock bqrtc.asm RTCDEV_SIMH 0x02 SIMH Simulator Real-Time Clock simrtc.asm RTCDEV_INT 0x03 Interrupt-based Real Time Clock intrtc.asm RTCDEV_DS7 0x04 Maxim DS1307 PCF I2C RTC w/ NVRAM ds7rtc.asm RTCDEV_RP5 0x05 Ricoh RPC01A Real-Time Clock w/ NVRAM rp5rtc.asm RTCDEV_EZ80 0x07 eZ80 on-chip RTC ez80rtc.asm The time functions to get and set the time (RTCGTM and RTCSTM) require a 6 byte date/time buffer in the following format. Each byte is BCD encoded. Offset Contents 0 Year (00-99) 1 Month (01-12) 2 Date (01-31) 3 Hours (00-24) 4 Minutes (00-59) 5 Seconds (00-59) Function 0x20 \u2013 RTC Get Time (RTCGETTIM) Entry Parameters Returned Values B: 0x20 A: Status HL: Date/Time Buffer Address Read the current value of the real-time clock and store the date/time in the Date/Time Buffer pointed to by HL. The Status (A) is a standard HBIOS result code. Function 0x21 \u2013 RTC Set Time (RTCSETTIM) Entry Parameters Returned Values B: 0x21 A: Status HL: Date/Time Buffer Address Set the current value of the real-time clock based on the Date/Time Buffer pointed to by HL. The Status (A) is a standard HBIOS result code. Function 0x22 \u2013 RTC Get NVRAM Byte (RTCGETBYT) Entry Parameters Returned Values B: 0x22 A: Status C: Index E: Value Read a single byte Value (E) from the Non-Volatile RAM of the RTC at the byte offset Index (C). The Status (A) is a standard HBIOS result code. Function 0x23 \u2013 RTC Set NVRAM Byte (RTCSETBYT) Entry Parameters Returned Values B: 0x23 A: Status C: Index E: Value Set a single byte Value (E) of the Non-Volatile RAM of the RTC at the byte offset Index (C). The Status (A) is a standard HBIOS result code. Function 0x24 \u2013 RTC Get NVRAM Block (RTCGETBLK) Entry Parameters Returned Values B: 0x24 A: Status HL: Buffer Address Read the entire contents of the Non-Volatile RAM into to a buffer pointed to by Buffer Address (HL). The Status (A) is a standard HBIOS result code. Function 0x25 \u2013 RTC Set NVRAM Block (RTCSETBLK) Entry Parameters Returned Values B: 0x25 A: Status HL: Buffer Address Write the entire contents of the Non-Volatile RAM from the buffer pointed to by Buffer Address (HL). The Status (A) is a standard HBIOS result code. Function 0x26 \u2013 RTC Get Alarm (RTCGETALM) Entry Parameters Returned Values B: 0x26 A: Status HL: Date/Time Buffer Address Work in progress, documentation required\u2026 Function 0x27 \u2013 RTC Set Alarm (RTCSETALM) Entry Parameters Returned Values B: 0x27 A: Status HL: Date/Time Buffer Address Work in progress, documentation required\u2026 Function 0x28 \u2013 RTC DEVICE (RTCDEVICE) Entry Parameters Returned Values B: 0x28 A: Status C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Returns device information for the RTC unit. The Status (A) is a standard HBIOS result code. Device Attribute (C) values are not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified character unit. Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver which is always 0 for RTC. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used. Display Keypad (DSKY) The Display Keypad functions provide access to a segment or LCD style display and associated optional keypad HBIOS only supports a single DSKY device since there is no reason to have more than one at a time. If the system contains multiple DSKY devices, only the first device discovered will be used. The DSKY unit is assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver DSKYDEV_ICM 0x01 Original ICM7218 based DSKY icm.asm DSKYDEV_PKD 0x02 Next Gen Intel P8279 based DSKY pkd.asm DSKYDEV_GM7303 0x03 GM7303 LCD Display + Keypad gm7303.asm DSKYDEV_LCD 0x04 HD44780-based LCD Display lcd.asm The keypad keys are identified by the following key ids. Not all keypads will contain all keys. Key Id Key Definition Key Id Key Definition \\$00 Hex Numeric 0 \\$10 Forward \\$01 Hex Numeric 1 \\$11 Backward \\$02 Hex Numeric 2 \\$12 Clear \\$03 Hex Numeric 3 \\$13 Enter \\$04 Hex Numeric 4 \\$14 Deposit \\$05 Hex Numeric 5 \\$15 Examine \\$06 Hex Numeric 6 \\$16 Go \\$07 Hex Numeric 7 \\$17 Boot \\$08 Hex Numeric 8 \\$18 F4 \\$09 Hex Numeric 9 \\$19 F3 \\$0A Hex Numeric A \\$1A F2 \\$0B Hex Numeric B \\$1B F1 \\$0C Hex Numeric C \\$0D Hex Numeric D \\$0E Hex Numeric E \\$0F Hex Numeric F Function 0x30 \u2013 DSKY Reset (DSKYRESET) Entry Parameters Returned Values B: 0x30 A: Status This function performs a device dependent reset operation on the DSKY. The display will be cleared, keyboard queue will be flushed, and chip will be reinitialized. The returned Status (A) is a standard HBIOS result code. Function 0x31 \u2013 DSKY (DSKYSTATUS) Entry Parameters Returned Values B: 0x31 A: Status / Characters Pending Return the count of Characters Pending (A) in the input buffer of the DSKY. If the unit has no input buffer or the buffer utilization is not available, the function may return simply 0 or 1 where 0 means there is no character available and 1 means there is at least one character available. The value returned in register A is used as both a Status (A) code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the number of characters in the buffer. Function 0x32 \u2013 DSKY Get Key (DSKYGETKEY) Entry Parameters Returned Values B: 0x32 A: Status E: Character Value Read and return a Character (E) from the DSKY. If no character(s) are available in the unit\u2019s input buffer, this function will wait indefinitely. The returned Status (A) is a standard HBIOS result code. The Character Value (E) returned is not ASCII. It is a keypad key id. The possible id values are listed at the start of this section. Function 0x33 \u2013 DSKY Show HEX (RTCSHOWHEX) Entry Parameters Returned Values B: 0x33 A: Status DE:HL=Binary Value Display the 32-bit binary value (DE:HL) in hex on the DSKY segment display. All decimal points of the display will be off. The Status (A) is a standard HBIOS result code. Function 0x34 \u2013 DSKY Show Segments (DSKYSHOWSEG) Entry Parameters Returned Values B: 0x34 A: Status HL: Buffer Address Display the segment-encoded values on the segment display. The encoding uses a small alphabet as defined below. The actual representation of a character is determined by the driver. The entire display is updated and it is assumed that an 8 character buffer will be pointed to by HL. The buffer must reside in high memory. The Status (A) is a standard HBIOS result code. 0x00: \u20180\u2019 0x01: \u20181\u2019 0x02: \u20182\u2019 0x03: \u20183\u2019 0x04: \u20184\u2019 0x05: \u20185\u2019 0x06: \u20186\u2019 0x07: \u20187\u2019 0x08: \u20188\u2019 0x09: \u20189\u2019 0x0A: \u2018A\u2019 0x0B: \u2018B\u2019 0x0C: \u2018C\u2019 0x0D: \u2018D\u2019 0x0E: \u2018E\u2019 0x0F: \u2018F\u2019 0x10: \u2019 \u2019 0x11: \u2018-\u2019 0x12: \u2018.\u2019 0x13: \u2018p\u2019 0x14: \u2018o\u2019 0x15: \u2018r\u2019 0x16: \u2018t\u2019 0x17: \u2018A\u2019 0x18: \u2018d\u2019 0x19: \u2018r\u2019 0x1A: \u2018G\u2019 Function 0x35 \u2013 DSKY Keypad LEDs (DSKYKEYLEDS) Entry Parameters Returned Values B: 0x35 A: Status HL: Buffer Address Light the LEDs for the keypad keys according to the bitmap contained in the buffer pointed to by HL. The buffer must be located in high memory and is assumed to be 8 bytes. At this time, the bitmap is specific to the PKD hardware and will be ignored by all other hardware. Function 0x36 \u2013 DSKY Status LED (DSKYSTATLED) Entry Parameters Returned Values B: 0x36 A: Status D: LED Number E: LED State Set or clear the status LED specified in D. The state of the LED is contained in E. If E=0, the LED will be turned off. If E=1, the LED will be turned on. This function is specific to the PKD hardware and will be ignored by all other hardware. The Status (A) is a standard HBIOS result code. Function 0x37 \u2013 DSKY Beep (DSKYBEEP) Entry Parameters Returned Values B: 0x37 A: Status Beep the onboard speaker of the DSKY. This function is specific to the PKD hardware. It will be ignored by the ICM hardware. The Status (A) is a standard HBIOS result code. Function 0x38 \u2013 DSKY Device (DSKYDEVICE) Entry Parameters Returned Values B: 0x38 A: Status C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Returns device information for the DSKY unit. The Status (A) is a standard HBIOS result code. Device Attribute (C) values are not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified character unit. Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver which is always 0 for DSKY. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used. Function 0x39 \u2013 DSKY Device (DSKYMESSAGE) Entry Parameters Returned Values B: 0x39 A: Status C: Message ID Instructs the display to show a textual representation of the associated message on the display. The IDs are defined in std.asm. Function 0x3A \u2013 DSKY Device (DSKYEVENT) Entry Parameters Returned Values B: 0x3A A: Status C: Event ID Instructs the display to update itself in response to an internal HBIOS state change. At this time the the events are: 0: CPU Speed Change 1: Disk Activity Video Display Adapter (VDA) The VDA functions are provided as a common interface to Video Display Adapters. Not all VDAs will include keyboard hardware. In this case, the keyboard functions should return a failure status. All video units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates their values. Device Type ID Description Driver VDADEV_VDU 0x00 MC6845 Family Video Display Controller vdu.asm VDADEV_CVDU 0x01 MC8563-based Video Display Controller cvdu.asm VDADEV_GDC 0x02 uPD7220 Video Display Controller gdc.asm VDADEV_TMS 0x03 TMS9918/38/58 Video Display Controller tms.asm VDADEV_VGA 0x04 HD6445CP4-based Video Display Controller vga.asm VDADEV_VRC 0x05 VGARC vrc.asm Depending on the capabilities of the hardware, the use of colors and attributes may or may not be supported. If the hardware does not support these capabilities, they will be ignored. Color byte values are constructed using typical RGBI (Red/Green/Blue/Intensity) bits. The high four bits of the value determine the background color and the low four bits determine the foreground color. This results in 16 unique color values for both foreground and background. The following table illustrates the color byte value construction: Bit Color Background 7 Intensity 6 Blue 5 Green 4 Red Foreground 3 Intensity 2 Blue 1 Green 0 Red The following table illustrates the resultant color for each of the possible 16 values for foreground or background: Foreground Background Color n0 nnnn0000 0n 0000nnnn Black n1 nnnn0001 1n 0001nnnn Red n2 nnnn0010 2n 0010nnnn Green n3 nnnn0011 3n 0011nnnn Brown n4 nnnn0100 4n 0100nnnn Blue n5 nnnn0101 5n 0101nnnn Magenta n6 nnnn0110 6n 0110nnnn Cyan n7 nnnn0111 7n 0111nnnn White n8 nnnn1000 8n 1000nnnn Gray n9 nnnn1001 9n 1001nnnn Light Red nA nnnn1010 An 1010nnnn Light Green nB nnnn1011 Bn 1011nnnn Yellow nC nnnn1100 Cn 1100nnnn Light Blue nD nnnn1101 Dn 1101nnnn Light Magenta nE nnnn1110 En 1110nnnn Light Cyan nF nnnn1111 Fn 1111nnnn Bright White Attribute byte values are constructed using the following bit encoding: Bit Effect 7 n/a (0) 6 n/a (0) 5 n/a (0) 4 n/a (0) 3 n/a (0) 2 Reverse 1 Underline 0 Blink The following codes are returned by a keyboard read to signify non-ASCII keystrokes: Value Keystroke Value Keystroke 0xE0 F1 0xF0 Insert 0xE1 F2 0xF1 Delete 0xE2 F3 0xF2 Home 0xE3 F4 0xF3 End 0xE4 F5 0xF4 PageUp 0xE5 F6 0xF5 PadeDown 0xE6 F7 0xF6 UpArrow 0xE7 F8 0xF7 DownArrow 0xE8 F9 0xF8 LeftArrow 0xE9 F10 0xF9 RightArrow 0xEA F11 0xFA Power 0xEB F12 0xFB Sleep 0xEC SysReq 0xFC Wake 0xED PrintScreen 0xFD Break 0xEE Pause 0xFE 0xEF App 0xFF Function 0x40 \u2013 Video Initialize (VDAINI) Entry Parameters Returned Values B: 0x40 A: Status C: Video Unit E: Video Mode HL: Font Bitmap Performs a full (re)initialization of the specified Video Unit (C). The screen is cleared and the keyboard buffer is flushed. If the specified Video Unit (C) supports multiple video modes, a Video Mode (E) can be specified (set to 0 for default/not specified). Video Mode (E) values are specific to each VDA. The returned Status (A) is a standard HBIOS result code. If the hardware and driver supports it, you can specify a Font Bitmap (HL) buffer address containing the character bitmap data to be loaded into the video processor. The buffer must be located entirely in the top 32K of the CPU memory space. HL must be set to zero if no character bitmap is specified (the driver will utilize a default character bitmap). Function 0x41 \u2013 Video Query (VDAQRY) Entry Parameters Returned Values B: 0x41 A: Status C: Video Unit C: Video Mode HL: Font Bitmap D: Rows E: Columns HL: Font Bitmap Return information about the specified Video Unit (C). Video Mode (C) will be set to the current video mode. Rows (D) and Columns (E) will return the dimensions of the video display as measured in rows and columns. Note that this is the count of rows and columns, not the last row/column number. The returned Status (A) is a standard HBIOS result code. If the hardware and driver support it, you can specify a Font Bitmap (HL) buffer address that will be filled with the current character bitmap data. The buffer must be located entirely in the top 32K of the CPU memory space. Font Bitmap (HL) must be set to zero if it does not point to a proper buffer area or memory corruption will result. If HL is not zero, it must point to a suitably sized memory buffer in the upper 32K of CPU address space that will be filled with the current character bitmap data. It is critical that HL be set to zero if it does not point to a proper buffer area or memory corruption will result. If the video device driver does not have the ability to provide character bitmap data, then Font Bitmap (HL) will be set to zero on return. Function 0x42 \u2013 Video Reset (VDARES) Entry Parameters Returned Values B: 0x42 A: Status C: Video Unit Performs a non-destructive reset of the specified Video Unit (C). Should re-initialize the video hardware without destroying the screen contents or cursor position. The current video mode will not be changed. The returned Status (A) is a standard HBIOS result code. Function 0x43 \u2013 Video Device (VDADEV) Entry Parameters Returned Values B: 0x43 A: Status C: Video Unit C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Reports device information about the specified Video Unit (C). The Status (A) is a standard HBIOS result code. Device Attribute (C) values are not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified Video Unit (C). Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. For example, for an TMS video unit, the value indicates the TMS circuit variant. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used. Function 0x44 \u2013 Video Set Cursor Style (VDASCS) Entry Parameters Returned Values B: 0x44 A: Status C: Video Unit D: Start/End E: Style If supported by the specified Video Unit (C), adjust the format of the cursor such that the cursor starts at the pixel specified in the top nibble of Start/End (D) and ends at the pixel specified in the bottom nibble of Start/End (D). So, if D=0x08, a block cursor would be used that starts at the top pixel of the character cell and ends at the ninth pixel of the character cell. The Status (A) is a standard HBIOS result code. Style (E) is reserved to control the style of the cursor (blink, visibility, etc.), but is not yet implemented. Adjustments to the cursor style may or may not be possible for any given video hardware and may be dependent on the active video mode. Function 0x45 \u2013 Video Set Cursor Position (VDASCP) Entry Parameters Returned Values B: 0x45 A: Status C: Video Unit D: Row E: Column Reposition the cursor of the specified Video Unit (C) to the specified Row (D) and Column (E). Specifying a row/column that exceeds the boundaries of the display results in undefined behavior. Cursor coordinates are 0 based (0,0 is the upper left corner of the display). The Status (A) is a standard HBIOS result code. Function 0x46 \u2013 Video Set Character Attribute (VDASAT) Entry Parameters Returned Values B: 0x46 A: Status C: Video Unit E: Attribute Assign the specified character Attribute (E) code to be used for all subsequent character writes/fills on the specified Video Unit (C). This attribute is used to fill new lines generated by scroll operations. The character attributes values are listed above. Note that a given video display may or may not support any/all attributes. The Status (A) is a standard HBIOS result code. Function 0x47 \u2013 Video Set Character Color (VDASCO) Entry Parameters Returned Values B: 0x47 A: Status C: Video Unit D: Scope E: Color Assign the specified Color (E) code for character foreground/background. If Scope (D) is 0, the specified color will be used for all subsequent character writes/fills. This color is also used to fill new lines generated by scroll operations. If Scope (D) is 1, then the specified foreground/background color will be applied immediately to the entire screen. Refer to the color code table above for a list of the available color codes. Note that a given video display may or may not support any/all colors. The Status (A) is a standard HBIOS result code. Function 0x48 \u2013 Video Write Character (VDAWRC) Entry Parameters Returned Values B: 0x48 A: Status C: Video Unit E: Character Write the Character (E) value to the display of the specified Video Unit (C). The character is written starting at the current cursor position and the cursor is advanced. If the end of the line is encountered, the cursor will be advanced to the start of the next line. The display will not scroll if the end of the screen is exceeded. The Status (A) is a standard HBIOS result code. Function 0x49 \u2013 Video Fill (VDAFIL) Entry Parameters Returned Values B: 0x49 A: Status C: Video Unit E: Character HL: Count Write the Character (E) value to the Video Unit (C) display the number of times specified by Count (HL). Characters are written starting at the current cursor position and the cursor is advanced by the number of characters written. If the end of the line is encountered, the characters will continue to be written starting at the next line as needed. The display will not scroll if the end of the screen is exceeded. Writing characters beyond the end of the screen results in undefined behavior. The Status (A) is a standard HBIOS result code. Function 0x4A \u2013 Video Copy (VDACPY) Entry Parameters Returned Values B: 0x4A A: Status C: Video Unit D: Source Row E: Source Column L: Count Copy Count (L) bytes from the specified Video Unit (C) display Source Row (D) and Source Column (E) to the current cursor position. The cursor position is not updated. The maximum Count (L) value is 255. Copying to/from overlapping areas is not supported and will have an undefined behavior. The display will not scroll if the end of the screen is exceeded. Copying beyond the active screen buffer area is not supported and results in undefined behavior. The Status (A) is a standard HBIOS result code. Function 0x4B \u2013 Video Scroll (VDASCR) Entry Parameters Returned Values B: 0x4B A: Status C: Video Unit E: Lines Scroll the video display of the specified Video Unit (C) forward or backwards by number of Lines (E) specified. If Lines (E) is positive, then a forward scroll is performed. If Lines (E) contains a negative number, then a reverse scroll will be performed. This function will scroll the entire screen contents. New lines revealed during the scroll operation will be filled with space characters (0x20) using the active character attribute and color. The cursor position will not be updated. The Status (A) is a standard HBIOS result code. Function 0x4C \u2013 Video Keyboard Status (VDAKST) Entry Parameters Returned Values B: 0x4C A: Status / Codes Pending C: Video Unit Return a count of the number of key Codes Pending (A) in the keyboard buffer for the specified Video Unit (C). If it is not possible to determine the actual number in the buffer, it is acceptable to return 1 to indicate there are key codes available to read and 0 if there are none available. The value returned in register A is used as both a Status (A) code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the number of key codes pending. Function 0x4D \u2013 Video Keyboard Flush (VDAKFL) Entry Parameters Returned Values B: 0x4D A: Status C: Video Unit If a keyboard buffer is in use on the Video Unit (C) specified, it should be purged and all contents discarded. The Status (A) is a standard HBIOS result code. Function 0x4E \u2013 Video Keyboard Read (VDAKRD) Entry Parameters Returned Values B: 0x4E A: Status C: Video Unit C: Scancode D: Keystate E: Keycode Read the next key data from keyboard of the specified Video Unit (C). If a keyboard buffer is used, return the next Keycode in the buffer. If no key data is available, this function will wait indefinitely for a keypress. The Status (A) is a standard HBIOS result code. The Scancode (C) value is the raw scancode from the keyboard for the keypress. Scancodes are optional and may not be implemented by the driver. The Scancode values are driver dependent. In the case of a PS/2 keyboard driver, they should be the PS/2 scancode. Other keyboard drivers may return values appropriate for their specific keyboard. If the driver does not implement this, it should return 0 in C. The Keystate (D) is a bitmap representing the value of all modifier keys and shift states as they existed at the time of the keystroke. The bitmap is defined as: Bit Keystate Indication 7 Key pressed was from the num pad 6 Caps Lock was active 5 Num Lock was active 4 Scroll Lock was active 3 Windows key was held down 2 Alt key was held down 1 Control key was held down 0 Shift key was held down Not all of these bits may be relevant for all keyboards. Any bit that is not relevant should be returned as 0. The Keycode (E) is generally returned as appropriate ASCII values, if possible. Special keys, like function keys and arrows, are returned as reserved codes as described at the start of this section. Function 0x4F \u2013 Read a character at current video position (VDARDC) Entry Parameters Returned Values B: 0x4F A: Status C: Video Unit E: Character B: Color E: Attribute This function will return the character data from the current cursor position of the display of the specified Video Unit (C). The data returned includes the Character (E) value, the Color (B), and the Attribute (E) corresponding to the current cursor position. If the display does not support colors or attributes then this function will return color white on black with no attributes. The ability to perform this function may not be available for all video devices. The Status (A) is a standard HBIOS result code. Sound (SND) Sound functions require that a Sound Unit number be specified in register C. This is the logical device unit number assigned during the boot process that identifies all sound devices uniquely. All sound units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver SNDDEV_SN76489 \\$00 SN76489 Programmable Sound Generator sn76489.asm SNDDEV_AY38910 \\$01 AY-3-8910/YM2149 Programmable Sound Generator ay38910.asm SNDDEV_BITMODE \\$02 Bit-bang Speaker spk.asm SNDDEV_YM2612 \\$03 YM2612 Programmable Sound Generator ym2612.asm The Sound functions defer the actual programming of the sound chip until the SNDPLAY function is called. You will call the volume and period/note functions to preset the desired sound output, then call SNDPLAY when you want the sound to change. The Sound functions do not manage the duration of the sound played. A sound will play indefinitely \u2013 the caller must implement an appropriate timing mechanism to manage the playing of a series of sounds. HBIOS B=51 C=00 L=80 ; Set volume to half level HBIOS B=53 C=00 HL=152 ; Select Middle C (C4) HBIOS B=54 C=00 D=01 ; Play note on Channel 1 Function 0x50 \u2013 Sound Reset (SNDRESET) Entry Parameters Returned Values B: 0x50 A: Status C: Sound Unit Reset the sound chip of specified Sound Unit (C). Turn off all sounds and set volume on all channels to silence. The returned Status (A) is a standard HBIOS result code. Function 0x51 \u2013 Sound Volume (SNDVOL) Entry Parameters Returned Values B: 0x51 A: Status C: Sound Unit L: Volume This function sets the sound chip Volume (L) for the specified Sound Unit (C). Volume (L) is a binary value ranging from 0 (silence) to 255 (maximum). The volume will be applied when the next SNDPLAY function is invoked. The returned Status (A) is a standard HBIOS result code. Note that not all sounds chips implement 256 volume levels. The driver will scale the volume to the closest possible level the chip provides. Function 0x52 \u2013 Sound Period (SNDPRD) Entry Parameters Returned Values B: 0x52 A: Status C: Sound Unit HL: Period This function sets the sound chip Period (HL) for the specified Sound Unit (C). The period will be applied when the next SNDPLAY function is invoked. The returned Status (A) is a standard HBIOS result code. The Period (HL) value is not a standardized value. The value is programmed directly into the period or frequency register of the sound chip. It is therefore a hardware dependent value. To play standardized notes, use the SNDNOTE function. Function 0x53 \u2013 Sound Note (SNDNOTE) Entry Parameters Returned Values B: 0x53 A: Status C: Sound Unit HL: Note This function sets the frequency generated by the sound of the specified Sound Unit (C). The frequency is standardized and is specified by using values that correspond to musical notes. The frequency will be applied when the next SNDPLAY function is invoked. The returned Status (A) is a standard HBIOS result code. The Note (HL) values correspond to quarter notes. Increasing/decreasing the value by 4 results in a full note increment/decrement. Increasing/decreasing the value by 48 results in a full octave increment/decrement. The value 0 corresponds to Bb/A# in octave 0. The sound chip resolution and its oscillator limit the range and accuracy of the notes played. The typical range of the AY-3-8910 is six octaves: Bb2/A#2 to A7, where each value is a unique tone. Values above and below can still be played but each quarter tone step may not result in a note change. The following table shows the mapping of the Note (HL) value to the corresponding octave and note. Note Octave 0 1 2 3 4 5 6 7 C - 8 56 104 152 200 248 296 C#/Db - 12 60 108 156 204 252 300 D - 16 64 112 160 208 256 304 D#/Eb - 20 68 116 164 212 260 308 E - 24 72 120 168 216 264 312 F - 28 76 124 172 220 268 316 F#/Gb - 32 80 128 176 224 272 320 G - 36 84 132 180 228 276 324 G#/Ab - 40 88 136 184 232 280 328 A - 44 92 140 188 236 284 332 A#/Bb 0 48 96 144 192 240 288 336 B 4 52 100 148 196 244 292 340 Function 0x54 \u2013 Sound Play (SNDPLAY) Entry Parameters Returned Values B: 0x54 A: Status C: Sound Unit D: Channel This function applies the previously specified volume and frequency of the specified Sound Unit (C) by programming the sound chip with the appropriate values. The values are applied to the specified Channel (D) of the chip. The returned Status (A) is a standard HBIOS result code. Note that there is no duration for the sound output \u2013 the programmed sound will be played indefinitely. It is up to the user to wait the desired amount of time, then change or silence the sound output as desired. The number of channels available on a sound chip varies. It is up to the caller to ensure that the appropriate number of channels are being programmed. Function 0x55 \u2013 Sound Query (SNDQUERY) Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit E: Subfunction This function will return a variety of information for a specified Sound Unit (C) according to the Subfunction (E) specified. The returned Status (A) is a standard HBIOS result code. SNDQUERY Subfunction 0x01 \u2013 Get count of audio channels supported (SNDQ_CHCNT) Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit B: Tone Channels E: 0x01 C: Noise Channels SNDQUERY Subfunction 0x02 \u2013 Get current volume setting (SNDQ_VOL) Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit L: Volume E: 0x02 SNDQdERY Subfunction 0x03 \u2013 Get current period setting (SNDQ_PERIOD) Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit HL: Period E: 0x03 SNDQUERY Subfunction 0x04 \u2013 Get device details (SNDQ_DEV) Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit B: Driver Identity E: 0x04 HL: Ports DE: Ports This subfunction reports detailed device information for the specified Sound Unit (C). Driver Identity (B) reports the audio device type. Ports (HL & DE) return relevant port addresses for the hardware specific to each device type. The following table defines the specific port information per device type: Audio ID Value Device Returned Registers SND_SN76489 0x01 SN76489 E=Left channel port, L=Right channel port SND_AY38910 0x02 AY-3-8910 D=Address port, E=Data port SND_BITMODE 0x03 I/O PORT D=Address port, E=Bit mask SND_YM2612 0x04 YM2612 Part 0: D=Address port, E=Data port Part 1: D=Address port, L=Part 1 Data port Function 0x56 \u2013 Sound Duration (SNDDUR) Entry Parameters Returned Values B: 0x56 A: Status C: Sound Unit HL: Duration This function sets the Duration (HL) of the note to be played in milliseconds for the specified Sound Unit (C). This function just sets the duration, the actual duration is applied in the SNDPLAY function. If the Duration (HL) is set to zero, then the SNDPLAY function will operate in a non-blocking mode. i.e. a tone will start playing and the play function will return. The tone will continue to play until the next tone is played. If the Duration (HL) is greater than zero, the sound will play for the duration defined in HL and then return. ***** Function Not Implemented **** Function 0x57 \u2013 Sound Device (SNDDEVICE) Entry Parameters Returned Values B: 0x57 A: Status C: Sound Unit C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Reports device information about the specified Sound Unit (C). The Status (A) is a standard HBIOS result code. The Device Attributes (C) value is not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified Sound Unit (C). Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used. Function 0x58 \u2013 Sound Beep (SNDBEEP) Entry Parameters Returned Values B: 0x58 A: Status C: Sound Unit Play a beep tone on the specified Sound Unit (C). The beep will normally be about 1/3 second in duration and the tone will be approximately B5. Extension (EXT) Helper (extension) functions that are not a core part of a BIOS. Function 0xE0 \u2013 Calculate Slice (EXTSLICE) Entry Parameters Returned Values B: 0xE0 A: Status D: Disk Unit B: Device Attributes E: Slice C: Media ID DEHL: Sector Address Report the Media ID (C), and Device Attributes (B) for the for media in the specified Disk Unit (D), and for hard disks the absolute Sector offset to the start of the Slice (E). The Status (A) is a standard HBIOS result code. This function extends upon Function 0x18 \u2013 Disk Media (DIOMEDIA) for hard disk media by scanning for a partition to determine if the disk uses HD512 or HD1K, correctly reporting MID_HD or MID_HDNEW respectively. See the following for some background Mapping to Media ID It will also return the sector number of the first sector in the slice if the slice number is valid. If the slice number is invalid (it wont fix on the media) an error will be returned. The slice calculation is performed by considering the partition start (if it exists), the size of a slice for the given format type, and ensuring that the slice fits within the media or partition size, taking into consideration other partitions that may exist. The Device Attributes (B) are the same as defined in Function 0x17 \u2013 Disk Device (DIODEVICE) If the Unit specified is not a hard disk the Media ID will be returned and the slice parameter ignored. If there is no media in device, or the slice number is invaid (Parameter Out Of Range) the function will return an error status. **NOTE: This function was placed in HBIOS to be shared between the diffeent CP/M varients supported by RomWBW. It is not strictly a BIOS function, and may be moved in future. System (SYS) Function 0xF0 \u2013 System Reset (SYSRESET) Entry Parameters Returned Values B: 0xF0 A: Status C: Subfunction This function performs various forms of a system reset depending on the value of Subfunction (C): Soft Reset (0x00): Perform a soft reset of HBIOS. Releases all HBIOS memory allocated by current OS. Does not reinitialize physical devices. Warm Start (0x01): Warm start the system returning to the boot loader prompt. Does not reinitialize physical devices. Cold Start (0x02): Perform a system cold start (like a power on). All devices are reinitialized. User Restart (0x03): Perform a video terminal reset. Terminal emulation and visual display systems are reset. The Status (A) is a standard HBIOS result code. Function 0xF1 \u2013 System Version (SYSVER) Entry Parameters Returned Values B: 0xF1 A: Status C: Reserved DE: Version L: Platform This function will return the HBIOS Version (DE) number and Platform (L) identifier. The Status (A) is a standard HBIOS result code. The Version (DE)number is encoded as BCD where the 4 digits are: [Major Version][Minor Version][Patch Level][Build Number] So, for example, a Version (DE) number of 0x3102 would indicate version 3.1.0, build 2. The hardware Platform (L) is identified as follows: Name Id **Platform ** PLT_SBC 1 ECB Z80 SBC PLT_ZETA 2 ZETA Z80 SBC PLT_ZETA2 3 ZETA Z80 V2 SBC PLT_N8 4 N8 (HOME COMPUTER) Z180 SBC PLT_MK4 5 MARK IV PLT_UNA 6 UNA BIOS PLT_RCZ80 7 RCBUS W/ Z80 PLT_RCZ180 8 RCBUS W/ Z180 PLT_EZZ80 9 EASY/TINY Z80 PLT_SCZ180 10 SMALL COMPUTER CENTRAL Z180 PLT_DYNO 11 DYNO MICRO-ATX MOTHERBOARD PLT_RCZ280 12 RCBUS W/ Z280 PLT_MBC 13 NHYODYNE MULTI-BOARD COMPUTER PLT_RPH 14 RHYOPHYRE GRAPHICS SBC PLT_Z80RETRO 15 Z80 RETRO COMPUTER PLT_S100 16 S100 COMPUTERS Z180 PLT_DUO 17 DUODYNE Z80 SYSTEM PLT_HEATH 18 HEATHKIT H8 Z80 SYSTEM PLT_EPITX 19 Z180 MINI-ITX PLT_MON 20 MONSPUTER (DEPRECATED) PLT_GMZ180 21 GENESIS Z180 SYSTEM PLT_NABU 22 NABU PC W/ ROMWBW OPTION BOARD PLT_FZ80 23 S100 FPGA Z80 PLT_RCEZ80 24 RCBUS W/ eZ80 For more information on these platforms see RomWBW Hardware Function 0xF2 \u2013 System Set Bank (SYSSETBNK) Entry Parameters Returned Values B: 0xF2 A: Status C: Bank ID C: Prior Bank ID Activates the specified memory Bank ID (C) and returns the Prior Bank ID (C). The function must be invoked from code located in the upper 32K and the stack must be in the upper 32K. The Status (A) is a standard HBIOS result code. If the system is using interrupt mode 1 interrupts, the you must take steps to ensure interrupts are properly handled. You generally have two choices: Disable interrupts while the User Bank is switched out Duplicate the interrupt mode 1 vector from the User Bank into the bank you are switching to. If the User Bank has been switched out, you will not be able to invoke the HBIOS API functions using an RST 08 instruction. You can use the alternative mechanism using CALL $FFF0 as described in Invocation . Function 0xF3 \u2013 System Get Bank (SYSGETBNK) Entry Parameters Returned Values B: 0xF3 A: Status C: Bank ID Returns the currently active Bank ID (C). The Status (A) is a standard HBIOS result code. Function 0xF4 \u2013 System Set Copy (SYSSETCPY) Entry Parameters Returned Values B: 0xF4 A: Status D: Destination Bank ID E: Source Bank ID HL: Byte Count Prepare for a subsequent interbank memory copy (SYSBNKCPY) function call by setting the Source Bank ID (E), Destination Bank ID (D), and Byte Count (HL) to be copied. The bank ID\u2019s are not range checked and must be valid for the system in use. The Status (A) is a standard HBIOS result code. No bytes are copied by this function. The SYSBNKCPY function must be called to actually perform the copy. The values setup by this function will remain unchanged until another call is make to this function. So, after calling SYSSETCPY, you may make multiple calls to SYSBNKCPY as long as you want to continue to copy between the already established Source/Destination Banks and the same size copy is being performed. Function 0xF5 \u2013 System Bank Copy (SYSBNKCPY) Entry Parameters Returned Values B: 0xF5 A: Status DE: Destination Address DE: New Destination Address HL: Source Address HL: New Source Address Copy a block of memory between banks. The Source Bank, Destination Bank, and Byte Count to copy must be established with a prior call to SYSSETCPY. However, it is not necessary to call SYSSETCPY prior to subsequent calls to SYSBNKCPY if the source/destination banks and copy length do not change. On return, the New Destination Address (DE) will be value of the original Destination Address (DE) incremented by the count of bytes copied. Likewise for the New Source Address (HL). This allows iterative invocations of this function to continue copying where the prior invocation left off. The Status (A) is a standard HBIOS result code. WARNINGS: This function is inherently dangerous and does not prevent you from corrupting critical areas of memory. Use with extreme caution. Overlapping source and destination memory ranges are not supported and will result in undetermined behavior. Copying of byte ranges that cross bank boundaries is undefined. Function 0xF6 \u2013 System Alloc (SYSALLOC) Entry Parameters Returned Values B: 0xF6 A: Status HL: Block Size HL: Block Address This function will attempt to allocate a Block Size (HL) bytes block of memory from the internal HBIOS heap. The HBIOS heap resides in the HBIOS bank in the area of memory left unused by HBIOS. If the allocation is successful, the Block Address (HL) of the allocated memory block is returned in HL. You will typically need to use the SYSBNKCPY function to read/write the allocated memory. The Status (A) is a standard HBIOS result code. Function 0xF7 \u2013 System Free (SYSFREE) Entry Parameters Returned Values B: 0xF7 A: Status HL: Block Address *** Function Not Implemented *** Note that all allocated memory can be freed by calling the SYSRESET function with a subfunction code of 0x00 (Soft Reset). Function 0xF8 \u2013 System Get (SYSGET) Entry Parameters Returned Values B: 0xF8 A: Status C: Subfunction This function will report various system information based on the sub-function value. The following lists the subfunctions available along with the registers/information utilized. The Status (A) is a standard HBIOS result code. SYSGET Subfunction 0x00 \u2013 Get Character Device Unit Count (CIOCNT) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x00 E: Count Return the Count (E) of character device units. The Status (A) is a standard HBIOS result code. SYSGET Subfunction 0x01 \u2013 Get Serial Unit Function (CIOFN) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x01 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the CIO function number to lookup in D and the CIO unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup. SYSGET Subfunction 0x10 \u2013 Get Disk Device Unit Count (DIOCNT) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x10 E: Count Return the Count (E) of disk device units. The Status (A) is a standard HBIOS result code. SYSGET Subfunction 0x11 \u2013 Get Disk Unit Function (DIOFN) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x11 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the DIO function number to lookup in D and the DIO unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup. SYSGET Subfunction 0x20 \u2013 Get RTC Device Unit Count (RTCCNT) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x20 E: Count Return the Count (E) of RTC device units. The Status (A) is a standard HBIOS result code. SYSGET Subfunction 0x40 \u2013 Get Video Device Unit Count (VDACNT) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x40 E: Count Return the Count (E) of video device units. The Status (A) is a standard HBIOS result code. SYSGET Subfunction 0x41 \u2013 Get Video Unit Function (VDAFN) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x41 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the VDA function number to lookup in D and the VDA unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup. SYSGET Subfunction 0x50 \u2013 Get Sound Device Unit Count (SNDCNT) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x50 E: Count Return the Count (E) of sound device units. The Status (A) is a standard HBIOS result code. SYSGET Subfunction 0x51 \u2013 Get Sound Unit Function (SNDFN) Entry Parameters Returned Values B: 0xF8 A: Status C: 0x51 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the SND function number to lookup in D and the SND unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup. SYSGET Subfunction 0xC0 \u2013 Get Switches (SWITCH) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xC0 HL: Switch Value D: Switch Key This function will return the current value (HL) of the switch (D) from NVRAM. Switches may be returned as a 16 bit (HL) or 8 bit (L) value. It is up to the caller to process the returned value correctly. Note for Switch 0xFF (status) the returned value is primarily in the Status (A) register. Errors are signaled in the return by setting the NZ flag. When set the (A) register may contain an error code, but this code does not conform to RomWBW standard Success is indicated by setting the Z flag For a description of switches please see RomWBW NVRAM Configuration SYSGET Subfunction 0xD0 \u2013 Get Timer Tick Count (TIMER) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xD0 DEHL: Tick Count C: Frequency Return the value of the global system timer Tick Count (DEHL). This is a double-word binary value. The frequency of the system timer in Hertz is returned in Frequency (C). The returned Status (A) is a standard HBIOS result code. The tick count is a 32 bit binary value. It will rollover to zero if the maximum value for a 32 bit number is reached. Note that not all hardware configuration have a system timer. You can determine if a timer exists by calling this function repeatedly to see if it is incrementing. SYSGET Subfunction 0xD1 \u2013 Get Seconds Count (SECONDS) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xD1 DEHL: Seconds Count C: Remainder Ticks Return the Seconds Count (DEHL) with the number of seconds that have elapsed since the system was started. This is a double-word binary value. Additionally, Remainder Ticks (C) is returned and contains the number of ticks that have elapsed within the current second. Note that Remainder Ticks (C) will have a value from 0 to 49 since there are 50 ticks per second. So, Remainder Ticks does not represent a fraction of the current second. Remainder Ticks (C) can be doubled to derive the hundredths of milliseconds elapsed within the current second. The availability of the Seconds Count (DEHL) is dependent on having a system timer active. If the hardware configuration has no system timer, then Seconds Count (DEHL) will not increment. SYSGET Subfunction 0xE0 \u2013 Get Boot Information (BOOTINFO) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xE0 L: Boot Bank ID D: Boot Disk Unit E: Boot Disk Slice This function returns information about the most recent boot operation performed. It includes the Boot Bank ID (L), the Boot Disk Unit (D), and the Boot Disk Slice (E). The returned Status (A) is a standard HBIOS result code. SYSGET Subfunction 0xF0 \u2013 Get CPU Information (CPUINFO) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF0 H: Z80 CPU Variant L: CPU Speed MHz DE: CPU Speed KHz BC: Oscillator Speed KHz This function returns information about the active CPU environment. The Z80 CPU Variant (H) will be one of: 0=Z80, 1=Z180, 2=Z180-K, 3=Z180-N, 4=Z280. The current CPU speed is provided as both CPU Speed MHz (L) and CPU Speed KHz (DE). The raw oscillator speed is provided as Oscillator Speed KHz (BC). The returned Status (A) is a standard HBIOS result code. SYSGET Subfunction 0xF1 \u2013 Get Memory Information (MEMINFO) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF1 D: ROM Bank Count E: RAM Bank Count This function returns the systems ROM Bank Count (D) and RAM Bank Count (E). Each bank is 32KB by definition. The returned Status (A) is a standard HBIOS result code. SYSGET Subfunction 0xF2 \u2013 Get Bank Information (BNKINFO) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF2 D: BIOS Bank ID E: User Bank ID Certain memory banks within a RomWBW system are special. The exact bank id for each of these varies depending on the configuration of the system. This function can be used to determine the BIOS Bank ID (D) and the User Bank ID (E). The returned Status (A) is a standard HBIOS result code. SYSGET Subfunction 0xF3 \u2013 Get CPU Speed (CPUSPD) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF3 L: Clock Mult D: Memory Wait States E: I/O Wait States This function will return the running CPU speed attributes of a system. The Clock Mult (L) returned indicates the frequency multiple being applied to the raw oscillator clock. If is defined as: 0=Half, 1=Full, and 2=Double. The wait states for the system are also provided as Memory Wait States (D) and I/O Wait States (E). The value of Memory Wait States (D) is the actual number of wait states, not the number of wait states added. The returned Status (A) is a standard HBIOS result code. SYSGET Subfunction 0xF4 \u2013 Get Front Panel Swithes (PANEL) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF4 L: Switches This function will return the current value of the switches (L) from the front panel of the system. If no front panel is available in the system, the returned Status (A) will indicate a No Hardware error. SYSGET Subfunction 0xF5 \u2013 Get Application Banks Information (APPBNKS) Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF5 H: App Banks Start ID L: App Banks Count E: Bank Size HBIOS may be configured to reserve a number of RAM memory banks that will be available for application use. This function returns information about the RAM memory banks currently available for application use. The function provides the bank id of the first available application bank (H) and the count of banks available (L). It also returns the size of a bank expressed as a number of 256-byte pages (E). The returned Status (A) is a standard HBIOS result code. The application banks are always a contiguous set of banks, so the App Banks Start ID can be incremented to address additional banks up to the limit indicated by App Banks Count. If the App Banks Count is zero, then there are no application banks available (regardless of the value of App Banks Start ID). HBIOS does not provide any mechanism to reserve application banks. Any concept of allocation of application banks must be implemented within the OS or application. This function does not change the current bank selected. You must use Function 0xF2 \u2013 System Set Bank (SYSSETBNK) or the proxy function Bank Select (BNKSEL) for this. Be sure to observe the warnings in the description of this function. Function 0xF9 \u2013 System Set (SYSSET) Entry Parameters Returned Values B: 0xF9 A: Status C: Subfunction This function will set various system parameters based on the sub-function value. The following lists the subfunctions available along with the registers/information utilized. The Status (A) is a standard HBIOS result code. SYSSET Subfunction 0xC0 \u2013 Set Switches (SWITCH) Entry Parameters Returned Values B: 0xF9 A: Status C: 0xC0 D: Switch Key HL: Switch Value This function will set the value (HL) into the switch (D) and store it into NVRAM. Switches may be passed as a 16 bit (HL) or 8 bit (L) value. It is up to the caller to send the value correctly. Note for Switch 0xFF (reset) the value (HL) is ignored Errors are signalled in the return by setting the NZ flag. When set the (A) register may contain an error code, but this code does not conform to RomWBW standard Success is indicated by setting the Z flag For a description of switches please see RomWBW NVRAM Configuration SYSSET Subfunction 0xD0 \u2013 Set Timer Tick Count (TIMER) Entry Parameters Returned Values B: 0xF9 A: Status C: 0xD0 DEHL: Timer Tick Count This function will explicitly set the system Timer Tick Count (DEHL) value. DEHL is a double-word binary value. The Status (A) is a standard HBIOS result code. SYSSET Subfunction 0xD1 \u2013 Set Seconds Count (SECONDS) Entry Parameters Returned Values B: 0xF9 A: Status C: 0xD1 DEHL: Seconds Count This function will explicitly set the system Seconds Count (DEHL) value. DEHL is a double-word binary value. The Status (A) is a standard HBIOS result code. SYSSET Subfunction 0xE0 \u2013 Set Boot Information (BOOTINFO) Entry Parameters Returned Values B: 0xF9 A: Status C: 0xE0 L: Boot Bank ID D: Boot Disk Unit E: Boot Disk Slice This function sets information about the most recent boot operation performed. It includes the Boot Bank ID (L), the Boot Disk Unit (D), and the Boot Disk Slice (E). The returned Status (A) is a standard HBIOS result code. SYSSET Subfunction 0xF3 \u2013 Set CPU Speed (CPUSPD) Entry Parameters Returned Values B: 0xF9 A: Status C: 0xF3 L: Clock Mult D: Memory Wait States E: I/O Wait States This function will modify the running CPU speed attributes of a system. Note that it is frequently impossible to tell if a system is capable of dynamic speed changes. This function makes the changes blindly. You can specify 0xFF for either of the wait state settings to have them left alone. If an attempt is made to change the speed of a system that is definitely incapable of doing so, then an error result is returned. The returned Status (A) is a standard HBIOS result code. The function will attempt to set the CPU speed based on the Clock Mult (L) value: 0=Half, 1=Full, 2=Double. Memory Wait States (D) and I/O Wait States (E) will be set if possible. The value of Memory Wait States (D) is the actual number of wait states, not the number of wait states added. Some peripherals are dependent on the CPU speed. For example, the Z180 ASCI baud rate and system timer are derived from the CPU speed. The Set CPU Speed function will attempt to adjust these peripherals for correct operation after modifying the CPU speed. However, in some cases this may not be possible. The baud rate of ASCI ports have a limited set of divisors. If there is no satisfactory divisor to retain the existing baud rate under the new CPU speed, then the baud rate of the ASCI port(s) will be affected. SYSSET Subfunction 0xF4 \u2013 Set Front Panel LEDs (PANEL) Entry Parameters Returned Values B: 0xF9 A: Status C: 0xF4 L: LEDs This function will set the front panel LEDs based on the bits in L. If no front panel is available in the system, the returned Status (A) will indicate a No Hardware error. Function 0xFA \u2013 System Peek (SYSPEEK) Entry Parameters Returned Values B: 0xFA A: Status D: Bank ID E: Byte Value HL: Memory Address This function retrieves and returns the Byte Value from the specified Bank ID (D) and Memory Address (HL). The bank specified is not range checked. The Status (A) is a standard HBIOS result code. Function 0xFB \u2013 System Poke (SYSPOKE) Entry Parameters Returned Values B: 0xFB A: Status D: Bank ID HL: Memory Address E: Byte Value This function sets the Byte Value (E) in the specified Bank ID (D) and Memory Address (HL). The bank specified is not range checked. The Status (A) is a standard HBIOS result code. Function 0xFC \u2013 System Interrupt Management (SYSINT) Entry Parameters Returned Values B: 0xFC A: Status C: Subfunction This function allows the caller to query information about the interrupt configuration of the running system and allows adding or hooking interrupt handlers dynamically. Register C is used to specify a sub-function. Additional input and output registers may be used as defined by the sub-function. The Status (A) is a standard HBIOS result code. Note that during interrupt processing, the lower 32K of CPU address space will contain the RomWBW HBIOS code bank, not the lower 32K of application TPA. As such, a dynamically installed interrupt handler does not have access to the lower 32K of TPA and must be careful to avoid modifying the contents of the lower 32K of memory. Invoking RomWBW HBIOS functions within an interrupt handler is not supported. Interrupt handlers are different under IM1 and IM2. Interrupt Mode 1: The new interrupt handler is responsible for chaining (JP) to the previous vector if the interrupt is not handled. If the interrupt is handled, the new handler may simply return (RET). When chaining to the previous interrupt handler, ZF must be set if interrupt is handled and ZF cleared if not handled. The interrupt management framework takes care of saving and restoring AF, BC, DE, HL, and IY. Any other registers modified must be saved and restored by the interrupt handler. Interrupt Mode 2: The new interrupt handler may either replace or hook the previous interrupt handler. To replace the previous interrupt handler, the new handler just returns (RET) when done. To hook the previous handler, the new handler can chain (JP) to the previous vector. Note that initially all IM2 interrupt vectors are set to be handled as \u201cBAD\u201d meaning that the interrupt is unexpected. In most cases, you do not want to chain to the previous vector because it will cause the interrupt to display a \u201cBAD INT\u201d system panic message. The interrupt framework will take care of issuing an EI and RETI instruction. Do not put these instructions in your new handler. Additionally, interrupt management framework takes care of saving and restoring AF, BC, DE, HL, and IY. Any other registers modified must be saved and restored by the interrupt handler. If the caller is transient, then the caller must remove the new interrupt handler and restore the original one prior to termination. This is accomplished by calling this function with the Interrupt Vector set to the Previous Vector returned in the original call. The caller is responsible for disabling interrupts prior to making an INTSET call and enabling them afterwards. The caller is responsible for ensuring that a valid interrupt handler is installed prior to enabling any hardware interrupts associated with the handler. Also, if the handler is transient, the caller must disable the hardware interrupt(s) associated with the handler prior to uninstalling it. SYSINT Subfunction 0x00 \u2013 Interrupt Info (INTINF) Entry Parameters Returned Values B: 0xFC A: Status C: 0x00 D: Interrupt Mode E: IVT Size Return current Interrupt Mode (D) of the system. Also return the number of Interrupt Vector Table (IVT) entries in IVT (E). For IM1, the size of the table is the number of vectors chained together. For IM2, the size of the table is the number of slots in the vector table. The Status (A) is a standard HBIOS result code. SYSINT Subfunction 0x10 \u2013 Get Interrupt (INTGET) Entry Parameters Returned Values B: 0xFC A: Status C: 0x10 HL: IVT Address E: IVT Index This function will return the IVT Address (HL) of the current interrupt vector for the specified IVT Index (C). The Status (A) is a standard HBIOS result code. SYSINT Subfunction 0x20 \u2013 Set Interrupt (INTSET) Entry Parameters Returned Values B: 0xFC A: Status C: 0x20 HL: Previous Interrupt Address E: IVT Index HL: Interrupt Address This function will set a new Interrupt Address (HL) at the IVT Index (E) specified. On return, the Previous Interrupt Address (HL) will be provided. Proxy Functions The following special functions are implemented inside of the HBIOS proxy area at the top of RAM. They do not cause a bank switch and are, therefore, much faster than their corresponding HBIOS API functions. The functions are invoked via the following dedicated jump table: Function Address ** Equate ** Invoke HBIOS Function (INVOKE) 0xFFF0 HB_INVOKE Bank Select (BNKSEL) 0xFFF3 HB_BNKSEL Bank Copy (BNKCPY) 0xFFF6 HB_BNKCPY Bank Call (BNKCALL) 0xFFF9 HB_BNKCALL The function addresses are also defined as equates in hbios.inc. It is suggested that you use the equates when possible. To use the functions, you may either call or jump to them. Some examples: CALL $FFF0 JP $FFF3 CALL HB_BNKCPY These functions are inherently dangerous and generally not value checked. Use with extreme caution. Invoke HBIOS Function (INVOKE) Address 0xFFF0 This function is an alternate mechanism for invoking the normal HBIOS API functions. The parameters and return values are as documented above. To put it another way, CALL $FFF0 is equivalent to RST 08 , but it can be used in any scenario when the normal bank is not selected. Bank Select (BNKSEL) Address 0xFFF3 Entry Parameters Returned Values A: Bank ID This function will select the memory bank identified by Bank ID (A). Register AF is destroyed. All other registers are preserved. The warnings described in Function 0xF2 \u2013 System Set Bank (SYSSETBNK) should be observed. Bank Copy (BNKCPY) Address 0xFFF6 Entry Parameters Returned Values HL: Source Address HL: Ending Source Address DE: Destination Address DE: Ending Destination Address BC: Count BC: 0 HB_SRCBNK: Source Bank ID HB_DSTBNK: Destination Bank ID This function will copy Count (BC) bytes from Source Address (HL) in Source Bank ID (HB_SRCBNK) to Destination Address (DE) in Destination Bank ID (HB_DSTBNK). The HB_SRCBNK and HB_DSTBNK fields are dedicated locations in the proxy. These locations are defined in hbios.inc: Source Bank ID: HB_SRCBNK = \\$FFE4 Destination Bank ID: HB_DSTBNK = \\$FFE7 The Source Bank ID and Destination Bank ID values must be populated in the specified addresses before calling this function. During processing, HL and DE, will be incremented. At termination, HL and DE will contain the \u201cnext\u201d source/destination addresses that would be copied. This allows this function to be invoked repeatedly to copy continuous blocks of data. Register AF is destroyed by this function. Register BC will be 0. Bank Call (BNKCALL) Address 0xFFF9 Entry Parameters Returned Values A: Target Bank ID IX: Target Address This function will perform a function call to a routine in another bank. It does this by selecting the Target Bank ID (A) and then calling the Target Address (IX). On return from the target function, the originally active bank is selected. Register usage is determined by the routine that is called. Since a different bank will be selected while the target function is active, the warnings described in Function 0xF2 \u2013 System Set Bank (SYSSETBNK) should be observed. Errors and diagnostics ROMWBW tries to provide useful information when a run time or build time error occurs. Many sections of the code also have code blocks that can be enable to aid in debugging and in some cases the level of reporting detail can be customized. Run Time Errors PANIC A panic error indicates a non-recoverable error. The processor status is displayed on the console and interrupts are disabled and execution is halted. A cold boot or reset is required to restart. Example error message: >>> PANIC: @06C4[DFA3:DFC3:0100:F103:04FC:0000:2B5E] *** System Halted *** The format of the information provided is @XXXX [-AF-:-BC-:-DE-:-HL-:-SP-:-IX-:-IY-] Where @XXXX is the address the panic was called from. The other information is the CPU register contents. Possible reasons a PANIC may occur are: RAM Bank range error when attempting a read or write to a RAM disk. Sector read function has not been setup but a read was attempted. An interrupt vector has not been set up when an interrupt was received. There was an attempt to add more devices than the device table had room for. An illegal SD card command was encountered. The @XXXX memory address can be cross referenced with the build source code to identify which section of the software or hardware caused the fault. SYSCHK A syschk error is identified when an internal error is detected. When this occurs an error code is returned to the calling program in the A register. A non-zero result indicates an error. Syschk errors may be reported to the console. Whether this occurs depends on the value of the diagnosis level equate DIAGLVL. By default syschk errors are not reported to the console. If the diagnosis level is set to display the diagnosis information, then memory address, register dump and error code is displayed. A key difference with the PANIC error is that execution may be continued. Example error message: >>> SYSCHK: @06C4 [DFA3:DFC3:0100:F103:04FC:0000:2B5E] FD Continue (Y/N) The format of the information provided is similar the PANIC report. @XXXX [-AF-:-BC-:-DE-:-HL-:-SP-:-IX-:-IY-] YY The syschk error codes YY is returned in the A register. Error Code YY Success 0x00 Undefined Error 0xFF Function Not Implemented 0xFE Invalid Function 0xFD Invalid Unit Number 0xFC Out Of Memory 0xFB Parameter Out Of Range 0xFA Media Not Present 0xF9 Hardware Not Present 0xF8 I/O Error 0xF7 Write Request To Read-Only Media 0xF6 Device Timeout 0xF5 Invalid Configuration 0xF4 Internal Error 0xF3 Error Level reporting placeholder Build time errors Build chain tool errors place holder Assembly time check errors placeholder Diagnostics Diagnostic LEDs Progress through the boot and initialization process can be difficult to monitor due to the lack of console or video output. Access to these output devices does not become available until late the in the boot process. If these output devices are also involved with the issue trying to be resolved then trouble shooting is even more difficult. ROMWBW can be configured to display boot progress with the assistance of additional hardware. This can take the form of a front panel LED display or LED breakout debugging board connected to an 8-bit output port. Or it can utilize existing platform status LEDS. As the boot code executes, the LED output display is updated to indicate the execution progress. Platforms that have these capabilities built in have them enabled by default. Front Panel display A LED front panel or breakout board needs to be connected the computers data, reset and port select lines. To enable this option the following settings can be made in the platforms custom configuration file. FPLED_ENABLE .SET TRUE ; ENABLE FRONT PANEL Custom hardware can be configured with : FPLED_IO .SET $nn ; USE PORT ADDRESS nn FPLED_INV .SET FALSE ; INVERTED LED BITS Platform Status LEDS These status LEDs use preexisting status LEDs on each platform. Enable using: LEDENABLE .SET TRUE ; ENABLES STATUS LED Customize using: LEDMODE .SET LEDMODE_STD ; LEDMODE_[STD|SC|RTC|NABU] LEDPORT .SET $nn ; STATUS LED PORT ADDRESS The following table shows the ROMWBW process steps in relation to the panel display. PANEL RomWBW Processes ........ Initial boot Jump to start address Disable interrupts Set interrupt mode Initialize critical ports and baud rate .......O Setup initial stack Memory manager and CPU configuration Set top bank to be RAM ......OO Get and save battery condition Install HBIOS proxy in upper memory If platform is MBC reconfigure memory manager Setup \u201cROMLESS\u201d HBIOS image or \u2026 Copy HBIOS from ROM to RAM if RAM flag not set Jump to HBIOS in RAM Set running in RAM flag .....OOO Finalize configuration for running in RAM Check battery condition Check for recovery mode boot ....OOOO Identify CPU type ...OOOOO Set cpu oscillator speed Setup counter-timers Setup heap ..OOOOOO Preconsole initialization .OOOOOOO Boot delay Set boot console device Bios announcement OOOOOOOO Display platform information Display memory configuration Display CPU family Verify ROM checksum Report battery condition Perform device driver initialization Report watchdog status Mark HBIOS heap so it is preserved Switch from boot console to CRT if active Display device summary Execute boot loader Appendix A Driver Instance Data fields This section is a work in progress\u2026 The following section outlines the read only data referenced by the SYSGET , subfunctions xxxFN for specific drivers. TMS9918 Driver: Name Offset Bytes Description PPIA 0 1 PPI PORT A PPIB 1 1 PPI PORT B PPIC 2 1 PPI PORT C PPIX 3 1 PPI CONTROL PORT DATREG 4 1 IO PORT ADDRESS FOR MODE 0 CMDREG 5 1 IO PORT ADDRESS FOR MODE 1 Below are the register mirror values that HBIOS used for initialisation REG. 0 6 1 \\$00 - NO EXTERNAL VID REG. 1 7 1 \\$50 or \\$70 - SET MODE 1 and interrupt if enabled REG. 2 8 1 \\$00 - PATTERN NAME TABLE := 0 REG. 3 9 1 \\$00 - NO COLOR TABLE REG. 4 10 1 \\$01 - SET PATTERN GENERATOR TABLE TO \\$800 REG. 5 11 1 \\$00 - SPRITE ATTRIBUTE IRRELEVANT REG. 6 12 1 \\$00 - NO SPRITE GENERATOR TABLE REG. 7 13 1 \\$F0 - WHITE ON BLACK DCNTL* 14 1 Z180 DMA/WAIT CONTROL ONLY PRESENT FOR Z180 BUILDS","title":"System Guide"},{"location":"SystemGuide/#overview","text":"The objective of RomWBW is to provide firmware, operating systems, and applications targeting the Z80 family of CPUs. The firmware, in the form of a ROM module, acts as the hardware interface layer with a well-defined API (the HBIOS). The associated operating systems and applications are adapted to the HBIOS API, not specific hardware. The HBIOS is modular and configurable. New hardware interfaces can be added in the form of straightforward driver modules. Within certain constraints, new hardware platforms can be supported by simply adjusting values in a build configuration file. RomWBW is geared toward hardware being developed in modern retro-computing hobbyist communities, not as replacement software for legacy hardware. As a result, RomWBW requires at least 128KB of bank switched RAM. The CP/M family of operating systems has been adapted to run under RomWBW including CP/M 2.2, Z-System, CP/M 3, and several other variants. RomWBW firmware (ROM) includes: System startup code (bootstrap) and bootloader A basic system/debug monitor HBIOS (Hardware BIOS) with support for most typical hardware components used in Z80 family computers Diagnostics and customizable debugging information. ROM-hosted operating systems (both CP/M 2.2 and Z-System) A ROM disk containing the standard OS applications and a RAM disk for working storage. It is appropriate to note that much of the code and components that make up a complete RomWBW package are derived from pre-existing work. Most notably, the embedded operating systems are simply ROM-based copies of generic CP/M or ZSDOS. Much of the hardware support code was originally produced by other members of the RetroBrew Computers Community. The remainder of this document focuses on RomWBW HBIOS which is the fundamental basis of RomWBW.","title":"Overview"},{"location":"SystemGuide/#background","text":"The Z80 CPU architecture has a limited, 64K address range. In general, this address space must accommodate a running application, disk operating system, and hardware support code. Modern retro-computing Z80 CPU platforms provide a physical address space that is much larger than the CPU address space (typically 512K or 1MB of physical RAM). This additional memory can be made available to the CPU using a technique called bank switching. To achieve this, the physical memory is divided up into chunks (banks) of 32K each. A designated area of the CPU\u2019s 64K address space is then reserved to \u201cmap\u201d any of the physical memory chunks. You can think of this as a window that can be adjusted to view portions of the physical memory in 32K blocks. In the case of RomWBW, the lower 32K of the CPU address space is used for this purpose (the window). The upper 32K of CPU address space is assigned a fixed 32K area of physical memory that never changes. The lower 32K can be \u201cmapped\u201d on the fly to any of the 32K banks of physical memory at a time. The primary constraint is that the CPU cannot be executing code in the lower 32K of CPU address space at the time that a bank switch is performed. By utilizing the pages of physical RAM for specific purposes and swapping in the correct page when needed, it is possible to utilize substantially more than 64K of RAM. Because the retro-computing community has now produced a very large variety of hardware, it has become extremely important to implement a bank switched solution to accommodate the maximum range of hardware devices and desired functionality.","title":"Background"},{"location":"SystemGuide/#general-design-strategy","text":"The design goal is to locate as much of the hardware dependent code as possible out of normal 64KB CP/M address space and into a bank switched area of memory. A very small code shim (proxy) is located in the top 512 bytes of CPU memory. This proxy is responsible for redirecting all hardware BIOS (HBIOS) calls by swapping the \u201cdriver code\u201d bank of physical RAM into the lower 32K and completing the request. The operating system is unaware this has occurred. As control is returned to the operating system, the lower 32KB of memory is switched back to the original memory bank. The HBIOS functions are invoked simply by placing function parameters in Z80 registers and calling an address within the HBIOS proxy. Additionally, HBIOS implements a complete hardware interrupt management framework. When a hardware interrupt occurs, control vectors through the HBIOS proxy which saves the machine state, selects the HBIOS driver bank into memory, and transfers control to the registered driver\u2019s interrupt handler. Upon completion of interrupt processing, control returns via the HBIOS proxy, machine state is restored, and normal processing resumes. The interrupt management framework supports Z80 interrupt modes 1, 2, and 3 (Z280). HBIOS is completely agnostic with respect to the operating system (it does not know or care what operating system is using it). The operating system makes simple calls to HBIOS to access any desired hardware functions. Since the HBIOS proxy occupies only 512 bytes at the top of memory, the vast majority of the CPU memory is available to the operating system and the running application. As far as the operating system is concerned, all of the hardware driver code has been magically implemented inside of the small 512 byte area at the top of the CPU address space. Unlike some other Z80 bank switching schemes, there is no attempt to build bank switching into the operating system itself. This is intentional so as to ensure that any operating system can easily be adapted without requiring invasive modifications to the operating system itself. This also keeps the complexity of memory management completely away from the operating system and applications. There are some operating systems that have built-in support for bank switching (e.g., CP/M 3). These operating systems are allowed to make use of the bank switched memory and are compatible with HBIOS. However, it is necessary that the customization of these operating systems take into account the banks of memory used by HBIOS and not attempt to use those specific banks. Note that all code and data are located in RAM memory during normal execution. While it is possible to use ROM memory to run code, it would require that more upper memory be reserved for data storage. It is simpler and more memory efficient to keep everything in RAM. At startup (boot) all required code is copied to RAM (shadowed) for subsequent execution.","title":"General Design Strategy"},{"location":"SystemGuide/#runtime-memory-layout","text":"RomWBW divides the standard 64KB Z80 address space into 2 sections. The lower 32KB is the \u201cbanked\u201d area. This is the area that will contain any of the 32KB chunks of physical RAM based on which bank is currently selected. The upper 32KB is \u201cfixed\u201d. This area of memory is never swapped out and is used to contain software and operating systems that must remain in the Z80 address space. Throughout this document, this mechanism of selecting banks of memory into the lower 32K is referred to as memory management. Achieving this functionality requires some type of hardware which is generally referred to as the system\u2019s Memory Management Unit (MMU). RomWBW supports a variety of MMUs \u2013 but they all perform the same function of swapping in/out banks of memory in the lower 32K of CPU address space. Figure 4.1 depicts the memory layout for a system running the CP/M operating system. Applications residing in TPA invoke BDOS services of CP/M, BDOS invokes the custom CBIOS APIs, and finally CBIOS invokes HBIOS functions as needed by calling into the HBIOS proxy. The HBIOS proxy swaps in the HBIOS bank as needed to perform the requested function. Additional banks of RAM are used to create a virtual disk drive. Bank Switched Memory Layout","title":"Runtime Memory Layout"},{"location":"SystemGuide/#bank-id","text":"RomWBW utilizes a specific assignment of memory banks for dedicated purposes. A numeric Bank Id is used to refer to the memory banks. The Bank Id is a single byte. In general, the Bank Id simply refers to each of the 32K banks in sequential order. In other words, Bank Id 0 is the first physical 32K, Bank Id 1 is the second, etc. However, the high order bit of the Bank Id has a special meaning. If it is 0, it indicates a ROM bank is being referred to. If it is 1, it indicates a RAM bank is being referred to. For example, let\u2019s say we have a typical system with 512KB of ROM and 512KB of RAM. The following table demonstrates how Bank Ids represent areas of physical memory. Physical Memory Type Physical Bank Bank Id 0x000000-0x007FFF ROM 0 0x00 0x008000-0x00FFFF ROM 1 0x01 0x010000-0x07FFFF ROM 2-15 0x02-0x0F 0x080000-0x087FFF RAM 16 0x80 0x088000-0x08FFFF RAM 17 0x81 0x090000-0x0FFFFF RAM 18-31 0x82-0x8F Note that Bank Id 0x00 is always the first bank of ROM and 0x80 is always the first bank of RAM. If there were more banks of physical ROM, they would be assigned Bank Ids starting with 0x10. Likewise, additional bank of physical RAM would be assigned Bank Ids starting with 0x90. The Bank Id is used in all RomWBW API functions when referring to the mapping of banks to the lower 32K bank area of the processor. In this way, all RomWBW functions can refer to a generic Bank Id without needing to understand how a specific hardware platform accesses the physical memory areas. A single routine within the HBIOS is implemented for each memory manager that maps Bank Ids to physical memory.","title":"Bank Id"},{"location":"SystemGuide/#bank-assignments","text":"RomWBW requires dedicated banks of memory for specific purposes. It uses Bank Ids via an algorithm to make these assignments. The following table describes the way the banks are assigned. The Typical column shows the specific values that would be assigned for a common system with 512KB of ROM and 512KB of RAM (nROM=16, nRAM=16). Bank Id Identity Typical Purpose 0x00 BID_BOOT 0x00 Boot Bank (HBIOS image) 0x01 BID_IMG0 0x01 Boot Loader, Monitor, ROM OSes, ROM Apps 0x02 BID_IMG1 0x02 ROM Apps 0x03 BID_IMG2 0x03 \\ 0x04 BID_ROMD0 0x04 First ROM Disk Bank nROM - 1 0x0F Last ROM Disk Bank 0x80 BID_BIOS 0x80 HBIOS (working copy) 0x81 BID_RAMD0 0x81 First RAM Disk Bank 0x80 + nRAM - 8 0x88 Last RAM Disk Bank 0x80 + nRAM - 7 BID_APP0 0x89 First Application Bank 0x80 + nRAM - 5 0x8B Last Application Bank 0x80 + nRAM - 4 BID_BUF 0x8C OS Disk Buffers 0x80 + nRAM - 3 BID_AUX 0x8D OS Code Bank 0x80 + nRAM - 2 BID_USR 0x8E User Bank (CP/M TPA) 0x80 + nRAM - 1 BID_COM 0x8F Common Bank In this table, nROM and nRAM refer to the number of corresponding ROM and RAM banks in the the system. The contents of the banks referred to above are described in more detail below: Boot Bank: The Boot Bank receives control when a system is first powered on. It contains a ROM (read-only) copy of the HBIOS. At boot, it does minimal hardware initialization, then copies itself to the HBIOS bank in RAM, then resumes execution from the RAM bank. Boot Loader: The application that handles loading of ROM or Disk based applications including operating systems. It copies itself to a RAM bank at the start of it\u2019s execution. Monitor: The application that implements the basic system monitor functions. It copies itself to a RAM bank at the start of it\u2019s execution. ROM OSes: Code images of CP/M 2.2 and Z-System which are copied to RAM and executed when a ROM-based operating system is selected in the Boot Loader. ROM Applications: Various ROM-based application images such as BASIC, FORTH, etc. They can be selected in the Boot Loader. The Boot Loader will copy the application image to a RAM bank, then transfer control to it. ROM Disk: A sequential series of banks assigned to provide the system ROM Disk contents. HBIOS: This bank hosts the running copy of the RomWBW HBIOS. RAM Disk: A sequential series of banks assigned to provide the system RAM Disk. Application Bank: A sequential series of banks that are available for use by applications that wish to utilize banked memory. OS Disk Buffers: This bank is used by CP/M 3 and ZPM3 for disk buffer storage. OS Code Bank: This bank is used by CP/M 3 and ZPM3 as an alternate bank for code. This allows these operating systems to make additional TPA space available for applications. User Bank: This is the default bank for applications to use. This includes the traditional TPA space for CP/M. Common Bank: This bank is mapped to the upper 32K of the processors memory space. It is a fixed mapping that is never changed in normal RomWBW operation hence the name \u201cCommon\u201d.","title":"Bank Assignments"},{"location":"SystemGuide/#memory-managers","text":"The following hardware memory managers are supported by RomWBW. The operation of these memory managers is not documented here \u2013 please refer to the documentation of your hardware provider for that. Z2: Memory memory manager introduced by Sergey Kiselv in the Zeta 2 SBC. Popular in many RCBus systems. Z180: Memory manager built into the Z180 CPU Z280: Memory manager built into the Z280 CPU ZRC: Memory manager onboard the ZRC series of computers by Bill Shen. SBC: Memory manager onboard the N8VEM SBC series of computers by Andrew Lynch. MBC: Memory manager onboard the Nhyodyne computer system by Andrew Lynch. N8: Memory manager onboard the N8 SBC computer by Andrew Lynch. EZ512: Memory manager onboard the EaZy80-512 Z80 CPU Module by Bill Shen. RPH: Memory manager onboard the Rhyophyre computer system by Andrew Lynch. The memory manager used is determined by the configuration choices that are part of a RomWBW build process. A given ROM can only have a single memory manager \u2013 it is not selected dynamically.","title":"Memory Managers"},{"location":"SystemGuide/#disk-layout","text":"","title":"Disk Layout"},{"location":"SystemGuide/#floppy-disk-layout","text":"RomWBVW generally handles floppy disks in the same physical formats as MS-DOS. However, the filesystem will normally be CP/M. The following table lists the floppy disk formats used by RomWBW. In all cases, the sector size is 512 bytes. HBIOS Media ID Capacity Tracks Heads Sectors MID_FD720 720KB 80 2 9 MID_FD144 1440KB 80 2 18 MID_FD360 360KB 40 2 9 MID_FD120 1200KB 80 2 15 MID_FD111 1155KB 77 2 15","title":"Floppy Disk Layout"},{"location":"SystemGuide/#hard-disk-layout","text":"RomWBW supports the use of PC MBR hard disk partitioning (see https://en.wikipedia.org/wiki/Disk_partitioning ). When accessing a hard disk device, HBIOS will look for a partition with type id 0x2E and will use that partition exclusively for all storage. If a hard disk does not have a valid partition table with a partition of type 0x2E, the HBIOS will treat the hard disk as dedicated storage and will store data starting at the first sector of the disk. The use of a partition of type 0x2E is preferred for RomWBW and is referred to as a \u201cModern\u201d disk layout. If there is no RomWBW partition on the disk, then the disk is designated as having a \u201cClassic\u201d disk layout. When a disk uses a RomWBW partition (type 0x2E) for storage (Modern layout), the CP/M filesystems on that disk will utilize a format with 1,024 directory entries per filesystem. If there is no RomWBW partition, the CP/M filesystems will have 512 directory entries per filesystem. As a result, the Modern disk layout with a RomWBW partition is also referred to as the \u201chd1k\u201d layout indicating 1024 directory entries. Similarly, the Classic disk layout (no partition of type 0x2E) is also referred to as the \u201chd512\u201d layout indicating 512 directory entries. The layout type of any hard disk is simply dictated by the existence of a RomWBW partition. This also means that if you add or remove a partition table entry of type 0x2E on existing hard disk media, you will lose access to any pre-existing CP/M data on the disk. If used, partitioning should be done before putting any data on the disk. WARNING: You can not mix the two hard disk layouts on one hard disk device. You can use different layouts on different hard disk devices in a single system though. Regardless of whether a disk is Modern or Classic, RomWBW supports the concept of CP/M filesystem slices. In general, CP/M filesystems are limited to 8MB. Since current disk media is dramatically larger than this, RomWBW implements a mechanism to put many (up to 256) CP/M filesystems on a single disk. Each such filesystem is called a slice referring to the idea that the disk has been sliced into many independent CP/M filesystems. RomWBW allows the disk slices to be mapped to the limited (16) drive letters of CP/M. The mapping can be modified on-the-fly on a running system as desired. If the case of a Modern disk layout (with a RomWBW partition), the slices are contained within the defined partition area and the number of slices is dictated by the size of the partition. In the case of a Classic disk layout (no RomWBW partition), the slices are located at the start of the disk (first sector). In either case, the slices are just sequential areas of space on the hard disk. RomWBW accesses all hard disks using Logical Block Addressing (pure sector offset). When necessary, RomWBW simulates the following disk geometry for operating systems: Sector = 512 Bytes Track = 16 Sectors (8KB per Track) Cylinder = 16 Tracks (256 Sectors per Cylinder, 128KB per Cylinder) If one is used, the FAT Partition must not overlap the CP/M slices. The FAT partition does not need to start immediately after the CP/M slices nor does it need to extend to the end of the hard disk. Its location and size are entirely determined by its corresponding partition table entry. Drive letters in CP/M are ASSIGNed to the numbered slices as desired. At boot, RomWBW automatically assigns up to 8 slices to drive letters starting with the first available drive letter (typically C:). Microsoft Windows will assign a single drive letter to the FAT partition when the CF/SD Card is inserted. The drive letter assigned has no relationship to the CP/M drive letters assigned to CP/M slices. In general, Windows, MacOS, or Linux know nothing about the CP/M slices and CP/M knows nothing about the FAT partition. However, the FAT application can be run under CP/M to access the FAT partition programmatically. Before being used, A CP/M slice must be (re)initialized using the CP/M command CLRDIR. A CP/M slice can be made bootable by copying a system image to the System Area using SYSCOPY. The FAT partition can be created from CP/M using the FDISK80 application. The FAT partition can be initialized using the FAT application from CP/M using the command FAT FORMAT n: where n is the RomWBW disk unit number containing the FAT partition to be formatted.","title":"Hard Disk Layout"},{"location":"SystemGuide/#modern-hard-disk-layout-hd1k","text":"Modern Disk Layout The CP/M filesystem on a Modern disk will accommodate 1,024 directory entries. The CP/M slices reside entirely within a hard disk partition of type 0x2E. The number of slices is determined by the number of slices that fit within the partition spaces allocated up to the maximum of 256.","title":"Modern Hard Disk Layout (hd1k)"},{"location":"SystemGuide/#classic-hard-disk-layout-hd512","text":"Classic Disk Layout The CP/M filesystem on a Classic disk will accommodate 512 directory entries. The CP/M slices reside on the hard disk starting at the first sector of the hard disk. The number of CP/M slices is not explicitly recorded anywhere on the hard disk. It is up to the system user to know how many slices are being used based on the size of the hard disk media and/or the start of a FAT partition. A partition table may exist within the first sector of the first slice. For Classic disks, the partition table defines only the location and size of the FAT partition. The Partition Table does not control the location or number of CP/M slices in any way. The Partition Table resides in a sector that is shared with the System Area of CP/M Slice 0. However, the RomWBW implementation of CP/M takes steps to avoid changing or corrupting the Partition Table area. The FAT partition can be created from CP/M using the FDISK80 application. The user is responsible for ensuring that the start of the FAT partition does not overlap with the area they intend to use for CP/M slices. FDISK80 has a Reserve option to assist with this.","title":"Classic Hard Disk Layout (hd512)"},{"location":"SystemGuide/#mapping-to-media-id","text":"HBIOS has a definition of \u201cMedia ID\u201d, which defines the type and physical properties of disk media provided by an underlying storage device. For a complete list of Media ID\u2019s please see Disk Input/Output (DIO) . There are two important Media ID\u2019s relating to Hard Disk Layouts: Media ID Format / Meaning MID_HD 4 Classic Disk Layout (hd512) \u2013and\u2013 HBIOS Hard Disk Drive MID_HDNEW 10 Modern Disk Layout (hd1k) HBIOS typically does not understand the format of data on a device, instead just treating all hard disks as raw sectors. MID_HD is the typical Media ID used by HBIOS to describe high capacity hard disk media When the Modern Disk Layout was added, the MID_HDNEW , was added to differentiate (at the operating system level) between the Classic and Modern layouts. However HBIOS itself typically does NOT make this distinction, since the use of these two formats is determined by the operating system based on the partition table on the media. There are two important HBIOS functions that deal with Media ID. Function 0x18 \u2013 Disk Media (DIOMEDIA) Function 0xE0 \u2013 Calculate Slice (EXTSLICE)","title":"Mapping to Media ID"},{"location":"SystemGuide/#system-boot-process","text":"A multi-phase boot strategy is employed. This is necessary because at cold start, the CPU is executing code from ROM in lower memory which is the same area that is bank switched. RomWBW supports multiple boot techniques as described below. The most common of these is the ROM boot.","title":"System Boot Process"},{"location":"SystemGuide/#rom-boot","text":"The ROM boot process normally begins with a system cold start (power on or hardware reset). The hardware is responsible for ensuring that the lower 32K of CPU memory (bank window) is mapped to the initial 32K of the ROM. The Z80 CPU begins execution at address zero which will be address zero of the ROM. The following steps occur during the ROM boot process: The ROM code performs basic hardware initialization and ensures that the top 32K of CPU memory is mapped to the proper RAM bank. The ROM code installs the HBIOS proxy code into the top 512 bytes of the CPU memory (0xFE00-0xFFFF). Using the proxy code services, the full HBIOS code is copied from the ROM bank to the RAM bank that it will use for normal processing. Again using the proxy code services, the RAM copy of HBIOS is activated in the bank window and execution transitions to the RAM copy of HBIOS. The HBIOS initializes the system console so that output can now be displayed to the user. The HBIOS now performs the full hardware discovery and initialization process while displaying it\u2019s progress. The HBIOS displays a final summary of the hardware device unit assignments and various configuration information. The HBIOS loads the RomWBW Boot Loader from ROM into RAM and jumps to it. At this point, the user would normally use Boot Loader commands to select and launch an operating system or applications from either ROM or disk. Note that the boot process is entirely operating system agnostic. It is unaware of the operating system being loaded. The Boot Loader prompts the user for the location of the binary image to load, but does not know anything about what is being loaded (the image is usually an operating system, but could be any executable code image). Once the Boot Loader has loaded the image at the selected location, it will transfer control to it. Assuming the typical situation where the image was an operating system, the loaded operating system will then perform its own initialization and begin normal operation.","title":"ROM Boot"},{"location":"SystemGuide/#application-boot","text":"Once the system is running (operating system loaded), it is possible to reboot the system from a system image (file) contained on the OS file system. This is referred to as an \u201cApplication Boot\u201d. The process is similar to a ROM boot, but the HBIOS code is loaded from an image file instead of ROM. This boot technique is useful to: 1) test a new build of a system image before programming it to the ROM; or 2) easily switch between system images on the fly. During the RomWBW build process, one of the output files produced is an actual CP/M application (an executable .COM program file). Like the normal .ROM files, this file is placed in the Binary directory with the same name as the ROM file, but with the file extension of .ROM. Once you have a running CP/M (or compatible) system, you can upload/copy this application file to the filesystem. By executing this file, you will initiate an Application Boot using the system image contained in the application file itself. Upon execution, the Application Boot program is loaded into memory by the previously running operating system starting at \\$0100. Note that the program image contains a full copy of the HBIOS to be installed and run. Once the Application Boot program is loaded by the previous operating system, control is passed to it and it performs a system initialization similar to the ROM Boot, but using the image loaded in RAM. Once the new HBIOS completes its initialization, it will launch the Boot Loader just like a ROM boot. The Application Boot program actually contains two other components beyond the new HBIOS. It has a copy of the Boot Loader and a copy of the Z-System OS. This is done in case the new HBIOS requires updated versions of the Boot Loader or OS to run. The Boot Loader is aware of this boot mode and automatically adapts it\u2019s menu appropriately. If you restart your system, then it will revert to a ROM Boot from the currently installed ROM.","title":"Application Boot"},{"location":"SystemGuide/#ram-boot","text":"Some hardware supported by RomWBW has a special mechanism for loading the boot and HBIOS code. These systems have no ROM chips. However, they have a small hardware bootstrap that loads a chunk of code from a disk device directly into RAM at system startup. The startup then proceeds very much like the Application Boot process described above. HBIOS is installed in its operating bank and control is passed to the Boot Loader.","title":"RAM Boot"},{"location":"SystemGuide/#boot-recovery","text":"To assist users when driver faults or mis-configuration causes a boot failure, RomWBW supports a limited recovery capability. This is achieved by allowing the user to reboot their machine, loading a minimal driver set. Implementation of this feature requires a hardware input \u201cBOOT RECOVERY\u201d button to be available and appropriate software configuration to be completed in the HBIOS. When implemented, holding the \u201cBOOT RECOVERY\u201d button in after a reset or power cycle will cause the normal driver load process to be skipped in preference to a minimal set of drivers being loaded. Typically this would be: Serial communication, RAM disk and parallel port IDE interface drivers. Platforms supporting this option currently are the MBC, Duodyne and latter version of the SBC.","title":"Boot Recovery"},{"location":"SystemGuide/#configuration","text":"","title":"Configuration"},{"location":"SystemGuide/#romwbw-nvram-configuration","text":"On systems with RTC devices (that have Non-Volatile RAM), RomWBW supports storing some limited configuration option options inside this RAM. Several configuration options are currently supported; these are known as Switches. The following switch ID\u2019s are defined, and described in sections below. Switch Number Name Description 0x00 -reserved- Reserved 0x01 Boot Options ROM or Disk Boot Settings 0x02 -n/a- -n/a- high order byte of previous switch 0x03 Auto Boot Automatically boot enabled without user input 0x04 - 0xFE -future- Future general usage 0xFF Status Reset Get Status or Reset Switches to Default RomWBW uses bytes located at the start of RTC NVRAM, and includes a Parity check of the bytes in NVRAM to check for authenticity before using the configuration. NVRAM Byte Name Description 0x00 Header Byte Header Signature Byte \u2018W\u2019 0x01 - 0x03 Switch Data Actual Switch Data 0x04 Parity Check Checksum byte to check integrity The above data is copied into the HBIOS Configuration Block (HCB) at startup at the location starting at CB_SWITCHES.","title":"RomWBW NVRAM Configuration"},{"location":"SystemGuide/#boot-options-nvsw_bootopts","text":"16 bit Switch defining the ROM application or Disk device to boot if automatic booting is enabled. Bit 15 Bits 14-8 Bits 7-0 1 = ROM App -undefined- App to Boot (Char) 0 = Disk Disk Unit (0-127) Disk Slice (0-255)","title":"Boot Options (NVSW_BOOTOPTS)"},{"location":"SystemGuide/#auto-boot-nvsw_autoboot","text":"8 bit Switch defining if the system should auto boot at startup. Bits 7-6 Bit 5 Bit 4 Bits 3-0 -unused- 1 = Auto Boot Enabled -unused- 0 = Immediate Boot with no delay -unused- 1 = Auto Boot Enabled -unused- (1-15) Timeout (seconds) before boot -unused- 0 = Auto Boot Disabled -unused- -undefined-","title":"Auto Boot (NVSW_AUTOBOOT)"},{"location":"SystemGuide/#status-reset-0xff","text":"The Status Reset switch is not a general purpose switch, it is a control mechanism to allow the global status of all switches to be determined. The meaning of the switch is different for Read (Get Status) and Write (Reset NVRAM)","title":"Status Reset (0xFF)"},{"location":"SystemGuide/#get-get-status","text":"The read Get Status of switches. This returns very specific values from the function call. Status A Register Z / NZ Flag NVRAM does not exist A=0 NZ flag set NVRAM exists, but has not been initialised A=1 NZ flag set NVRAM exists, and has been fully initialised A=\u2018W\u2019 Z flag set","title":"GET (Get Status)"},{"location":"SystemGuide/#set-reset-nvram","text":"Reset NVRAM to default values. This will wipe any existing data and set default values into NVRAM.","title":"SET (Reset NVRAM)"},{"location":"SystemGuide/#driver-model","text":"The framework code for bank switching also allows hardware drivers to be implemented mostly without concern for memory management. Drivers are coded to simply implement the HBIOS functions appropriate for the type of hardware being supported. When the driver code gets control, it has already been mapped to the CPU address space and simply performs the requested function based on parameters passed in registers. Upon return, the bank switching framework takes care of restoring the original memory layout expected by the operating system and application. Drivers do need to be aware of the bank switching if a buffer address is being used in the function call. If the buffer address is in the lower 32K of RAM, then the memory it points to will be from the User Bank, not the HBIOS bank which is now active. In this case, the driver must use an inter-bank copy to access the data. If the buffer address is in the top 32K of RAM, then the driver will have access to it directly even after a bank switch, so no special steps are required. For some functions, the location of the buffer is required to be in the top 32K of RAM to simplify the operation of the driver. It is usually better if the OS or application calling a buffered function places the buffer in the top 32K because this may avoid a double-copy operation. If driver code must make calls to other code, drivers, or utilities in the HBIOS bank, it must make those calls directly (it must not use RST 08). This is to avoid a nested bank switch which is not supported at this time.","title":"Driver Model"},{"location":"SystemGuide/#character-emulation-video-services","text":"In addition to a generic set of routines to handle typical character input/output, HBIOS also includes functionality for managing built-in video display adapters. To start with there is a basic set of character input/output functions, the CIOXXX functions, which allow for simple character data streams. These functions fully encompass routing byte stream data to/from serial ports. Note that there is a special character pseudo-device called \u201cCRT\u201d. When characters are read/written to/from the CRT character device, the data is actually passed to a built-in terminal emulator which, in turn, utilizes a set of VDA (Video Display Adapter) functions (such as cursor positioning, scrolling, etc.). Figure 9.1 depicts the relationship between these components of HBIOS video processing: Character / Emulation / Video Services Normally, the operating system will simply utilize the CIOXXX functions to send and receive character data. The Character I/O Services will route I/O requests to the specified physical device which is most frequently a serial port (such as UART or ASCI). As shown above, if the CRT device is targeted by a CIOXXX function, it will actually be routed to the Emulation Services which implement TTY, ANSI, etc. escape sequences. The Emulation Services subsequently rely on the Video Display Adapter Services as an additional layer of abstraction. This allows the emulation code to be completely unaware of the actual physical device (device independent). Video Display Adapter (VDA) Services contains drivers as needed to handle the available physical video adapters. Note that the Emulation and VDA Services API functions are available to be called directly. Doing so must be done carefully so as to not corrupt the \u201cstate\u201d of the emulation logic. Before invoking CIOXXX functions targeting the CRT device, it is necessary that the underlying layers (Emulation and VDA) be properly initialized. The Emulation Services must be initialized to specify the desired emulation and specific physical VDA device to target. Likewise, the VDA Services may need to be initialized to put the specific video hardware into the proper mode, etc.","title":"Character / Emulation / Video Services"},{"location":"SystemGuide/#hbios-reference","text":"","title":"HBIOS Reference"},{"location":"SystemGuide/#invocation","text":"HBIOS functions are invoked by placing the required parameters in CPU registers and executing an RST 08 instruction. Note that HBIOS does not preserve register values that are unused. However, the values of the Z80 alternate registers and IX/IY will be preserved (these registers may be used within HBIOS, but will be saved and restored internally). An alternate method of invoking HBIOS functions is to use CALL $FFF0 . Since the RST 08 vector exists in page zero of the CPU address space, it may be paged out when alternate memory banks are selected. If this may be true when you are invoking a function, you should use the CALL method. Normally, applications will not call HBIOS functions directly. It is intended that the operating system makes all HBIOS function calls. Applications that are considered system utilities may use HBIOS, but must be careful not to modify the operating environment in any way that the operating system does not expect. In general, the desired function is placed in the B register. Register C is frequently used to specify a sub-function or a target device unit number. Additional registers are used as defined by the specific function. Register A should be used to return function result information. See below for result code definitions. The character, disk, and video device functions all refer to target devices using a logical device unit number that is passed in the C register. Keep in mind that these unit numbers are assigned dynamically at HBIOS initialization during the device discovery process. The assigned unit numbers are displayed on the console at the conclusion of device initialization. The unit assignments will never change after HBIOS initialization. However, they can change at the next boot if there have been hardware or BIOS customization changes. Code using HBIOS functions should not assume fixed unit assignments. Some functions utilize pointers to memory buffers. Unless otherwise stated, such buffers can be located anywhere in the Z80 CPU 64K address space. However, performance sensitive buffers (primarily disk I/O buffers) will require double-buffering if the caller\u2019s buffer is in the lower 32K of CPU address space. For optimal performance, such buffers should be placed in the upper 32K of CPU address space. HBIOS also implements a small number of core functions in the HBIOS proxy area at the top of RAM. These exist primarily to facilitate the operation of normal HBIOS function calls. However, they are available to be used by OSes and applications. These functions can only be invoked by calling into a jump table in upper RAM.","title":"Invocation"},{"location":"SystemGuide/#result-codes","text":"The following function result codes are defined generically for all HBIOS functions. Most function calls will return a result in register A. Code Definition 0 function succeeded -1 undefined error -2 function not implemented -3 invalid function -4 invalid unit number -5 out of memory -6 parameter out of range -7 media not present -8 hardware not present -9 I/O error -10 write request to read-only media -11 device timeout -12 invalid configuration","title":"Result Codes"},{"location":"SystemGuide/#character-inputoutput-cio","text":"Character Input/Output functions require that a Character Unit number be specified in register C. This is the logical device unit number assigned during the boot process that identifies all character devices uniquely. A special value of 0x80 can be used for the Character Unit to refer to the current console device. All character units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver CIODEV_UART 0x00 16C550 Family Serial Interface uart.asm CIODEV_ASCI 0x01 Z180 Built-in Serial Ports asci.asm CIODEV_TERM 0x02 Terminal ansi.asm CIODEV_PRPCON 0x03 PropIO Serial Console Interface prp.asm CIODEV_PPPCON 0x04 ParPortProp Serial Console Interface ppp.asm CIODEV_SIO 0x05 Zilog Serial Port Interface sio.asm CIODEV_ACIA 0x06 MC68B50 Asynchronous Interface acia.asm CIODEV_PIO 0x07 Zilog Parallel Interface Controller pio.asm CIODEV_UF 0x08 FT232H-based ECB USB FIFO uf.asm CIODEV_DUART 0x09 SCC2681 Family Dual UART duart.asm CIODEV_Z2U 0x0A Zilog Z280 Built-in Serial Ports z2u.asm CIODEV_LPT 0x0B Parallel I/O Controller lpt.asm CIODEV_ESPCON 0x0C ESP32 VGA Console esp.asm CIODEV_ESPSER 0x0D ESP32 Serial Port esp.asm CIODEV_SCON 0x0E S100 Console scon.asm CIODEV_SSER 0x0F Simple Serial Console sser.asm CIODEV_EZ80UART 0x10 eZ80 Built-in UART0 Interface ez80uart.asm Character devices can usually be configured with line characteristics such as speed, framing, etc. A word value (16 bit) is used to describe the line characteristics as indicated below: Bits Characteristic 15-14 Reserved (set to 0) 13 RTS 12-8 Baud Rate (see below) 7 DTR 6 XON/XOFF Flow Control 5 1 = Stick Parity(Mark/Space), 0 = Normal Parity (odd/even) 4 1 = Even/Space, 0 = Odd/Mark 3 Parity Enable (set for true) 2 Stop Bits (set for true) 1-0 Data Bits (5-8 encoded as 0-3) The 5-bit Baud Rate value (V) is encoded as V = 75 * 2^X * 3^Y. The bits are defined as YXXXX. Actual character values are a single byte (8 bits). The Character I/O functions do not modify or interpret the values being sent/received so they can be used to pass 8-bit binary data without corruption. Note that some OSes will modify character data (truncate to 7 bits, etc.).","title":"Character Input/Output (CIO)"},{"location":"SystemGuide/#function-0x00-character-input-cioin","text":"Entry Parameters Returned Values B: 0x00 A: Status C: Character Unit E: Character Read and return a Character (E) from the specified Character Unit (C). If no character(s) are available in the unit\u2019s input buffer, this function will wait indefinitely. The returned Status (A) is a standard HBIOS result code.","title":"Function 0x00 \u2013 Character Input (CIOIN)"},{"location":"SystemGuide/#function-0x01-character-output-cioout","text":"Entry Parameters Returned Values B: 0x01 A: Status (0-OK, else error) C: Character Unit E: Character Send a Character (E) via the specified Character Unit (C). If there is no space available in the unit\u2019s output buffer, the function will wait indefinitely. The returned Status (A) is a standard HBIOS result code.","title":"Function 0x01 \u2013 Character Output (CIOOUT)"},{"location":"SystemGuide/#function-0x02-character-input-status-cioist","text":"Entry Parameters Returned Values B: 0x02 A: Status / Characters Pending C: Character Unit Return the count of Characters Pending (A) in the input buffer of the specified Character Unit (C). If the unit has no input buffer or the buffer utilization is not available, the function may return simply 0 or 1 where 0 means there is no character available and 1 means there is at least one character available. The value returned in register A is used as both a Status (A) code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the number of characters in the input buffer.","title":"Function 0x02 \u2013 Character Input Status (CIOIST)"},{"location":"SystemGuide/#function-0x03-character-output-status-cioost","text":"Entry Parameters Returned Values B: 0x03 A: Status / Space Free C: Character Unit Return the count of buffer Space Free (A) for the specified Character Unit (C). For example, if a 16 byte output buffer contains 6 characters waiting to be sent out the unit\u2019s serial interface, this function would return 10; the number of positions available in the output buffer. If the port has no output buffer or the buffer utilization is not available, the function may return simply 0 or 1 where 0 means there is no buffer space available and 1 means there is space in the output buffer for at least one character. The return value in register A is used as both a status code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the buffer space available.","title":"Function 0x03 \u2013 Character Output Status (CIOOST)"},{"location":"SystemGuide/#function-0x04-character-io-initialization-cioinit","text":"Entry Parameters Returned Values B: 0x04 A: Status C: Character Unit DE: Line Characteristics Condition the interface of the specified Character Unit (C) according to the specified Line Characteristics (DE). The definition of the line characteristics value is described above. If DE contains -1 (0xFFFF), then the device will be reinitialized with the previous line characteristics used (a reset) and any buffer contents will be flushed. The Status (A) is a standard HBIOS result code. Not all line characteristics are supported by all character interfaces. It is up to the driver of the character unit to decide how to deal with characteristics that are not available. For example, many character drivers do not allow flow control settings (RTS/CTS, XON/XOFF) to be modified dynamically. In most cases, these settings are ignored by the driver in this function call.","title":"Function 0x04 \u2013 Character I/O Initialization (CIOINIT)"},{"location":"SystemGuide/#function-0x05-character-io-query-cioquery","text":"Entry Parameters Returned Values B: 0x05 A: Status C: Character Unit DE: Line Characteristics Returns the current Line Characteristics (DE) of the specified Character Unit (C). The definition of the line characteristics value is described above. The returned status (A) is a standard HBIOS result code.","title":"Function 0x05 \u2013 Character I/O Query (CIOQUERY)"},{"location":"SystemGuide/#function-0x06-character-io-device-ciodevice","text":"Entry Parameters Returned Values B: 0x06 A: Status C: Character Unit C: Device Attributes D: Device Type E: Device Number H: Device Mode L: Device I/O Base Address Returns device information for the specified Character Unit (C). The status (A) is a standard HBIOS result code. The two high bits of Device Attribute (C) are: 00 = RS/232, 01 = Terminal, 10 = Parallel. The remaining bits should be ignored and are used internally. Device Type (D) indicates the specific hardware driver that handles the specified Character Unit. Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. For example, a Device Type of 0x50 with a Device Number of 2 refers to the third port being handled by the SIO driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. For example, for a UART, the value indicates the chip variant. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used.","title":"Function 0x06 \u2013 Character I/O Device (CIODEVICE)"},{"location":"SystemGuide/#disk-inputoutput-dio","text":"Disk Input/Output functions require that a Disk Unit number be specified in register C. This is the logical device unit number assigned during the boot process that identifies all disk devices uniquely. All character units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates their values. Device Type ID Description Driver DIODEV_MD 0x00 Memory Disk md.asm DIODEV_FD 0x01 Floppy Disk fd.asm DIODEV_RF 0x02 RAM Floppy rf.asm DIODEV_IDE 0x03 IDE Disk ide.asm DIODEV_ATAPI 0x04 ATAPI Disk (not implemented) DIODEV_PPIDE 0x05 PPIDE Disk ppide.asm DIODEV_SD 0x06 SD Card sd.asm DIODEV_PRPSD 0x07 PropIO SD Card prp.asm DIODEV_PPPSD 0x08 ParPortProp SD Card ppp.asm DIODEV_HDSK 0x09 SIMH HDSK Disk hdsk.asm DIODEV_PPA 0x0A Iomega PPA Disk ppa.asm DIODEV_IMM 0x0B Iomega IMM Disk imm.asm DIODEV_SYQ 0x0C Syquest Sparq Disk syq.asm DIODEV_CHUSB 0x0D CH375/376 USB Disk ch.asm DIODEV_CHSD 0x0E CH375/376 SD Card ch.asm A fixed set of media types are defined. The currently defined media types identifiers are listed below. Each driver will support one or more of the defined media types. Media ID Format MID_NONE 0 No media installed MID_MDROM 1 ROM Drive MID_MDRAM 2 RAM Drive MID_RF 3 RAM Floppy (LBA) MID_HD 4 Hard Disk (LBA) w/ 512 directory entries MID_FD720 5 3.5\u201d 720K Floppy MID_FD144 6 3.5\u201d 1.44M Floppy MID_FD360 7 5.25\u201d 360K Floppy MID_FD120 8 5.25\u201d 1.2M Floppy MID_FD111 9 8\u201d 1.11M Floppy MID_HDNEW 10 Hard Disk (LBA) w/ 1024 directory entries NOTE : HBIOS typically does not actually differentiate between MID_HD and MID_HDNEW, it will generally only use MID_HD. See the section Mapping to Media ID for information on this. HBIOS supports both Cylinder/Head/Sector (CHS) and Logical Block Addresses (CHS) when locating a sector for I/O (see DIOSEEK function). For devices that are natively CHS (e.g., floppy disk), the HBIOS driver can convert LBA values to CHS values according to the geometry of the current media. For devices that are natively LBA (e.g., hard disk), the HBIOS driver simulates CHS using a fictitious geometry provided by the driver (typically 16 sectors per track and 16 heads per cylinder).","title":"Disk Input/Output (DIO)"},{"location":"SystemGuide/#function-0x10-disk-status-diostatus","text":"Entry Parameters Returned Values B: 0x10 A: Status C: Disk Unit Returns the driver specific Status (A) of the specified disk device unit (C) based on the last operation performed. The return value in register A is used as both a device status and a standard HBIOS result code. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents a driver-specific device status. In all cases, the value 0 means OK.","title":"Function 0x10 \u2013 Disk Status (DIOSTATUS)"},{"location":"SystemGuide/#function-0x11-disk-reset-dioreset","text":"Entry Parameters Returned Values B: 0x11 A: Status C: Disk Unit This function performs a device dependent reset operation on the Disk Unit specified (C). The driver will clear any error status on the disk unit, attempt to reset the interface, and flag the disk unit for initialization on the next I/O function call. Any prior media identification will be cleared. The returned Status (A) is a standard HBIOS result code. If the specified disk unit (C) is one of multiple units on a single hardware bus, then all units on that bus will be reset. For example, if the master disk on an IDE bus is reset, then the slave disk will also be reset.","title":"Function 0x11 \u2013 Disk Reset (DIORESET)"},{"location":"SystemGuide/#function-0x12-disk-seek-dioseek","text":"Entry Parameters Returned Values B: 0x12 A: Status C: Disk Unit DEHL: Sector Address This function will set the desired sector to be used for the next I/O operation on the specified Disk Unit (C). The returned Status (A) is a standard HBIOS result code. An actual seek operation is generally not performed on the disk hardware by this function. The function typically just records the sector address for subsequent I/O function calls. The double-word Sector Address (DEHL) can represent either a Logical Block Address (LBA) or a Cylinder/Head/Sector (CHS). Bit 7 of D is set (1) for LBA mode and cleared (0) for CHS mode. For LBA mode operation, the high bit is set and the rest of the double-word is then treated as the logical sector address. For CHS mode operation, the Sector Address (DEHL) registers are interpreted as: D=Head, E=Sector, and HL=Track. All values (including sector) are 0 relative. Prior versions of the floppy driver did not accept LBA mode addresses. However, this restriction has been removed as of HBIOS v3.1. At this point, all disk drivers support both LBA and CHS addressing.","title":"Function 0x12 \u2013 Disk Seek (DIOSEEK)"},{"location":"SystemGuide/#function-0x13-disk-read-dioread","text":"Entry Parameters Returned Values B: 0x13 A: Status C: Disk Unit E: Sectors Read D: Buffer Bank ID E: Sector Count HL: Buffer Address Read Sector Count (E) sectors into the buffer located in Buffer Bank ID (D) at Buffer Address (HL) starting at the Current Sector. The returned Status (A) is a standard HBIOS result code. The Current Sector is established by a prior DIOSEEK function call; however, multiple read/write/verify function calls can be made after a seek function. The Current Sector is incremented after each sector successfully read. On error, the Current Sector will be the sector where the error occurred. Sectors Read (E) indicates the number of sectors successfully read. The caller must ensure that the Buffer Address is large enough to contain all sectors requested. Disk data transfers will be faster if the buffer resides in the top 32K of memory because it avoids a double buffer copy. Also for buffers in the top 32K of memory the Bank ID is not strictly required as this memory is alway mapped to the common bank. For buffers in the bottom 32KB ram, the Bank ID is used to identify the bank to use for the buffer. If you do not wih to use banked memory you will need to provide the current Bank ID, which can be obtained using Function 0xF3 \u2013 System Get Bank (SYSGETBNK)","title":"Function 0x13 \u2013 Disk Read (DIOREAD)"},{"location":"SystemGuide/#function-0x14-disk-write-diowrite","text":"Entry Parameters Returned Values B: 0x14 A: Status C: Disk Unit E: Sectors Written D: Buffer Bank ID E: Sector Count HL: Buffer Address Write Sector Count (E) sectors from the buffer located in Buffer Bank ID (D) at Buffer Address (HL) starting at the Current Sector. The returned Status (A) is a standard HBIOS result code. The Current Sector is established by a prior DIOSEEK function call; however, multiple read/write/verify function calls can be made after a seek function. The Current Sector is incremented after each sector successfully written. On error, the Current Sector will be the sector where the error occurred. Sectors Written (E) indicates the number of sectors successfully written. Disk data transfers will be faster if the buffer resides in the top 32K of memory because it avoids a double copy.","title":"Function 0x14 \u2013 Disk Write (DIOWRITE)"},{"location":"SystemGuide/#function-0x15-disk-verify-dioverify","text":"Entry Parameters Returned Values B: 0x15 A: Status C: Disk Unit E: Sectors Verified E: Sector Count *** Function Not Implemented ***","title":"Function 0x15 \u2013 Disk Verify (DIOVERIFY)"},{"location":"SystemGuide/#function-0x16-disk-format-dioformat","text":"Entry Parameters Returned Values B: 0x16 A: Status C: Disk Unit D: Head E: Fill Byte HL: Cylinder *** Function Not Implemented ***","title":"Function 0x16 \u2013 Disk Format (DIOFORMAT)"},{"location":"SystemGuide/#function-0x17-disk-device-diodevice","text":"Entry Parameters Returned Values B: 0x17 A: Status C: Disk Unit C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Reports device information about the specified Disk Unit (C). The Status (A) is a standard HBIOS result code. The Device Attribute (C) value returned indicates various feature indicators related to the device being referenced by the specified Disk Unit (C). The high 3 bits apply to all devices. The definition of the low 5 bits depends on whether the device is a Floppy (indicated by bit 5). The common bits are: Bits Definition 7 Floppy 6 Removable 5 High Capacity (>8 MB) The Floppy specific bits are: Bits Definition 4-3 Form Factor: 0=8\u201d, 1=5.25\u201d, 2=3.5\u201d, 3=Other 2 Sides: 0=SS, 1=DS 1-0 Density: 0=SD, 1=DD, 2=HD, 3=ED The non-Floppy specific bits are: Bits Definition 4 LBA Capable 3-0 Media Type: 0=Hard Disk, 1=CF, 2=SD, 3=USB, 4=ROM, 5=RAM, 6=FLASH, 7=RAMF, 8=CD-ROM, 9=Cartridge Device Type (D) indicates the specific hardware driver that handles the specified Disk Unit (C). Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. For example, a Device Type of 0x30 with a Device Number of 1 refers to the second disk being handled by the IDE driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. For example, for an IDE unit, the value indicates the IDE circuit variant. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used.","title":"Function 0x17 \u2013 Disk Device (DIODEVICE)"},{"location":"SystemGuide/#function-0x18-disk-media-diomedia","text":"Entry Parameters Returned Values B: 0x18 A: Status C: Disk Unit E: Media ID E: Flags Report the Media ID (E) for the for media in the specified Disk Unit (C). If bit 0 of Flags (E) is set, then media discovery or verification will be performed. The Status (A) is a standard HBIOS result code. If there is no media in device, function will return an error status. NOTE : This function will always return MID_HD for hard disk devices. See the section Mapping to Media ID for information on this. To determine if an HD1K formatted partition exists on the hard disk please see the following function. Function 0xE0 \u2013 Calculate Slice (EXTSLICE)","title":"Function 0x18 \u2013 Disk Media (DIOMEDIA)"},{"location":"SystemGuide/#function-0x19-disk-define-media-diodefmed","text":"Entry Parameters Returned Values B: 0x19 A: Status C: Disk Unit E: Media ID *** Function Not Implemented ***","title":"Function 0x19 \u2013 Disk Define Media (DIODEFMED)"},{"location":"SystemGuide/#function-0x1a-disk-capacity-diocapacity","text":"Entry Parameters Returned Values B: 0x1A A: Status C: Disk Unit DEHL: Sector Count BC: Block Size Report the current media capacity information for the specified Disk Unit (C). The Sector Count (DEHL) is a double-word number representing the total number of blocks on the device. Block Size (BC) contains the block size in bytes. The Status (A) is a standard HBIOS result code. If the media is unknown, an error will be returned. This function will not attempt to discover or verify the media loaded in the unit specified. You can use precede this function with the DIOMEDIA function to force this if desired.","title":"Function 0x1A \u2013 Disk Capacity (DIOCAPACITY)"},{"location":"SystemGuide/#function-0x1b-disk-geometry-diogeometry","text":"Entry Parameters Returned Values B: 0x1B A: Status C: Disk Unit D: Heads / LBA E: Sectors HL: Cylinder Count BC: Block Size Report the geometry for the media in the specified Disk Unit (C). If a device uses LBA mode addressing natively, then the drivers simulated geometry will be returned. The Status (A) is a standard HBIOS result code. If the media is unknown, an error will be returned. LBA capability is indicated by D:7. When set, the device is capable of LBA addressing. Refer to Function 0x12 \u2013 Disk Seek (DIOSEEK) for more information on specifying LBA vs. CHS addresses. Heads (D:6-0) refers to the number of heads per cylinder. Sectors (E) refers to the number of sectors per track. Cylinder Count (HL) is the total number of cylinders addressable for the media. Block Size (BC) is the number of bytes in one sector.","title":"Function 0x1B \u2013 Disk Geometry (DIOGEOMETRY)"},{"location":"SystemGuide/#real-time-clock-rtc","text":"The Real Time Clock functions provide read/write access to the clock and related Non-Volatile RAM. HBIOS only supports a single RTC device since there is no reason to have more than one at a time. The RTC unit is assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver RTCDEV_DS 0x00 Maxim DS1302 Real-Time Clock w/ NVRAM dsrtc.asm RTCDEV_BQ 0x01 BQ4845P Real Time Clock bqrtc.asm RTCDEV_SIMH 0x02 SIMH Simulator Real-Time Clock simrtc.asm RTCDEV_INT 0x03 Interrupt-based Real Time Clock intrtc.asm RTCDEV_DS7 0x04 Maxim DS1307 PCF I2C RTC w/ NVRAM ds7rtc.asm RTCDEV_RP5 0x05 Ricoh RPC01A Real-Time Clock w/ NVRAM rp5rtc.asm RTCDEV_EZ80 0x07 eZ80 on-chip RTC ez80rtc.asm The time functions to get and set the time (RTCGTM and RTCSTM) require a 6 byte date/time buffer in the following format. Each byte is BCD encoded. Offset Contents 0 Year (00-99) 1 Month (01-12) 2 Date (01-31) 3 Hours (00-24) 4 Minutes (00-59) 5 Seconds (00-59)","title":"Real Time Clock (RTC)"},{"location":"SystemGuide/#function-0x20-rtc-get-time-rtcgettim","text":"Entry Parameters Returned Values B: 0x20 A: Status HL: Date/Time Buffer Address Read the current value of the real-time clock and store the date/time in the Date/Time Buffer pointed to by HL. The Status (A) is a standard HBIOS result code.","title":"Function 0x20 \u2013 RTC Get Time (RTCGETTIM)"},{"location":"SystemGuide/#function-0x21-rtc-set-time-rtcsettim","text":"Entry Parameters Returned Values B: 0x21 A: Status HL: Date/Time Buffer Address Set the current value of the real-time clock based on the Date/Time Buffer pointed to by HL. The Status (A) is a standard HBIOS result code.","title":"Function 0x21 \u2013 RTC Set Time (RTCSETTIM)"},{"location":"SystemGuide/#function-0x22-rtc-get-nvram-byte-rtcgetbyt","text":"Entry Parameters Returned Values B: 0x22 A: Status C: Index E: Value Read a single byte Value (E) from the Non-Volatile RAM of the RTC at the byte offset Index (C). The Status (A) is a standard HBIOS result code.","title":"Function 0x22 \u2013 RTC Get NVRAM Byte (RTCGETBYT)"},{"location":"SystemGuide/#function-0x23-rtc-set-nvram-byte-rtcsetbyt","text":"Entry Parameters Returned Values B: 0x23 A: Status C: Index E: Value Set a single byte Value (E) of the Non-Volatile RAM of the RTC at the byte offset Index (C). The Status (A) is a standard HBIOS result code.","title":"Function 0x23 \u2013 RTC Set NVRAM Byte (RTCSETBYT)"},{"location":"SystemGuide/#function-0x24-rtc-get-nvram-block-rtcgetblk","text":"Entry Parameters Returned Values B: 0x24 A: Status HL: Buffer Address Read the entire contents of the Non-Volatile RAM into to a buffer pointed to by Buffer Address (HL). The Status (A) is a standard HBIOS result code.","title":"Function 0x24 \u2013 RTC Get NVRAM Block (RTCGETBLK)"},{"location":"SystemGuide/#function-0x25-rtc-set-nvram-block-rtcsetblk","text":"Entry Parameters Returned Values B: 0x25 A: Status HL: Buffer Address Write the entire contents of the Non-Volatile RAM from the buffer pointed to by Buffer Address (HL). The Status (A) is a standard HBIOS result code.","title":"Function 0x25 \u2013 RTC Set NVRAM Block (RTCSETBLK)"},{"location":"SystemGuide/#function-0x26-rtc-get-alarm-rtcgetalm","text":"Entry Parameters Returned Values B: 0x26 A: Status HL: Date/Time Buffer Address Work in progress, documentation required\u2026","title":"Function 0x26 \u2013 RTC Get Alarm (RTCGETALM)"},{"location":"SystemGuide/#function-0x27-rtc-set-alarm-rtcsetalm","text":"Entry Parameters Returned Values B: 0x27 A: Status HL: Date/Time Buffer Address Work in progress, documentation required\u2026","title":"Function 0x27 \u2013 RTC Set Alarm (RTCSETALM)"},{"location":"SystemGuide/#function-0x28-rtc-device-rtcdevice","text":"Entry Parameters Returned Values B: 0x28 A: Status C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Returns device information for the RTC unit. The Status (A) is a standard HBIOS result code. Device Attribute (C) values are not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified character unit. Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver which is always 0 for RTC. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used.","title":"Function 0x28 \u2013 RTC DEVICE (RTCDEVICE)"},{"location":"SystemGuide/#display-keypad-dsky","text":"The Display Keypad functions provide access to a segment or LCD style display and associated optional keypad HBIOS only supports a single DSKY device since there is no reason to have more than one at a time. If the system contains multiple DSKY devices, only the first device discovered will be used. The DSKY unit is assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver DSKYDEV_ICM 0x01 Original ICM7218 based DSKY icm.asm DSKYDEV_PKD 0x02 Next Gen Intel P8279 based DSKY pkd.asm DSKYDEV_GM7303 0x03 GM7303 LCD Display + Keypad gm7303.asm DSKYDEV_LCD 0x04 HD44780-based LCD Display lcd.asm The keypad keys are identified by the following key ids. Not all keypads will contain all keys. Key Id Key Definition Key Id Key Definition \\$00 Hex Numeric 0 \\$10 Forward \\$01 Hex Numeric 1 \\$11 Backward \\$02 Hex Numeric 2 \\$12 Clear \\$03 Hex Numeric 3 \\$13 Enter \\$04 Hex Numeric 4 \\$14 Deposit \\$05 Hex Numeric 5 \\$15 Examine \\$06 Hex Numeric 6 \\$16 Go \\$07 Hex Numeric 7 \\$17 Boot \\$08 Hex Numeric 8 \\$18 F4 \\$09 Hex Numeric 9 \\$19 F3 \\$0A Hex Numeric A \\$1A F2 \\$0B Hex Numeric B \\$1B F1 \\$0C Hex Numeric C \\$0D Hex Numeric D \\$0E Hex Numeric E \\$0F Hex Numeric F","title":"Display Keypad (DSKY)"},{"location":"SystemGuide/#function-0x30-dsky-reset-dskyreset","text":"Entry Parameters Returned Values B: 0x30 A: Status This function performs a device dependent reset operation on the DSKY. The display will be cleared, keyboard queue will be flushed, and chip will be reinitialized. The returned Status (A) is a standard HBIOS result code.","title":"Function 0x30 \u2013 DSKY Reset (DSKYRESET)"},{"location":"SystemGuide/#function-0x31-dsky-dskystatus","text":"Entry Parameters Returned Values B: 0x31 A: Status / Characters Pending Return the count of Characters Pending (A) in the input buffer of the DSKY. If the unit has no input buffer or the buffer utilization is not available, the function may return simply 0 or 1 where 0 means there is no character available and 1 means there is at least one character available. The value returned in register A is used as both a Status (A) code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the number of characters in the buffer.","title":"Function 0x31 \u2013 DSKY (DSKYSTATUS)"},{"location":"SystemGuide/#function-0x32-dsky-get-key-dskygetkey","text":"Entry Parameters Returned Values B: 0x32 A: Status E: Character Value Read and return a Character (E) from the DSKY. If no character(s) are available in the unit\u2019s input buffer, this function will wait indefinitely. The returned Status (A) is a standard HBIOS result code. The Character Value (E) returned is not ASCII. It is a keypad key id. The possible id values are listed at the start of this section.","title":"Function 0x32 \u2013 DSKY Get Key (DSKYGETKEY)"},{"location":"SystemGuide/#function-0x33-dsky-show-hex-rtcshowhex","text":"Entry Parameters Returned Values B: 0x33 A: Status DE:HL=Binary Value Display the 32-bit binary value (DE:HL) in hex on the DSKY segment display. All decimal points of the display will be off. The Status (A) is a standard HBIOS result code.","title":"Function 0x33 \u2013 DSKY Show HEX (RTCSHOWHEX)"},{"location":"SystemGuide/#function-0x34-dsky-show-segments-dskyshowseg","text":"Entry Parameters Returned Values B: 0x34 A: Status HL: Buffer Address Display the segment-encoded values on the segment display. The encoding uses a small alphabet as defined below. The actual representation of a character is determined by the driver. The entire display is updated and it is assumed that an 8 character buffer will be pointed to by HL. The buffer must reside in high memory. The Status (A) is a standard HBIOS result code. 0x00: \u20180\u2019 0x01: \u20181\u2019 0x02: \u20182\u2019 0x03: \u20183\u2019 0x04: \u20184\u2019 0x05: \u20185\u2019 0x06: \u20186\u2019 0x07: \u20187\u2019 0x08: \u20188\u2019 0x09: \u20189\u2019 0x0A: \u2018A\u2019 0x0B: \u2018B\u2019 0x0C: \u2018C\u2019 0x0D: \u2018D\u2019 0x0E: \u2018E\u2019 0x0F: \u2018F\u2019 0x10: \u2019 \u2019 0x11: \u2018-\u2019 0x12: \u2018.\u2019 0x13: \u2018p\u2019 0x14: \u2018o\u2019 0x15: \u2018r\u2019 0x16: \u2018t\u2019 0x17: \u2018A\u2019 0x18: \u2018d\u2019 0x19: \u2018r\u2019 0x1A: \u2018G\u2019","title":"Function 0x34 \u2013 DSKY Show Segments (DSKYSHOWSEG)"},{"location":"SystemGuide/#function-0x35-dsky-keypad-leds-dskykeyleds","text":"Entry Parameters Returned Values B: 0x35 A: Status HL: Buffer Address Light the LEDs for the keypad keys according to the bitmap contained in the buffer pointed to by HL. The buffer must be located in high memory and is assumed to be 8 bytes. At this time, the bitmap is specific to the PKD hardware and will be ignored by all other hardware.","title":"Function 0x35 \u2013 DSKY Keypad LEDs (DSKYKEYLEDS)"},{"location":"SystemGuide/#function-0x36-dsky-status-led-dskystatled","text":"Entry Parameters Returned Values B: 0x36 A: Status D: LED Number E: LED State Set or clear the status LED specified in D. The state of the LED is contained in E. If E=0, the LED will be turned off. If E=1, the LED will be turned on. This function is specific to the PKD hardware and will be ignored by all other hardware. The Status (A) is a standard HBIOS result code.","title":"Function 0x36 \u2013 DSKY Status LED (DSKYSTATLED)"},{"location":"SystemGuide/#function-0x37-dsky-beep-dskybeep","text":"Entry Parameters Returned Values B: 0x37 A: Status Beep the onboard speaker of the DSKY. This function is specific to the PKD hardware. It will be ignored by the ICM hardware. The Status (A) is a standard HBIOS result code.","title":"Function 0x37 \u2013 DSKY Beep (DSKYBEEP)"},{"location":"SystemGuide/#function-0x38-dsky-device-dskydevice","text":"Entry Parameters Returned Values B: 0x38 A: Status C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Returns device information for the DSKY unit. The Status (A) is a standard HBIOS result code. Device Attribute (C) values are not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified character unit. Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver which is always 0 for DSKY. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used.","title":"Function 0x38 \u2013 DSKY Device (DSKYDEVICE)"},{"location":"SystemGuide/#function-0x39-dsky-device-dskymessage","text":"Entry Parameters Returned Values B: 0x39 A: Status C: Message ID Instructs the display to show a textual representation of the associated message on the display. The IDs are defined in std.asm.","title":"Function 0x39 \u2013 DSKY Device (DSKYMESSAGE)"},{"location":"SystemGuide/#function-0x3a-dsky-device-dskyevent","text":"Entry Parameters Returned Values B: 0x3A A: Status C: Event ID Instructs the display to update itself in response to an internal HBIOS state change. At this time the the events are: 0: CPU Speed Change 1: Disk Activity","title":"Function 0x3A \u2013 DSKY Device (DSKYEVENT)"},{"location":"SystemGuide/#video-display-adapter-vda","text":"The VDA functions are provided as a common interface to Video Display Adapters. Not all VDAs will include keyboard hardware. In this case, the keyboard functions should return a failure status. All video units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates their values. Device Type ID Description Driver VDADEV_VDU 0x00 MC6845 Family Video Display Controller vdu.asm VDADEV_CVDU 0x01 MC8563-based Video Display Controller cvdu.asm VDADEV_GDC 0x02 uPD7220 Video Display Controller gdc.asm VDADEV_TMS 0x03 TMS9918/38/58 Video Display Controller tms.asm VDADEV_VGA 0x04 HD6445CP4-based Video Display Controller vga.asm VDADEV_VRC 0x05 VGARC vrc.asm Depending on the capabilities of the hardware, the use of colors and attributes may or may not be supported. If the hardware does not support these capabilities, they will be ignored. Color byte values are constructed using typical RGBI (Red/Green/Blue/Intensity) bits. The high four bits of the value determine the background color and the low four bits determine the foreground color. This results in 16 unique color values for both foreground and background. The following table illustrates the color byte value construction: Bit Color Background 7 Intensity 6 Blue 5 Green 4 Red Foreground 3 Intensity 2 Blue 1 Green 0 Red The following table illustrates the resultant color for each of the possible 16 values for foreground or background: Foreground Background Color n0 nnnn0000 0n 0000nnnn Black n1 nnnn0001 1n 0001nnnn Red n2 nnnn0010 2n 0010nnnn Green n3 nnnn0011 3n 0011nnnn Brown n4 nnnn0100 4n 0100nnnn Blue n5 nnnn0101 5n 0101nnnn Magenta n6 nnnn0110 6n 0110nnnn Cyan n7 nnnn0111 7n 0111nnnn White n8 nnnn1000 8n 1000nnnn Gray n9 nnnn1001 9n 1001nnnn Light Red nA nnnn1010 An 1010nnnn Light Green nB nnnn1011 Bn 1011nnnn Yellow nC nnnn1100 Cn 1100nnnn Light Blue nD nnnn1101 Dn 1101nnnn Light Magenta nE nnnn1110 En 1110nnnn Light Cyan nF nnnn1111 Fn 1111nnnn Bright White Attribute byte values are constructed using the following bit encoding: Bit Effect 7 n/a (0) 6 n/a (0) 5 n/a (0) 4 n/a (0) 3 n/a (0) 2 Reverse 1 Underline 0 Blink The following codes are returned by a keyboard read to signify non-ASCII keystrokes: Value Keystroke Value Keystroke 0xE0 F1 0xF0 Insert 0xE1 F2 0xF1 Delete 0xE2 F3 0xF2 Home 0xE3 F4 0xF3 End 0xE4 F5 0xF4 PageUp 0xE5 F6 0xF5 PadeDown 0xE6 F7 0xF6 UpArrow 0xE7 F8 0xF7 DownArrow 0xE8 F9 0xF8 LeftArrow 0xE9 F10 0xF9 RightArrow 0xEA F11 0xFA Power 0xEB F12 0xFB Sleep 0xEC SysReq 0xFC Wake 0xED PrintScreen 0xFD Break 0xEE Pause 0xFE 0xEF App 0xFF","title":"Video Display Adapter (VDA)"},{"location":"SystemGuide/#function-0x40-video-initialize-vdaini","text":"Entry Parameters Returned Values B: 0x40 A: Status C: Video Unit E: Video Mode HL: Font Bitmap Performs a full (re)initialization of the specified Video Unit (C). The screen is cleared and the keyboard buffer is flushed. If the specified Video Unit (C) supports multiple video modes, a Video Mode (E) can be specified (set to 0 for default/not specified). Video Mode (E) values are specific to each VDA. The returned Status (A) is a standard HBIOS result code. If the hardware and driver supports it, you can specify a Font Bitmap (HL) buffer address containing the character bitmap data to be loaded into the video processor. The buffer must be located entirely in the top 32K of the CPU memory space. HL must be set to zero if no character bitmap is specified (the driver will utilize a default character bitmap).","title":"Function 0x40 \u2013 Video Initialize (VDAINI)"},{"location":"SystemGuide/#function-0x41-video-query-vdaqry","text":"Entry Parameters Returned Values B: 0x41 A: Status C: Video Unit C: Video Mode HL: Font Bitmap D: Rows E: Columns HL: Font Bitmap Return information about the specified Video Unit (C). Video Mode (C) will be set to the current video mode. Rows (D) and Columns (E) will return the dimensions of the video display as measured in rows and columns. Note that this is the count of rows and columns, not the last row/column number. The returned Status (A) is a standard HBIOS result code. If the hardware and driver support it, you can specify a Font Bitmap (HL) buffer address that will be filled with the current character bitmap data. The buffer must be located entirely in the top 32K of the CPU memory space. Font Bitmap (HL) must be set to zero if it does not point to a proper buffer area or memory corruption will result. If HL is not zero, it must point to a suitably sized memory buffer in the upper 32K of CPU address space that will be filled with the current character bitmap data. It is critical that HL be set to zero if it does not point to a proper buffer area or memory corruption will result. If the video device driver does not have the ability to provide character bitmap data, then Font Bitmap (HL) will be set to zero on return.","title":"Function 0x41 \u2013 Video Query (VDAQRY)"},{"location":"SystemGuide/#function-0x42-video-reset-vdares","text":"Entry Parameters Returned Values B: 0x42 A: Status C: Video Unit Performs a non-destructive reset of the specified Video Unit (C). Should re-initialize the video hardware without destroying the screen contents or cursor position. The current video mode will not be changed. The returned Status (A) is a standard HBIOS result code.","title":"Function 0x42 \u2013 Video Reset (VDARES)"},{"location":"SystemGuide/#function-0x43-video-device-vdadev","text":"Entry Parameters Returned Values B: 0x43 A: Status C: Video Unit C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Reports device information about the specified Video Unit (C). The Status (A) is a standard HBIOS result code. Device Attribute (C) values are not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified Video Unit (C). Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. For example, for an TMS video unit, the value indicates the TMS circuit variant. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used.","title":"Function 0x43 \u2013 Video Device (VDADEV)"},{"location":"SystemGuide/#function-0x44-video-set-cursor-style-vdascs","text":"Entry Parameters Returned Values B: 0x44 A: Status C: Video Unit D: Start/End E: Style If supported by the specified Video Unit (C), adjust the format of the cursor such that the cursor starts at the pixel specified in the top nibble of Start/End (D) and ends at the pixel specified in the bottom nibble of Start/End (D). So, if D=0x08, a block cursor would be used that starts at the top pixel of the character cell and ends at the ninth pixel of the character cell. The Status (A) is a standard HBIOS result code. Style (E) is reserved to control the style of the cursor (blink, visibility, etc.), but is not yet implemented. Adjustments to the cursor style may or may not be possible for any given video hardware and may be dependent on the active video mode.","title":"Function 0x44 \u2013 Video Set Cursor Style (VDASCS)"},{"location":"SystemGuide/#function-0x45-video-set-cursor-position-vdascp","text":"Entry Parameters Returned Values B: 0x45 A: Status C: Video Unit D: Row E: Column Reposition the cursor of the specified Video Unit (C) to the specified Row (D) and Column (E). Specifying a row/column that exceeds the boundaries of the display results in undefined behavior. Cursor coordinates are 0 based (0,0 is the upper left corner of the display). The Status (A) is a standard HBIOS result code.","title":"Function 0x45 \u2013 Video Set Cursor Position (VDASCP)"},{"location":"SystemGuide/#function-0x46-video-set-character-attribute-vdasat","text":"Entry Parameters Returned Values B: 0x46 A: Status C: Video Unit E: Attribute Assign the specified character Attribute (E) code to be used for all subsequent character writes/fills on the specified Video Unit (C). This attribute is used to fill new lines generated by scroll operations. The character attributes values are listed above. Note that a given video display may or may not support any/all attributes. The Status (A) is a standard HBIOS result code.","title":"Function 0x46 \u2013 Video Set Character Attribute (VDASAT)"},{"location":"SystemGuide/#function-0x47-video-set-character-color-vdasco","text":"Entry Parameters Returned Values B: 0x47 A: Status C: Video Unit D: Scope E: Color Assign the specified Color (E) code for character foreground/background. If Scope (D) is 0, the specified color will be used for all subsequent character writes/fills. This color is also used to fill new lines generated by scroll operations. If Scope (D) is 1, then the specified foreground/background color will be applied immediately to the entire screen. Refer to the color code table above for a list of the available color codes. Note that a given video display may or may not support any/all colors. The Status (A) is a standard HBIOS result code.","title":"Function 0x47 \u2013 Video Set Character Color (VDASCO)"},{"location":"SystemGuide/#function-0x48-video-write-character-vdawrc","text":"Entry Parameters Returned Values B: 0x48 A: Status C: Video Unit E: Character Write the Character (E) value to the display of the specified Video Unit (C). The character is written starting at the current cursor position and the cursor is advanced. If the end of the line is encountered, the cursor will be advanced to the start of the next line. The display will not scroll if the end of the screen is exceeded. The Status (A) is a standard HBIOS result code.","title":"Function 0x48 \u2013 Video Write Character (VDAWRC)"},{"location":"SystemGuide/#function-0x49-video-fill-vdafil","text":"Entry Parameters Returned Values B: 0x49 A: Status C: Video Unit E: Character HL: Count Write the Character (E) value to the Video Unit (C) display the number of times specified by Count (HL). Characters are written starting at the current cursor position and the cursor is advanced by the number of characters written. If the end of the line is encountered, the characters will continue to be written starting at the next line as needed. The display will not scroll if the end of the screen is exceeded. Writing characters beyond the end of the screen results in undefined behavior. The Status (A) is a standard HBIOS result code.","title":"Function 0x49 \u2013 Video Fill (VDAFIL)"},{"location":"SystemGuide/#function-0x4a-video-copy-vdacpy","text":"Entry Parameters Returned Values B: 0x4A A: Status C: Video Unit D: Source Row E: Source Column L: Count Copy Count (L) bytes from the specified Video Unit (C) display Source Row (D) and Source Column (E) to the current cursor position. The cursor position is not updated. The maximum Count (L) value is 255. Copying to/from overlapping areas is not supported and will have an undefined behavior. The display will not scroll if the end of the screen is exceeded. Copying beyond the active screen buffer area is not supported and results in undefined behavior. The Status (A) is a standard HBIOS result code.","title":"Function 0x4A \u2013 Video Copy (VDACPY)"},{"location":"SystemGuide/#function-0x4b-video-scroll-vdascr","text":"Entry Parameters Returned Values B: 0x4B A: Status C: Video Unit E: Lines Scroll the video display of the specified Video Unit (C) forward or backwards by number of Lines (E) specified. If Lines (E) is positive, then a forward scroll is performed. If Lines (E) contains a negative number, then a reverse scroll will be performed. This function will scroll the entire screen contents. New lines revealed during the scroll operation will be filled with space characters (0x20) using the active character attribute and color. The cursor position will not be updated. The Status (A) is a standard HBIOS result code.","title":"Function 0x4B \u2013 Video Scroll (VDASCR)"},{"location":"SystemGuide/#function-0x4c-video-keyboard-status-vdakst","text":"Entry Parameters Returned Values B: 0x4C A: Status / Codes Pending C: Video Unit Return a count of the number of key Codes Pending (A) in the keyboard buffer for the specified Video Unit (C). If it is not possible to determine the actual number in the buffer, it is acceptable to return 1 to indicate there are key codes available to read and 0 if there are none available. The value returned in register A is used as both a Status (A) code and the return value. Negative values (bit 7 set) indicate a standard HBIOS result (error) code. Otherwise, the return value represents the number of key codes pending.","title":"Function 0x4C \u2013 Video Keyboard Status (VDAKST)"},{"location":"SystemGuide/#function-0x4d-video-keyboard-flush-vdakfl","text":"Entry Parameters Returned Values B: 0x4D A: Status C: Video Unit If a keyboard buffer is in use on the Video Unit (C) specified, it should be purged and all contents discarded. The Status (A) is a standard HBIOS result code.","title":"Function 0x4D \u2013 Video Keyboard Flush (VDAKFL)"},{"location":"SystemGuide/#function-0x4e-video-keyboard-read-vdakrd","text":"Entry Parameters Returned Values B: 0x4E A: Status C: Video Unit C: Scancode D: Keystate E: Keycode Read the next key data from keyboard of the specified Video Unit (C). If a keyboard buffer is used, return the next Keycode in the buffer. If no key data is available, this function will wait indefinitely for a keypress. The Status (A) is a standard HBIOS result code. The Scancode (C) value is the raw scancode from the keyboard for the keypress. Scancodes are optional and may not be implemented by the driver. The Scancode values are driver dependent. In the case of a PS/2 keyboard driver, they should be the PS/2 scancode. Other keyboard drivers may return values appropriate for their specific keyboard. If the driver does not implement this, it should return 0 in C. The Keystate (D) is a bitmap representing the value of all modifier keys and shift states as they existed at the time of the keystroke. The bitmap is defined as: Bit Keystate Indication 7 Key pressed was from the num pad 6 Caps Lock was active 5 Num Lock was active 4 Scroll Lock was active 3 Windows key was held down 2 Alt key was held down 1 Control key was held down 0 Shift key was held down Not all of these bits may be relevant for all keyboards. Any bit that is not relevant should be returned as 0. The Keycode (E) is generally returned as appropriate ASCII values, if possible. Special keys, like function keys and arrows, are returned as reserved codes as described at the start of this section.","title":"Function 0x4E \u2013 Video Keyboard Read (VDAKRD)"},{"location":"SystemGuide/#function-0x4f-read-a-character-at-current-video-position-vdardc","text":"Entry Parameters Returned Values B: 0x4F A: Status C: Video Unit E: Character B: Color E: Attribute This function will return the character data from the current cursor position of the display of the specified Video Unit (C). The data returned includes the Character (E) value, the Color (B), and the Attribute (E) corresponding to the current cursor position. If the display does not support colors or attributes then this function will return color white on black with no attributes. The ability to perform this function may not be available for all video devices. The Status (A) is a standard HBIOS result code.","title":"Function 0x4F \u2013 Read a character at current video position (VDARDC)"},{"location":"SystemGuide/#sound-snd","text":"Sound functions require that a Sound Unit number be specified in register C. This is the logical device unit number assigned during the boot process that identifies all sound devices uniquely. All sound units are assigned a Device Type ID which indicates the specific hardware device driver that handles the unit. The table below enumerates these values. Device Type ID Description Driver SNDDEV_SN76489 \\$00 SN76489 Programmable Sound Generator sn76489.asm SNDDEV_AY38910 \\$01 AY-3-8910/YM2149 Programmable Sound Generator ay38910.asm SNDDEV_BITMODE \\$02 Bit-bang Speaker spk.asm SNDDEV_YM2612 \\$03 YM2612 Programmable Sound Generator ym2612.asm The Sound functions defer the actual programming of the sound chip until the SNDPLAY function is called. You will call the volume and period/note functions to preset the desired sound output, then call SNDPLAY when you want the sound to change. The Sound functions do not manage the duration of the sound played. A sound will play indefinitely \u2013 the caller must implement an appropriate timing mechanism to manage the playing of a series of sounds. HBIOS B=51 C=00 L=80 ; Set volume to half level HBIOS B=53 C=00 HL=152 ; Select Middle C (C4) HBIOS B=54 C=00 D=01 ; Play note on Channel 1","title":"Sound (SND)"},{"location":"SystemGuide/#function-0x50-sound-reset-sndreset","text":"Entry Parameters Returned Values B: 0x50 A: Status C: Sound Unit Reset the sound chip of specified Sound Unit (C). Turn off all sounds and set volume on all channels to silence. The returned Status (A) is a standard HBIOS result code.","title":"Function 0x50 \u2013 Sound Reset (SNDRESET)"},{"location":"SystemGuide/#function-0x51-sound-volume-sndvol","text":"Entry Parameters Returned Values B: 0x51 A: Status C: Sound Unit L: Volume This function sets the sound chip Volume (L) for the specified Sound Unit (C). Volume (L) is a binary value ranging from 0 (silence) to 255 (maximum). The volume will be applied when the next SNDPLAY function is invoked. The returned Status (A) is a standard HBIOS result code. Note that not all sounds chips implement 256 volume levels. The driver will scale the volume to the closest possible level the chip provides.","title":"Function 0x51 \u2013 Sound Volume (SNDVOL)"},{"location":"SystemGuide/#function-0x52-sound-period-sndprd","text":"Entry Parameters Returned Values B: 0x52 A: Status C: Sound Unit HL: Period This function sets the sound chip Period (HL) for the specified Sound Unit (C). The period will be applied when the next SNDPLAY function is invoked. The returned Status (A) is a standard HBIOS result code. The Period (HL) value is not a standardized value. The value is programmed directly into the period or frequency register of the sound chip. It is therefore a hardware dependent value. To play standardized notes, use the SNDNOTE function.","title":"Function 0x52 \u2013 Sound Period (SNDPRD)"},{"location":"SystemGuide/#function-0x53-sound-note-sndnote","text":"Entry Parameters Returned Values B: 0x53 A: Status C: Sound Unit HL: Note This function sets the frequency generated by the sound of the specified Sound Unit (C). The frequency is standardized and is specified by using values that correspond to musical notes. The frequency will be applied when the next SNDPLAY function is invoked. The returned Status (A) is a standard HBIOS result code. The Note (HL) values correspond to quarter notes. Increasing/decreasing the value by 4 results in a full note increment/decrement. Increasing/decreasing the value by 48 results in a full octave increment/decrement. The value 0 corresponds to Bb/A# in octave 0. The sound chip resolution and its oscillator limit the range and accuracy of the notes played. The typical range of the AY-3-8910 is six octaves: Bb2/A#2 to A7, where each value is a unique tone. Values above and below can still be played but each quarter tone step may not result in a note change. The following table shows the mapping of the Note (HL) value to the corresponding octave and note. Note Octave 0 1 2 3 4 5 6 7 C - 8 56 104 152 200 248 296 C#/Db - 12 60 108 156 204 252 300 D - 16 64 112 160 208 256 304 D#/Eb - 20 68 116 164 212 260 308 E - 24 72 120 168 216 264 312 F - 28 76 124 172 220 268 316 F#/Gb - 32 80 128 176 224 272 320 G - 36 84 132 180 228 276 324 G#/Ab - 40 88 136 184 232 280 328 A - 44 92 140 188 236 284 332 A#/Bb 0 48 96 144 192 240 288 336 B 4 52 100 148 196 244 292 340","title":"Function 0x53 \u2013 Sound Note (SNDNOTE)"},{"location":"SystemGuide/#function-0x54-sound-play-sndplay","text":"Entry Parameters Returned Values B: 0x54 A: Status C: Sound Unit D: Channel This function applies the previously specified volume and frequency of the specified Sound Unit (C) by programming the sound chip with the appropriate values. The values are applied to the specified Channel (D) of the chip. The returned Status (A) is a standard HBIOS result code. Note that there is no duration for the sound output \u2013 the programmed sound will be played indefinitely. It is up to the user to wait the desired amount of time, then change or silence the sound output as desired. The number of channels available on a sound chip varies. It is up to the caller to ensure that the appropriate number of channels are being programmed.","title":"Function 0x54 \u2013 Sound Play (SNDPLAY)"},{"location":"SystemGuide/#function-0x55-sound-query-sndquery","text":"Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit E: Subfunction This function will return a variety of information for a specified Sound Unit (C) according to the Subfunction (E) specified. The returned Status (A) is a standard HBIOS result code.","title":"Function 0x55 \u2013 Sound Query (SNDQUERY)"},{"location":"SystemGuide/#sndquery-subfunction-0x01-get-count-of-audio-channels-supported-sndq_chcnt","text":"Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit B: Tone Channels E: 0x01 C: Noise Channels","title":"SNDQUERY Subfunction 0x01 \u2013 Get count of audio channels supported (SNDQ_CHCNT)"},{"location":"SystemGuide/#sndquery-subfunction-0x02-get-current-volume-setting-sndq_vol","text":"Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit L: Volume E: 0x02","title":"SNDQUERY Subfunction 0x02 \u2013 Get current volume setting (SNDQ_VOL)"},{"location":"SystemGuide/#sndqdery-subfunction-0x03-get-current-period-setting-sndq_period","text":"Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit HL: Period E: 0x03","title":"SNDQdERY Subfunction 0x03 \u2013 Get current period setting (SNDQ_PERIOD)"},{"location":"SystemGuide/#sndquery-subfunction-0x04-get-device-details-sndq_dev","text":"Entry Parameters Returned Values B: 0x55 A: Status C: Sound Unit B: Driver Identity E: 0x04 HL: Ports DE: Ports This subfunction reports detailed device information for the specified Sound Unit (C). Driver Identity (B) reports the audio device type. Ports (HL & DE) return relevant port addresses for the hardware specific to each device type. The following table defines the specific port information per device type: Audio ID Value Device Returned Registers SND_SN76489 0x01 SN76489 E=Left channel port, L=Right channel port SND_AY38910 0x02 AY-3-8910 D=Address port, E=Data port SND_BITMODE 0x03 I/O PORT D=Address port, E=Bit mask SND_YM2612 0x04 YM2612 Part 0: D=Address port, E=Data port Part 1: D=Address port, L=Part 1 Data port","title":"SNDQUERY Subfunction 0x04 \u2013 Get device details (SNDQ_DEV)"},{"location":"SystemGuide/#function-0x56-sound-duration-snddur","text":"Entry Parameters Returned Values B: 0x56 A: Status C: Sound Unit HL: Duration This function sets the Duration (HL) of the note to be played in milliseconds for the specified Sound Unit (C). This function just sets the duration, the actual duration is applied in the SNDPLAY function. If the Duration (HL) is set to zero, then the SNDPLAY function will operate in a non-blocking mode. i.e. a tone will start playing and the play function will return. The tone will continue to play until the next tone is played. If the Duration (HL) is greater than zero, the sound will play for the duration defined in HL and then return. ***** Function Not Implemented ****","title":"Function 0x56 \u2013 Sound Duration (SNDDUR)"},{"location":"SystemGuide/#function-0x57-sound-device-snddevice","text":"Entry Parameters Returned Values B: 0x57 A: Status C: Sound Unit C: Device Attributes D: Device Type E: Device Number H: Device Unit Mode L: Device I/O Base Address Reports device information about the specified Sound Unit (C). The Status (A) is a standard HBIOS result code. The Device Attributes (C) value is not yet defined. Device Type (D) indicates the specific hardware driver that handles the specified Sound Unit (C). Values are listed at the start of this section. Device Number (E) indicates the physical device number assigned per driver. Device Mode (H) is used to indicate the variant of the chip or circuit that is used by the specified unit. The Device I/O Base Address (L) indicates the starting port address of the hardware interface that is servicing the specified unit. Both of these values are considered driver specific. Refer to the associated hardware driver for the values used.","title":"Function 0x57 \u2013 Sound Device (SNDDEVICE)"},{"location":"SystemGuide/#function-0x58-sound-beep-sndbeep","text":"Entry Parameters Returned Values B: 0x58 A: Status C: Sound Unit Play a beep tone on the specified Sound Unit (C). The beep will normally be about 1/3 second in duration and the tone will be approximately B5.","title":"Function 0x58 \u2013 Sound Beep (SNDBEEP)"},{"location":"SystemGuide/#extension-ext","text":"Helper (extension) functions that are not a core part of a BIOS.","title":"Extension (EXT)"},{"location":"SystemGuide/#function-0xe0-calculate-slice-extslice","text":"Entry Parameters Returned Values B: 0xE0 A: Status D: Disk Unit B: Device Attributes E: Slice C: Media ID DEHL: Sector Address Report the Media ID (C), and Device Attributes (B) for the for media in the specified Disk Unit (D), and for hard disks the absolute Sector offset to the start of the Slice (E). The Status (A) is a standard HBIOS result code. This function extends upon Function 0x18 \u2013 Disk Media (DIOMEDIA) for hard disk media by scanning for a partition to determine if the disk uses HD512 or HD1K, correctly reporting MID_HD or MID_HDNEW respectively. See the following for some background Mapping to Media ID It will also return the sector number of the first sector in the slice if the slice number is valid. If the slice number is invalid (it wont fix on the media) an error will be returned. The slice calculation is performed by considering the partition start (if it exists), the size of a slice for the given format type, and ensuring that the slice fits within the media or partition size, taking into consideration other partitions that may exist. The Device Attributes (B) are the same as defined in Function 0x17 \u2013 Disk Device (DIODEVICE) If the Unit specified is not a hard disk the Media ID will be returned and the slice parameter ignored. If there is no media in device, or the slice number is invaid (Parameter Out Of Range) the function will return an error status. **NOTE: This function was placed in HBIOS to be shared between the diffeent CP/M varients supported by RomWBW. It is not strictly a BIOS function, and may be moved in future.","title":"Function 0xE0 \u2013 Calculate Slice (EXTSLICE)"},{"location":"SystemGuide/#system-sys","text":"","title":"System (SYS)"},{"location":"SystemGuide/#function-0xf0-system-reset-sysreset","text":"Entry Parameters Returned Values B: 0xF0 A: Status C: Subfunction This function performs various forms of a system reset depending on the value of Subfunction (C): Soft Reset (0x00): Perform a soft reset of HBIOS. Releases all HBIOS memory allocated by current OS. Does not reinitialize physical devices. Warm Start (0x01): Warm start the system returning to the boot loader prompt. Does not reinitialize physical devices. Cold Start (0x02): Perform a system cold start (like a power on). All devices are reinitialized. User Restart (0x03): Perform a video terminal reset. Terminal emulation and visual display systems are reset. The Status (A) is a standard HBIOS result code.","title":"Function 0xF0 \u2013 System Reset (SYSRESET)"},{"location":"SystemGuide/#function-0xf1-system-version-sysver","text":"Entry Parameters Returned Values B: 0xF1 A: Status C: Reserved DE: Version L: Platform This function will return the HBIOS Version (DE) number and Platform (L) identifier. The Status (A) is a standard HBIOS result code. The Version (DE)number is encoded as BCD where the 4 digits are: [Major Version][Minor Version][Patch Level][Build Number] So, for example, a Version (DE) number of 0x3102 would indicate version 3.1.0, build 2. The hardware Platform (L) is identified as follows: Name Id **Platform ** PLT_SBC 1 ECB Z80 SBC PLT_ZETA 2 ZETA Z80 SBC PLT_ZETA2 3 ZETA Z80 V2 SBC PLT_N8 4 N8 (HOME COMPUTER) Z180 SBC PLT_MK4 5 MARK IV PLT_UNA 6 UNA BIOS PLT_RCZ80 7 RCBUS W/ Z80 PLT_RCZ180 8 RCBUS W/ Z180 PLT_EZZ80 9 EASY/TINY Z80 PLT_SCZ180 10 SMALL COMPUTER CENTRAL Z180 PLT_DYNO 11 DYNO MICRO-ATX MOTHERBOARD PLT_RCZ280 12 RCBUS W/ Z280 PLT_MBC 13 NHYODYNE MULTI-BOARD COMPUTER PLT_RPH 14 RHYOPHYRE GRAPHICS SBC PLT_Z80RETRO 15 Z80 RETRO COMPUTER PLT_S100 16 S100 COMPUTERS Z180 PLT_DUO 17 DUODYNE Z80 SYSTEM PLT_HEATH 18 HEATHKIT H8 Z80 SYSTEM PLT_EPITX 19 Z180 MINI-ITX PLT_MON 20 MONSPUTER (DEPRECATED) PLT_GMZ180 21 GENESIS Z180 SYSTEM PLT_NABU 22 NABU PC W/ ROMWBW OPTION BOARD PLT_FZ80 23 S100 FPGA Z80 PLT_RCEZ80 24 RCBUS W/ eZ80 For more information on these platforms see RomWBW Hardware","title":"Function 0xF1 \u2013 System Version (SYSVER)"},{"location":"SystemGuide/#function-0xf2-system-set-bank-syssetbnk","text":"Entry Parameters Returned Values B: 0xF2 A: Status C: Bank ID C: Prior Bank ID Activates the specified memory Bank ID (C) and returns the Prior Bank ID (C). The function must be invoked from code located in the upper 32K and the stack must be in the upper 32K. The Status (A) is a standard HBIOS result code. If the system is using interrupt mode 1 interrupts, the you must take steps to ensure interrupts are properly handled. You generally have two choices: Disable interrupts while the User Bank is switched out Duplicate the interrupt mode 1 vector from the User Bank into the bank you are switching to. If the User Bank has been switched out, you will not be able to invoke the HBIOS API functions using an RST 08 instruction. You can use the alternative mechanism using CALL $FFF0 as described in Invocation .","title":"Function 0xF2 \u2013 System Set Bank (SYSSETBNK)"},{"location":"SystemGuide/#function-0xf3-system-get-bank-sysgetbnk","text":"Entry Parameters Returned Values B: 0xF3 A: Status C: Bank ID Returns the currently active Bank ID (C). The Status (A) is a standard HBIOS result code.","title":"Function 0xF3 \u2013 System Get Bank (SYSGETBNK)"},{"location":"SystemGuide/#function-0xf4-system-set-copy-syssetcpy","text":"Entry Parameters Returned Values B: 0xF4 A: Status D: Destination Bank ID E: Source Bank ID HL: Byte Count Prepare for a subsequent interbank memory copy (SYSBNKCPY) function call by setting the Source Bank ID (E), Destination Bank ID (D), and Byte Count (HL) to be copied. The bank ID\u2019s are not range checked and must be valid for the system in use. The Status (A) is a standard HBIOS result code. No bytes are copied by this function. The SYSBNKCPY function must be called to actually perform the copy. The values setup by this function will remain unchanged until another call is make to this function. So, after calling SYSSETCPY, you may make multiple calls to SYSBNKCPY as long as you want to continue to copy between the already established Source/Destination Banks and the same size copy is being performed.","title":"Function 0xF4 \u2013 System Set Copy (SYSSETCPY)"},{"location":"SystemGuide/#function-0xf5-system-bank-copy-sysbnkcpy","text":"Entry Parameters Returned Values B: 0xF5 A: Status DE: Destination Address DE: New Destination Address HL: Source Address HL: New Source Address Copy a block of memory between banks. The Source Bank, Destination Bank, and Byte Count to copy must be established with a prior call to SYSSETCPY. However, it is not necessary to call SYSSETCPY prior to subsequent calls to SYSBNKCPY if the source/destination banks and copy length do not change. On return, the New Destination Address (DE) will be value of the original Destination Address (DE) incremented by the count of bytes copied. Likewise for the New Source Address (HL). This allows iterative invocations of this function to continue copying where the prior invocation left off. The Status (A) is a standard HBIOS result code. WARNINGS: This function is inherently dangerous and does not prevent you from corrupting critical areas of memory. Use with extreme caution. Overlapping source and destination memory ranges are not supported and will result in undetermined behavior. Copying of byte ranges that cross bank boundaries is undefined.","title":"Function 0xF5 \u2013 System Bank Copy (SYSBNKCPY)"},{"location":"SystemGuide/#function-0xf6-system-alloc-sysalloc","text":"Entry Parameters Returned Values B: 0xF6 A: Status HL: Block Size HL: Block Address This function will attempt to allocate a Block Size (HL) bytes block of memory from the internal HBIOS heap. The HBIOS heap resides in the HBIOS bank in the area of memory left unused by HBIOS. If the allocation is successful, the Block Address (HL) of the allocated memory block is returned in HL. You will typically need to use the SYSBNKCPY function to read/write the allocated memory. The Status (A) is a standard HBIOS result code.","title":"Function 0xF6 \u2013 System Alloc (SYSALLOC)"},{"location":"SystemGuide/#function-0xf7-system-free-sysfree","text":"Entry Parameters Returned Values B: 0xF7 A: Status HL: Block Address *** Function Not Implemented *** Note that all allocated memory can be freed by calling the SYSRESET function with a subfunction code of 0x00 (Soft Reset).","title":"Function 0xF7 \u2013 System Free (SYSFREE)"},{"location":"SystemGuide/#function-0xf8-system-get-sysget","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: Subfunction This function will report various system information based on the sub-function value. The following lists the subfunctions available along with the registers/information utilized. The Status (A) is a standard HBIOS result code.","title":"Function 0xF8 \u2013 System Get (SYSGET)"},{"location":"SystemGuide/#sysget-subfunction-0x00-get-character-device-unit-count-ciocnt","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x00 E: Count Return the Count (E) of character device units. The Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0x00 \u2013 Get Character Device Unit Count (CIOCNT)"},{"location":"SystemGuide/#sysget-subfunction-0x01-get-serial-unit-function-ciofn","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x01 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the CIO function number to lookup in D and the CIO unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup.","title":"SYSGET Subfunction 0x01 \u2013 Get Serial Unit Function (CIOFN)"},{"location":"SystemGuide/#sysget-subfunction-0x10-get-disk-device-unit-count-diocnt","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x10 E: Count Return the Count (E) of disk device units. The Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0x10 \u2013 Get Disk Device Unit Count (DIOCNT)"},{"location":"SystemGuide/#sysget-subfunction-0x11-get-disk-unit-function-diofn","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x11 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the DIO function number to lookup in D and the DIO unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup.","title":"SYSGET Subfunction 0x11 \u2013 Get Disk Unit Function (DIOFN)"},{"location":"SystemGuide/#sysget-subfunction-0x20-get-rtc-device-unit-count-rtccnt","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x20 E: Count Return the Count (E) of RTC device units. The Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0x20 \u2013 Get RTC Device Unit Count (RTCCNT)"},{"location":"SystemGuide/#sysget-subfunction-0x40-get-video-device-unit-count-vdacnt","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x40 E: Count Return the Count (E) of video device units. The Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0x40 \u2013 Get Video Device Unit Count (VDACNT)"},{"location":"SystemGuide/#sysget-subfunction-0x41-get-video-unit-function-vdafn","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x41 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the VDA function number to lookup in D and the VDA unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup.","title":"SYSGET Subfunction 0x41 \u2013 Get Video Unit Function (VDAFN)"},{"location":"SystemGuide/#sysget-subfunction-0x50-get-sound-device-unit-count-sndcnt","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x50 E: Count Return the Count (E) of sound device units. The Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0x50 \u2013 Get Sound Device Unit Count (SNDCNT)"},{"location":"SystemGuide/#sysget-subfunction-0x51-get-sound-unit-function-sndfn","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0x51 HL: Function Address D: Function DE: Unit Data Address E: Unit This function will lookup the actual driver function address and unit data address inside the HBIOS driver. On entry, place the SND function number to lookup in D and the SND unit number in E. On return, HL will contain the address of the requested function in the HBIOS driver (in the HBIOS bank). DE will contain the associated unit data address (also in the HBIOS bank). See Appendix A for details. The returned Status (A) is a standard HBIOS result code. This function can be used to speed up HBIOS calls by looking up the function and data address for a specific driver function. After this, the caller can use interbank calls directly to the function in the driver which bypasses the overhead of the normal function invocation lookup.","title":"SYSGET Subfunction 0x51 \u2013 Get Sound Unit Function (SNDFN)"},{"location":"SystemGuide/#sysget-subfunction-0xc0-get-switches-switch","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xC0 HL: Switch Value D: Switch Key This function will return the current value (HL) of the switch (D) from NVRAM. Switches may be returned as a 16 bit (HL) or 8 bit (L) value. It is up to the caller to process the returned value correctly. Note for Switch 0xFF (status) the returned value is primarily in the Status (A) register. Errors are signaled in the return by setting the NZ flag. When set the (A) register may contain an error code, but this code does not conform to RomWBW standard Success is indicated by setting the Z flag For a description of switches please see RomWBW NVRAM Configuration","title":"SYSGET Subfunction 0xC0 \u2013 Get Switches (SWITCH)"},{"location":"SystemGuide/#sysget-subfunction-0xd0-get-timer-tick-count-timer","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xD0 DEHL: Tick Count C: Frequency Return the value of the global system timer Tick Count (DEHL). This is a double-word binary value. The frequency of the system timer in Hertz is returned in Frequency (C). The returned Status (A) is a standard HBIOS result code. The tick count is a 32 bit binary value. It will rollover to zero if the maximum value for a 32 bit number is reached. Note that not all hardware configuration have a system timer. You can determine if a timer exists by calling this function repeatedly to see if it is incrementing.","title":"SYSGET Subfunction 0xD0 \u2013 Get Timer Tick Count (TIMER)"},{"location":"SystemGuide/#sysget-subfunction-0xd1-get-seconds-count-seconds","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xD1 DEHL: Seconds Count C: Remainder Ticks Return the Seconds Count (DEHL) with the number of seconds that have elapsed since the system was started. This is a double-word binary value. Additionally, Remainder Ticks (C) is returned and contains the number of ticks that have elapsed within the current second. Note that Remainder Ticks (C) will have a value from 0 to 49 since there are 50 ticks per second. So, Remainder Ticks does not represent a fraction of the current second. Remainder Ticks (C) can be doubled to derive the hundredths of milliseconds elapsed within the current second. The availability of the Seconds Count (DEHL) is dependent on having a system timer active. If the hardware configuration has no system timer, then Seconds Count (DEHL) will not increment.","title":"SYSGET Subfunction 0xD1 \u2013 Get Seconds Count (SECONDS)"},{"location":"SystemGuide/#sysget-subfunction-0xe0-get-boot-information-bootinfo","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xE0 L: Boot Bank ID D: Boot Disk Unit E: Boot Disk Slice This function returns information about the most recent boot operation performed. It includes the Boot Bank ID (L), the Boot Disk Unit (D), and the Boot Disk Slice (E). The returned Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0xE0 \u2013 Get Boot Information (BOOTINFO)"},{"location":"SystemGuide/#sysget-subfunction-0xf0-get-cpu-information-cpuinfo","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF0 H: Z80 CPU Variant L: CPU Speed MHz DE: CPU Speed KHz BC: Oscillator Speed KHz This function returns information about the active CPU environment. The Z80 CPU Variant (H) will be one of: 0=Z80, 1=Z180, 2=Z180-K, 3=Z180-N, 4=Z280. The current CPU speed is provided as both CPU Speed MHz (L) and CPU Speed KHz (DE). The raw oscillator speed is provided as Oscillator Speed KHz (BC). The returned Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0xF0 \u2013 Get CPU Information (CPUINFO)"},{"location":"SystemGuide/#sysget-subfunction-0xf1-get-memory-information-meminfo","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF1 D: ROM Bank Count E: RAM Bank Count This function returns the systems ROM Bank Count (D) and RAM Bank Count (E). Each bank is 32KB by definition. The returned Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0xF1 \u2013 Get Memory Information (MEMINFO)"},{"location":"SystemGuide/#sysget-subfunction-0xf2-get-bank-information-bnkinfo","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF2 D: BIOS Bank ID E: User Bank ID Certain memory banks within a RomWBW system are special. The exact bank id for each of these varies depending on the configuration of the system. This function can be used to determine the BIOS Bank ID (D) and the User Bank ID (E). The returned Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0xF2 \u2013 Get Bank Information (BNKINFO)"},{"location":"SystemGuide/#sysget-subfunction-0xf3-get-cpu-speed-cpuspd","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF3 L: Clock Mult D: Memory Wait States E: I/O Wait States This function will return the running CPU speed attributes of a system. The Clock Mult (L) returned indicates the frequency multiple being applied to the raw oscillator clock. If is defined as: 0=Half, 1=Full, and 2=Double. The wait states for the system are also provided as Memory Wait States (D) and I/O Wait States (E). The value of Memory Wait States (D) is the actual number of wait states, not the number of wait states added. The returned Status (A) is a standard HBIOS result code.","title":"SYSGET Subfunction 0xF3 \u2013 Get CPU Speed (CPUSPD)"},{"location":"SystemGuide/#sysget-subfunction-0xf4-get-front-panel-swithes-panel","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF4 L: Switches This function will return the current value of the switches (L) from the front panel of the system. If no front panel is available in the system, the returned Status (A) will indicate a No Hardware error.","title":"SYSGET Subfunction 0xF4 \u2013 Get Front Panel Swithes (PANEL)"},{"location":"SystemGuide/#sysget-subfunction-0xf5-get-application-banks-information-appbnks","text":"Entry Parameters Returned Values B: 0xF8 A: Status C: 0xF5 H: App Banks Start ID L: App Banks Count E: Bank Size HBIOS may be configured to reserve a number of RAM memory banks that will be available for application use. This function returns information about the RAM memory banks currently available for application use. The function provides the bank id of the first available application bank (H) and the count of banks available (L). It also returns the size of a bank expressed as a number of 256-byte pages (E). The returned Status (A) is a standard HBIOS result code. The application banks are always a contiguous set of banks, so the App Banks Start ID can be incremented to address additional banks up to the limit indicated by App Banks Count. If the App Banks Count is zero, then there are no application banks available (regardless of the value of App Banks Start ID). HBIOS does not provide any mechanism to reserve application banks. Any concept of allocation of application banks must be implemented within the OS or application. This function does not change the current bank selected. You must use Function 0xF2 \u2013 System Set Bank (SYSSETBNK) or the proxy function Bank Select (BNKSEL) for this. Be sure to observe the warnings in the description of this function.","title":"SYSGET Subfunction 0xF5 \u2013 Get Application Banks Information (APPBNKS)"},{"location":"SystemGuide/#function-0xf9-system-set-sysset","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: Subfunction This function will set various system parameters based on the sub-function value. The following lists the subfunctions available along with the registers/information utilized. The Status (A) is a standard HBIOS result code.","title":"Function 0xF9 \u2013 System Set (SYSSET)"},{"location":"SystemGuide/#sysset-subfunction-0xc0-set-switches-switch","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: 0xC0 D: Switch Key HL: Switch Value This function will set the value (HL) into the switch (D) and store it into NVRAM. Switches may be passed as a 16 bit (HL) or 8 bit (L) value. It is up to the caller to send the value correctly. Note for Switch 0xFF (reset) the value (HL) is ignored Errors are signalled in the return by setting the NZ flag. When set the (A) register may contain an error code, but this code does not conform to RomWBW standard Success is indicated by setting the Z flag For a description of switches please see RomWBW NVRAM Configuration","title":"SYSSET Subfunction 0xC0 \u2013 Set Switches (SWITCH)"},{"location":"SystemGuide/#sysset-subfunction-0xd0-set-timer-tick-count-timer","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: 0xD0 DEHL: Timer Tick Count This function will explicitly set the system Timer Tick Count (DEHL) value. DEHL is a double-word binary value. The Status (A) is a standard HBIOS result code.","title":"SYSSET Subfunction 0xD0 \u2013 Set Timer Tick Count (TIMER)"},{"location":"SystemGuide/#sysset-subfunction-0xd1-set-seconds-count-seconds","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: 0xD1 DEHL: Seconds Count This function will explicitly set the system Seconds Count (DEHL) value. DEHL is a double-word binary value. The Status (A) is a standard HBIOS result code.","title":"SYSSET Subfunction 0xD1 \u2013 Set Seconds Count (SECONDS)"},{"location":"SystemGuide/#sysset-subfunction-0xe0-set-boot-information-bootinfo","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: 0xE0 L: Boot Bank ID D: Boot Disk Unit E: Boot Disk Slice This function sets information about the most recent boot operation performed. It includes the Boot Bank ID (L), the Boot Disk Unit (D), and the Boot Disk Slice (E). The returned Status (A) is a standard HBIOS result code.","title":"SYSSET Subfunction 0xE0 \u2013 Set Boot Information (BOOTINFO)"},{"location":"SystemGuide/#sysset-subfunction-0xf3-set-cpu-speed-cpuspd","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: 0xF3 L: Clock Mult D: Memory Wait States E: I/O Wait States This function will modify the running CPU speed attributes of a system. Note that it is frequently impossible to tell if a system is capable of dynamic speed changes. This function makes the changes blindly. You can specify 0xFF for either of the wait state settings to have them left alone. If an attempt is made to change the speed of a system that is definitely incapable of doing so, then an error result is returned. The returned Status (A) is a standard HBIOS result code. The function will attempt to set the CPU speed based on the Clock Mult (L) value: 0=Half, 1=Full, 2=Double. Memory Wait States (D) and I/O Wait States (E) will be set if possible. The value of Memory Wait States (D) is the actual number of wait states, not the number of wait states added. Some peripherals are dependent on the CPU speed. For example, the Z180 ASCI baud rate and system timer are derived from the CPU speed. The Set CPU Speed function will attempt to adjust these peripherals for correct operation after modifying the CPU speed. However, in some cases this may not be possible. The baud rate of ASCI ports have a limited set of divisors. If there is no satisfactory divisor to retain the existing baud rate under the new CPU speed, then the baud rate of the ASCI port(s) will be affected.","title":"SYSSET Subfunction 0xF3 \u2013 Set CPU Speed (CPUSPD)"},{"location":"SystemGuide/#sysset-subfunction-0xf4-set-front-panel-leds-panel","text":"Entry Parameters Returned Values B: 0xF9 A: Status C: 0xF4 L: LEDs This function will set the front panel LEDs based on the bits in L. If no front panel is available in the system, the returned Status (A) will indicate a No Hardware error.","title":"SYSSET Subfunction 0xF4 \u2013 Set Front Panel LEDs (PANEL)"},{"location":"SystemGuide/#function-0xfa-system-peek-syspeek","text":"Entry Parameters Returned Values B: 0xFA A: Status D: Bank ID E: Byte Value HL: Memory Address This function retrieves and returns the Byte Value from the specified Bank ID (D) and Memory Address (HL). The bank specified is not range checked. The Status (A) is a standard HBIOS result code.","title":"Function 0xFA \u2013 System Peek (SYSPEEK)"},{"location":"SystemGuide/#function-0xfb-system-poke-syspoke","text":"Entry Parameters Returned Values B: 0xFB A: Status D: Bank ID HL: Memory Address E: Byte Value This function sets the Byte Value (E) in the specified Bank ID (D) and Memory Address (HL). The bank specified is not range checked. The Status (A) is a standard HBIOS result code.","title":"Function 0xFB \u2013 System Poke (SYSPOKE)"},{"location":"SystemGuide/#function-0xfc-system-interrupt-management-sysint","text":"Entry Parameters Returned Values B: 0xFC A: Status C: Subfunction This function allows the caller to query information about the interrupt configuration of the running system and allows adding or hooking interrupt handlers dynamically. Register C is used to specify a sub-function. Additional input and output registers may be used as defined by the sub-function. The Status (A) is a standard HBIOS result code. Note that during interrupt processing, the lower 32K of CPU address space will contain the RomWBW HBIOS code bank, not the lower 32K of application TPA. As such, a dynamically installed interrupt handler does not have access to the lower 32K of TPA and must be careful to avoid modifying the contents of the lower 32K of memory. Invoking RomWBW HBIOS functions within an interrupt handler is not supported. Interrupt handlers are different under IM1 and IM2. Interrupt Mode 1: The new interrupt handler is responsible for chaining (JP) to the previous vector if the interrupt is not handled. If the interrupt is handled, the new handler may simply return (RET). When chaining to the previous interrupt handler, ZF must be set if interrupt is handled and ZF cleared if not handled. The interrupt management framework takes care of saving and restoring AF, BC, DE, HL, and IY. Any other registers modified must be saved and restored by the interrupt handler. Interrupt Mode 2: The new interrupt handler may either replace or hook the previous interrupt handler. To replace the previous interrupt handler, the new handler just returns (RET) when done. To hook the previous handler, the new handler can chain (JP) to the previous vector. Note that initially all IM2 interrupt vectors are set to be handled as \u201cBAD\u201d meaning that the interrupt is unexpected. In most cases, you do not want to chain to the previous vector because it will cause the interrupt to display a \u201cBAD INT\u201d system panic message. The interrupt framework will take care of issuing an EI and RETI instruction. Do not put these instructions in your new handler. Additionally, interrupt management framework takes care of saving and restoring AF, BC, DE, HL, and IY. Any other registers modified must be saved and restored by the interrupt handler. If the caller is transient, then the caller must remove the new interrupt handler and restore the original one prior to termination. This is accomplished by calling this function with the Interrupt Vector set to the Previous Vector returned in the original call. The caller is responsible for disabling interrupts prior to making an INTSET call and enabling them afterwards. The caller is responsible for ensuring that a valid interrupt handler is installed prior to enabling any hardware interrupts associated with the handler. Also, if the handler is transient, the caller must disable the hardware interrupt(s) associated with the handler prior to uninstalling it.","title":"Function 0xFC \u2013 System Interrupt Management (SYSINT)"},{"location":"SystemGuide/#sysint-subfunction-0x00-interrupt-info-intinf","text":"Entry Parameters Returned Values B: 0xFC A: Status C: 0x00 D: Interrupt Mode E: IVT Size Return current Interrupt Mode (D) of the system. Also return the number of Interrupt Vector Table (IVT) entries in IVT (E). For IM1, the size of the table is the number of vectors chained together. For IM2, the size of the table is the number of slots in the vector table. The Status (A) is a standard HBIOS result code.","title":"SYSINT Subfunction 0x00 \u2013 Interrupt Info (INTINF)"},{"location":"SystemGuide/#sysint-subfunction-0x10-get-interrupt-intget","text":"Entry Parameters Returned Values B: 0xFC A: Status C: 0x10 HL: IVT Address E: IVT Index This function will return the IVT Address (HL) of the current interrupt vector for the specified IVT Index (C). The Status (A) is a standard HBIOS result code.","title":"SYSINT Subfunction 0x10 \u2013 Get Interrupt (INTGET)"},{"location":"SystemGuide/#sysint-subfunction-0x20-set-interrupt-intset","text":"Entry Parameters Returned Values B: 0xFC A: Status C: 0x20 HL: Previous Interrupt Address E: IVT Index HL: Interrupt Address This function will set a new Interrupt Address (HL) at the IVT Index (E) specified. On return, the Previous Interrupt Address (HL) will be provided.","title":"SYSINT Subfunction 0x20 \u2013 Set Interrupt (INTSET)"},{"location":"SystemGuide/#proxy-functions","text":"The following special functions are implemented inside of the HBIOS proxy area at the top of RAM. They do not cause a bank switch and are, therefore, much faster than their corresponding HBIOS API functions. The functions are invoked via the following dedicated jump table: Function Address ** Equate ** Invoke HBIOS Function (INVOKE) 0xFFF0 HB_INVOKE Bank Select (BNKSEL) 0xFFF3 HB_BNKSEL Bank Copy (BNKCPY) 0xFFF6 HB_BNKCPY Bank Call (BNKCALL) 0xFFF9 HB_BNKCALL The function addresses are also defined as equates in hbios.inc. It is suggested that you use the equates when possible. To use the functions, you may either call or jump to them. Some examples: CALL $FFF0 JP $FFF3 CALL HB_BNKCPY These functions are inherently dangerous and generally not value checked. Use with extreme caution.","title":"Proxy Functions"},{"location":"SystemGuide/#invoke-hbios-function-invoke","text":"Address 0xFFF0 This function is an alternate mechanism for invoking the normal HBIOS API functions. The parameters and return values are as documented above. To put it another way, CALL $FFF0 is equivalent to RST 08 , but it can be used in any scenario when the normal bank is not selected.","title":"Invoke HBIOS Function (INVOKE)"},{"location":"SystemGuide/#bank-select-bnksel","text":"Address 0xFFF3 Entry Parameters Returned Values A: Bank ID This function will select the memory bank identified by Bank ID (A). Register AF is destroyed. All other registers are preserved. The warnings described in Function 0xF2 \u2013 System Set Bank (SYSSETBNK) should be observed.","title":"Bank Select (BNKSEL)"},{"location":"SystemGuide/#bank-copy-bnkcpy","text":"Address 0xFFF6 Entry Parameters Returned Values HL: Source Address HL: Ending Source Address DE: Destination Address DE: Ending Destination Address BC: Count BC: 0 HB_SRCBNK: Source Bank ID HB_DSTBNK: Destination Bank ID This function will copy Count (BC) bytes from Source Address (HL) in Source Bank ID (HB_SRCBNK) to Destination Address (DE) in Destination Bank ID (HB_DSTBNK). The HB_SRCBNK and HB_DSTBNK fields are dedicated locations in the proxy. These locations are defined in hbios.inc: Source Bank ID: HB_SRCBNK = \\$FFE4 Destination Bank ID: HB_DSTBNK = \\$FFE7 The Source Bank ID and Destination Bank ID values must be populated in the specified addresses before calling this function. During processing, HL and DE, will be incremented. At termination, HL and DE will contain the \u201cnext\u201d source/destination addresses that would be copied. This allows this function to be invoked repeatedly to copy continuous blocks of data. Register AF is destroyed by this function. Register BC will be 0.","title":"Bank Copy (BNKCPY)"},{"location":"SystemGuide/#bank-call-bnkcall","text":"Address 0xFFF9 Entry Parameters Returned Values A: Target Bank ID IX: Target Address This function will perform a function call to a routine in another bank. It does this by selecting the Target Bank ID (A) and then calling the Target Address (IX). On return from the target function, the originally active bank is selected. Register usage is determined by the routine that is called. Since a different bank will be selected while the target function is active, the warnings described in Function 0xF2 \u2013 System Set Bank (SYSSETBNK) should be observed.","title":"Bank Call (BNKCALL)"},{"location":"SystemGuide/#errors-and-diagnostics","text":"ROMWBW tries to provide useful information when a run time or build time error occurs. Many sections of the code also have code blocks that can be enable to aid in debugging and in some cases the level of reporting detail can be customized.","title":"Errors and diagnostics"},{"location":"SystemGuide/#run-time-errors","text":"","title":"Run Time Errors"},{"location":"SystemGuide/#panic","text":"A panic error indicates a non-recoverable error. The processor status is displayed on the console and interrupts are disabled and execution is halted. A cold boot or reset is required to restart. Example error message: >>> PANIC: @06C4[DFA3:DFC3:0100:F103:04FC:0000:2B5E] *** System Halted *** The format of the information provided is @XXXX [-AF-:-BC-:-DE-:-HL-:-SP-:-IX-:-IY-] Where @XXXX is the address the panic was called from. The other information is the CPU register contents. Possible reasons a PANIC may occur are: RAM Bank range error when attempting a read or write to a RAM disk. Sector read function has not been setup but a read was attempted. An interrupt vector has not been set up when an interrupt was received. There was an attempt to add more devices than the device table had room for. An illegal SD card command was encountered. The @XXXX memory address can be cross referenced with the build source code to identify which section of the software or hardware caused the fault.","title":"PANIC"},{"location":"SystemGuide/#syschk","text":"A syschk error is identified when an internal error is detected. When this occurs an error code is returned to the calling program in the A register. A non-zero result indicates an error. Syschk errors may be reported to the console. Whether this occurs depends on the value of the diagnosis level equate DIAGLVL. By default syschk errors are not reported to the console. If the diagnosis level is set to display the diagnosis information, then memory address, register dump and error code is displayed. A key difference with the PANIC error is that execution may be continued. Example error message: >>> SYSCHK: @06C4 [DFA3:DFC3:0100:F103:04FC:0000:2B5E] FD Continue (Y/N) The format of the information provided is similar the PANIC report. @XXXX [-AF-:-BC-:-DE-:-HL-:-SP-:-IX-:-IY-] YY The syschk error codes YY is returned in the A register. Error Code YY Success 0x00 Undefined Error 0xFF Function Not Implemented 0xFE Invalid Function 0xFD Invalid Unit Number 0xFC Out Of Memory 0xFB Parameter Out Of Range 0xFA Media Not Present 0xF9 Hardware Not Present 0xF8 I/O Error 0xF7 Write Request To Read-Only Media 0xF6 Device Timeout 0xF5 Invalid Configuration 0xF4 Internal Error 0xF3","title":"SYSCHK"},{"location":"SystemGuide/#error-level-reporting","text":"placeholder","title":"Error Level reporting"},{"location":"SystemGuide/#build-time-errors","text":"","title":"Build time errors"},{"location":"SystemGuide/#build-chain-tool-errors","text":"place holder","title":"Build chain tool errors"},{"location":"SystemGuide/#assembly-time-check-errors","text":"placeholder","title":"Assembly time check errors"},{"location":"SystemGuide/#diagnostics","text":"","title":"Diagnostics"},{"location":"SystemGuide/#diagnostic-leds","text":"Progress through the boot and initialization process can be difficult to monitor due to the lack of console or video output. Access to these output devices does not become available until late the in the boot process. If these output devices are also involved with the issue trying to be resolved then trouble shooting is even more difficult. ROMWBW can be configured to display boot progress with the assistance of additional hardware. This can take the form of a front panel LED display or LED breakout debugging board connected to an 8-bit output port. Or it can utilize existing platform status LEDS. As the boot code executes, the LED output display is updated to indicate the execution progress. Platforms that have these capabilities built in have them enabled by default.","title":"Diagnostic LEDs"},{"location":"SystemGuide/#front-panel-display","text":"A LED front panel or breakout board needs to be connected the computers data, reset and port select lines. To enable this option the following settings can be made in the platforms custom configuration file. FPLED_ENABLE .SET TRUE ; ENABLE FRONT PANEL Custom hardware can be configured with : FPLED_IO .SET $nn ; USE PORT ADDRESS nn FPLED_INV .SET FALSE ; INVERTED LED BITS","title":"Front Panel display"},{"location":"SystemGuide/#platform-status-leds","text":"These status LEDs use preexisting status LEDs on each platform. Enable using: LEDENABLE .SET TRUE ; ENABLES STATUS LED Customize using: LEDMODE .SET LEDMODE_STD ; LEDMODE_[STD|SC|RTC|NABU] LEDPORT .SET $nn ; STATUS LED PORT ADDRESS The following table shows the ROMWBW process steps in relation to the panel display. PANEL RomWBW Processes ........ Initial boot Jump to start address Disable interrupts Set interrupt mode Initialize critical ports and baud rate .......O Setup initial stack Memory manager and CPU configuration Set top bank to be RAM ......OO Get and save battery condition Install HBIOS proxy in upper memory If platform is MBC reconfigure memory manager Setup \u201cROMLESS\u201d HBIOS image or \u2026 Copy HBIOS from ROM to RAM if RAM flag not set Jump to HBIOS in RAM Set running in RAM flag .....OOO Finalize configuration for running in RAM Check battery condition Check for recovery mode boot ....OOOO Identify CPU type ...OOOOO Set cpu oscillator speed Setup counter-timers Setup heap ..OOOOOO Preconsole initialization .OOOOOOO Boot delay Set boot console device Bios announcement OOOOOOOO Display platform information Display memory configuration Display CPU family Verify ROM checksum Report battery condition Perform device driver initialization Report watchdog status Mark HBIOS heap so it is preserved Switch from boot console to CRT if active Display device summary Execute boot loader","title":"Platform Status LEDS"},{"location":"SystemGuide/#appendix-a-driver-instance-data-fields","text":"This section is a work in progress\u2026 The following section outlines the read only data referenced by the SYSGET , subfunctions xxxFN for specific drivers.","title":"Appendix A Driver Instance Data fields"},{"location":"SystemGuide/#tms9918-driver","text":"Name Offset Bytes Description PPIA 0 1 PPI PORT A PPIB 1 1 PPI PORT B PPIC 2 1 PPI PORT C PPIX 3 1 PPI CONTROL PORT DATREG 4 1 IO PORT ADDRESS FOR MODE 0 CMDREG 5 1 IO PORT ADDRESS FOR MODE 1 Below are the register mirror values that HBIOS used for initialisation REG. 0 6 1 \\$00 - NO EXTERNAL VID REG. 1 7 1 \\$50 or \\$70 - SET MODE 1 and interrupt if enabled REG. 2 8 1 \\$00 - PATTERN NAME TABLE := 0 REG. 3 9 1 \\$00 - NO COLOR TABLE REG. 4 10 1 \\$01 - SET PATTERN GENERATOR TABLE TO \\$800 REG. 5 11 1 \\$00 - SPRITE ATTRIBUTE IRRELEVANT REG. 6 12 1 \\$00 - NO SPRITE GENERATOR TABLE REG. 7 13 1 \\$F0 - WHITE ON BLACK DCNTL* 14 1 Z180 DMA/WAIT CONTROL ONLY PRESENT FOR Z180 BUILDS","title":"TMS9918 Driver:"},{"location":"UserGuide/","text":"RomWBW User Guide \\ Version 3.6 \\ Wayne Warthen ( wwarthen@gmail.com ) \\ 31 May 2025 Preface This document is a general usage guide for the RomWBW software and is generally the best place to start with RomWBW. On a personal note, I found this document very difficult to write. Members of the retro-computing community have dramatically different experiences, skill levels, and desires. I realize some readers will find this document far too basic. Others will find it lacking in many areas. I am doing my best and encourage you to provide constructive feedback. Conventions Used Size Suffixes Within the documentation and in RomWBW in general, the use of size suffixes KB, MB, GB, and TB refer to the binary variant as shown below. The modern suffixes (KiB, MiB, etc.) are not used here because they were not prevalent during the time that the RomWBW OSes were used. This keeps all of RomWBW and associated applications consistent. Suffix Value Meaning KB 1024 1,024 bytes MB 1024 2 1,048,576 bytes GB 1024 3 1,073,741,824 bytes TB 1024 4 1,099,511,627,776 bytes Links and URLs Many of the references in the documentation to Internet addresses (URLs) do not provide the address in the text. However, these links are embedded and \u201cclickable\u201d within the documents. Your PDF viewer should highlight these links in some manner (typically an alternate color or an underline). Getting Started Installation In general, installation of RomWBW on your platform is very simple. You just need to program your ROM with the correct ROM image from the RomWBW distribution. Subsequently, you can write disk images on your disk drives (IDE disk, CF Card, SD Card, etc.) which then provides even more functionality. Depending on how you got your hardware, you may have already been provided with a pre-programmed ROM chip. If so, use that initially. Otherwise, you will need to use a ROM programmer to initially program your ROM chip. Please refer to the documentation that came with your ROM programmer for more information. The fully-built distribution releases are available on the RomWBW Releases Page ( https://github.com/wwarthen/RomWBW/releases ) of the repository. The distribution is a .zip archive. After downloading it to a working directory on your modern computer (Windows/Linux/Mac) use any zip tool to extract the contents of the archive. The Binary directory of the distribution contains the pre-built ROM images. Refer to RomWBW Hardware to identify the correct ROM image for your system. A complete list of the currently supported platforms is found in RomWBW Hardware . You must burn the correct ROM image that matches your hardware Once you have a running RomWBW system, you can generally update your ROM to a newer version in-situ with the included ROM Flashing tool (Will Sowerbutts\u2019 FLASH application) as described in the Upgrading chapter of this document. System Startup Initially, don\u2019t worry about trying to write a disk image to any disk (or CF/SD/USB) devices you have. This will be covered later. You will be able to boot and check out your system with just the ROM. Connect a serial terminal or computer with terminal emulation software to the primary serial port of your CPU board. You may need to refer to your hardware provider\u2019s documentation for details. A null-modem connection may be required. Set the baud rate as indicated in RomWBW Hardware . Set the line characteristics to 8 data bits, 1 stop bit, no parity, and no flow control. If possible, select ANSI or VT-100 terminal emulation. Hardware flow control is not required for terminal operation, but may be necessary for Serial Port Transfers . RomWBW will automatically attempt to detect and support typical add-on components for each of the systems supported. More information on the required system configuration and optional supported components for each ROM is found in RomWBW Hardware . Upon power-up, your terminal should display a sign-on banner within 2 seconds followed by hardware inventory and discovery information. When hardware initialization is completed, a boot loader prompt allows you to choose a ROM-based operating system, system monitor, application, or boot from a disk device. Core System Information During startup, the first few lines of information displayed provide the most basic information on your system. In the example above, these lines are the Core System Information: RomWBW HBIOS v3.5, 2025-03-01 RCBus [RCZ80_kio] Z80 @ 7.372MHz 0 MEM W/S, 1 I/O W/S, INT MODE 2, Z2 MMU 512KB ROM, 512KB RAM ROM VERIFY: 00 00 00 00 PASS The first line is a version identification banner for RomWBW. After that you see a group of 4 lines describing the basic system. In this example, the platform is the RCBus running a configuration named \u201cRCZ80_kio\u201d. The CPU is a Z80 with a current clock speed of 7.372 MHz. There are 0 memory wait states and 1 I/O wait state. Z80 interrupt mode 2 is active and the bank memory manager is type \u201cZ2\u201d which is standard for RCBus. The system has 512KB of ROM total and 512KB of RAM total. Finally, a verification of the checksums of the critical ROM banks is shown (all 4 should be 00). RomWBW attempts to detect the running configuration of the system at startup. Depending on your hardware, there may be inaccuracies in this section. For example, in some cases the CPU clock speed is assumed rather than actually measured. This does not generally affect the operation of your system. If you want to correct any of the information displayed, you can create a custom ROM which is described later. Hardware Discovery The next set of messages during boot show the hardware devices as they are probed and initially configured. In the example above, these lines are: KIO: IO=0x80 ENABLED CTC: IO=0x84 TIMER MODE=TIM16 AY: MODE=RCZ80 IO=0xD8 NOT PRESENT SIO0: IO=0x89 SIO MODE=115200,8,N,1 SIO1: IO=0x8B SIO MODE=115200,8,N,1 DSRTC: MODE=STD IO=0xC0 NOT PRESENT MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB FD: MODE=RCWDC IO=0x50 NOT PRESENT IDE: IO=0x10 MODE=RC IDE0: NO MEDIA IDE1: NO MEDIA PPIDE: IO=0x20 PPIDE0: LBA BLOCKS=0x00773800 SIZE=3815MB PPIDE1: NO MEDIA What you see will depend on your specific system and ROM, but should match the hardware present in your system. Each device has a tag that precedes the colon. This tag identifies the driver and instance of each device. For example, the tag \u201cSIO0:\u201d refers to the SIO serial port driver and specifically the first channel. The \u201cSIO1:\u201d tag refers to the second channel. In many cases you will see IO=0xNN in the data following the tag. This identifies the base I/O port address of the hardware device and is useful for identifying hardware conflicts. Note that you may see some lines indicating that the associated hardware is not present. Above, you can see that the FD driver did not find a floppy interface. Lines such as these are completely normal when your system does not have the associated hardware. Finally, be aware that all ROMs are configured to identify specific hardware devices at specific port addresses. If you add hardware to your system that is not automatically identified, you may need to build a custom ROM to add support for it. Building a custom ROM is covered later. RomWBW Hardware contains a list of the RomWBW hardware devices which may help you identify the hardware discovered in your system. Device Unit Assignments In order to support a wide variety of hardware, RomWBW HBIOS uses a modular approach to implementing device drivers and presenting devices to an operating system. In general, all devices are classified as one of the following: Disk (RAM/ROM Disk, Floppy Disk, Hard Disk, CF Card, SD Card, etc.) Character (Serial Ports, Parallel Ports, etc.) Video (Video Display/Keyboard Interfaces) Sound (Audio Playback Devices) RTC/NVRAM (Real Time Clock, Non-volatile RAM) System (Internal Services, e.g. Timer, DMA, etc.) HBIOS uses the concept of unit numbers to present a generic set of hardware devices to the operating system. As an example, a typical system might have a ROM Disk, RAM Disk, Floppy Drives, and Disk Drives. All of these are considered disk devices and are presented to the operating system as generic block devices. This means that each operating system does not need to embed code to interact directly with all of the different hardware devices \u2013 RomWBW takes care of that. In the final group of startup messages, a device unit summary table is displayed so that you can see how the actual hardware devices have been mapped to unit numbers during startup. Unit Device Type Capacity/Mode ---------- ---------- ---------------- -------------------- Char 0 UART0: RS-232 38400,8,N,1 Char 1 UART1: RS-232 38400,8,N,1 Disk 0 MD1: RAM Disk 384KB,LBA Disk 1 MD0: ROM Disk 384KB,LBA Disk 2 FD0: Floppy Disk 3.5\",DS/HD,CHS Disk 3 FD1: Floppy Disk 3.5\",DS/HD,CHS Disk 4 IDE0: CompactFlash 3815MB,LBA Disk 5 IDE1: Hard Disk -- Disk 6 PRPSD0: SD Card 1886MB,LBA Video 0 CVDU0: CRT Text,80x25 In this example, you can see that the system has a total of 7 Disk Units numbered 0-6. There are also 2 Character Units and 1 Video Unit. The table shows the unit numbers assigned to each of the devices. Notice how the unit numbers are assigned sequentially regardless of the specific device. There may or may not be media in the disk devices listed. For example, the floppy disk devices (Disk Units 2 & 3) may not have a floppy in the drive. Also note that Disk Unit 4 shows a disk capacity, but Disk Unit 5 does not. This is because the PPIDE interface of the system supports up to two drives, but there is only one actual drive attached. A unit number is assigned to all available devices regardless of whether they have actual media installed at boot time. Note that Character Unit 0 is the initial system console unless modified in a customized ROM image. If your system has an RTC/NVRAM device, it will not be listed in the unit summary table. Since only a single RTC/NVRAM device can exist in one system, unit numbers are not required nor used for this type of device. Also, System devices are not listed because they are entirely internal to RomWBW. Startup Example Here is an example of a fairly typical startup. Your system will have different devices and configuration, but the startup should look similar. RomWBW HBIOS v3.5, 2025-03-01 RCBus [RCZ80_kio] Z80 @ 7.372MHz 0 MEM W/S, 1 I/O W/S, INT MODE 2, Z2 MMU 512KB ROM, 512KB RAM ROM VERIFY: 00 00 00 00 PASS KIO: IO=0x80 ENABLED CTC: IO=0x84 TIMER MODE=TIM16 AY: MODE=RCZ80 IO=0xD8 NOT PRESENT SIO0: IO=0x89 SIO MODE=115200,8,N,1 SIO1: IO=0x8B SIO MODE=115200,8,N,1 DSRTC: MODE=STD IO=0xC0 NOT PRESENT MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB FD: MODE=RCWDC IO=0x50 NOT PRESENT IDE: IO=0x10 MODE=RC IDE0: NO MEDIA IDE1: NO MEDIA PPIDE: IO=0x20 PPIDE0: LBA BLOCKS=0x00773800 SIZE=3815MB PPIDE1: NO MEDIA Unit Device Type Capacity/Mode ---------- ---------- ---------------- -------------------- Char 0 SIO0: RS-232 115200,8,N,1 Char 1 SIO1: RS-232 115200,8,N,1 Disk 0 MD0: RAM Disk 256KB,LBA Disk 1 MD1: ROM Disk 384KB,LBA Disk 2 IDE0: Hard Disk -- Disk 3 IDE1: Hard Disk -- Disk 4 PPIDE0: CompactFlash 3815MB,LBA Disk 5 PPIDE1: Hard Disk -- If your system completes the ROM-based boot process successfully, you should see the RomWBW Boot Loader prompt. For example: RCBus [RCZ80_kio] Boot Loader Boot [H=Help]: If you get to this prompt, your system has completed the boot process and is ready to accept commands. Note that the Boot Loader is not an operating system or application. It is essentially the point where you choose which operating system or application you want RomWBW to execute. The Boot Loader is explained in detail in the next section. For now, you can try a few simple commands to confirm that you can interact with the system. At the Boot Loader prompt, you can type H for help. You can type L to list the available built-in ROM applications. If your terminal supports ANSI escape sequences, you can try the \u2018P\u2019 command to play a simple on-screen game. Instructions for the game are found in RomWBW Applications . If all of this seems fine, your ROM has been successfully programmed. Boot Loader Operation Once your system has completed the startup process, it presents a Boot Loader command prompt. The purpose of the Boot Loader is to select and launch a desired application or operating system. It also has the ability to configure some aspects of system operation. After starting your system, following the hardware initialization, you will see the RomWBW Boot Loader prompt. Below is an example. Note that the text preceding \u201cBoot Loader\u201d will vary and identifies your specific system and configuration. Mark IV [MK4_wbw] Boot Loader Boot [H=Help]: From the Boot Loader prompt, you can enter commands to select and launch any of the RomWBW operating systems or ROM applications. It also allows you to manage some basic settings of the system. To enter a command, just enter the command followed by \\ . For example, typing H will display a short command summary: Boot [H=Help]: h L - List ROM Applications D - Device Inventory R - Reboot System W - RomWBW Configure I [] - Set Console Interface/Baud Rate V [] - View/Set HBIOS Diagnostic Verbosity [.] - Boot Disk Unit/Slice Likewise the L command (List ROM Applications) will display the list of ROM Applications that you can launch right from the Boot Loader: Boot [H=Help]: L ROM Applications: M: Monitor Z: Z-System C: CP/M 2.2 F: Forth B: BASIC T: Tasty BASIC P: Play a Game N: Network Boot X: XModem Flash Updater U: User App A more complete description of these options is found below in System Management . Starting Applications from ROM To start a ROM application you just enter the corresponding letter at the Boot Loader prompt. In the following example, we launch the built-in Microsoft BASIC interpreter. From within BASIC, we use the BYE command to return to the Boot Loader: Boot [H=Help]: b Loading BASIC... Memory top? Z80 BASIC Ver 4.7b Copyright (C) 1978 by Microsoft 55603 Bytes free Ok bye Mark IV [MK4_wbw] Boot Loader Boot [H=Help]: The following ROM applications and OSes are available at the boot loader prompt: Application Description Monitor Z80 system debug monitor w/ Intel Hex loader CP/M 2.2 Digital Research CP/M 2.2 OS Z-System ZSDOS 1.1 w/ ZCPR 1 (Enhanced CP/M compatible OS) Forth Brad Rodriguez\u2019s ANSI compatible Forth language BASIC Microsoft ROM BASIC Tasty BASIC Dimitri Theuling\u2019s Tiny BASIC implementation Play A simple video game (requires ANSI terminal emulation) Network Boot Boot system via Wiznet MT011 device Flash Update Upload and flash a new ROMWBW image using xmodem User App User written application placeholder The User App is provided as a way to access a custom written ROM module. In the pre-built ROMs, selecting User App will just return to the Boot Loader menu. If you are interested in creating a custom application to run here, review the \u201cusrrom.asm\u201d file in the Source/HBIOS folder of the distribution. Each of the ROM Applications is documented in RomWBW Applications . Some of the applications (such as BASIC) also have their own independent manual in the Doc directory of the distribution. The OSes included in the ROM (CP/M 2.2 & Z-System) are described in the Operating Systems chapter of this document. In general, the command to exit any of these applications and restart the system is BYE . The exceptions are the Monitor which uses X and Play which uses Q . NOTE: Of the ROM Applications, only the operating systems (CP/M and Z-System) have the ability to interact with disk drives. So, other than these 2 OSes, the ROM Applications do not have any way to save or load data from peristent/disk storage. For example, if you launch BASIC from the Boot Loader, you will not be able to save or load your programs. You will need to start an operating system first and then run BASIC in order to save or load programs. Two of the ROM Applications are, in fact, complete operating systems. Specifically, \u201cCP/M 2.2\u201d and \u201cZ-System\u201d are provided so that you can actually start either operating system directly from your ROM. This technique is useful when: You don\u2019t yet have any real disk drives in your system You want to setup real disk drives for the first time You are upgrading your system and need to upgrade your real disk drives The RAM disk and ROM disk drives will be available even if you have no physical disk devices attached to your system. Booting an operating system from ROM is not intended as a way to use your operating system on a long-term basis. The ROM disk has only a small subset of the operating system files. Additionally, you cannot easily customize your ROM disk because you cannot write to it. For any significant use of an operating system, you should boot directly to the disk/slice that contains the complete operating system. This is described in the next section. Starting Operating Systems from Disk In order to make use of the more sophisticated operating systems available with RomWBW, you will need to boot an operating system from a disk. Setting up disks is described in detail later. For now, we will just go over the command line for performing this type of boot. From the Boot Loader prompt, you can enter a number ( \\ ) and optionally a dot followed by a second number ( \\ ). The \\ unit number refers to a disk unit that was displayed when the system was booted \u2013 essentially it specifies the specific physical disk drive you want to boot. The \\ numbers refers to a portion of the disk unit to boot. If no slice is specified, then it is equivalent to booting from the first slice (slice 0). Disk units and slices are described in more detail later. Following this, you should see the operating system startup messages. Your operating system prompt will typically be A> and when you look at the drive letter assignments, you should see that A: has been assigned to the disk and slice you selected to boot. If you receive the error message \u201cDisk not bootable!\u201d, you have either failed to properly initialize the disk and slice requested or you have selected an invalid/unavailable disk/slice. The following example shows a disk boot into the first slice of disk unit 4 which happens to be the CP/M 2.2 operating system on this disk. This is accomplished by entering just the number \u20184\u2019 and pressing \\