From 5eff29f4de19de299e34252e5942491b63d45eb2 Mon Sep 17 00:00:00 2001
From: wwarthen <wwarthen@users.noreply.github.com>
Date: Sat, 31 May 2025 14:11:23 +0000
Subject: [PATCH] deploy: f5e19873674abdd3399858fd281cfcb6647e553d

---
 Applications/index.html  |   2 +-
 Catalog/index.html       |   2 +-
 Hardware/index.html      |   2 +-
 Introduction/index.html  |   2 +-
 SystemGuide/index.html   |   2 +-
 UserGuide/index.html     |   2 +-
 index.html               | 260 ++++++++++++++++++++-------------------
 search/search_index.json |   2 +-
 8 files changed, 142 insertions(+), 132 deletions(-)

diff --git a/Applications/index.html b/Applications/index.html
index 8f715e80..9b293e5e 100644
--- a/Applications/index.html
+++ b/Applications/index.html
@@ -456,7 +456,7 @@
 <p><strong>RomWBW Applications Guide</strong> \
 Version 3.6 \
 MartinR \&amp; Phillip Summers  (<a href="mailto:"></a>) \
-30 May 2025</p>
+31 May 2025</p>
 <h1 id="summary">Summary</h1>
 <p>RomWBW is supplied with a suite of software applications that enhance
 the use of the system. Some of these applications have been written
diff --git a/Catalog/index.html b/Catalog/index.html
index 0b06f1c0..817c641e 100644
--- a/Catalog/index.html
+++ b/Catalog/index.html
@@ -332,7 +332,7 @@
 <p><strong>RomWBW Disk Catalog</strong> \
 Version 3.6 \
 Mark Pruden \&amp; Mykl Orders  (<a href="mailto:"></a>) \
-30 May 2025</p>
+31 May 2025</p>
 <h1 id="romwbw-distribution-file-catalog">RomWBW Distribution File Catalog</h1>
 <p>This document is a reference to the files found on the disk media
 distributed with RomWBW. Specifically, RomWBW provides a set of floppy
diff --git a/Hardware/index.html b/Hardware/index.html
index 6e27b0e6..ef6062d2 100644
--- a/Hardware/index.html
+++ b/Hardware/index.html
@@ -384,7 +384,7 @@
 <p><strong>RomWBW Hardware</strong> \
 Version 3.6 \
 Wayne Warthen  (<a href="mailto:wwarthen@gmail.com">wwarthen@gmail.com</a>) \
-30 May 2025</p>
+31 May 2025</p>
 <h1 id="overview">Overview</h1>
 <h2 id="supported-platforms">Supported Platforms</h2>
 <p>This section contains a summary of the system configuration target for
diff --git a/Introduction/index.html b/Introduction/index.html
index 9b0ee826..bc20a9c0 100644
--- a/Introduction/index.html
+++ b/Introduction/index.html
@@ -189,7 +189,7 @@
 <p><strong>RomWBW Introduction</strong> \
 Version 3.6 \
 Wayne Warthen  (<a href="mailto:wwarthen@gmail.com">wwarthen@gmail.com</a>) \
-30 May 2025</p>
+31 May 2025</p>
 <h1 id="overview">Overview</h1>
 <p>RomWBW software provides a complete, commercial quality implementation
 of CP/M (and workalike) operating systems and applications for modern
diff --git a/SystemGuide/index.html b/SystemGuide/index.html
index aabcb0ca..6390c598 100644
--- a/SystemGuide/index.html
+++ b/SystemGuide/index.html
@@ -659,7 +659,7 @@
 <p><strong>RomWBW System Guide</strong> \
 Version 3.6 \
 Wayne Warthen  (<a href="mailto:wwarthen@gmail.com">wwarthen@gmail.com</a>) \
-30 May 2025</p>
+31 May 2025</p>
 <h1 id="overview">Overview</h1>
 <p>The objective of RomWBW is to provide firmware, operating systems, and
 applications targeting the Z80 family of CPUs. The firmware, in the form
diff --git a/UserGuide/index.html b/UserGuide/index.html
index a7a4842c..708994bc 100644
--- a/UserGuide/index.html
+++ b/UserGuide/index.html
@@ -535,7 +535,7 @@
 <p><strong>RomWBW User Guide</strong> \
 Version 3.6 \
 Wayne Warthen  (<a href="mailto:wwarthen@gmail.com">wwarthen@gmail.com</a>) \
-30 May 2025</p>
+31 May 2025</p>
 <h4 id="preface">Preface</h4>
 <p>This document is a general usage guide for the RomWBW software and is
 generally the best place to start with RomWBW.</p>
diff --git a/index.html b/index.html
index 6f5425c0..b69a4c57 100644
--- a/index.html
+++ b/index.html
@@ -149,19 +149,21 @@
 </div></div>
                     <div class="col-md-9" role="main">
 
-<p>$define{doc_title}{ReadMe}$
-$include{"Basic.h"}$</p>
+<p><strong>RomWBW ReadMe</strong> \
+Version 3.6 \
+Wayne Warthen  (<a href="mailto:wwarthen@gmail.com">wwarthen@gmail.com</a>) \
+31 May 2025</p>
 <h1 id="overview">Overview</h1>
-<p>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.</p>
-<p>A wide variety of platforms are supported including those
-produced by these developer communities:</p>
+<p>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.</p>
+<p>A wide variety of platforms are supported including those produced by
+these developer communities:</p>
 <ul>
 <li><a href="https://www.retrobrewcomputers.org">RetroBrew Computers</a>
   (<a href="https://www.retrobrewcomputers.org">https://www.retrobrewcomputers.org</a>)</li>
-<li><a href="https://rc2014.co.uk">RC2014</a> (<a href="https://rc2014.co.uk">https://rc2014.co.uk</a>), \
-  <a href="https://groups.google.com/g/rc2014-z80">RC2014-Z80</a>
+<li><a href="https://rc2014.co.uk">RC2014</a> (<a href="https://rc2014.co.uk">https://rc2014.co.uk</a>),<br />
+<a href="https://groups.google.com/g/rc2014-z80">RC2014-Z80</a>
   (<a href="https://groups.google.com/g/rc2014-z80">https://groups.google.com/g/rc2014-z80</a>)</li>
 <li><a href="https://groups.google.com/g/retro-comp">Retro Computing</a>
   (<a href="https://groups.google.com/g/retro-comp">https://groups.google.com/g/retro-comp</a>)</li>
@@ -174,7 +176,8 @@ produced by these developer communities:</p>
 <ul>
 <li>Z80 Family CPUs including Z80, Z180, and Z280</li>
 <li>Banked memory services for several banking designs</li>
-<li>Disk drivers for RAM, ROM, Floppy, IDE ATA/ATAPI, CF, SD, USB, Zip, Iomega</li>
+<li>Disk drivers for RAM, ROM, Floppy, IDE ATA/ATAPI, CF, SD, USB, Zip,
+  Iomega</li>
 <li>Serial drivers including UART (16550-like), ASCI, ACIA, SIO</li>
 <li>Video drivers including TMS9918, SY6545, MOS8563, HD6445</li>
 <li>Keyboard (PS/2) drivers via VT8242 or PPI interfaces</li>
@@ -197,96 +200,103 @@ 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.</p>
-<p>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 -- 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.</p>
-<p>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 "combo" 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.</p>
-<p>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.</p>
+OSes and allows up to 2GB of accessible storage on a single device, with
+up to 128MB accessible at any one time.</p>
+<p>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 – 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.</p>
+<p>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 “combo” 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.</p>
+<p>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.</p>
 <p>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
+slices or on stand-alone media. This makes exchanging files with modern
 OSes such as Windows, MacOS, and Linux very easy.</p>
 <h1 id="acquiring-romwbw">Acquiring RomWBW</h1>
 <p>The <a href="https://github.com/wwarthen/RomWBW">RomWBW Repository</a>
 (<a href="https://github.com/wwarthen/RomWBW">https://github.com/wwarthen/RomWBW</a>) on GitHub is the official
-distribution location for all project source and documentation.
-The fully-built distribution releases are available on the
-<a href="https://github.com/wwarthen/RomWBW/releases">RomWBW Releases Page</a>
-(<a href="https://github.com/wwarthen/RomWBW/releases">https://github.com/wwarthen/RomWBW/releases</a>) of the repository.
-On this page, you will normally see a Development Snapshot as well as
+distribution location for all project source and documentation. The
+fully-built distribution releases are available on the <a href="https://github.com/wwarthen/RomWBW/releases">RomWBW Releases
+Page</a>
+(<a href="https://github.com/wwarthen/RomWBW/releases">https://github.com/wwarthen/RomWBW/releases</a>) 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.</p>
-<p>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.</p>
+<p>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.</p>
 <p>All source code and distributions are maintained on GitHub. Code
 contributions are very welcome.</p>
 <h1 id="installation-operation">Installation &amp; Operation</h1>
 <p>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
+distribution. Subsequently, you can write disk images on your disk
 drives (IDE disk, CF Card, SD Card, etc.) which then provides even more
 functionality.</p>
-<p>Complete instructions for installation and operation of RomWBW are
-found in the $doc_user$.  It is also a good idea to review the
-<a href="https://github.com/wwarthen/RomWBW/blob/master/RELEASE_NOTES.md">Release Notes</a>
+<p>Complete instructions for installation and operation of RomWBW are found
+in the <a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20User%20Guide.pdf">RomWBW User
+Guide</a>.
+It is also a good idea to review the <a href="https://github.com/wwarthen/RomWBW/blob/master/RELEASE_NOTES.md">Release
+Notes</a>
 for helpful release-specific information.</p>
 <h2 id="documentation">Documentation</h2>
-<p>Documentation for $doc_product$ includes:</p>
+<p>Documentation for RomWBW includes:</p>
 <ul>
-<li>$doc_intro$</li>
-<li>$doc_user$</li>
-<li>$doc_sys$</li>
-<li>$doc_apps$</li>
-<li>$doc_catalog$</li>
-<li>$doc_hardware$</li>
+<li><a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20Introduction.pdf">RomWBW
+  Introduction</a></li>
+<li><a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20User%20Guide.pdf">RomWBW User
+  Guide</a></li>
+<li><a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20System%20Guide.pdf">RomWBW System
+  Guide</a></li>
+<li><a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20Applications.pdf">RomWBW
+  Applications</a></li>
+<li><a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20Disk%20Catalog.pdf">RomWBW Disk
+  Catalog</a></li>
+<li><a href="https://github.com/wwarthen/RomWBW/raw/master/Doc/RomWBW%20Hardware.pdf">RomWBW
+  Hardware</a></li>
 </ul>
 <h1 id="acknowledgments">Acknowledgments</h1>
-<p>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 --
-please let me know if I missed you!</p>
+<p>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 – please
+let me know if I missed you!</p>
 <ul>
 <li>
-<p>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.</p>
+<p>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.</p>
 </li>
 <li>
 <p>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.</p>
+  derived and he has always been a great source of knowledge and advice.</p>
 </li>
 <li>
-<p>Douglas Goodall contributed code, time, testing, and advice in  "the
-  early days". He created an entire suite of application programs to
+<p>Douglas Goodall contributed code, time, testing, and advice in “the
+  early days”. 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
+  due to internal changes within RomWBW. As of RomWBW 2.6, these
   applications are no longer provided.</p>
 </li>
 <li>
-<p>Sergey Kiselev created several hardware platforms for RomWBW
-  including the very popular Zeta.</p>
+<p>Sergey Kiselev created several hardware platforms for RomWBW including
+  the very popular Zeta.</p>
 </li>
 <li>
-<p>David Giles created support for the Z180 CSIO which is now included
-  SD Card driver.</p>
+<p>David Giles created support for the Z180 CSIO which is now included SD
+  Card driver.</p>
 </li>
 <li>
 <p>Phil Summers contributed the Forth and BASIC adaptations in ROM, the
@@ -298,14 +308,14 @@ please let me know if I missed you!</p>
   platform.</p>
 </li>
 <li>
-<p>Spencer Owen created the RC2014 series of hobbyist kit computers
-  which has exponentially increased RomWBW usage.  Some of his kits
-  include RomWBW.</p>
+<p>Spencer Owen created the RC2014 series of hobbyist kit computers which
+  has exponentially increased RomWBW usage. Some of his kits include
+  RomWBW.</p>
 </li>
 <li>
 <p>Stephen Cousins has likewise created a series of hobbyist kit
-  computers at Small Computer Central and is distributing RomWBW
-  with many of them.</p>
+  computers at Small Computer Central and is distributing RomWBW with
+  many of them.</p>
 </li>
 <li>
 <p>Alan Cox has contributed some driver code and has provided a great
@@ -340,10 +350,9 @@ please let me know if I missed you!</p>
 <p>The RomWBW Disk Catalog document was produced by Mykl Orders.</p>
 </li>
 <li>
-<p>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.</p>
+<p>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.</p>
 </li>
 <li>
 <p>Martin R has provided substantial help reviewing and improving the
@@ -352,7 +361,9 @@ please let me know if I missed you!</p>
 <li>
 <p>Mark Pruden has made a wide variety of contributions including:</p>
 </li>
-<li>significant content in the Disk Catalog and User Guide</li>
+<li>
+<p>significant content in the Disk Catalog and User Guide</p>
+</li>
 <li>creation of the Introduction and Hardware documents</li>
 <li>Z3PLUS operating system disk image</li>
 <li>COPYSL and SLABEL utility</li>
@@ -364,42 +375,41 @@ please let me know if I missed you!</p>
 <p>Jacques Pelletier has contributed the DS1501 RTC driver code.</p>
 </li>
 <li>
-<p>Jose Collado has contributed enhancements to the TMS driver
-  including compatibility with standard TMS register configuration.</p>
+<p>Jose Collado has contributed enhancements to the TMS driver including
+  compatibility with standard TMS register configuration.</p>
 </li>
 <li>
 <p>Kevin Boone has contributed a generic HBIOS date/time utility (WDATE).</p>
 </li>
 <li>
-<p>Matt Carroll has contributed a fix to XM.COM that corrects the
-  port specification when doing a send.</p>
+<p>Matt Carroll has contributed a fix to XM.COM that corrects the port
+  specification when doing a send.</p>
 </li>
 <li>
-<p>Dean Jenkins enhanced the build process to accommodate the
-  Raspberry Pi 4.</p>
+<p>Dean Jenkins enhanced the build process to accommodate the Raspberry
+  Pi 4.</p>
 </li>
 <li>
 <p>Tom Plano has contributed a new utility (HTALK) to allow talking
   directly to HBIOS COM ports.</p>
 </li>
 <li>
-<p>Lars Nelson has contributed several generic utilities such as
-  a universal (OS agnostic) UNARC application.</p>
+<p>Lars Nelson has contributed several generic utilities such as a
+  universal (OS agnostic) UNARC application.</p>
 </li>
 <li>
 <p>Dylan Hall added support for specifying a secondary console.</p>
 </li>
 <li>
-<p>Bill Shen has contributed boot loaders for several of his
-  systems.</p>
+<p>Bill Shen has contributed boot loaders for several of his systems.</p>
 </li>
 <li>
-<p>Laszlo Szolnoki has contributed an EF9345 video display
-  controller driver.</p>
+<p>Laszlo Szolnoki has contributed an EF9345 video display controller
+  driver.</p>
 </li>
 <li>
-<p>Ladislau Szilagyi has contributed an enhanced version of
-  CP/M Cowgol that leverages RomWBW memory banking.</p>
+<p>Ladislau Szilagyi has contributed an enhanced version of CP/M Cowgol
+  that leverages RomWBW memory banking.</p>
 </li>
 <li>
 <p>Les Bird has contributed support for the NABU w/ Option Board</p>
@@ -407,51 +417,51 @@ please let me know if I missed you!</p>
 </ul>
 <p>Contributions of all kinds to RomWBW are very welcome.</p>
 <h1 id="licensing">Licensing</h1>
-<p>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.</p>
-<p>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.</p>
-<p>You should have received a copy of the GNU General Public License
-along with RomWBW.  If not, see <a href="https://www.gnu.org/licenses/">https://www.gnu.org/licenses/</a>.</p>
-<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>You should have received a copy of the GNU General Public License along
+with RomWBW. If not, see <a href="https://www.gnu.org/licenses/">https://www.gnu.org/licenses/</a>.</p>
+<p>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.</p>
 <p>If anyone feels their work is being used outside of its intended
 licensing, please notify:</p>
 <blockquote>
-<p>$doc_author$ \
-<a href="mailto:$doc_authmail$">$doc_authmail$</a></p>
+<p>Wayne Warthen<br />
+<a href="&#109;&#97;&#105;&#108;&#116;&#111;&#58;&#119;&#119;&#97;&#114;&#116;&#104;&#101;&#110;&#64;&#103;&#109;&#97;&#105;&#108;&#46;&#99;&#111;&#109;">&#119;&#119;&#97;&#114;&#116;&#104;&#101;&#110;&#64;&#103;&#109;&#97;&#105;&#108;&#46;&#99;&#111;&#109;</a></p>
 </blockquote>
-<p>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.</p>
+<p>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.</p>
 <p>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.</p>
-<p>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.</p>
+composed of multiple components with different licenses. It is believed
+that in all such cases the licenses are compatible with GPL version 3.</p>
+<p>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.</p>
 <p>All contributions to RomWBW are subject to this license.</p>
 <h1 id="getting-assistance">Getting Assistance</h1>
 <p>The best way to get assistance with RomWBW or any aspect of the
 RetroBrew Computers projects is via one of the community forums:</p>
 <ul>
 <li><a href="https://www.retrobrewcomputers.org/forum/">RetroBrew Computers Forum</a></li>
-<li><a href="https://groups.google.com/forum/#!forum/rc2014-z80">RC2014 Google Group</a></li>
-<li><a href="https://groups.google.com/forum/#!forum/retro-comp">retro-comp Google Group</a></li>
+<li><a href="https://groups.google.com/forum/#!forum/rc2014-z80">RC2014 Google
+  Group</a></li>
+<li><a href="https://groups.google.com/forum/#!forum/retro-comp">retro-comp Google
+  Group</a></li>
 </ul>
-<p>Submission of issues and bugs are welcome at the
-<a href="https://github.com/wwarthen/RomWBW">RomWBW GitHub Repository</a>.</p>
-<p>Also feel free to email $doc_author$ at <a href="mailto:$doc_authmail$">$doc_authmail$</a>.</p></div>
+<p>Submission of issues and bugs are welcome at the <a href="https://github.com/wwarthen/RomWBW">RomWBW GitHub
+Repository</a>.</p>
+<p>Also feel free to email Wayne Warthen at <a href="&#109;&#97;&#105;&#108;&#116;&#111;&#58;&#119;&#119;&#97;&#114;&#116;&#104;&#101;&#110;&#64;&#103;&#109;&#97;&#105;&#108;&#46;&#99;&#111;&#109;">&#119;&#119;&#97;&#114;&#116;&#104;&#101;&#110;&#64;&#103;&#109;&#97;&#105;&#108;&#46;&#99;&#111;&#109;</a>.</p></div>
             </div>
         </div>
 
@@ -533,5 +543,5 @@ RetroBrew Computers projects is via one of the community forums:</p>
 
 <!--
 MkDocs version : 1.6.1
-Build Date UTC : 2025-05-31 02:24:55.812478+00:00
+Build Date UTC : 2025-05-31 14:11:20.526415+00:00
 -->
diff --git a/search/search_index.json b/search/search_index.json
index f18fd5ab..1113f311 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":"$define{doc_title}{ReadMe}$ $include{\"Basic.h\"}$ 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 -- 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 \"combo\" 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 $doc_user$. It is also a good idea to review the Release Notes for helpful release-specific information. Documentation Documentation for $doc_product$ includes: $doc_intro$ $doc_user$ $doc_sys$ $doc_apps$ $doc_catalog$ $doc_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 -- 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 \"the early days\". 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: $doc_author$ \\ $doc_authmail$ 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 $doc_author$ at $doc_authmail$ .","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 -- 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 \"combo\" 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 $doc_user$. It is also a good idea to review the Release Notes for helpful release-specific information.","title":"Installation &amp; Operation"},{"location":"#documentation","text":"Documentation for $doc_product$ includes: $doc_intro$ $doc_user$ $doc_sys$ $doc_apps$ $doc_catalog$ $doc_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 -- 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 \"the early days\". 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: $doc_author$ \\ $doc_authmail$ 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 $doc_author$ at $doc_authmail$ .","title":"Getting Assistance"},{"location":"Applications/","text":"RomWBW Applications Guide \\ Version 3.6 \\ MartinR \\& Phillip Summers ( ) \\ 30 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 <u> [<c>] - Set Console Interface/Baud code V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 <drv> = ASSIGN ASSIGN [ <drv> ],... ASSIGN <drv> =[ <device> :[ <slice> ]],... ASSIGN <tgtdrv> = <srcdrv> ,... ASSIGN /B='*'<option>'*'['*'<option>'*'['*'<option>'*'...]] 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 <drv> will display the assignment for the specific drive For example, ASSIGN C: will display the assignment for drive C:. ASSIGN <drv> = <device> [: <slice> ] 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 <drv> = 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 <tgtdrv> = <srcdrv> 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= <option><option> \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 [ \\<filename> ] 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 <drv> Usage CLRDIR <drv> 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 [ <speed> [,[ <memws> ][,[ <iows> ]]] CPUSPD (W)armBoot CPUSPD (C)oldBoot <speed> is one of (H)alf, (F)ull, (D)ouble, or (Q)uad. <memws> is a number specifying the desired memory wait states. <iows> 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 \\<disk>.\\<unit> format. The syntax (similar to copy) for the command is: COPYSL \\<destunit> [ . \\<slice> ] = \\<srcunit> [ . \\<slice> ] [ / \\<options> ] 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 <path> FAT COPY <src> <dst> FAT REN <from> <to> FAT DEL <path>[<file>|<dir>] FAT MD <path> FAT FORMAT <drv> <path> is a FAT path <src> , <dst> are FAT or CP/M filenames <from> , <to> are FAT filenames <file> is a FAT filename <dir> is a FAT directory name <drv> is a RomWBW disk unit number CP/M filespec: <d> :FILENAME.EXT ( <d> is CP/M drive letter A-P) FAT filespec: <u> :/DIR/FILENAME.EXT ( <u> 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 <filename> [options] FLASH VERIFY <filename> [options] FLASH WRITE <filename> [options] <filename> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/P] /? displays command usage and version information <n> is the character device unit number <baud> is numerical baudrate <parity> is (N)one, (O)dd, (E)ven, (M)ark, or (S)pace <databits> is number of data bits, typically 7 or 8 <stopbits> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/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 <dest> = <src> <dest> is the drive to receive the operating system image or alternatively a filename to save the operating system image <src> is the drive containing an operating system image or alternatively a filename containing the system image to be placed on the destination Usage Both <dest> and <src> 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 [ \\<filename> ] 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 <filename> * * <filename> 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 <filename> <filename> 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 <hr> <min> WDATE <hr> <min> <sec> WDATE <year> <month> <day> <hr> <min> <sec> 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 <filename> XM SK <filename> XM L <library> <filename> XM LK <library> <filename> XM R <filename> 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 <filename> is the name of a file to send or receive <library> 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 \\<mode>\\<protocol>\\<unit> [ \\<filename> ] where \\<mode> 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 \\<protocol> can be: X - Xmodem 128 byte blocks (CRC) C - Xmodem 128 byte blocks (Checksum) K - Ymodem 1024 byte blocks (CRC only) and \\<unit> 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 [\\<unit>] \\<unit> 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 \\<unit> 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 <u> [<c>] - Set Console Interface/Baud code V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 &amp; 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 <drv> = ASSIGN ASSIGN [ <drv> ],... ASSIGN <drv> =[ <device> :[ <slice> ]],... ASSIGN <tgtdrv> = <srcdrv> ,... ASSIGN /B='*'<option>'*'['*'<option>'*'['*'<option>'*'...]]","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 <drv> will display the assignment for the specific drive For example, ASSIGN C: will display the assignment for drive C:. ASSIGN <drv> = <device> [: <slice> ] 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 <drv> = 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 <tgtdrv> = <srcdrv> 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= <option><option> \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 [ \\<filename> ]","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 <drv>","title":"Syntax"},{"location":"Applications/#usage_3","text":"CLRDIR <drv> 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 [ <speed> [,[ <memws> ][,[ <iows> ]]] CPUSPD (W)armBoot CPUSPD (C)oldBoot <speed> is one of (H)alf, (F)ull, (D)ouble, or (Q)uad. <memws> is a number specifying the desired memory wait states. <iows> 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 \\<disk>.\\<unit> format. The syntax (similar to copy) for the command is: COPYSL \\<destunit> [ . \\<slice> ] = \\<srcunit> [ . \\<slice> ] [ / \\<options> ] 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 <path> FAT COPY <src> <dst> FAT REN <from> <to> FAT DEL <path>[<file>|<dir>] FAT MD <path> FAT FORMAT <drv> <path> is a FAT path <src> , <dst> are FAT or CP/M filenames <from> , <to> are FAT filenames <file> is a FAT filename <dir> is a FAT directory name <drv> is a RomWBW disk unit number CP/M filespec: <d> :FILENAME.EXT ( <d> is CP/M drive letter A-P) FAT filespec: <u> :/DIR/FILENAME.EXT ( <u> 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 <filename> [options] FLASH VERIFY <filename> [options] FLASH WRITE <filename> [options] <filename> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/P] /? displays command usage and version information <n> is the character device unit number <baud> is numerical baudrate <parity> is (N)one, (O)dd, (E)ven, (M)ark, or (S)pace <databits> is number of data bits, typically 7 or 8 <stopbits> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/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 <dest> = <src> <dest> is the drive to receive the operating system image or alternatively a filename to save the operating system image <src> 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 <dest> and <src> 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 [ \\<filename> ]","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 <filename> * * <filename> 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 <filename> <filename> 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 <hr> <min> WDATE <hr> <min> <sec> WDATE <year> <month> <day> <hr> <min> <sec>","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 <filename> XM SK <filename> XM L <library> <filename> XM LK <library> <filename> XM R <filename> 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 <filename> is the name of a file to send or receive <library> 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 \\<mode>\\<protocol>\\<unit> [ \\<filename> ] where \\<mode> 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 \\<protocol> can be: X - Xmodem 128 byte blocks (CRC) C - Xmodem 128 byte blocks (Checksum) K - Ymodem 1024 byte blocks (CRC only) and \\<unit> 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 [\\<unit>] \\<unit> 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 \\<unit> 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 ( ) \\ 30 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 ) \\ 30 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 ) \\ 30 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 &amp; 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 ) \\ 30 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 \\<Reserved> 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 \\<Reserved> 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 ) \\ 30 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 <enter> for help. You can type L <enter> 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 \\<enter> . For example, typing H<enter> will display a short command summary: Boot [H=Help]: h L - List ROM Applications D - Device Inventory R - Reboot System W - RomWBW Configure I <u> [<c>] - Set Console Interface/Baud Rate V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 ( \\<diskunit> ) and optionally a dot followed by a second number ( \\<slice> ). The \\<disk unit> 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 \\<slice> 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 \\<enter> . Boot [H=Help]: 4 Booting Disk Unit 4, Slice 0, Sector 0x00000800... Volume \"Unlabelled\" [0xD000-0xFE00, entry @ 0xE600]... CBIOS v3.1.1-pre.194 [WBW] Formatting RAMDISK... Configuring Drives... A:=IDE0:0 B:=MD0:0 C:=MD1:0 D:=FD0:0 E:=FD1:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 I:=PRPSD0:0 J:=PRPSD0:1 K:=PRPSD0:2 L:=PRPSD0:3 1081 Disk Buffer Bytes Free CP/M-80 v2.2, 54.0K TPA A> Notice that a list of drive letters and their assignments to RomWBW devices and slices is displayed during the initialization of the operating system. Here is another example where we are booting disk unit 4, slice 3 which is the CP/M 3 operating system on this disk: Boot [H=Help]: 4.3 Booting Disk Unit 4, Slice 3, Sector 0x0000C800... Volume \"Unlabelled\" [0x0100-0x1000, entry @ 0x0100]... CP/M V3.0 Loader Copyright (C) 1998, Caldera Inc. BNKBIOS3 SPR F600 0800 BNKBIOS3 SPR 4500 3B00 RESBDOS3 SPR F000 0600 BNKBDOS3 SPR 1700 2E00 60K TPA CP/M v3.0 [BANKED] for HBIOS v3.5 A> Some operating systems (such as CP/M 3 shown above) do not list the drive assignments during initialization. In this case, you can use the ASSIGN command to display the current assignments. The Boot Loader simply launches whatever is in the disk unit/slice you have specified. It does not know what operating system is at that location. The layout of operating systems on disk media is described in the Disk Images section of this document. Auto-Submit Batch Files All of the operating systems supplied with RomWBW have the ability to execute a \u201cbatch\u201d of commands by creating a batch submission file containing the commands to be executed. The mechanism for running commands automatically at startup varies by operating system. In some cases, it was built into the original operating system. In other cases, I have added this capability in the RomWBW BIOS of the operating system. In all cases, the file containing the commands to run at startup must be on the boot drive (A:). RomWBW automatically assigns A: to the disk slice you choose to boot. Adding a startup command file to the ROM Disk is not recommended because it would require customizing and building a new ROM. Use of bootable disk slices is preferred since the startup command files can be added/edited without any special system customization. Here is an overview for each operating system: CP/M 2.2 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Note that original CP/M 2.2 itself did not have this ability \u2013 it was added to the RomWBW CP/M 2.2 BIOS. The use of SUBMIT files is documented in Section 1.6.7 SUBMIT Command of the CPM Manual included in the Doc/CPM folder of the RomWBW distribution. Z-System (ZSDOS 1.1) - Will run run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Works exactly the same as CP/M 2.2. The original Z-System ZSDOS 1.1 did not have this ability \u2013 it was added to the RomWBW Z-System BIOS. The Z-System documentation does not cover the use of SUBMIT files \u2013 please refer to the CP/M 2.2 documentation. NZCOM - Will run the command STARTZCM at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the NZCOM Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the NZCOM boot process. Note that NZCOM itself is launched from ZSDOS via the included PROFILE.SUB file. CP/M 3 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. This mechanism is built into the CP/M 3 operating system. Please see Section 4.5 Executing Multiple Commands and Section 5.2.74 Executing the SUBMIT Command of the CPM3 Users Guide included in the Doc/CPM folder of the RomWBW distribution. Z3PLUS - Will run the command STARTZ3P at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the Z3PLUS Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the Z3PLUS boot process. Note that Z3PLUS itself is launched from CP/M 3 via the included PROFILE.SUB file. ZPM3 - Will run the command STARTZPM at startup. This is normally an alias file. You use SALIAS to edit such files. ZPM3 has no real documentation. The NZCOM documentation of STARTZCM is generally correct for ZPM3. Since RomWBW can utilize many disk slices, it is very easy to create slices for specific workflows (editing, software development, games, etc.). You can then just boot to the slice that is optimized for the task you want to perform. Each such slice may have its own startup command batch file that customizes the environment for the specific workflow desired. System Management Listing Device Inventory The device units available in your system are listed in the boot messages. However, if that list has scrolled off of your screen, you can use the \u2018D\u2019 command to display a list of them at any time from the Boot Loader prompt. Unit Device Type Capacity/Mode ---------- ---------- ---------------- -------------------- Char 0 ASCI0: RS-232 38400,8,N,1 Char 1 ASCI1: RS-232 38400,8,N,1 Char 2 UART0: RS-232 38400,8,N,1 Char 3 UART1: RS-232 38400,8,N,1 Char 4 UART2: RS-232 38400,8,N,1 Char 5 UART3: RS-232 38400,8,N,1 Char 6 TERM0: Terminal Video 0,ANSI Char 7 PRPCON0: Terminal Term Module,ANSI Disk 0 MD0: RAM Disk 352KB,LBA Disk 1 MD1: Flash Drive 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 IDE2: CompactFlash 3823MB,LBA Disk 7 IDE3: Hard Disk -- Disk 8 IDE4: Hard Disk -- Disk 9 IDE5: Hard Disk -- Disk 10 SD0: SD Card -- Disk 11 PRPSD0: SD Card 15193MB,LBA Video 0 TMS0: CRT Text,40x24 Sound 0 SND0: AY-3-8910 3+1 CHANNELS Rebooting the System The \u2018R\u2019 command within the Boot Loader performs a software reset of the system. The system will perform a startup just like powering up or pressing the hardware reset button (although the hardware is not physically reset). There is generally no need to do this, but it can be convenient when you want to see the boot messages again or ensure your system is in a clean state. Boot [H=Help]: r Restarting System... Setting NVRAM Options On systems with RTC devices (that have Non-Volatile RAM), RomWBW supports storing some limited configuration option options inside this NVRAM. Several configuration options are currently supported, these are known as Switches Specify Automatic boot at startup, after an optional delay (AB) Define the Disk or ROM App to be booted at for automatic boot (BO) RomWBW uses bytes located at the start of RTC NVRAM, and includes a checksum of the bytes in NVRAM to check for integrity before using the configuration. Initially NVRAM has to be reset (with default values), before it can be used. As well as setting defaults, it also writes the correct checksum, and allows the NVRAM to be accessed and to store the RomWBW config. This is an explicit step that must be done, as any existing data stored is overwritten. If you are using NVRAM for other purposes, then you can continue to do so so long as you do NOT perform this Reset step. NVRAM may also need to be reset in these circumstances: When there has been a loss of power to the NVRAM. When upgrading to a new RomWBW version, or a RomWBW version that has new switches. If the NVRAM has been overwritten by another application. If you want to continue to use NVRAM in your applications you may want to consider storing your data above the RomWBW Switch data. To configure these options an inbuilt ROM application is provided which can be accessed by the command \u201c W \u201d from the RomWBW boot menu. This application is also built as a CP/M utility, but is not included on an disk image, it is found in the Binary/Applications folder of the RomWBW distribution. For further guidance on using this application please see the section \u201cRomWBW System Configuration\u201d in the RomWBW Applications document. If your system has both a Front Panel as well as NVRAM, be aware that the Front Panel switches take precedence over the NVRAM configuration settings. Note that the WizNet class of Network devices also contain NVRAM which is entirely separate from the RomWBW configuration NVRAM described here. A separate utility is used to set the WizNet NVRAM (see CP/NET Client Setup ). RomWBW Applications Changing Console and Console Speed Your system can support a number of devices for the console. They may be VDU type devices or serial devices. If you want to change which device is the console, the I menu option can be used to choose the unit and its speed. The command format is I <unit> [<baudrate>] where \\<unit> is the character unit to select and \\<baudrate> is the optional baud rate. Supported baud rates are: 75 450 1800 7200 38400 115200 460800 1843200 150 600 2400 9600 28800 153600 614400 2457600 225 900 3600 14400 57600 230400 921600 3686400 300 1200 4800 19200 76800 307200 1228800 7372800 Here is an example of changing the console to unit #1 (the second serial port) and switching the port to 9600 baud: Boot [H=Help]: i 1 9600 Change speed now. Press a key to resume. Console on Unit #1 At this point, the Boot Loader prompt will be displayed on character unit #1. Note that not all character devices support changing baud rates and some only support a limited subset of the baud rates listed. If you attempt to select an invalid baud rate for your system, you will get an error message. HBIOS Diagnostic Verbosity The \u2018V\u2019 command of the Boot Loader allows you to view and optionally change the level of diagnostic messages that RomWBW will produce. The normal verbosity level is 4, which means to display only fatal errors. You can increase this level to see more warnings when function calls to RomWBW HBIOS detect problems. The use of diagnostic levels above 4 are really intended only for software developers. I do not recommend changing this under normal circumstances. Console Takeover If your system has more than one character unit, then the Boot Loader will \u201cpoll\u201d all of the character devices for a request to make any of the alternate character devices the active console. This is called a console takeover request. This functionality must be enabled in the ROM build configuration, but currently it is for all standard ROMs. To request a console takeover, you just press the \\<space> character twice in a row at the port or terminal that you want to move the console to. The terminal or communication software must be configured for the default serial port speed and data bits for this to work. A takeover request is only possible while the active console is showing the Boot Loader prompt prior to typing any characters at the active console. In other words, once you start typing at the active console prompt, the takeover polling is suspended. If you have started typing characters, you can press \\<enter> at the active console to get a fresh Boot Loader prompt and reactivate the polling. If you have built a custom ROM that includes an automatic boot command with a timeout, then performing a console takeover will abort the timeout process and the automatic boot command will not be performed. Front Panel RomWBW supports the concept of a simple front panel. The following image is a conceptual view of such a front panel. If your system has a front panel, it should look similar to the RomWBW Front Panel . RomWBW Front Panel The LEDs in the top row of the panel are used for multiple purposes. They are initially used to display the progress of the system boot. This may help in diagnosing a hardware or configuration issue in a system that does not progress far enough to display text output on the console. The meaning of the LEDs is: O------- System Boot has started OO------ Common RAM bank activated OOO----- HBIOS transitioned to RAM OOOO---- Basic initialization done OOOOO--- CPU detection complete OOOOOO-- System timer configured OOOOOOO- Pre-console device init done OOOOOOOO Console activation Once the system has booted, the LEDs are used to indicate disk device activity. Each LED numbered 7-0 represents disk units 7-0. As each disk device performs I/O, the LED will light while the disk is active. This is only possible for the first 8 disk units. The second row of the front panel is composed of switches that allow you to control a few aspects of the system startup. The switches are also re-read during warm boot, so confirm the switch settings are your desired boot configuration before executing \u2018REBOOT /W\u2019. The first two switches affect the device used as the initial console. CRT/Serial Sec/Pri Explanation CRT Pri Primary Cathode Ray Tube device (high speed console) CRT Sec Secondary Cathode Ray Tube device (high speed console) Serial Pri Boot Console is Primary Serial Port Serial Sec Boot Console is Secondary Serial Port If not available (default): \u201cChar Unit 0\u201d is used The final six switches allow you to select the desired boot device. Auto / Menu Disk / ROM Floppy / Hard ROM/App/Boot Slice 4 2 1 Explanation Menu \u2013 \u2013 \u2013 \u2013 \u2013 Boot to RomWBW Menu Auto Disk Floppy # # # Boot Selected Floppy Disk Index Auto Disk Hard # # # Boot Selected Hard Disk Index Auto ROM \u2013 # # # Boot selected ROM Index If not available: Boot Loader Command Prompt \u2018\u2013\u2019 Ignored \u2018#\u2019 bit flag to select any three bits 4,2,1 ROM or Hard Disk - First 8 Drive Images 4 2 1 Floppy / Hard Drive Index ROM Index 0 0 0 Zero Monitor 0 0 1 One BASIC 0 2 0 Two Forth 0 2 1 Three Game 4 0 0 Four CP/M 4 0 1 Five Z-System 4 2 0 Six Net Boot 4 2 1 Seven User Disk Management The systems supported by RomWBW all have the ability to use persistent disk media. Some systems have disk interfaces built-in, while others will require add-in cards. You will need to refer to the documentation for your system for your specific options. The RomWBW firmware provides a hardware abstraction layer, All disks will work on all hardware variations. This means you can remove disk media from one RomWBW system and put it in a different RomWBW system. The only constraint is that the applications on the disk media must be up to date with the firmware on the system being used. Key Terminology/Concepts The following important terminology applies Disk (or Disk Drive) The hardware storage device that RomWBW talks to. RomWBW supports a variety of storage disk device types. ROM Disk - RomWBW firmware - containing CPM utilities RAM Disk - A section of system RAM initially empty Floppy Disk(s) - Removable media Hard Disk(s) - Includes CF Cards, SD Cards, USB Stick, etc. The different disk types are further defined in the section Disk Types . Media The storage device inserted into a disk drive, e.g. a floppy disk, CF Card, SD Card, etc. Slice For hard disks a Slice is a smaller logical block of disk space that is allocated and formatted with a filesystem and typically allocated to a Drive letter. Slices allow large modern storage media to be sliced up into smaller units compatible with CP/M. Slices should not be confused with partitions, a slice is not a partition. The concept of slices is described in detail in the section Hard Disk Slices . Drive The mapping of a hardware disk (and slice) to a Drive letter in an operating system. A Drive has a file system installed on it Disk Image A disk image is a predefined image of a complete CP/M filesystem, or filesystem(s), including any partition tables (for hard disk images). Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. This comes in for form of a file which is suitable for copying directly onto target media, using a modern computer. It is generally easier to use these disk images than transferring files over individually. See the section Disk Images for further details. Startup Hardware Discovery During startup RomWBW performs detection for hardware supported by your platform. During startup you will see messages for any disk interface(s), listing device types (e.g. FD:, IDE:, SD:), and any media that has been found on these interfaces. The messages you see will vary depending on your hardware and the media you have installed. As an example, here are the messages you might see if you have an IDE interface in your system with a single disk drive connected to the primary side of the interface: IDE: IO=0x80 MODE=MK4 IDE0: 8-BIT LBA BLOCKS=0x00773800 SIZE=3815MB IDE1: NO MEDIA See RomWBW Hardware for a complete list of the different device types supported. If you do not see drive letters assigned as expected, refer to the prior system boot messages to ensure media has been detected in the interface. Each drive letter refers back to a specific disk hardware interface like IDE0. This is important as it is telling you what each drive letter refers to. Mass storage disks (like IDE) will normally have multiple drive letters assigned. The extra drive letters refer to additional \u201cslices\u201d on the disk. Once your system has working disk devices, they will be accessible from any operating system you choose to run. Disk storage is available whether you boot your OS from ROM or from the disk media itself. Drive Letter Assignment In legacy CP/M operating systems only 16 drive letters (A:-P:) available to be assigned to disks Drive letters were generally mapped to disk drives in a completely fixed way. For example, drive A: would always refer to the first floppy disk drive. RomWBW implements a much more flexible drive letter assignment mechanism so that any drive letter can dynamically be assigned to any disk device, or slice of media. For clarification, CP/M cannot refer directly to disk devices, CP/M only understands drive letters, so to access a given disk device it must first be assigned to a drive letter. As the operating system starts up, you should see a list of drive letters assigned to the disk media you have installed. Here is an example of the list of drive letter assignments made during the startup of Z-System: Configuring Drives... A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 Above you can see that: Drive A: has been assigned to MD0 which is the RAM disk device. Drive B: has been assigned to MD1 which is the ROM disk device. Drives C: and D: have been assigned to floppy disk drives. Drives E: thru H: have been assigned to the IDE0 hard disk device. The 4 entries for IDE0 are referring to the first 4 slices on that disk. CP/M 3 and ZPM3 do not automatically display the assignments at startup, but you can use ASSIGN to display them. The assignments at boot will stay the same on each boot as long as you do not make changes to your hardware configuration. i.e. If you insert or remove an SD Card, CF Card or USB Stick, the drive assignments will change at next boot. Since drive letter assignments can change, you must be careful when doing destructive things like using CLRDIR to make sure the drive letter you use is referring to the desired media. Drive assignments can be changed at any time, by the ASSIGN command. Please see the section Assign Drive Letters for further details. Default Drive Letters When an operating system is booted, RomWBW will automatically assign drive letters to disk devices. The assignment process varies depending on: the disk/slice you choose to boot from, and the number, type, and sizes of mass storage devices available at boot The A: drive letter is considered special by most CP/M operating systems and is automatically used in some cases. e.g. submitting batch files, and is expected to be a writable volume. If you boot to a physical disk device, then the first drive letter (A:) will be assigned to the disk/slice that you are booting from, and the rest of the drive letters will be offset to accommodate this. By making the selected disk/slice the A: drive, you can setup different disks/slices for specific uses and just boot it, and the booted operating system will be the A: drive However when performing a ROM boot of an operating system, the first two drive letters will be assigned to your RAM disk (A:) and your ROM disk (B:). This provides the maximum compatibility with CP/M. After the first drive letter is assigned (as well as the second drive letter in the case of a ROM boot), RomWBW will assign additional drive letters based on the disk drives in the system. Additional drive letters will be assigned in the following order: RAM Disk ROM Disk Floppy Disk(s) Hard Disk(s) If a disk/slice was already assigned as the A: (or B:) drive letter, then it will not be assigned again. Floppy or removable disk drives will be assigned a drive letter regardless of whether there is any media inserted at the time of boot. In the case of hard disks, 1-8 drive letters will be assigned to the initial 1-8 slices of the disk drive. The number of drive letters assigned to each hard disk depends on the number of hard disks in the system: 1 Hard Disk: 8 drive letters (slices) 2 Hard Disks: 4 drive letters (slices) per disk 3+ Hard Disks: 2 drive letters (slices) per disk This somewhat complicated algorithm is used to try and maximize the limited number of operating system drive letters available (16) to the available disk devices as evenly as possible. For hard disk devices which are treated as non-removable media, drive letters will only be assigned to disk devices that actually contain media. i.e. No drive letters will be assigned to an SD Card slot that has no SD Card inserted. Assign Drive Letters The ASSIGN command is used to view or change the current drive letter mappings. Any changes made to drive letter mappings take immediate effect Refer to RomWBW Applications for more information on use of the ASSIGN command. Since drive letter assignments are easily changed at any time using the ASSIGN command, you can customize your assignments as desired after starting the operating system. Even better, you can use an auto-submit batch file to customzie the assignments at startup without any user intervention. Disk Operations/Commands With some understanding of how RomWBW presents disk space to the operating systems, we need to go over the options for actually setting up your disk(s) with content. Preparing Media for First Use You can initialize the media in-place using your RomWBW system. Essentially, this means you are creating a set of blank directories on your disk so that files can be saved there. This is somewhat analogous to partitioning of a hard disk or doing a low level format of a floppy disk. Initilizing a Floppy disk is covered in the section Floppy Disk Formatting , or for a Hard disk the section Hard Disk Preparation covers the steps to manually setup a hard disk for first use. Clearing (Formatting) Drives This is somewhat analogous to doing a FORMAT operation on other systems. With RomWBW you use the CLRDIR command to do this. This command is merely \u201cclearing out\u201d the directory space of the drive referred to by a drive letter and setting up the new empty directory. Refer to RomWBW Applications for more information on use of the CLRDIR command. Since CLRDIR works on drive letters, make absolutely sure you know what media and slice are assigned to that drive letter before using CLRDIR because CLRDIR will wipe out any pre-existing contents of the slice. After CLRDIR completes, the slice should be ready to use by the operating system via the drive letter assigned. Start by using the DIR command on the drive. This should return without error, but list no files. Here is an example of using CLRDIR . In this example, the ASSIGN command is used to show the current drive letter assignments. Then the CLRDIR command is used to initialize the directory of drive \u2018G\u2019 which is slice 2 of hard disk device IDE0 (\u201cIDE0:2\u201d). B>ASSIGN A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 B>CLDIR G: CLRDIR Version 1.2B May 2024 by Max Scane Warning - this utility will overwrite the directory sectors of Drive: G Type CAPITAL Y to proceed, any key other key to exit. Y Directory cleared. B> Checking Disk Layout If you are not sure which disk layout is used for your existing media, you can use the CP/M 2.2 STAT command to display information including the number of \u201c32 Byte Directory Entries\u201d for a drive letter on the corresponding hard disk. If it indicates 512, your disk layout is legacy (hd512). If it indicates 1024, your disk layout is modern (hd1k). Here is an example of checking the disk layout. B>STAT E:DSK: E: Drive Characteristics 65408: 128 Byte Record Capacity 8176: Kilobyte Drive Capacity 1024: 32 Byte Directory Entries 0: Checked Directory Entries 256: Records/ Extent 32: Records/ Block 64: Sectors/ Track 2: Reserved Tracks It is critical that you include DSK: after the drive letter in the STAT command line. The important line to look at is labeled \u201c32 Byte Directory Entries\u201d. Disk Types RAM & ROM Disks A typical RomWBW system has 512KB of ROM and 512KB of RAM. Some portions of each are dedicated to loading and running applications and operating system. The space left over is available for an operating system to use as a pseudo-disk device (ROM Disk and RAM Disk). Unlike other types of disk devices, ROM and RAM Disks do not contain an actual operating system and are not \u201cbootable\u201d. However, they are accessible to any operating system (whether the operating system is loaded from ROM or a different disk device). Neither RAM nor ROM disks require explicit formatting or initialization. ROM disks are pre-formatted and RAM disks are formatted automatically with an empty directory when first used. RAM Disk The RAM disk provides a small CP/M filesystem that you can use for the temporary storage of files. Unless your system has a battery backed mechanism for persisting your RAM contents, the RAM disk contents will be lost at each power-off. The RAM disk is an excellent choice for storing temporary files because it is very fast. You will notice that the first time an operating system is started after the power was turned off, you will see a message indicating that the RAM disk is being formatted. If you reset your system without turning off power, the RAM disk will not be reformatted and it\u2019s contents will still be intact. ROM Disk Like the RAM disk, the ROM disk also provides a small CP/M filesystem, but it\u2019s contents are static \u2013 they are part of the ROM. As such, you cannot save files to the ROM disk. Any attempt to do this will result in a disk I/O error. The contents of the ROM disk have been chosen to provide a core set of tools and applications that are helpful for either CP/M 2.2 or ZSDOS. Since ZSDOS is CP/M 2.2 compatible, this works fairly well. However, you will find some files on the ROM disk that will work with ZSDOS, but will not work on CP/M 2.2. For example, LDDS , which loads the ZSDOS date/time stamper will only run under ZSDOS. Flash ROM Disks The limitation of ROM disks being read-only can be overcome on some platforms with the appropriate selection of Flash ROM chip and system configuration. In this case the flash-file system can be enabled which will allow the ROM disk to be read and written to. Flash devices have a limited write lifespan and continual usage will eventually wear out the device. It is not suited for high usage applications. Enabling ROM disk writing requires building a custom ROM. Floppy Disks If your system has the appropriate hardware, RomWBW will support the use of floppy disks. The supported floppy disk formats are generally derived from the IBM PC floppy disk formats: 5.25\u201d 360K Double-sided, Double-density 5.25\u201d 1.2M Double-sided, High-density 3.5\u201d 720K Double-sided, Double-density 3.5\u201d 1.44M Double-sided, High-density When supported, RomWBW is normally configured for 2 3.5\u201d floppy disk drives. If a high-density disk drive is used, then RomWBW automatically detects and adapts to double-density or high-density media. It cannot automatically detect 3.5\u201d vs. 5.25\u201d disk drive types \u2013 the ROM must be pre-configured for the disk drive type. WARNING: Some of the operating systems provided with RomWBW require that a soft-reset be performed when swapping floppy disk media. For example, under CP/M 2.2, you must press control-C at the CP/M prompt after inserting a new floppy disk. The consequences of failing to perform the soft-reset vary from unexpected error messages to full disk directory corruption. Hard Disks The concept of a hard disk in RomWBW applies to any storage device that provides at least 8MB of space. The actual media can be a real spinning hard disk, a CompactFlash Card, a SD Card, etc. In this document, the term hard disk will apply equally to all of these. The vintage operating systems included with RomWBW were produced at a time when mass storage devices were quite small. CP/M 2.2 could only handle filesystems up to 8MB. Since storage devices today are quite large, RomWBW implements a mechanism called slicing (see Hard Disk Slices ) to allow up to 256 8MB CP/M filesystems on a single large storage device, where each slice can be assigned to a drive letter in CPM, and be treated as its own hard disk drive (from a CPM perspective). In order to achieve compatibility across all of the operating systems supported by RomWBW, the hard disk filesystem format used is 8MB. This ensures any filesystem will be accessible to any of the operating systems. RomWBW uses Logical Block Addressing (LBA) to interact with all hard disks. The RomWBW operating systems use older Cylinder/Head/Sector (CHS) addressing. To accommodate the operating systems, RomWBW emulates CHS addressing. Specifically, it makes all hard disks look like they have 16 sectors and 16 heads. The number of tracks varies with the size of the physical hard disk. Hard Disk Layouts When RomWBW uses a hard disk, it utilizes an area of the physical hard disk drive space to store a sequential series of slices that contain the actual CP/M filesystems referred to by drive letters by the operating system. Two hard disk layout schemes exist: Modern (hd1k) Legacy (hd512) You cannot mix disk layouts on a single disk device, however It is perfectly fine for one system to have multiple hard disks with different layouts \u2013 each physical disk device is handled separately. If you are setting up a new disk, the modern (hd1k) layout is recommended for the following reasons: Larger number of directory entries per filesystem Simplifies creation of coresident FAT filesystem Reduces chances of data corruption Each slice occupies exactly 8MB (an exact power of 2) in size Both the legacy and modern disk layouts continue to be fully supported by RomWBW. There are no plans to deprecate the legacy layout. Modern Layout RomWBW (Starting with v3.2) supports the use of disk partitioning, utilising a Master Boot Record (MBR) partition tables. The Wikipedia article on the Master Boot Record is excellent if you are not familiar with them. RomWBW uses the partition type id 0x2E . This partition type id does not equate to any existing well-known partition types \u2013 it was chosen because it is not generally used. RomWBW does not support extended partitions \u2013 only a single primary partition can be used. The existence of a partition table entry for RomWBW on a hard disk makes it behave in the modern mode. Removing the RomWBW partition entry from a modern hard disk layout will cause the existing data to be unavailable and/or corrupted The CP/M filesystem in the slices of the modern disk layout contain 1024 directory entries. Legacy Layout Originally, RomWBW always used the very start of the hard disk media for the location of the slices. In this layout, slice 0 referred to the first chunk of ~8MB on the disk, slice 1 referred to the second chunk of ~8MB on the disk, and so on. The number of slices is limited to the size of the disk media \u2013 if you attempted to read/write to a slice that would exceed the disk size, you would see I/O errors. The legacy format takes steps to allow a partition table to still be used for other types of filesystems such as DOS/FAT. It just does not use a partition table entry to determine the start of the RomWBW slices. The lack of a RomWBW partition table entry will cause legacy behaviour. Adding a partition table entry on an existing legacy RomWBW hard disk will cause the existing data to be unavailable and/or corrupted. The CP/M filesystem in the slices of the legacy disk layout contain 512 directory entries. Hard Disk Slices RomWBW implements a mechanism called slicing to allow multiple CP/M filesystem on a single large storage device. To say it another way, the media is \u201csliced up\u201d into many CP/M filesystems. You cannot use slices on any media less than 8MB in size. Specifically, you cannot slice RAM disks, ROM disks, floppy disks, etc. All of these are considered to have a single slice (0) It is very important to understand that RomWBW slices are not individually created or allocated on your hard disk. RomWBW uses a single partition on your hard disk to contain the slices. You should think of slices as just an index into a sequential set of 8MB areas that exist in this partition. RomWBW allows up to up to 256 slices each of 8MB in size on a single large storage device. This allows the use of up to 2GB of usable space on one media device. It is possible to create other partitions (typically FAT), for now, we are just talking about the slices within the single RomWBW partition. Slice Assignment When assigning Hard disks to drive letters you also need to assign the slice. Referring to slices within a storage device is done by appending a :<n> where \\<n> is the device relative slice number from 0-255. For example, if you have an IDE device, it will show up as IDE0: in the boot messages meaning the first IDE device. To refer to the fourth slice of IDE0, you would type \u201cIDE0:3\u201d. Here are some examples: IDE0:0 First slice of disk in IDE0 IDE0: First slice of disk in IDE0 IDE0:3 Fourth slice of disk in IDE0 So, if you wanted to use drive letter L: to refer to the fourth slice of IDE0, you could use the command ASSIGN L:=IDE0:3 . There are a couple of rules to be aware of when assigning drive letters. First, you may only refer to a specific device/slice with one drive letter at a time. Said another way, you cannot have multiple drive letters referring to a the same device/slice at the same time. Second, there must always be a drive assigned to A:. Any attempt to violate these rules will be blocked by the ASSIGN command. As you see, the name of a slice does not reference the hard disk partition containing the slices. Since there can only be a single RomWBW partition containing slices on any disk, the partition is determined automatically. RomWBW does not prevent you from assigning slices to drive letters even if the location of the slice does not fit on the physical disk. Any attempt to access a drive letter mapped to a slice that does not fit will result in an error such as \u201cno disk\u201d from the operating system. For example, a 64MB CF Card (which is typically a bit smaller than 64MB) will only fit 7 slices. At startup, you will typically see 8 drive letters assigned to the CF Card. Attempting to access the last drive letter will result in a \u201cno disk\u201d error from the operating system. Hard Disk Capacity The exact number of CP/M filesystem slices that will fit on your specific physical hard disk can be determined as follows: For modern (hd1k) disk layouts, it is 1024KB + (slices * 8192KB). Or equivalent to say 1MB + (slices * 8MB). For legacy (hd512) disk layouts, it is slices * 8,320KB. WARNING : In this document KB means 1024 bytes and MB means 1048576 bytes (frequently expressed as KiB and MiB in modern terminology). In general, hard disk capacities use KB to mean 1000 bytes and MB to mean 1,000,000 bytes. As an example, A \u201c64MB\u201d CF Card probably has less than 62.5MB of actual space (using the RomWBW definition that 1MB is 1048576 bytes). Such a drive will not support 8 slices. It will support 7 slices just fine because 1024KB + (7 * 8192MB) = 57MB (hd1k) or 7 * 8,320KB = 58.24MB (hd512) Although you can use up to 256 slices per physical disk, equating to 2GB of storage this large number of slices is rarely used. It is recommended that hard disk media used with RomWBW be 1GB or greater in capacity. This will support the RomWBW Combo Disk Image (see Combo Hard Disk Image ) that allows you to use 64 CP/M filesystem slices and a 384KB FAT filesystem. Disk Preparation There are two approaches to preparing disks for use by RomWBW. Manual : Use RomWBW itself to format empty disks and then transfer files over to the disks. Images : Use a modern computer to write a pre-built disk image including files to a disk. This section of the document describes the manual process of preparing empty disks that are ready for use by an operating system. Alternatively, you can use the pre-built RomWBW disk images to quickly create disk media that already has a large selection of files and bootable operating system slices. Using images to prepare a disk is documented in Disk Images . You do not need to follow the instructions in this section if you want to use disk images. Floppy Disk Formatting Floppy media must be physically formatted before it can be used. This is normally accomplished by using the supplied Floppy Disk Utility FDU application. This application interacts directly with your hardware and therefore you must specify your floppy interface hardware at application startup. Additionally, you need to specify the floppy disk drive and media format to use for formatting. Refer to RomWBW Applications for more information on use of the FDU command. Since the physical format of floppy media is the same as that used in a standard MS-DOS/Windows computer, you can also format floppy disk media in a standard computer. However there are caveats: The directory format itself will NOT be compatible with CP/M OSes. You WILL need to use the CLRDIR command to reformat the directory area from CP/M. See section Clearing (Formatting) Drives FDU allows you to specify physical sector interleaving (defaults to 2) which will result in faster floppy disk I/O. Formatting on a modern computer may not optimize this. Below is a sample session using FDU to format a 1.44M floppy disk in the first (primary) floppy disk drive: B>FDU Floppy Disk Utility (FDU) v5.8, 26-Jul-2021 [HBIOS] Copyright (C) 2021, Wayne Warthen, GNU GPL v3 SELECT FLOPPY DISK CONTROLLER: (A) Disk IO ECB Board (B) Disk IO 3 ECB Board (C) Zeta SBC Onboard FDC (D) Zeta 2 SBC Onboard FDC (E) Dual IDE ECB Board (F) N8 Onboard FDC (G) RCBus SMC (SMB) (H) RCBus WDC (SMB) (I) SmallZ80 Expansion (J) Dyno-Card FDC, D1030 (K) RCBus EPFDC (L) Multi-Board Computer FDC (X) Exit === OPTION ===> D-IDE ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=720KB DS/DD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> SETUP ENTER UNIT [00-03] (00): 00: 3.5\" 720KB - 9 SECTORS, 2 SIDES, 80 TRACKS, DOUBLE DENSITY 01: 3.5\" 1.44MB - 18 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 02: 5.25\" 320KB - 8 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 03: 5.25\" 360KB - 9 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 04: 5.25\" 1.2MB - 15 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 05: 8\" 1.11MB - 15 SECTORS, 2 SIDES, 77 TRACKS, DOUBLE DENSITY 06: 5.25\" 160KB - 8 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 07: 5.25\" 180KB - 9 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 08: 5.25\" 320KB - 8 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY 09: 5.25\" 360KB - 9 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY ENTER MEDIA [00-09] (00): 01 00: POLLING (RECOMMENDED) 01: INTERRUPT (!!! READ MANUAL !!!) 02: FAST INTERRUPT (!!! READ MANUAL !!!) 03: INT/WAIT (!!! READ MANUAL !!!) 04: DRQ/WAIT (!!! NOT YET IMPLEMENTED!!!) ENTER MODE [00-04] (00): ENTER TRACE LEVEL [00-01] (00): ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> FORMAT (T)RACK, (D)ISK ===> DISK ENTER INTERLEAVE [01-12] (02): RESET DRIVE... PROGRESS: TRACK=4F HEAD=01 SECTOR=01 ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> EXIT You can confirm a floppy disk is ready for content by simply running a DIR command on it. The DIR command should complete without error and should list no files. Hard Disk Preparation This section deals with initializing hard disk media entirely from your RomWBW system. The following instructions are one way to proceed. This does not mean to imply it is the only possible way. First you need to understand The disk layout approach (either hd1k or the legacy hd512). See Hard Disk Layouts section if you are not sure. hd1k should be the preferred layout. The number of 8MB slices that you want to allocate, preferred is 64 slices. At least 1 slice of 8MB is required If you want to leave space for a FAT partition. See FAT Filesystem Preparation The total capacity of your drive, to hold the CP/M (and other) partition(s) Then you will need to start by inserting the disk media, booting RomWBW, and confirming that the media is being recognized. If RomWBW recognizes the media, it will indicate this in the boot messages even though the media may not yet been prepared for use. Then launch either CP/M 2.2 or Z-System from ROM using the Boot Loader C or Z commands respectively. You can now use the tools on the ROM disk to prepare your disks. Note that you may see the operating system assign disks/slices to drives letters even though the disks/slices are not yet initialized. This is normal and does not mean the disks/slices are ready to use. Partition Setup To setup a partition you must run the FDISK80 utility. After FDISK80 starts, enter the disk unit number of the new media. The disk unit number was assigned at boot See Device Unit Assignments Refer to RomWBW Applications for more information on use of the FDISK80 utility. If you want to use the legacy hd512 layout skip down to the Legacy (hd512) section Modern (hd1k) At this point, use the I command to initialize (reset) the partition table to an empty state. You must create a partition for the RomWBW CP/M slices. Then create a partition using the N command. Importantly: The partition number should typically be 1 the first partition The partition can be placed anywhere you want, The typical location for the RomWBW partition is at 1MB. The partition size should be the total size of all the slices you require, and must be at least 8MB in size, in increments of 8MB makes sense. You must then set the type of partition to 2E using the T command. The P command can be used to display the partition before it is written Finally the partition can be written to disk using the W write command. WARNING : Modifying the partition table of existing media will make any data on the media inaccessible. Below is an example of creating a RomWBW partition following these guidelines. FDISK80 for RomWBW, UNA, Mini-M68k, KISS-68030, SBC-188 ---- Version 1.1-22 created 7-May-2020 (Running under RomWBW HBIOS) HBIOS unit number [0..11]: 4 Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 00 *** empty *** 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>i >>n New partition number: 1 Starting Cylinder (default 0): 1Mb Ending Cylinder (or Size= \"+nnn\"): +512Mb >>t Change type of partition number: 1 New type (in hex), \"L\" lists types: 2e >>p Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>w Do you really want to write to disk? [N/y]: y Okay FDISK exit. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again. Legacy (hd512) At this point, use the I command to initialize (reset) the partition table to an empty state. To use the hd512 layout, use W to write the empty table to the disk and exit. Remember that the lack of a partition for RomWBW implies the legacy (hd512) layout. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again. FAT Partition At this point you may want to consider creating a FAT partition Please see the section FAT Filesystem Preparation for detils on how to setup the FAT partition. Slice Initialization You need to initialize each slice for CP/M to use it. This is somewhat analogous to doing a FORMAT operation on other systems, and is done using the CLRDIR command. This is covered in the section Clearing (Formatting) Drives WARNING : Earlier versions of the CLRDIR application do not appear to check for disk errors when it runs. If you attempt to run CLRDIR on a drive that is mapped to a slice that does not actually fit on the physical disk, it may behave erratically. Assuming you want to use additional slices, you should initialize them using the same process. You may need to reassign drive letters to access some slices that are beyond the ones automatically assigned. You can use the ASSIGN command to handle this. Post Disk Preparation Once a disk (either floppy or hard disk) has been initialised and formattted you may optionally; * Make the disk bootable * Copy system (or other) files to the disk Making a Disk Bootable To make a disk bootable you will need to follow the specific instructions in Operating Systems , as each operating system will be different. Generally you will need to use SYSCOPY to setup the system track(s) of the disk.As an example, If you wanted to setup C: as a bootable Z-System disk you would use: B>SYSCOPY C:=B:ZSYS.SYS SYSCOPY v2.0 for RomWBW CP/M, 17-Feb-2020 (CP/M 2 Mode) Copyright 2020, Wayne Warthen, GNU GPL v3 Transfer system image from B:ZSYS.SYS to C: (Y/N)? Y Reading image... Writing image... Done Once this process succeeds, you will be able to boot directly to the disk slice from the boot loader prompt. See the instructions in Starting Operating Systems from Disk for details on this. Copying System Files As well as making the disk bootable, you may need to transfer other system and application files to your disks. Refer to Transferring Files for more information on getting files onto your disks. Disk Images Since it would be quite a bit of work to transfer over all the files you might want initially to your disk(s), It is generally easier to use these disk images than transferring your files over individually. RomWBW comes with a variety of ready to use disk images. You can use your modern Windows, Linux, or Mac computer to copy a disk image onto the disk media, then just move the media over to your RomWBW computer. The disk image files are found in the Binary directory of the distribution. Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. The following table shows the disk images available. Disk Image Description Boot xxx_aztec.img Aztec C Compiler No xxx_bascomp.img Microsoft Basic-80 Compiler No xxx_blank.img empty image No xxx_cowgol.img Cowgol 2.0 Compiler No xxx_cpm22.img DRI CP/M 2.2 Operating System Yes xxx_cpm3.img DRI CP/M 3 Operating System Yes xxx_dos65.img DOS/65 Operating System Yes xxx_fortran.img Microsoft Fortran-80 Compiler No xxx_games.img Games Disk for CP/M No xxx_hitechc.img HI-TECH Z80 CP/M C compiler No xxx_msxroms1.img MSX ROMs Disk 1 No xxx_msxroms2.img MSX ROMs Disk 2 No xxx_nzcom.img NZCOM ZCPR 3.4 Operating System Yes xxx_qpm.img QPM Operating System Yes xxx_tpascal.img Borland Turbo Pascal Compiler No xxx_ws4.img WordStar v4 & ZDE Applications No xxx_z80asm.img Relocating macro assembler for CP/M No xxx_zpm3.img ZPM3 Operating System Yes xxx_zsdos.img ZCPR-DJ & ZSDOS 1.1 Operating System Yes You will find 3 sets of these .img files in the distribution. The \u201cxxx\u201d portion of the filename will be: \u201cfd_\u201d for a floppy image. \u201chd1k_\u201d for a modern layout hard disk image. \u201chd512_\u201d for a legacy layout hard disk image. In the case of xxx_dos65.img, only an hd512 variant is provided. This is a constraint of the DOS65 distribution. There is also an image file called \u201cpsys.img\u201d which contains a bootable p-System hard disk image. It contains 6 p-System filesystem slices, but these are not interoperable with the CP/M slices described above. This file is discussed separately under UCSD p-System in Operating Systems section. Floppy Disk Images The floppy disk images are all intended to be used with 3.5\u201d high-density, double-sided 1.44 MB floppy disk media. This is ideal for the default floppy disk drive support included in RomWBW standard ROMs. For floppy disks, the .img file is written directly to the floppy media as is. The floppy .img files are 1.44 MB which is the exact size of a single 3.5\u201d high density floppy disk. You will need a floppy disk drive of the same type connected to your modern computer to write this image. Although modern computers do not come equipped with a floppy disk drive, you can still find USB floppy drives that work well for this. The floppy disk must be physically formatted before writing the image onto it. You can do this with RomWBW using FDU as described in the Floppy Disk Formatting section of this document. While you can also format the floppy using your modern computer, using FDU is preferable. RomWBW includes a Windows application called RawWriteWin in the Tools directory of the distribution. This simple application will let you choose a file and write it to an attached floppy disk drive. For Linux/MacOS, I think you can use the dd command (but I have not actually tried this). It is probably obvious, but writing an image to a floppy disk will overwrite and destroy all previous contents. Once the image has been written to the floppy disk, you can insert the floppy disk in your RomWBW floppy disk and read/write files on it according to the specific operating system instructions. If the image is bootable, then you will be able to boot from it by entering the floppy disk drive\u2019s corresponding unit number at the RomWBW Boot Loader command prompt. Hard Disk Images Keeping in mind that a RomWBW hard disk (including CF/SD/USB devices) allows you to have multiple slices (CP/M filesystems), there are a couple ways to image hard disk media. The easiest approach is to use the Combo Disk Image. This hard disk image is already prepared with 6 slices containing 5 ready-to-run OSes and a slice with the WordStar application files. Alternatively, you can create your own hard disk image with the specific slice contents you choose. Standard Hard Disk Layout As previously described in Hard Disk Layouts , the exact placement of slices and optional FAT partition will vary depending on which disk layout (hd512 or hd1k) you are using and your partition table entries. To simplify the use of hard disk images, RomWBW has adopted a standard partition layout for disk image files provided. This standard layout is used to produce the Combo Disk Images described below. These partition sizes and locations were chosen to: Fit entirely on 1GB media Allow for 64 CP/M filesystem slices Allow for a 384KB FAT filesystem The standard partition table table entries are: \u2014 Modern (hd1k) \u2014 \u2014 Legacy (hd512) \u2014 Byte(s) Sector(s) Byte(s) Sector(s) RomWBW Partition Start 1 MB 2,048 \u2013 \u2013 RomWBW Partition Size 512 MB 1,048,576 \u2013 \u2013 FAT Filesystem Start 513 MB 1,050,624 520 MB 1,064,960 FAT Filesystem Size 384 MB 786,432 384 MB 786,432 \\<end> 897 MB 1,851,392 904 MB 1,837,056 NOTE: RomWBW is not limited to these partition table entries. You can change the size and location of the RomWBW and/or FAT partitions to increase/decrease the number of slices or FAT filesystem size. Doing so would require using FDISK80 to define your own custom disk layout and initializing your filesystems manually. The RomWBW System Guide has more information on the standard disk layouts as implemented in the Combo Disk Images. Additionally, there is a document called \u201cHard Disk Anatomy.pdf\u201d in the Doc directory of the RomWBW distribution with detailed information on the standard disk layouts. Combo Hard Disk Image The Combo Disk Image is essentially just a single disk image that has several of the individual filesystem images (slices) already concatenated together using the standard disk layout described above. The Combo Disk Image includes the partition table of the standard disk layout and the following 6 slices in the positions indicated: Slice Description Slice 0 DRI CP/M 2.2 Operating System Slice 1 ZCPR-DJ & ZSDOS 1.1 Operating System Slice 2 NZCOM ZCPR 3.4 Operating System Slice 3 DRI CP/M 3 Operating System Slice 4 ZPM3 Operating System Slice 5 WordStar v4 & ZDE Applications Slice 6-63 blank unformatted There are actually 2 Combo Disk Images in the distribution. One for an hd512 disk layout (hd512_combo.img) and one for an hd1k disk layout (hd1k_combo.img). Simply use the image file that corresponds to your desired hard disk layout. Review the information in Hard Disk Layouts if you need more information of the disk layout options. Note : Apart from the hd512 and hd1k Combo Disk Images (mentioned above) there are actually a number of other hd1k_*_combo.img files. These additional combo files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct combo file The Combo Disk Image actually only contains the initial partition table, and the first 6 slices (Slice 0 to 5), this is approximately 49MB in size. While the partition table reserves space to store 64 CP/M filesystem slices as well as a single 384MB FAT filesystem, these areas remain empty, and must be initialized manually using CLRDIR for CP/M filesystems and FAT FORMAT for the FAT filesystem. Combo Disk Image Capacity The standard hard disk layout used by the Combo Disk Image was designed to fit well on a 1GB hard disk. The 64 CP/M slices (approximately 512MB) and 384MB FAT filesystem all fit well within a 1GB hard disk. This size choice was a bit arbitrary, but based on the idea that 1GB CF/SD/USB Media is easy and cheap to acquire. It is fine if your hard disk is smaller than 1GB. It just means that it will not be possible to use the pre-allocated FAT filesystem partition and any CP/M filesystem slices that don\u2019t fit. The true number of CP/M filesystem slices that will fit on your specific physical hard disk can be calculated as described in Hard Disk Capacity . If you attempt to access a slice past the end of the physical hard disk you will get \u201cno disk\u201d errors. You should calculate the maximum number of slices your hard disk will support and do not exceed this number. Combo Disk Image Advice A great way to maintain your own data on a hard disk is to put your data in slices beyond the first 6. By doing so, you can always \u201cre-image\u201d your drive media with the Combo Disk Image without overlaying the data stored in the slices beyond the first 6. Just be very careful to use the same combo image layout (hd512 or hd1k) as you used originally. Custom Hard Disk Image For hard disks, each .img file represents a single slice (CP/M filesystem). Since a hard disk can contain many slices, you can just concatenate the slices (.img files) together to create your desired hard disk image. If you look in the Binary directory of the distribution, you will see that there are more disk (slice) images than the 6 that are included in the Combo Disk Images. These supplemental disk images are identified by looking for the files that start with hd1k_ or hd512_. Adding Slices to Combo Image You can add slices to the Combo Disk Images simply by tacking slices onto the end. For example, if you want to add a slice containing the MSX ROMs to the end of the combo image, you could use one of the following command lines depending on your operating system: Windows: COPY /B hd1k_combo.img + hd1k_msxroms.img my_hd.img Linus/MaxOS: cat hd1k_combo.img hd1k_msxroms.img >my_hd.img Note that you must be sure to use either the hd1k_ or hd512_ prefixed files together. You cannot mix them. Creating a new Custom Image If you want to create a completely custom hard disk image that is not based on the existing combo image, you can generate a disk image entirely from scratch using whatever slices you want in whatever order you like. For example, if you want to create a hard disk image that has slices for CP/M 2.2, CP/M 3, and WordStar in the hd512 format, you would use the command line of your modern computer to create the final image: Windows: COPY /B hd512_cpm22.img + hd512_cpm3.img + hd512_ws hd.img Linux/MacOS: cat hd512_cpm22.img hd512_cpm3.img hd512_ws >hd.img NOTE: For the hd1k disk layout, you must prepend the prefix file called hd1k_prefix.dat which contains the required partition table. So, for an hd1k layout you would use the following: Windows: COPY /B hd1k_prefix.dat + hd1k_cpm22.img + hd1k_cpm3.img + hd1k_ws hd.img Linux/MacOS: cat hd1k_prefix.dat hd1k_cpm22.img hd1k_cpm3.img hd1k_ws >hd.img Note : Apart from the hd1k_prefix.dat file (mentioned above) there are actaully a number of other hd1k_*_prefix.dat files. These additional prefix files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct prefix file In all of the examples above, the resulting file (hd.img) would now be written to your hard disk media and would be ready to use in a RomWBW system. If you wish to further customize or create new disk image definitions, please refer to the ReadMe.txt file in the Source/Images directory. Writing Hard Disk Images Once you have chosen a Combo Hard Disk Image file or prepared your own custom hard disk image file, it will need to be written to the media using your modern computer. When using this method, the disk will be partitioned and setup with 1 or more slices containing ready-to-run bootable operating systems. To write a hard disk image file onto your actual media (actual hard disk or CF/SD/USB Media), you need to use an image writing utility on your modern computer. Your modern computer will need to have an appropriate interface or slot that accepts the media. To actually copy the image On Linux or MacOS , you can use the dd command. On Windows, in the \u201cTools\u201d directory of the distribution, there is an application called Win32DiskImager. In all cases, the image file should be written to the media starting at the very first block or sector of the media. This is the default behaviour on all software. To be entirely clear, writing a disk image file to your hard disk media will overwrite an pre-existing partition table and the number of slices that your image file contains. It will not overwrite or corrupt slices beyond those in the image file. As a result, you can use additional slices as a place to maintain your personal data because these slices will survive re-imaging of the media. If you setup a FAT partition on your media, it will also survive the imaging process. Media Usage and Initialization Once you have copied the image onto the hard disk media, you can move the media over to your RomWBW system. You can then boot to the operating system slices by specifying ( \\<diskunit>.\\<slice> ) at the RomWBW Boot Loader command prompt. See the section Starting Operating Systems from Disk for further details You are not limited to the number of slices that are contained in the image that you write to your hard disk media. You can use additional slices as long your media has room for them. However, writing the disk image will not initialize the additional slices. You will need to use the CLRDIR application to initialize any un-initialized slice before its first use, and and optionally SYSCOPY if you want th slice to be bootable. If you use the combo image this applies to slices 6 thru 63. The procedure for this is documented in the Clearing (Formatting) Drives section. Likewise, the pre-allocated FAT partition must still be formatted using FAT FORMAT in order to actually use it (see FAT Filesystem Preparation ). Alternatively, the FAT partition can be formatted on a modern computer. Re-Imaging Existing Media In order for your additional slices and/or FAT partition to survive re-imaging, you must follow these rules: Do not modify the partition table of the media using FDISK80 or any other partition management tools. Ensure that your hard disk image file uses the same disk layout approach (hd512 or hd1k) as previously used on the media. Writing Hard Disk Slices This section covers techniques to copy partial images onto pre-existing media, in effect performing a selective slice copy. These techniques currently only apply to hd1k formatted media, which has a partition table entry, and a convenient 1MB size metric. However adapting to hd512 is possible, but left to the user. You will need to have access to a Linux/MacOS machine, or have the Linux tools for Windows installed, including the dd command line tool. For Windows there are multiple options for installing dd including MSYS2 , CygWin , and dd for Windows . WARNING : The dd command is a low-level utility that writes directly to raw disk sectors with almost no safety checks. It is very easy to corrupt a disk if this tool is used incorrectly. The dd command supports options to define precisely source and destination offsets and sizes to copy. From the documentation of dd the following options are important. if=file Read input from file instead of the standard input. of=file Write output to file instead of the standard output. skip=n Skip n blocks from the beginning of the input before copying. seek=n Seek n blocks from the beginning of the output before copying. count=n Copy only n input blocks. bs=n Set both input and output block size to n bytes instead of the default 512 The best approach is to copy data to the RomWBW partition. To do this, you must first determine the name that your operating system is using for the RomWBW disk and partition. An easy way to determine this may be the linux mount command, which lists the currently mounted partitions. From here you can more easily determine the naming scheme used by your operating system. Typically disk devices are named something like /dev/disk9 or /dev/sdg , noting above the g is a alphabetic and it could be any letter. This naming is arbitrary and depend on the operating system, and the specific hardware connecting the device Partitions are typically named by simply adding a number after the name of the hard disk device. For example, the first partition could be /dev/disk9s1 , /dev/sdg1 , or /dev/sdgp1 . In the following examples we use the above dd options, noting the of= option is the RomWBW target partition. ** NOTE ** A second approach (Examples 3 and 4) is to address the hard disk as a raw disk device and we take explicit steps to calculate the start of the RomWBW partition. While this works, it is better to use the partition relative approach. The commands in the examples below are run from the Binary folder of RomWBW distribution. Example 1 : Copy the Games image to an empty slice of our media In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5). We are just copying the needed slice to the existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/sdg1 seek=6 bs=8M Password: 1+0 records in 1+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) Since bs=8MB the seek=6 skips the first 6 (8MB slices) slices (in the target image) and writes the games image to the 7th slice. Example 2 : Copy the entire Combo Image without replacing partition table In all of the following examples we use bs=1MB to defines the block size used in other parameters. This is convenient since the combo image reserves 1MB for the partition table at the start of the disk. In this example we will copy the (hd1k) combo image (which includes a partition table) over our media without replacing the partition table. In this example we assume the media has already been formatted with the combo image, and we have modified the partition table, which we do not want to overwrite. Binary % sudo dd if=hd1k_combo.img of=/dev/sdg1 skip=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB (partition table) in the input file, effectively stripping out the combo images partition table, before overwriting the slices in the target partition. Example 3 : Copy the Combo Image without replacing partition table This example is identical to Example 2 except it writes to the target disk device itself ( of=/dev/disk9 ), not the target partition. Binary % sudo dd if=hd1k_combo.img of=/dev/disk9 skip=1 seek=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB in the input file, and likewise seek=1 skips the first 1MB of the target media file we are writing to, thus in effect we are skipping the first 1MB, which contains the partition table itself. Example 4 : Copy the Games image to an empty slice of our media In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5) We are just coping the needed slice to this existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/disk9 seek=49 bs=1M Password: 8+0 records in 8+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) The seek=49 skips the first 49MB of the media file we are writing to. 49 is calculated as (slice number * 8) + 1 , where 8 is the size of a slice and 1 is the size of the partition table im megabytes. Thus we are skipping 6 slices (in the combo image) and writing to the 7th slice. Operating Systems One of the primary goals of RomWBW is to expose a set of generic hardware functions that make it easy to adapt operating systems to any hardware supported by RomWBW. As a result, there are now 8 operating systems that have been adapted to run under RomWBW. The adaptations are identical for all hardware supported by RomWBW because RomWBW hides all hardware specifics from the operating system. By design, the operating systems provided with RomWBW are original and unmodified from their original distribution. Patches published by the authors are generally included or applied. The various enhancements RomWBW provides (such as hard disk slices) are implemented entirely within the system adaptation component of each operating system (e.g., CP/M CBIOS). As a result, each operating system should function exactly as documented by the authors and retain maximum compatibility with original applications. Note that all of the operating systems included with RomWBW support the same basic filesystem format from DRI CP/M 2.2 (except for p-System). As a result, a formatted filesystem will be accessible to any operating system. The only possible issue is that if you turn on date/time stamping using the newer OSes, the older OSes will not understand this. The older OS will not corrupt the files, but the date/time stamps will not be maintained. The following sections briefly describe the operating system options currently available and brief operating notes. Digital Research CP/M 2.2 This is the most widely used variant of the Digital Research operating systems. It has the most basic feature set, but is essentially the compatibility metric for all other CP/M-like operating systems including those listed below. If you are new to the CP/M world, I would recommend using this CP/M variant to start with simply because it is the most stable and you are less likely to encounter compatibility issues. Documentation CPM Manual Boot Disk To make a bootable CP/M disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cCPM.SYS\u201d. For example: SYSCOPY C:=B:CPM.SYS Character Device Mapping Character device mapping under CP/M 2.2 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The CP/M Logical Devices are: Device Description CON: System console device, used by CCP for communication with the operator RDR: Paper tape reader device PUN: Paper tape punch device LST: Output list device The CP/M Physical Devices are: Device Description TTY: Teletype device (slow speed console) CRT: Cathode ray tube device (high speed console) BAT: Batch processing (input from RDR: , output to LST: ) UC1: User-defined console PTR: Paper tape reader (high speed reader) UR1: User-defined reader #1 UR2: User-defined reader #2 PTP: Paper tape punch (high speed punch) UP1: User-defined punch #1 UP2: User-defined punch #2 LPT: Line printer UL1: User-defined list device #1 CP/M Logical Devices are mapped to CP/M Physical Devices via the IOBYTE at 0x0003 as shown below. Logical Device LST: PUN: RDR: CON: IOBYTE Bits 7 6 5 4 3 2 1 0 0 (0b00) TTY: TTY: TTY: TTY: 1 (0b01) CRT: PTP: PTR: CRT: 2 (0b10) LPT: UP1: UR1: BAT: 3 (0b11) UL1: UP2: UR2: UC1: The mappings above can be managed using the STAT command. This command essentially just modifies the IOBYTE value. CP/M Physical Devices are mapped to RomWBW HBIOS devices during the boot process depending on the number of HBIOS Char devices in the system. All CP/M Physical Devices are initially mapped to HBIOS Char 0. If additional HBIOS Char devices are available in the system, they will be mapped as below: CP/M RomWBW HBIOS TTY: Char 0 CRT: CRT BAT: CP/M RDR/LST UC1: Char 1 PTR: Char 1 UR1: Char 2 UR2: Char 3 PTP: Char 1 UP1: Char 2 UP2: Char 3 LPT: Char 1 UL1: Char 2 Normally, the HBIOS Console device (Loader prompt) is on HBIOS Device Char 0. If it has been reassigned to a different HBIOS character device before launching CP/M, then the above mapping will be modified. TTY: will be assigned to the current HBIOS console Char device. The remaining assignments will be filled in with the other Char devices as available. Notes You can change media, but it must be done while at the OS command prompt and you must warm start CP/M by pressing ctrl-C. This is a CP/M 2.2 constraint and is well documented in the DRI manual. SUBMIT.COM has been patched per DRI to always place submit files on A:. This ensures the submitted file will always be properly executed. The original versions of DDT, DDTZ, and ZSID used the RST 38 vector which conflicts with interrupt mode 1 use of this vector. The DDT, DDTZ, and ZSID applications in RomWBW have been modified to use RST 30 to avoid this issue. Z-System applications will not run under CP/M 2.2. For example, the LDDS date stamper will not work. Z-System Z-System is the most popular non-DRI CP/M workalike \u201cclone\u201d which is generally referred to as Z-System. Z-System is intended to be an enhanced version of CP/M and should run all CP/M 2.2 applications. It is optimized for the Z80 CPU (as opposed to 8080 for CP/M) and has some significant improvements such as date/time stamping of files. Z-System is a somewhat ambiguous term because there are multiple generations of this software. RomWBW Z-System is a combination of both ZCPR-DJ (the CCP) and ZSDOS 1.1 (the BDOS) when referring to Z-System. The latest version of Z-System (ZCPR 3.4) is also provided with RomWBW via the NZ-COM adaptation (see below). Documentation ZCPR Manual ZCPR-DJ ZSDOS Manual Boot Disk To make a bootable Z-System disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cZSYS.SYS\u201d. For example: SYSCOPY C:=B:ZSYS.SYS Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The CP/M 2.2 STAT command is used to manipulate the device mappings. Notes Although most CP/M 2.2 applications will run under Z-System, some may not work as expected. The best example is PIP which is not aware of the ZSDOS paths and will fail in some scenarios (use COPY instead). Although ZSDOS can recognize a media change in some cases, it will not always work. You should only change media at a command prompt and be sure to warm start the OS with a ctrl-C. ZSDOS has a concept of fast relog of drives. This means that after a warm start, it avoids the overhead of relogging all the disk drives. There are times when this causes issues. After using tools like CLRDIR or MAP, you may need to run \u201cRELOG\u201d to get the drive properly recognized by ZSDOS. ZSVSTAMP expects to be running under the ZCPR 3.X command processor. By default, RomWBW uses ZCPR 1.0 (intentionally, to reduce space usage) and ZSVSTAMP will just abort in this case. It will work fine if you implement NZCOM. ZSVSTAMP is included solely to facilitate usage if/when you install NZCOM. Many of the tools can be configured (using either ZCNFG or DSCONFIG). The configuration process modifies the actual application file itself. This will fail if you try to modify one that is on the ROM disk because it will not be able to update the image. DATSWEEP can be configured using DSCONFIG. However, DSCONFIG itself needs to be configured first for proper terminal emulation by using SETTERM. So, run SETTERM on DSCONFIG before using DSCONFIG to configure DATSWEEP! Generic CP/M PIP and ZSDOS path searching do not mix well if you use PIP to copy to or from a directory in the ZSDOS search path. Best to use COPY from the ZSDOS distribution. NZCOM Automatic Z-System NZCOM is a much further refined version of Z-System (ZCPR 3.4). NZCOM was sold as an enhancement for existing users of CP/M 2.2 or ZSDOS. For this reason, (by design) NZCOM does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into a host OS. On the RomWBW NZCOM disk images, the boot OS is ZSDOS 1.1. A PROFILE.SUB file is included which automatically launches NZCOM as soon as ZSDOS loads. NZCOM is a companion product to Z3PLUS, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. NZCOM is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation and use MKZCM as desired to customize your system. NZCOM has substantially more functionality than CP/M or basic Z-System. It is important to read the \u201cNZCOM Users Manual.pdf\u201d document in order to use this operating system effectively. Documentation NZCOM Users Manual Z-System Users Guide ZCPR3.3 User Guide Boot Disk Since NZ-COM boots via Z-System, you can make a bootable NZ-COM disk using ZSYS.SYS as described in Z-System above. You will need to add a PROFILE.SUB file to auto-start NZ-COM itself. Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . However, it is not possible to manipulate the CP/M Logical to Physical device mapping using the STAT command. The mapping is static. Note: A custom ZCPR IOP module could theoretically be used to manage the character device mappings. RomWBW does not provide this module and writing an IOP module is beyond the scope of this document. Notes All of the notes for Z-System above generally apply to NZCOM. There is no DIR command, you must use SDZ instead. If you don\u2019t like this, look into the ALIAS facility. For consistency with other ZCPR3 operating systems (ZPM3, Z3PLUS) the SHOW.COM and HELP.COM command files were renamed to ZSHOW.COM and ZHELP.COM Digital Research CP/M 3 This is the Digital Research follow-up product to their very popular CP/M 2.2 operating system. While highly compatible with CP/M 2.2, it features many enhancements and is not 100% compatible. It makes direct use of banked memory to increase the user program space (TPA). It also has a new suite of support tools and help system. Documentation CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide Boot Disk To create (or update) a CP/M 3 boot drive, you must place CPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS and CCP.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. CPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/CPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . CPMLDR.SYS CPM3.SYS or CPM3BNK.SYS CCP.COM The CPM3.SYS boot file is provided in 2 versions. In the Binary/CPM3 distribution directory, CPM3.SYS is the \u201cnon-banked\u201d version of CP/M 3. The CPM3BNK.SYS file is the \u201cbanked\u201d version of CP/M 3. You almost certainly want to transfer the banked CPM3BNK.SYS version. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place CPMLDR.SYS on the boot track of the target drive. CPM3.SYS and CCP.COM can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into CP/M 3 to create or update a CP/M 3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the CP/M 3 disk. Assuming the target CP/M 3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:CPMLDR.SYS COPY A:CPM3BNK.SYS F:CPM3.SYS COPY A:CCP.COM F: Note in the example above that CPM3BNK.SYS is renamed to CPM3.SYS in the copy command. Character Device Mapping Character device mapping under CP/M 3 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The primary CP/M Logical Devices are: Device Description CON: Console input or output device AUX: Auxiliary Input or Output Device LST: List output device, usually the printer There are various aliases for these devices. Please refer to the CP/M 3 Users Guide for more information. The mapping of CP/M 3 Logical Devices to Physical Devices is performed using the DEVICE command. CP/M 3 refers to Physical Character Devices using the COM device label. These COM devices are mapped directly to the RomWBW HBIOS Char devices as described below: COM0: \u2013> HBIOS Char 0 COM1: \u2013> HBIOS Char 1 COM2: \u2013> HBIOS Char 2 . . . COMn: \u2013> HBIOS Char n Notes The COPYSYS command described in the DRI CP/M 3 documentation is not provided with RomWBW. The RomWBW SYSCOPY command is used instead. Although CP/M 3 is generally able to run CP/M 2.2 programs, this is not universally true. This is especially true of the utility programs included with the operating system. For example, the SUBMIT program of CP/M 3 is completely different/incompatible from the SUBMIT program of CP/M 2.2. RomWBW fully supports CP/M 3 file date/time stamping, but this requires that the disk be properly initialized for it. This process has not been performed on the CP/M 3 disk image. Follow the CP/M 3 documentation to complete this process, if desired. Z3PLUS Z-System for CP/M-Plus Z3PLUS is a much further refined version of Z-System (ZCPR 3.4). Z3PLUS was sold as an enhancement for existing users of CP/M 3. For this reason, (by design) Z3PLUS does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into CP/M 3. A PROFILE.SUB file is included which automatically launches Z3PLUS as soon as CP/M 3 loads. Z3PLUS is a companion product to NZ-COM, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. Z3PLUS is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation to customize your system. Z3PLUS has substantially more functionality than CP/M 3 or the basic Z-System. It is important to read the \u201cZ3PLUS Users Manual.pdf\u201d document in order to use this operating system effectively. Documentation Z3PLUS Users Manual Z-System Users Guide ZCPR3.3 User Guide Boot Disk Since Z3PLUS boots via CP/M 3, you first must make the disk CP/M 3 bootable. This is not a simple process, as well as placing CPMLDR.SYS on the system track of the disk there are several files that are required on the disk itself.This is described in Digital Research CP/M 3 section above. You will need to add a PROFILE.SUB file to auto-start Z3PLUS itself. Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings. Notes All of the notes for Digital Research CP/M 3 above generally apply to Z3PLUS. Some applications in the Z3PLUS distribution have been upgraded with newer versions. This is done with in ZPM3 Simeon Cran\u2019s ZPM3 is an interesting combination of the features of both CP/M 3 and ZCPR3. Essentially, it has the features of and compatibility with both. Due to this dual compatibility, the ZPM3 distribution image contains most of the standard CP/M 3 files as well as a variety of common ZCPR3 applications. However, you will notice that user area 0 of the disk has only a few files. Most of the files are distributed among other user areas which is standard practice for ZCPR3. Most importantly, you will see most of the applications in user area 15. The applications can be executed from any user area because ZPM3 has a default search path that includes User 15. The ZPM3 distribution comes with essentially no utility programs at all. In addition to the standard CP/M 3 utilities, RomWBW includes a variety of common ZCPR3 utilities. Documentation ZPM3 has no real documentation. You are expected to understand both CP/M 3 and ZCPR 3. The best source of information is: CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide Z-System Users Guide ZCPR3.3 User Guide Boot Disk To create (or update) a ZPM3 boot drive, you must place ZPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS , ZCCP.COM , ZINSTAL.ZPM , and STARTZPM.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. ZPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/ZPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . ZPMLDR.SYS CPM3.SYS ZCCP.COM ZINSTAL.ZPM STARTZPM.COM You may be surprised to see the file called CPM3.SYS . This is not a typo. Although it is called CPM3.SYS , it is ZPM and not the same as CPM3.SYS in the CPM3 directory. Also, unlike CP/M 3, ZPM3 is always banked, so you will not find two versions of the file. CPM3.SYS is a banked implementation of ZPM3. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place ZPMLDR.SYS on the boot track of the target drive. The remaining boot files can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into ZPM3 to create or update a ZPM3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the ZPM disk. Assuming the target ZPM3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:ZPMLDR.SYS COPY A:CPM3.SYS F:CPM3.SYS COPY A:CCP.COM F: COPY A:ZINSTAL.ZPM F: COPY A:STARTZPM.COM F: Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings. Notes The ZPM3 operating system is contained in the file called CPM3.SYS which is confusing, but this is as intended by the ZPM3 distribution. I believe it was done this way to make it easier for users to transition from CP/M 3 to ZPM3. The command line editing key bindings were slightly modified by Jon Saxton when he applied a few ZPM3 fixes. This is explained in the file zpm3fix.txt in the distribution folder Source/ZPM3. The current key bindings are from the \u201cNew\u201d column below. Old New Function ^A ^A one word left ^B ^B to beginning/end of line ^C ^C reboot if at start of line ^D ^D right one char ^E ^E get previous line ^F ^F right one word ^G ^G delete char at cursor ^H ^H destructive backspace ^I ^I (TAB) ignored here ^J ^J (LF) exit editor ^K ^K delete all to the right ^L ^L ignored ^M ^M (CR) exit editor ^N ^N ignored ^O ^O ignored ^P ^P toggle printer echoing ^Q ^Q toggle autoprompt (if enabled) ^R ^R ignored ^S ^S left one char ^T ^T delete word at cursor ^U ^U add line to history ^V ^V clear line, delete from history ^W ^X get next line from history ^X ^W delete all to the left ^Y ^Y clear line QP/M QP/M is another OS providing compatibility with and enhancements to CP/M 2.2. It is provided as a bootable disk image for RomWBW. Refer to the ReadMe.txt file in Source/Images/d_qpm for more details regarding the RomWBW adaptation and customizations. Documentation QP/M 2.7 Installation Guide and Supplements QP/M 2.7 Interface Guide QP/M 2.7 Features and Facilities Boot Disk To create or update a bootable QP/M Z-System disk, a special process is required. QP/M is not provided in source format. You are expected to install QP/M over an existing CP/M installation using the QINSTALL.COM application. To update an existing QP/M boot disk with the latest RomWBW CBIOS, you must use 2 steps: apply the generic CP/M system track, then reinstall the QP/M components. To do this, you can perform the following steps: Boot to the existing QP/M disk. At this point, drive A should be the QP/M disk that you wish to update. You may receive a warning about CBIOS/HBIOS version mismatch. Use RomWBW SYSCOPY to place the stock RomWBW CP/M OS image onto the system tracks of the QP/M boot disk: SYSCOPY A:=x:CPM.SYS where x is the drive letter of your ROM Disk. Run QINSTALL to overlay the QP/M OS components on your QP/M boot disk. WARNING : QINSTALL has no mechanism for retaining previous non-default settings. Any previous non-default settings you previously made with QINSTALL will need to be reapplied. The pre-built RomWBW QP/M disk image includes a couple of specific non-default settings to optimize use with RomWBW. Please review the notes in the ReadMe.txt file in Source/Images/d_qpm. Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The mappings can be viewed or modified using the QP/M QSTAT command which is analogous to the CP/M 2.2 STAT command. Do not use the CP/M 2.2 STAT command under QP/M. Notes QPM is not available as source. This implementation was based on the QPM binary distribution and has been minimally customized for RomWBW. When booted, the QPM startup banner will indicate CP/M 2.2. This is because QPM uses the CP/M 2.2 CBIOS code. QINSTALL is used to customize QPM. It is included on the disk image. You should review the notes in the ReadMe.txt file in Source/Images/d_qpm before making changes. In addition to the QPM disk image, all of the QPM distribution files can be found in the RomWBW distribution in the Source/Images/d_qpm/u0 directory. The QPM disk image is not included as one of the slices on the RomWBW Combo Disk Image. If you want to include QPM, you can do so by following the directions in Source/Images/Readme.txt. UCSD p-System This is a full implementation of the UCSD p-System IV.0 for Z80 running under RomWBW. Unlike the OSes above, p-System uses its own unique filesystem and is not interoperable with other OSes. It was derived from the p-System Adaptable Z80 System. Unlike some other distributions, this implements a native p-System Z80 Extended BIOS, it does not rely on a CP/M BIOS layer. The p-System is provided on a hard disk image file called psys.img. This must be copied to its own dedicated hard disk media (CF Card, SD Card, etc.). It is booted by selecting slice 0 of the corresponding hard disk unit at the RomWBW Boot Loader prompt. Do not attempt to use CP/M slices on the same disk. Due to limitations in the p-System configuration mechanism, it does not recognize the arrow keys of an ANSI Terminal. To work around this, the following control keys have been defined: Function Key Up ctrl+E Down ctrl+X Left ctrl+S Right ctrl+D Refer to Source/pSys/ReadMe.txt for more details about the p-System adaptation. Documentation UCSD p-System Users Manual Boot Disk There is no mechanism provided to create a p-System boot disk from scratch under RomWBW. This has already been done as part of the porting process. You must use the provided p-System hard disk image file which is bootable. Character Device Mapping RomWBW Character Devices are automatically assigned to p-System devices at startup. The current HBIOS Console device is assigned to CONSOLE:. The next available HBIOS Char device is assigned to REMIN:/REMOUT:. The next available HBIOS Char devices is assigned to PRINTER: Notes There is no floppy support at this time. The hard disk image contains 6 p-System slices which are assigned to p-System unit numbers 4, 5, 9, 10, 11, and 12 which is standard for p-System. Slices 0-5 are assigned sequentially to these p-System unit numbers and it is not possible to reassign them. Unit #4 (slice 0) is bootable and contains all of the p-System distribution files. Unit #5 (slice 1) is just a blank p-System filesystem. The other units (9-12) have not been initialized, but this can be done from Filer using the Zero command. p-System relies heavily on the use of a full screen terminal. This implementation has been setup to expect an ANSI or DEC VT-100 terminal or emulator. The screen output will be garbled if no such terminal or emulator is used for console output. There is no built-in mechanism to move files in and out of p-System. However, the .vol files in Source/pSys can be read and modified by CiderPress. CiderPress is able to add and remove individual files. Andrew Davidson has created a Python script that can extract p-System volumes from an existing disk image file. The script is also capable of inserting a modified volume back into the disk image file. This tool is available at https://github.com/robosnacks/psysimg . FreeRTOS Phillip Stevens has ported FreeRTOS to run under RomWBW. FreeRTOS is not provided in the RomWBW distribution. FreeRTOS is available under the MIT licence and further general information is available at FreeRTOS . Phillip may be contacted via his GitHub Page . Fuzix Fuzix is a Unix-ish operating system for small systems. It is the work of Alan Cox and is hosted on GitHub at https://github.com/EtchedPixels/FUZIX . Fuzix itself is a stand-alone operating system, but it frequently utilizes RomWBW to boot and launch on RomWBW-supported platforms. For those Fuzix platforms that leverage RomWBW for startup, you will program your ROM with the normal RomWBW ROM \u2013 there is no Fuzix-specific ROM. A Fuzix disk image for your system is then written to your disk media. After booting your system via the normal RomWBW ROM, you start Fuzix simply by choosing the disk device containing the Fuzix image at the RomWBW Loader prompt. To create a Fuzix disk image: Locate and download the Fuzix disk image for your system from https://www.fuzix.org/ . For each platform, you will typically find two image files. An emulator image ( emu-xxx.img ) and a disk image ( disk.img ). You want the disk image file. Write the disk image file to your physical media (CF Card, SD Card, etc.) starting at the beginning of the media (first sector). Do not combine the Fuzix image with the RomWBW disk images \u2013 they are entirely separate. To boot into Fuzix: Insert your Fuzix disk media. Power-up or reset your system. RomWBW should load normally and bring you to the RomWBW Boot Loader prompt. Depending on the platform, Fuzix may be built to run at a different baud rate that the default RomWBW baud rate. If so, it is best to change your RomWBW baud rate prior to initiating the Fuzix startup. You can do this at the loader prompt with a command like this: I 0 38400 Replace 38400 with the desired baud rate for Fuzix. You will be prompted to change your terminal\u2019s baud rate at this time. At the RomWBW Boot Loader prompt, enter the disk unit number of the Fuzix media. Fuzix should load and you will see device discovery/information messages that vary depending on your platform. This is a typical example: RCBus [RCZ180_nat_wbw] Boot Loader FP Switches = 0x00 Boot [H=Help]: 2 Booting Disk Unit 2, Slice 0, Sector 0x00000000... Volume \"Fuzix 126 Loader\" [0xF200-0xF400, entry @ 0xF200]... FUZIX version 0.4 Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha Copyright (c) 2013-2015 Will Sowerbutts wi...@sowerbutts.com Copyright (c) 2014-2023 Alan Cox al...@etchedpixels.co.uk Devboot 512kB total RAM, 448kB available to processes (15 processes max) Enabling interrupts ... ok. 0000 : CF Card - OK 0001 : - absent hda: hda1 hda2 (swap) bootdev: At the bootdev: prompt, enter hda1 . Fuzix should load and you will be prompted for a date/time. Here is a typical example: bootdev: hda1 Mounting root fs (root_dev=1, ro): OK Starting /init init version 0.9.1 Checking root file system. Current date is Fri 2023-08-18 Enter new date: Current time is 13:30:24 Enter new time: ^ ^ n n Fuzix 0.4 @< Welcome to Fuzix m m login: At the login: prompt, enter root . No password is required. You should then get a Fuzix # command prompt. login: root Welcome to FUZIX. # You may now use Fuzix as desired. The general operation and use of Fuzix is outside of the scope of this document. Custom Applications The operation of the RomWBW hosted operating systems is enhanced through several custom applications. You have already read about one of these \u2013 the ASSIGN command. These applications are functional on all of the OS variants included with RomWBW. The applications discussed here are not the same as the built-in ROM applications mentioned previously. These applications run as commands within the operating systems provided by RomWBW. So, these commands are only available at an operating system prompt after an operating system has been loaded. All of the RomWBW Custom Applications are built to function under all of the RomWBW Operating Systems (except for p-System). In general, the applications will automatically adapt as needed to the currently running operating system. One exception is FDU \u2013 the Floppy Disk Utility. This application requires that you pick the floppy disk interface you want to interact with. There is more complete documentation of all of these applications in the related RomWBW manual \u201c RomWBW Applications \u201d found in the Doc directory of the distribution. The following custom applications are found on the ROM disk and are, therefore, globally available. Application **Description ASSIGN Add, change, and delete drive letter assignments. Use ASSIGN /? for usage instructions. SYSCOPY Copy system image to a device to make it bootable. Use SYSCOPY with no parms for usage instructions. MODE Reconfigures serial ports dynamically. FDU Format and test floppy disks. Menu driven interface. FORMAT Will someday be a command line tool to format floppy disks. Currently does nothing! XM XModem file transfer program adapted to hardware. Automatically uses primary serial port on system. FLASH Will Sowerbutts\u2019 in-situ ROM programming utility. FDISK80 John Coffman\u2019s Z80 hard disk partitioning tool. See documentation in Doc directory. FAT Access MS-DOS FAT filesystems from RomWBW (based on FatFs). TALK Direct console I/O to a specified character device. RTC Manage and test the Real Time Clock hardware. TIMER Display value of running periodic system timer. CPUSPD Change the running CPU speed and wait states of the system. Some custom applications do not fit on the ROM disk. They are found on the disk image files or the individual files can be found in the Binary/Apps directory of the distribution. They are also included on the floppy disk and hard disk images. Application Description TUNE Play .PT2, .PT3, .MYM audio files. INTTEST Test interrupt vector hooking. Real Time Clock & Date/Time Stamping RomWBW supports a variety of real time clock hardware. If your system has this hardware, then it will be able to maintain the current date and time even while your system is turned off. Additionally, depending on the operating system being used, you may be able to utilize date/time stamping of files. To facilitate this a CP/M clock driver (WBWCLK) has been included inside CLOCKS.DAT that will read the clock via a RomWBW HBIOS call You can determine if your system has a real time clock present (and functioning) by looking at the boot messages. Here is an example of a boot message reflecting the detection of a valid real time clock module: DSRTC: MODE=STD IO=0x8A Thu 2023-10-19 14:07:11 CHARGE=ON This example is from a DSRTC clock module. You may have a different one, but it will always display the current date/time. In some cases, your real time clock will support charging of the battery or super-capacitor while the system has power. The status of this charging is displayed. If the date/time of your RTC needs to be updated, you will need to do this with one of the utilities described below. There is no ability to update the date/time of the RTC in the RomWBW Boot Loader or Monitor. Date/Time Utilities RomwWBW includes two utilities for displaying or setting the date/time stored by the RTC. They are both a bit different and are briefly described below. A third utility TESTCLOK is also included as part of ZSDOS WDATE Utility The WDATE utility (contributed by Kevin Boone) is an application that will display and/or update the current date/time. Its operation is described in RomWBW Applications . This utility works with any of the supported RomWBW RTC hardware. Here is an example of displaying and updating the date/time with this utility: A>wdate Thursday 19 October 14:14:43 2023 A>wdate 23 10 19 14 24 30 A>wdate Thursday 19 October 14:24:34 2023 Note that WDATE does not have anything to do with date/time stamping of files. It merely displays and sets the real time clock value. RTC Utility Like WDATE , the RTC utility (contributed by Andrew Lynch) will let you display and set the current date/time. However, this utility only works with the DSRTC hardware (DS1302 chip). It is a \u201cdirect to hardware application\u201d. Its operation is described in RomWBW Applications . Here is an example of displaying and updatting the date/time with this utility: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>t Current time: 23-10-19 14:30:25-05 RTC>i Init date/time. YEAR:23 MONTH:10 DATE:19 HOURS:14 MINUTES:31 SECONDS:00 DAY:05 The RTC utility is also capable of turning the charging feature of the DS1320 chip on or off. Here is an example of turning if off and back on: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>n Trickle charger disabled. RTC>c Trickle charger enabled. Do not enable charging unless you are sure that your system supports this. If your RTC is being powered by a normal battery, it would be dangerous to enable charging. TESTCLOK Utility The TESTCLOK utility is used to test a selected CPM clock driver loaded from the CLOCKS.DAT file. After selecting the location of CLOCKS.DAT and the clock driver (45. WBWCLK) it displays the currently configured time until a key is pressed. A>testclok TESTCLOK V1.0 Copyright (C) 1988 H.F. Bower / C.W. Cotrill Extract Clock from Library ([Y]/N) : Y Location of CLOCKS.DAT [A0:] : <RETURN> 1. ACTRIX 2. ALSPA 3. AMPRO-LB 4. ANLYTCL-PRD 5. AP2-CDZ180 6. AP2-THND/MT 7. AP2-TIMASTR 8. AP2E+PCP-TM 9. AP2E+PCPI 10. AP2E-THUNDR 11. AP2E-TMASTR 12. BIG-BD-II 13. BP-BIOS 14. CCS-WALLCLK 15. CPUPRO-SSB1 16. ELECTR-MFIO 17. EPSON-QX10 18. ETS180IO+ 19. H19-SUPER19 20. H19-ULTRA 21. H19-WATZMAN 22. H89-BITZERO 23. H89-PC12 24. H89-WIDGET 25. H89-WISE 26. H89UTI 27. HEATH-BIOS 28. HOUSEMASTER 29. K83-HOLMES 30. KAYPRO-84 31. KENMOR-ZTIM 32. KPRO-ADVENT 33. KPRO-LEGACY 34. MD3-MACK 35. MTN100K-DAY 36. ONEAC-ON! 37. OTRANA-ATCH 38. P&T-HEARTBT 39. QTSYS-S100 40. RELATIVE 41. S100-5832 42. SB180-HRTBT 43. SB180-XBIOS 44. SIMHCLOK 45. WBWCLK 46. XEROX-820 47. ZSDOS-BIOS Enter Clock Driver Selection : 45 ..Loading : WBWCLK ... Linking Clock Module... OK RomWBW HBIOS Clock 1.1 RomWBW Series HBIOS Clock Press any key to quit... 19 Oct 2023 14:24:34 Since this runs at the CPM driver level it is useful as an end-to-end test to prove that date time stamping is able to read the correct time The TESTCLOK utility is provided by ZSDOS, plese see the ZSDOS Manual for further information Date/Time File Stamping If an RTC is available in your system, then most operating systems can use it to date/time stamp files. This just means recording the date/time of file creation, update, and or access in the directory. This capability is available in all of the RomWBW operating system except the original DRI CP/M 2.2. Three types of date/time stamping are supported using realtime clock supported by RomWBW HBIOS. DateStamper, NZT and P2DOS. In some cases (such as ZSDOS), you must load an RSX (memory resident utility) to enable date/time stamping of files. This could be automated using a PROFILE.SUB file. Preconfigured loaders are provided, bypassing the need to use SETUPZST. Additionally, you will need to initialize the directory. The procedure varies depending on the date/time stamping mechanism, so you must review the associated documentation. The date/time stamping mechanisms for each operating system are generally not compatible. If you initialize a directory for a type of stamping, you should be careful not to manipulate that directory with a different operating system with a different date/time stamping mechanism. Doing so may corrupt the directory. The RomWBW disk images do not have date/time stamping initialized. This is to avoid any chance of directory corruption. DateStamper DateStamper datestamping follows the standard set by Plu*Perfect Systems. This method stores stamps in a disk file named !!!TIME&.DAT . Only DateStamper stamping stores full time and date stamps for file Creation, Last Modification, and Last Access, and may be used with any CP/M diskette format. In addition, the DateStamper protocol is supported by a mature set of compatible utilities. Key Utilities LDDS.COM - Load DateStamper date/time stamping resident extension. (RomWBW Provided) PUTDS.COM - Prepare disk for DateStamper date/time stamping. After using PUTDS to initialize a directory for ZDS date stamping, it may be necessary to run RELOG before the stamping routines will actually start working. P2DOS (CP/M Plus compatible) CP/M Plus-type datestamping is also widely used due to the popularity of CP/M Plus (also know as CP/M 3). CP/M Plus-type file datestamping uses directory sectors to store file datestamps which may be accessed more quickly by programs, but there is no Last File Access stamp. Finally, the range of utilities for this type of stamps is more limited than for the DateStamper protocol. Key Utilities LDP2D.COM - Load P2DOS date/time stamping resident extension. (RomWBW Provided) INITDIR.COM - Prepares disks for P2DOS-type file stamping. NZT The use of NZT needs to be further documented Key Utilities LDNZT.COM - Load NZT date/time stamping resident extension. (RomWBW Provided) Additional Notes The following files have been provided, customised and tested for for use in RomWBW CLOCKS.DAT - Library of clock drivers, which has been updated to include the RomWBW clock driver WBWCLK, and also includes the SIMHCLOK clock driver. The file is just a standard LU type library and is easily updated using NULU. The members are the relocatable binaries, but with the .REL extension removed. STAMPS.DAT - Library of available date/time stamping modules for SETUPZST. The file has been replaced with an updated version from the Walnut Creek CP/M CDROM. The original version has a bug that prevents RSX (resident system extension) mode to load properly. Additional Notes SETUPZST (provided by ZSDOS) Should not normally be needed since the creation of the appropriate LDTIM loaders has already been performed. FILEDATE only works with DateStamper style date stamping. If you run it on a drive that is not initialized for DateStamper, it will complain FILEDATE, !!!TIME&.DAT missing . This is normal and just means that you have not initialized that drive for DateStamper (using PUTDS). ZXD will handle either DateStamper or P2DOS type date stamping. However, it must be configured appropriately. As distributed, it will look for P2DOS date stamps. Use ZCNFG to reconfigure it for P2DOS if that is what you are using. Timezone None of the operating systems distributed with RomWBW have any concept of timezone. When files are date/time stamped, the date/time will simply be whatever date/time the RTC currently has. The normal practice is to set the RTC to your local time. This implies that you would need to manually adjust the RTC for daylight savings time and/or when you travel to a different time zone. The date/time stamps of files in directories will also be stored in local time. This includes files stored in a FAT filesystem. If you subsequently view the directory from modern machines (Windows, Linux, etc.), the date/time displayed will depend on the behavior of the modern system. For example, Linux assumes that the date/time of files is UTC. So, if you create a file on a FAT filesystem with your RomWBW computer and then use Linux to view the directory, the date/time stamps will seem \u201coff\u201d by a few hours. The only alternative you may consider is setting the date/time of your RTC to UTC. Since UTC is consistent across all timezones and daylight savings time, your file date/time stamps will also be consistent. Of course, this will mean that your RomWBW computer will display a date/time that seems wrong because it is not local time. CP/NET Networking Digital Research created a simple network file sharing system called CP/NET. This allowed a network server running CP/NOS to host files available to network attached CP/M computers. Essentially, the host becomes a simple file sharing server. RomWBW disk images include an adaptation of the DRI CP/NET client software provided by Douglas Miller. RomWBW does not support operation as a network server itself. However, Douglas has also developed a Java-based implementation of the DRI network server that can be used to provide host services from a modern computer. Both CP/NET 1.2 and 3.0 clients are provided. Version 1.2 is for use with CP/M 2.2 and compatible OSes. Version 3.0 is for use with CP/M 3 and compatible OSes. The CP/NET client software provided with RomWBW requires a supported ethernet interface module. At this time, the following are supported: RCBus MT011 w/ Ethernet Featherwing and (optionally) SPI FRAM (e.g., Adafruit SPI Non-Volatile FRAM Breakout) Duodyne Disk I/O w/ Wiz850IO and (optionally) SPI NVRAM (e.g., 25LC256) Generic Serial Interface NOTE: The Generic Serial Interface is supported by RomWBW, but is not documented here. You must refer to the CP/NET documentation referenced below. The client software interacts directly with this hardware. In a future version of RomWBW, I hope to add a generic networking API that will allow a greater range of network hardware to be used. To use CP/NET effectively, you will want to review the documentation provided by Douglas on at his cpnet-z80 GitHub Project . Additionally, you should consult the DRI documentation which is not included with RomWBW, but is available on the cpnet-z80 site. Below, I will provide the general steps involved in setting up a network using MT011 with RomWBW. CP/NET Client Setup The CP/NET client files are included on the RomWBW disk images, but they are found in user area 4. They are placed there to avoid confusing anyone that is not specifically trying to run a network client. They are only found on the CPM 2.2 and CP/M 3 slices. Using CP/NET on alternative OSes may work, but is not officially supported. The CP/NET client files are packaged in .LBR library files. The library files are found in user area 4. 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 First, you need to merge the files from the correct library file into user area 0. This is done by extracting the files using the NULU library management utility application. Start NULU specifying desired CP/NET library for \\<filename>: A>NULU 4:<filename> At the NULU prompt, extract the files using the -E *.* command: -READY A0:>-E *.* Exit NULU using the -X command: -Extract members A0:>-x Here is an example of extracting the CP/NET 1.2 client files for an RCBus system w/ MT011. You should be in user area 0 when performing this operation. A>nulu 4:cpn12mt NULU 1.52 (07/12/87) Copyright (C) 1984, 1985 & 1987 by Martin Murray Bug fixes in version 1.52 by Mick Waters TYPE -H FOR HELP Library A4:CPN12MT.LBR open. (Buffer size: 259 sectors) Active entries: 27, Deleted: 0, Free: 5, Total: 32. -READY A0:>-e *.* Extracting... CCP .SPR to A0:CCP .SPR CPM2NET .HLP to A0:CPM2NET .HLP CPNBOOT .COM to A0:CPNBOOT .COM CPNET12 .HLP to A0:CPNET12 .HLP CPNETLDR.COM to A0:CPNETLDR.COM CPNETSTS.COM to A0:CPNETSTS.COM DSKRESET.COM to A0:DSKRESET.COM ENDLIST .COM to A0:ENDLIST .COM LOCAL .COM to A0:LOCAL .COM LOGIN .COM to A0:LOGIN .COM LOGOFF .COM to A0:LOGOFF .COM MAIL .COM to A0:MAIL .COM NDOS .SPR to A0:NDOS .SPR NETDOWN .COM to A0:NETDOWN .COM NETSTAT .COM to A0:NETSTAT .COM NETWORK .COM to A0:NETWORK .COM NVRAM .COM to A0:NVRAM .COM PIPNET .COM to A0:PIPNET .COM RDATE .COM to A0:RDATE .COM SNIOS .SPR to A0:SNIOS .SPR SRVSTAT .COM to A0:SRVSTAT .COM TR .COM to A0:TR .COM WIZCFG .COM to A0:WIZCFG .COM WIZDBG .COM to A0:WIZDBG .COM WIZTEST .COM to A0:WIZTEST .COM XSUBNET .COM to A0:XSUBNET .COM -Extract members A0:>-x Closing A4:CPN12MT.LBR... At this point, you will need to configure your ethernet adapter for your local network using WIZCFG . The definitive guide to the use of WIZCFG is on the cpnet-z80 site in the document called \u201cCPNET-WIZ850io.pdf\u201d. Here is an example of the commands needed to configure the WizNet: wizcfg w n F0 set CP/NET node id wizcfg w i 192.168.1.201 set WizNet IP address wizcfg w g 192.168.1.1 set local network gateway IP address wizcfg w s 255.255.255.0 set WizNet subnet mask wizcfg w 0 00 192.168.1.3 31100 set server node ID, IP address, & port You will need to use values appropriate for your local network. You can use the command wiznet w to display the current values which is useful to confirm they have been set as intended. A>wizcfg w Node ID: F0H IP Addr: 192.168.1.201 Gateway: 192.168.1.1 Subnet: 255.255.255.0 MAC: 98:76:B6:11:00:C4 Socket 0: 00H 192.168.1.3 31100 0 These values can be persisted across power-cycles if your system has NVRAM storage. To program the values into your NVRAM, you would use the same commands as above, but omit the w parameter. The \u201cCPNET-WIZ850io.pdf\u201d document is highly recommended to understand the operation of WIZCFG . If you do not utilize NVRAM to persist your configuration, you will need to reapply these commands every time you power cycle your RomWBW computer, so I recommend putting them into a SUBMIT file. After applying these commands, you should be able ping the WizNet from another computer on the local network. If this works, then the client-side is ready. CP/NET Sever Setup These instructions will assume you are using Douglas Miller\u2019s CpnetSocketServer to implement a CP/NOS server on your network. The definitive guide to this software is also on the [cpnet-z80] (https://github.com/durgadas311/cpnet-z80) site and is called \u201cCpnetSocketServer.pdf\u201d. The software is a Java application, so it can generally run anywhere there is a Java runtime environment available. I have normally used it on a Linux system and have had good results with that. You will need to download the application called \u201cCpnetSocketServer.jar\u201d from the cpnet-z80 site. The application uses a configuration file. My configuration file is called \u201ccpnet00.rc\u201d and has these contents: cpnetserver_host = 192.168.1.3 cpnetserver_port = 31100 cpnetserver_temp = P cpnetserver_sid = 00 cpnetserver_max = 16 cpnetserver_root_dir = /home/wayne/cpnet/root You will also need to setup a directory structure with the drive letters per the documentation. To start the server, you would use a command like this: java -jar CpnetSocketServer.jar conf=cpnet00.rc At this point, the server should start and you should see the following: CpnetSocketServer v1.3 Using config in cpnet00.rc Server 00 Listening on 192.168.1.3 port 31100 debug false Your CP/NET server should now be ready to accept client connections. CP/NET Usage With both the client and server configured, you are ready to load and use CP/NET on your RomWBW system. CP/NET documentation is available on the cpnet-z80 site. The document is called \u201cdri-cpnet.pdf\u201d. Under CP/M 2.2, you will start the networking client using the command CPNETLDR . Under CP/M 3, you use the command NDOS3 . If that works, you can map network drives as local drives using the NETWORK command. The CPNETSTS command is useful for displaying the current status. Here is a sample session from CP/M 2.2: A>cpnetldr CP/NET 1.2 Loader ================= BIOS E600H 1A00H BDOS D800H 0E00H SNIOS SPR D400H 0400H NDOS SPR C800H 0C00H TPA 0000H C800H CP/NET 1.2 loading complete. A>network k:=c:[0] A>dir k: K: TELNET COM : ZDENST COM : CLRDIR COM : RTC COM K: DDTZ COM : MBASIC COM : XSUBNET COM : NETWORK COM K: WGET COM : UNCR COM : FLASH COM : PIP COM K: TIMEZONE COM : COMPARE COM : ZAP COM A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = LOCAL Drive B: = LOCAL Drive C: = LOCAL Drive D: = LOCAL Drive E: = LOCAL Drive F: = LOCAL Drive G: = LOCAL Drive H: = LOCAL Drive I: = LOCAL Drive J: = LOCAL Drive K: = Drive C: on Network Server ID = 00H Drive L: = LOCAL Drive M: = LOCAL Drive N: = LOCAL Drive O: = LOCAL Drive P: = LOCAL Console Device = LOCAL List Device = LOCAL If you are using CpSocketServer to provide the CP/NOS server, then you will see some messages on your server console when clients connect. Here are the messages issued by the server in the above example: Connection from 192.168.1.201 (31100) Remote 192.168.1.201 is f0 Creating HostFileBdos 00 device with root dir /home/wayne/cpnet/root At this point CP/NET is ready for general use. You should be able to access files on the network mapped drives just like files on your local drives. Network Boot It is possible to boot your RomWBW system directly from a network server if it has the required hardware. 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. The supported hardware is: RCBus System w/ MT011 including: Featherwing WizNet W5500 SPI FRAM on secondary SPI interface (CS2) Doudyne Disk I/O Board including: WIZ850io Module 25LCxxx Serial SPI EEPROM Unlike the CP/NET Client, the presence of dedicated non-volatile storage is required to hold the network configuration. This will be FRAM (for MT011) or Serial SPI EEPROM (Duodyne). The NVRAM is used to store your WizNet configuration values so they do not need to be re-entered every time you power-cycle your system. It is important to understand that the operating system that is loaded in this case is not a RomWBW enhanced operating system. Some commands (such as the ASSIGN command) will not be possible. Also, you will only have access to drives provided by the network server \u2013 no local disk drives will be available. Using the same values from the previous example, you would issue the WIZCFG commands: wizcfg n F0 wizcfg i 192.168.1.201 wizcfg g 192.168.1.1 wizcfg s 255.255.255.0 wizcfg 0 00 192.168.1.3 31100 Note that the \u2018w\u2019 parameter is now omitted which causes these values to be written to NVRAM. As before, your network server will need to be running CpnetSocketServer. However, you will need to setup a directory that contains some files that will be sent to your RomWBW system when the Network boot is performed. By default the directory will be ~/NetBoot . In this directory you need to place the following files: cpnos.sys ndos.spr snios.spr You also need to make sure CpnetSocketServer is configured with an \u2018A\u2019 drive and that drive must contain (at an absolute minimum) the following file: ccp.spr All of these files are found in the Binary/CPNET/NetBoot directory of the RomWBW distribution. You will find 2 sub-directories named MT and DUO. Get the files from the sub-directory corresponding to your specific hardware. Finally, you need to add the following line to your CpnetSocketServer configuration file: netboot_default = cpnos.sys To perform the network boot, you start your RomWBW system normally which should leave you at the Boot Loader prompt. The \u2018N\u2019 command will initiate the network boot. Here is an example of what this looks like: RCBus [RCZ180_nat_wbw] Boot Loader Boot [H=Help]: n Loading Network Boot... MT011 WizNET Network Boot WBWBIOS SPR FD00 0100 COBDOS SPR FA00 0300 SNIOS SPR F600 0400 NDOS SPR EA00 0C00 58K TPA A> The CP/M operating system and the CP/NET components have been loaded directly from the network server. All of your drive letters are automatically mapped directly to the drive letters configured with CpnetSocketServer. A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = Drive A: on Network Server ID = 00H Drive B: = Drive B: on Network Server ID = 00H Drive C: = Drive C: on Network Server ID = 00H Drive D: = Drive D: on Network Server ID = 00H Drive E: = Drive E: on Network Server ID = 00H Drive F: = Drive F: on Network Server ID = 00H Drive G: = Drive G: on Network Server ID = 00H Drive H: = Drive H: on Network Server ID = 00H Drive I: = Drive I: on Network Server ID = 00H Drive J: = Drive J: on Network Server ID = 00H Drive K: = Drive K: on Network Server ID = 00H Drive L: = Drive L: on Network Server ID = 00H Drive M: = Drive M: on Network Server ID = 00H Drive N: = Drive N: on Network Server ID = 00H Drive O: = Drive O: on Network Server ID = 00H Drive P: = Drive P: on Network Server ID = 00H Console Device = LOCAL List Device = LOCAL At this point you can use CP/M and CP/NET normally, but all disk access will be to/from the network drives. There is no access to your local disk drives in this boot mode. Transferring Files Transferring files between your modern computer and your RomWBW system can be achieved in a variety of ways. The most common of these are described below. All of these have a certain degree of complexity and I encourage new users to use the available community forums to seek assistance as needed. Serial Port Transfers RomWBW provides an serial file transfer program called XModem that has been adapted to run under RomWBW hardware. The program is called XM and is on your ROM disk as well as all of the pre-built disk images. You can type XM by itself to get usage information. In general, you will run XM with parameters to indicate you want to send or receive a file on your RomWBW system. Then, you will use your modern computers terminal program to complete the process. The XM application generally tries to detect the hardware you are using and adapt to it. However, you must ensure that you have a reliable serial connection. You must also ensure that the speed of the connection is not too fast for XModem to service. If your file transfer attempts are failing, try either of the following: Check that hardware flow control is enabled in your terminal emulation software. Reduce the speed of your serial port connection. There is an odd interaction between XModem and partner terminal programs that can occur. Essentially, after launching XM , you must start the protocol on your modern computer fairly quickly (usually in about 20 seconds or so). So, if you do not pick a file on your modern computer quickly enough, you will find that the transfer completes about 16K, then hangs. The interaction that causes this is beyond the scope of this document. Disk Image Transfers It is possible to pass disk images between your RomWBW system and your modern computer. This assumes you have an appropriate media slot on your modern computer for the media you want to use (CF Card, SD Card, floppy drive, etc.). The general process to get files from your modern computer to a RomWBW computer is: Use cpmtools on your modern computer to create a RomWBW CP/M filesystem image. Insert your RomWBW media (CF Card, SD Card, floppy disk, etc.) in your modern computer. Use a disk imaging tool to copy the RomWBW filesystem image onto the media. Move the media back to the RomWBW computer. This process is a little complicated, but it has the benefit of allowing you to get a lot of files over to your RomWBW system quickly and with little chance of corruption. The process can be run in reverse to get files from your RomWBW computer to a modern computer. The exact use of these tools is a bit too much for this document, but the tools are all included in the RomWBW distribution along with usage documents. Note that the build scripts for RomWBW create the default disk images supplied with RomWBW. It is relatively easy to customize the contents of the disk images that are part of RomWBW. This is described in more detail in the Source/Images directory of the distribution. FAT Filesystem Transfers The FAT filesystem format that originated with MS-DOS is almost ubiquitous across modern computers. Virtually all operating systems now support reading and writing files to a FAT filesystem. For this reason, RomWBW now has the ability to read and write files on FAT filesystems. This capability means that you can generally use your modern computer to make an SD Card, CF Card, or USB Drive with a standard FAT filesystem on it, then place that media in your RomWBW computer and access the files. Files can be copied between a FAT filesystem and a CP/M filesystem, but you cannot execute files directly from a FAT filesystem. FAT12, FAT16, and FAT32 formats are supported. Long filenames are not supported. Files with long filenames will show up with their names truncated into the older 8.3 convention. If you have files on your modern computer with long filenames, it is usually easiest to rename them on the modern computer. A FAT filesystem can be located on floppy or hard disk media. For hard disk media, a valid FAT Filesystem partition must exist. Some additional Notes and WARNINGS Things to be careful about CP/M (and compatible) OSes do not support all of the filename characters that a modern computer does. The following characters are not permitted in a CP/M filename: < > . , ; : = ? * [ ] _ % | ( ) / \\ The FAT application does not auto-rename files when it encounters invalid filenames. It will just issue an error and quit. Additionally, the error message is not very clear about the problem. Microsoft Windows will sometimes suggest reformatting partitions that it does not recognize (e.g. RomWBW). If you are using media that contains both a FAT partition and a RomWBW partition you may prompted to format a partition of your SD/CF/USB Media when inserting the card into a Windows computer, you probably want to select Cancel. FAT Filesystem Preparation In general, you can create media formatted with a FAT filesystem on your RomWBW computer or on your modern computer. We will only be discussing the RomWBW-based approach here. Floppy Disk In the case of a floppy disk, you can use the FAT application to format the floppy disk. The floppy disk must already be physically formatted using RomWBW FDU or equivalent. If your floppy disk is on RomWBW disk unit 2, you could use FAT FORMAT 2: . This will overwrite the floppy with a FAT filesystem and all previous contents will be lost. Once formatted this way, the floppy disk can be used in a floppy drive attached to a modern computer or it can be used on RomWBW using the other FAT tool commands. Hard Disk In the case of hard disk media, it is necessary to have a FAT partition. If you prepared your RomWBW hard disk media using the disk image process, then this partition will already be defined and you do not need to recreate it. This default FAT partition is located at approximately 512MB from the start of your disk and it is 384MB in size. So, your hard disk media must be 1GB or greater to use this default FAT partition. You can confirm the existence of the FAT partition with FDISK80 by using the \u2018P\u2019 command to show the current partition table. Here is an example of a partition table listing from FDISK80 that includes the FAT partition (labelled \u201cFAT16\u201d): Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 FAT16 06 1023:0:1 1023:15:16 1050624 786432 384M 3 00 *** empty *** 4 00 *** empty *** If your hard disk media does not have a FAT partition already defined, you will need to define one using FDISK80 by using the \u2018N\u2019 command. Ensure that the location and size of the FAT partition does not overlap any of the CP/M slice area and that it fits within the size of your media. Once the partition is defined, you will still need to format it. Just as with a floppy disk, you use the FAT tool to do this. If your hard disk media is on RomWBW disk unit 4, you would use FAT FORMAT 4: . This will look something like this: E>fat format 4: About to format FAT Filesystem on Disk Unit #4. All existing FAT partition data will be destroyed!!! Continue (y/n)? Formatting... Done Your FAT filesystem is now ready to use. If your RomWBW system has multiple disk drives/slots, you can also just create a disk with your modern computer that is a dedicated FAT filesystem disk. You can use your modern computer to format the disk (floppy, CF Card, SD Card, etc.), then insert the disk in your RomWBW computer and access it using FAT based on its RomWBW unit number. FAT Application Usage Transferring files is accomplished by running a RomWBW custom application called FAT . This application understands both FAT filesystems as well as CP/M filesystems. To copy files from your modern computer to your RomWBW computer, start by putting the disk media with the FAT filesystem in your modern computer. The modern computer should recognize it. Then copy the files you want to get to your RomWBW computer onto this media. Once done, remove the media from your modern computer and insert it in the RomWBW computer. Finally, use the FAT tool to copy the files onto a CP/M drive. This process works just fine in reverse if you want to copy files from a CP/M filesystem to your modern computer. Complete instructions for the FAT application are found in RomWBW Applications . Here, we will just provide a couple of simple examples. Note that the FAT application is not on the ROM disk because it is too large to include there. The most important thing to understand about the FAT application is how it refers to FAT filesystems vs. CP/M filesystems. It infers this based on the file specification provided. If you use a specification like C:SAMPLE.TXT , it will use the C: drive of your CP/M operating system. If you use a specification like 4:SAMPLE.TXT , it will use the FAT filesystem on the disk in RomWBW disk unit 4. Basically, if you start your file or directory specification with a number followed by a colon, it means FAT filesystem. Anything else will mean CP/M filesystem. Here are a few examples. This first example shows how to get a FAT directory listing from RomWBW disk unit 4: E>fat dir 4: Directory of 4: E> As you can see, there are currently no files there. Now let\u2019s copy a file from CP/M to the FAT directory: E>fat copy sample.txt 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT ... [OK] 1 File(s) Copied If we list the FAT directory again, you will see the file: E>fat dir 4: Directory of 4: 01/30/2023 17:50:14 29952 ---A SAMPLE.TXT Now let\u2019s copy the file from the FAT filesystem back to CP/M. This time we will get a warning about overwriting the file. For this example, we don\u2019t want to do that, so we abort and reissue the command specifying a new filename to use: E>fat copy 4:sample.txt e: Copying... 4:/SAMPLE.TXT ==> E:SAMPLE.TXT Overwrite? (Y/N) [Skipped] 0 File(s) Copied E>fat copy 4:sample.txt e:sample2.txt Copying... 4:/SAMPLE.TXT ==> E:SAMPLE2.TXT ... [OK] 1 File(s) Copied Finally, let\u2019s try using wildcards: E>fat copy sample*.* 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT Overwrite? (Y/N) ... [OK] SAMPLE2.TXT ==> 4:/SAMPLE2.TXT ... [OK] 2 File(s) Copied Customizing RomWBW Startup Command Processing Most of the operating systems supported by RomWBW provide a mechanism to run commands at boot. This is similar to the AUTOEXEC.BAT files from MS-DOS. With the exception of ZPM3 and p-System, all operating systems will look for a file called PROFILE.SUB on the system drive at boot. If it is found, it will be processed as a standard CP/M submit file. You can read about the use of the SUBMIT facility in the CP/M manuals included in the RomWBW distribution. Note that the boot disk must also have a copy of SUBMIT.EXE . Note that the automatic startup processing generally requires booting to a disk drive. Since the ROM disk is not writable, there is no simple way to add/edit a PROFILE.SUB file there. If you want to customize your ROM and add a PROFILE.SUB file to the ROM Disk, it will work, but is a lot harder than using a boot disk. In the case of ZPM3, the file called STARTZPM.COM will be run at boot. To customize this file, you use the ZCPR ALIAS facility. You will need to refer to ZCPR documentation for more information on the ALIAS facility. p-System has its own startup command processing mechanism that is covered in the p-System documentation. NVRAM Configuration See section Setting NVRAM Options for information about how to apply NVRAM configuration. ROM Customization The pre-built ROM images are configured for the basic capabilities of each platform. Additionally, some of the typical add-on hardware for each platform will be automatically detected and used. If you want to go beyond this, RomWBW provides a very flexible configuration mechanism based on configuration files. Creating a customized ROM requires running a build script, but it is quite easy to do. Essentially, the creation of a custom ROM is accomplished by updating a small configuration file, then running a script to compile the software and generate the custom ROM and disk images. There are build scripts for Windows, Linux, and MacOS to accommodate virtually all users. All required build tools (compilers, assemblers, etc.) are included in the distribution, so it is not necessary to setup a build environment on your computer. RomWBW can be built on modern Windows, Linux, or MacOS computers. The process for building a custom ROM is documented in the ReadMe.txt file in the Source directory of the distribution. Any modern version of Windows (32-bit or 64-bit), MacOS, or Linux released in the last 10 years should be able to run the build process. For those who are interested in more than basic system customization, note that all source code is provided (including the operating systems). Modification of the source code is considered an expert level task and is left to the reader to pursue. Note that the ROM customization process does not apply to UNA. All UNA customization is performed within the ROM setup script that is built into the ROM. ROM User Application The User App is provided as a way to access a custom written ROM application. 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 instead, review the \u201cusrrom.asm\u201d file in the Source/HBIOS folder of the distribution. Upgrading Upgrading to a newer release of RomWBW is essentially just a matter of updating the ROM chip in your system. If you have spare ROM chips for your system and a ROM programmer, it is always safest to retain your existing, working ROM chip and program a new one with the new firmware. If the new one fails to boot, you can easily return to the known working ROM. For each ROM that comes with the RomWBW distribution, you will find that there are actually 3 different variants: .rom contains the complete ROM chip image .upd contains the system code, but omits the ROM Disk contents .com contains a CP/M executable version of the ROM code So, for example, RCZ80_std contains the following files: SBC_std.rom SBC_std.upd SBC_std.com The use of the .com variant is described below in Application Boot . As previously discussed, the ROM in most RomWBW systems contains both the system code as well as a ROM Disk with files on it. The .rom variant of the ROM contains a full ROM chip image including both the system code and the Rom Disk contents. The .upd variant of the ROM contains only the system code portion of the ROM. If you apply the .upd variant to your system, it will overlay the system code, but will not overlay the ROM Disk contents (they remain intact). You may use either the .rom or the .upd file when updating your ROM chip (this does not apply to Application Boot). It is best to use the .rom file for your upgrade because the files on your ROM Disk should be updated whenever you update your system code. The advantage of the .upd variant is that is much smaller, so you can upload and apply it faster. The ROM update instructions below generally refer to using the .rom variant. However, you may substitute the .upd variant if desired. Application Boot Prior to attempting to reprogram your actual ROM chip, you may wish to \u201ctry\u201d the update to ensure it will work on your system. With RomWBW, you can upload a new ROM image executable and load it from the command line. For each ROM image file (.rom) in the Binary directory, you will find a corresponding application file (.com). For example, for SBC_std.rom, there is also an SBC_std.com file. You can upload the .com file to your system using XModem, then simply run the .com file. You will see your system go through the normal startup process just like it was started from ROM. However, your physical ROM has not been updated and the next time you boot your system, it will revert to the system image contained in ROM. Using this .com version of a ROM is an excellent way to confirm that the new ROM code you intend to program will work correctly. If it does not, then you can just reboot and your old ROM will be loaded. When the .com file is loaded, you will be taken to the normal Boot Loader menu. However, you will find that the only OS that is available to boot from ROM is ZSDOS. There is only room for a single OS in the .com file. Even if you don\u2019t normally use ZSDOS, this will still confirm that your system operates well under the new ROM code. Upgrading via Flash Utility If you do not have easy access to a ROM programmer, it is usually possible to reprogram your system ROM using the FLASH utility from Will Sowerbutts. This application, called FLASH.COM, can be found on the ROM drive of any running system. In this case, you would need to transfer the new ROM image (.rom) over to your system using XModem (or one of the other mechanisms described in the Transferring Files section). The ROM image is too large to fit on your RAM drive, so you will need to transfer it to a larger storage drive. Once the ROM image is on your system, you can use the FLASH application to update your ROM. The following is a typical example of transferring ROM image using XModem and flashing the chip in-situ. NOTE : The FLASH utility can not determine the type of your ROM chip if it is write protected. Additionally, it has no way to determine if it is write protected. If the FLASH utility indicates it does not recognize your ROM chip, check to ensure the chip is not write protected. E>xm r rom.rom XMODEM v12.5 - 07/13/86 RBC, 28-Aug-2019 [WBW], ASCI Receiving: E0:ROM.IMG 7312k available for uploads File open - ready to receive To cancel: Ctrl-X, pause, Ctrl-X Thanks for the upload E>flash write rom.rom FLASH4 by Will Sowerbutts <will@sowerbutts.com> version 1.2.3 Using RomWBW (v2.6+) bank switching. Flash memory chip ID is 0xBFB7: 39F040 Flash memory has 128 sectors of 4096 bytes, total 512KB Write complete: Reprogrammed 2/128 sectors. Verify (128 sectors) complete: OK! Obviously, there is some risk to this approach since any issues with the programming or ROM image could result in a non-functional system. To confirm your ROM chip has been successfully updated, restart your system and boot an operating system from ROM. Do not boot from a disk device yet. Review the boot messages to see if any issues have occurred. Upgrading via XModem Flash Updater Similar to using the Flash utility, the system ROM can be updated or upgraded through the ROM-based updater utility. This works by reprogramming the flash ROM as the file is being transferred. Using the ROM-based updater has the advantage that secondary storage is not required to hold the new image. In other words, it is not necessary to have a mass storage device available to store the ROM image. From the Boot Loader menu select X (Xmodem Flash Updater) and then U (Begin Update). Then initiate the Xmodem transfer of the .rom file. Since the XModem Flash Updater will be relatively slow, you may wish to use the .upd varient of the ROM. More information can be found in the ROM Applications document. Post Upgrade Update Once you are satisfied that the ROM is working well, you will need to update the system images and RomWBW custom applications on your disk drives. The system images and custom applications are matched to the RomWBW ROM firmware in use. If you attempt to boot a disk or run applications that have not been updated to match the current ROM firmware, you are likely to have odd problems. The simplest way to update your disk media is to just use your modern computer to overwrite the entire media with the latest disk image of your choice. This process is described below in the Disk Images section. If you wish to update existing disk media in your system, you need to perform the following steps. If the disk is bootable, you need to update the system image on the disk using the procedure described in the Operating Systems section of this document. Finally, if you have copies of any of the RomWBW custom applications on your hard disk, you need to update them with the latest copies. The following applications are found on your ROM disk. Use COPY to copy them over any older versions of the app on your disk: ASSIGN.COM SYSCOPY.COM MODE.COM FDU.COM FORMAT.COM XM.COM FLASH.COM FDISK80.COM TALK.COM RTC.COM TIMER.COM FAT.COM For example: B>COPY ASSIGN.COM C: Some RomWBW custom applications are too large to fit on the ROM disk. If you are using any of these you will need to transfer them to your system and then update all copies. These applications are found in the Binary/Apps directory of the distribution and in all of the disk images. TUNE.COM The files normally contained on the standard ROM Disk is based on a 512K ROM. If your system has a smaller size ROM, then not all of these files will be included on your ROM Disk. You will need to copy them to your system from the /Binary/Apps folder of the RomWBW distribution. WARNING : If you run a RomWBW-specific application that is not the appropriate for the version of RomWBW you are running, the application will generate an error message and abort. System Update As previously described, a RomWBW ROM contains ROM applications as well as a ROM disk image. If you are upgrading your ROM with a new patch level release, you may wish to upgrade just the application portion of the ROM. This is referred to as a System Update. If the system running ROMWBW utilizes the SST39SF040 Flash chip then it is possible to do a System Update in place of a System Upgrade in some cases. A System Update would involve only updating the BIOS, ROM applications and ROM-hosted operating systems. A System Update may be more favorable than a System Upgrade in cases such as: Overwriting of the ROM drive contents is not desired. Temporary disk space is unavailable to hold a full ROM image. To reduce the time taken to transfer and flash a full ROM. Configuration changes are only minor and do not impact disk applications. The RomWBW build process generates a system update file along with the normal ROM image and can be identified by the extension \u201c.upd\u201d. It will be 128Kb in size. In comparison the normal ROM image will have the extension \u201c.rom\u201d and be 512Kb or 1024Kb in size. Transferring and flashing the System Update is accomplished in the same manner as described above in Upgrading via Flash Utility with the required difference being that the flash application needs to be directed to complete a partial flash using the /P command line switch. E>FLASH WRITE ROM.UPD /P","title":"User Guide"},{"location":"UserGuide/#preface","text":"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.","title":"Preface"},{"location":"UserGuide/#conventions-used","text":"","title":"Conventions Used"},{"location":"UserGuide/#size-suffixes","text":"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","title":"Size Suffixes"},{"location":"UserGuide/#links-and-urls","text":"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).","title":"Links and URLs"},{"location":"UserGuide/#getting-started","text":"","title":"Getting Started"},{"location":"UserGuide/#installation","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. 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.","title":"Installation"},{"location":"UserGuide/#system-startup","text":"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.","title":"System Startup"},{"location":"UserGuide/#core-system-information","text":"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.","title":"Core System Information"},{"location":"UserGuide/#hardware-discovery","text":"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.","title":"Hardware Discovery"},{"location":"UserGuide/#device-unit-assignments","text":"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.","title":"Device Unit Assignments"},{"location":"UserGuide/#startup-example","text":"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 <enter> for help. You can type L <enter> 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.","title":"Startup Example"},{"location":"UserGuide/#boot-loader-operation","text":"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 \\<enter> . For example, typing H<enter> will display a short command summary: Boot [H=Help]: h L - List ROM Applications D - Device Inventory R - Reboot System W - RomWBW Configure I <u> [<c>] - Set Console Interface/Baud Rate V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 .","title":"Boot Loader Operation"},{"location":"UserGuide/#starting-applications-from-rom","text":"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.","title":"Starting Applications from ROM"},{"location":"UserGuide/#starting-operating-systems-from-disk","text":"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 ( \\<diskunit> ) and optionally a dot followed by a second number ( \\<slice> ). The \\<disk unit> 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 \\<slice> 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 \\<enter> . Boot [H=Help]: 4 Booting Disk Unit 4, Slice 0, Sector 0x00000800... Volume \"Unlabelled\" [0xD000-0xFE00, entry @ 0xE600]... CBIOS v3.1.1-pre.194 [WBW] Formatting RAMDISK... Configuring Drives... A:=IDE0:0 B:=MD0:0 C:=MD1:0 D:=FD0:0 E:=FD1:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 I:=PRPSD0:0 J:=PRPSD0:1 K:=PRPSD0:2 L:=PRPSD0:3 1081 Disk Buffer Bytes Free CP/M-80 v2.2, 54.0K TPA A> Notice that a list of drive letters and their assignments to RomWBW devices and slices is displayed during the initialization of the operating system. Here is another example where we are booting disk unit 4, slice 3 which is the CP/M 3 operating system on this disk: Boot [H=Help]: 4.3 Booting Disk Unit 4, Slice 3, Sector 0x0000C800... Volume \"Unlabelled\" [0x0100-0x1000, entry @ 0x0100]... CP/M V3.0 Loader Copyright (C) 1998, Caldera Inc. BNKBIOS3 SPR F600 0800 BNKBIOS3 SPR 4500 3B00 RESBDOS3 SPR F000 0600 BNKBDOS3 SPR 1700 2E00 60K TPA CP/M v3.0 [BANKED] for HBIOS v3.5 A> Some operating systems (such as CP/M 3 shown above) do not list the drive assignments during initialization. In this case, you can use the ASSIGN command to display the current assignments. The Boot Loader simply launches whatever is in the disk unit/slice you have specified. It does not know what operating system is at that location. The layout of operating systems on disk media is described in the Disk Images section of this document.","title":"Starting Operating Systems from Disk"},{"location":"UserGuide/#auto-submit-batch-files","text":"All of the operating systems supplied with RomWBW have the ability to execute a \u201cbatch\u201d of commands by creating a batch submission file containing the commands to be executed. The mechanism for running commands automatically at startup varies by operating system. In some cases, it was built into the original operating system. In other cases, I have added this capability in the RomWBW BIOS of the operating system. In all cases, the file containing the commands to run at startup must be on the boot drive (A:). RomWBW automatically assigns A: to the disk slice you choose to boot. Adding a startup command file to the ROM Disk is not recommended because it would require customizing and building a new ROM. Use of bootable disk slices is preferred since the startup command files can be added/edited without any special system customization. Here is an overview for each operating system: CP/M 2.2 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Note that original CP/M 2.2 itself did not have this ability \u2013 it was added to the RomWBW CP/M 2.2 BIOS. The use of SUBMIT files is documented in Section 1.6.7 SUBMIT Command of the CPM Manual included in the Doc/CPM folder of the RomWBW distribution. Z-System (ZSDOS 1.1) - Will run run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Works exactly the same as CP/M 2.2. The original Z-System ZSDOS 1.1 did not have this ability \u2013 it was added to the RomWBW Z-System BIOS. The Z-System documentation does not cover the use of SUBMIT files \u2013 please refer to the CP/M 2.2 documentation. NZCOM - Will run the command STARTZCM at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the NZCOM Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the NZCOM boot process. Note that NZCOM itself is launched from ZSDOS via the included PROFILE.SUB file. CP/M 3 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. This mechanism is built into the CP/M 3 operating system. Please see Section 4.5 Executing Multiple Commands and Section 5.2.74 Executing the SUBMIT Command of the CPM3 Users Guide included in the Doc/CPM folder of the RomWBW distribution. Z3PLUS - Will run the command STARTZ3P at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the Z3PLUS Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the Z3PLUS boot process. Note that Z3PLUS itself is launched from CP/M 3 via the included PROFILE.SUB file. ZPM3 - Will run the command STARTZPM at startup. This is normally an alias file. You use SALIAS to edit such files. ZPM3 has no real documentation. The NZCOM documentation of STARTZCM is generally correct for ZPM3. Since RomWBW can utilize many disk slices, it is very easy to create slices for specific workflows (editing, software development, games, etc.). You can then just boot to the slice that is optimized for the task you want to perform. Each such slice may have its own startup command batch file that customizes the environment for the specific workflow desired.","title":"Auto-Submit Batch Files"},{"location":"UserGuide/#system-management","text":"","title":"System Management"},{"location":"UserGuide/#listing-device-inventory","text":"The device units available in your system are listed in the boot messages. However, if that list has scrolled off of your screen, you can use the \u2018D\u2019 command to display a list of them at any time from the Boot Loader prompt. Unit Device Type Capacity/Mode ---------- ---------- ---------------- -------------------- Char 0 ASCI0: RS-232 38400,8,N,1 Char 1 ASCI1: RS-232 38400,8,N,1 Char 2 UART0: RS-232 38400,8,N,1 Char 3 UART1: RS-232 38400,8,N,1 Char 4 UART2: RS-232 38400,8,N,1 Char 5 UART3: RS-232 38400,8,N,1 Char 6 TERM0: Terminal Video 0,ANSI Char 7 PRPCON0: Terminal Term Module,ANSI Disk 0 MD0: RAM Disk 352KB,LBA Disk 1 MD1: Flash Drive 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 IDE2: CompactFlash 3823MB,LBA Disk 7 IDE3: Hard Disk -- Disk 8 IDE4: Hard Disk -- Disk 9 IDE5: Hard Disk -- Disk 10 SD0: SD Card -- Disk 11 PRPSD0: SD Card 15193MB,LBA Video 0 TMS0: CRT Text,40x24 Sound 0 SND0: AY-3-8910 3+1 CHANNELS","title":"Listing Device Inventory"},{"location":"UserGuide/#rebooting-the-system","text":"The \u2018R\u2019 command within the Boot Loader performs a software reset of the system. The system will perform a startup just like powering up or pressing the hardware reset button (although the hardware is not physically reset). There is generally no need to do this, but it can be convenient when you want to see the boot messages again or ensure your system is in a clean state. Boot [H=Help]: r Restarting System...","title":"Rebooting the System"},{"location":"UserGuide/#setting-nvram-options","text":"On systems with RTC devices (that have Non-Volatile RAM), RomWBW supports storing some limited configuration option options inside this NVRAM. Several configuration options are currently supported, these are known as Switches Specify Automatic boot at startup, after an optional delay (AB) Define the Disk or ROM App to be booted at for automatic boot (BO) RomWBW uses bytes located at the start of RTC NVRAM, and includes a checksum of the bytes in NVRAM to check for integrity before using the configuration. Initially NVRAM has to be reset (with default values), before it can be used. As well as setting defaults, it also writes the correct checksum, and allows the NVRAM to be accessed and to store the RomWBW config. This is an explicit step that must be done, as any existing data stored is overwritten. If you are using NVRAM for other purposes, then you can continue to do so so long as you do NOT perform this Reset step. NVRAM may also need to be reset in these circumstances: When there has been a loss of power to the NVRAM. When upgrading to a new RomWBW version, or a RomWBW version that has new switches. If the NVRAM has been overwritten by another application. If you want to continue to use NVRAM in your applications you may want to consider storing your data above the RomWBW Switch data. To configure these options an inbuilt ROM application is provided which can be accessed by the command \u201c W \u201d from the RomWBW boot menu. This application is also built as a CP/M utility, but is not included on an disk image, it is found in the Binary/Applications folder of the RomWBW distribution. For further guidance on using this application please see the section \u201cRomWBW System Configuration\u201d in the RomWBW Applications document. If your system has both a Front Panel as well as NVRAM, be aware that the Front Panel switches take precedence over the NVRAM configuration settings. Note that the WizNet class of Network devices also contain NVRAM which is entirely separate from the RomWBW configuration NVRAM described here. A separate utility is used to set the WizNet NVRAM (see CP/NET Client Setup ). RomWBW Applications","title":"Setting NVRAM Options"},{"location":"UserGuide/#changing-console-and-console-speed","text":"Your system can support a number of devices for the console. They may be VDU type devices or serial devices. If you want to change which device is the console, the I menu option can be used to choose the unit and its speed. The command format is I <unit> [<baudrate>] where \\<unit> is the character unit to select and \\<baudrate> is the optional baud rate. Supported baud rates are: 75 450 1800 7200 38400 115200 460800 1843200 150 600 2400 9600 28800 153600 614400 2457600 225 900 3600 14400 57600 230400 921600 3686400 300 1200 4800 19200 76800 307200 1228800 7372800 Here is an example of changing the console to unit #1 (the second serial port) and switching the port to 9600 baud: Boot [H=Help]: i 1 9600 Change speed now. Press a key to resume. Console on Unit #1 At this point, the Boot Loader prompt will be displayed on character unit #1. Note that not all character devices support changing baud rates and some only support a limited subset of the baud rates listed. If you attempt to select an invalid baud rate for your system, you will get an error message.","title":"Changing Console and Console Speed"},{"location":"UserGuide/#hbios-diagnostic-verbosity","text":"The \u2018V\u2019 command of the Boot Loader allows you to view and optionally change the level of diagnostic messages that RomWBW will produce. The normal verbosity level is 4, which means to display only fatal errors. You can increase this level to see more warnings when function calls to RomWBW HBIOS detect problems. The use of diagnostic levels above 4 are really intended only for software developers. I do not recommend changing this under normal circumstances.","title":"HBIOS Diagnostic Verbosity"},{"location":"UserGuide/#console-takeover","text":"If your system has more than one character unit, then the Boot Loader will \u201cpoll\u201d all of the character devices for a request to make any of the alternate character devices the active console. This is called a console takeover request. This functionality must be enabled in the ROM build configuration, but currently it is for all standard ROMs. To request a console takeover, you just press the \\<space> character twice in a row at the port or terminal that you want to move the console to. The terminal or communication software must be configured for the default serial port speed and data bits for this to work. A takeover request is only possible while the active console is showing the Boot Loader prompt prior to typing any characters at the active console. In other words, once you start typing at the active console prompt, the takeover polling is suspended. If you have started typing characters, you can press \\<enter> at the active console to get a fresh Boot Loader prompt and reactivate the polling. If you have built a custom ROM that includes an automatic boot command with a timeout, then performing a console takeover will abort the timeout process and the automatic boot command will not be performed.","title":"Console Takeover"},{"location":"UserGuide/#front-panel","text":"RomWBW supports the concept of a simple front panel. The following image is a conceptual view of such a front panel. If your system has a front panel, it should look similar to the RomWBW Front Panel . RomWBW Front Panel The LEDs in the top row of the panel are used for multiple purposes. They are initially used to display the progress of the system boot. This may help in diagnosing a hardware or configuration issue in a system that does not progress far enough to display text output on the console. The meaning of the LEDs is: O------- System Boot has started OO------ Common RAM bank activated OOO----- HBIOS transitioned to RAM OOOO---- Basic initialization done OOOOO--- CPU detection complete OOOOOO-- System timer configured OOOOOOO- Pre-console device init done OOOOOOOO Console activation Once the system has booted, the LEDs are used to indicate disk device activity. Each LED numbered 7-0 represents disk units 7-0. As each disk device performs I/O, the LED will light while the disk is active. This is only possible for the first 8 disk units. The second row of the front panel is composed of switches that allow you to control a few aspects of the system startup. The switches are also re-read during warm boot, so confirm the switch settings are your desired boot configuration before executing \u2018REBOOT /W\u2019. The first two switches affect the device used as the initial console. CRT/Serial Sec/Pri Explanation CRT Pri Primary Cathode Ray Tube device (high speed console) CRT Sec Secondary Cathode Ray Tube device (high speed console) Serial Pri Boot Console is Primary Serial Port Serial Sec Boot Console is Secondary Serial Port If not available (default): \u201cChar Unit 0\u201d is used The final six switches allow you to select the desired boot device. Auto / Menu Disk / ROM Floppy / Hard ROM/App/Boot Slice 4 2 1 Explanation Menu \u2013 \u2013 \u2013 \u2013 \u2013 Boot to RomWBW Menu Auto Disk Floppy # # # Boot Selected Floppy Disk Index Auto Disk Hard # # # Boot Selected Hard Disk Index Auto ROM \u2013 # # # Boot selected ROM Index If not available: Boot Loader Command Prompt \u2018\u2013\u2019 Ignored \u2018#\u2019 bit flag to select any three bits 4,2,1 ROM or Hard Disk - First 8 Drive Images 4 2 1 Floppy / Hard Drive Index ROM Index 0 0 0 Zero Monitor 0 0 1 One BASIC 0 2 0 Two Forth 0 2 1 Three Game 4 0 0 Four CP/M 4 0 1 Five Z-System 4 2 0 Six Net Boot 4 2 1 Seven User","title":"Front Panel"},{"location":"UserGuide/#disk-management","text":"The systems supported by RomWBW all have the ability to use persistent disk media. Some systems have disk interfaces built-in, while others will require add-in cards. You will need to refer to the documentation for your system for your specific options. The RomWBW firmware provides a hardware abstraction layer, All disks will work on all hardware variations. This means you can remove disk media from one RomWBW system and put it in a different RomWBW system. The only constraint is that the applications on the disk media must be up to date with the firmware on the system being used.","title":"Disk Management"},{"location":"UserGuide/#key-terminologyconcepts","text":"The following important terminology applies","title":"Key Terminology/Concepts"},{"location":"UserGuide/#disk-or-disk-drive","text":"The hardware storage device that RomWBW talks to. RomWBW supports a variety of storage disk device types. ROM Disk - RomWBW firmware - containing CPM utilities RAM Disk - A section of system RAM initially empty Floppy Disk(s) - Removable media Hard Disk(s) - Includes CF Cards, SD Cards, USB Stick, etc. The different disk types are further defined in the section Disk Types .","title":"Disk (or Disk Drive)"},{"location":"UserGuide/#media","text":"The storage device inserted into a disk drive, e.g. a floppy disk, CF Card, SD Card, etc.","title":"Media"},{"location":"UserGuide/#slice","text":"For hard disks a Slice is a smaller logical block of disk space that is allocated and formatted with a filesystem and typically allocated to a Drive letter. Slices allow large modern storage media to be sliced up into smaller units compatible with CP/M. Slices should not be confused with partitions, a slice is not a partition. The concept of slices is described in detail in the section Hard Disk Slices .","title":"Slice"},{"location":"UserGuide/#drive","text":"The mapping of a hardware disk (and slice) to a Drive letter in an operating system. A Drive has a file system installed on it","title":"Drive"},{"location":"UserGuide/#disk-image","text":"A disk image is a predefined image of a complete CP/M filesystem, or filesystem(s), including any partition tables (for hard disk images). Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. This comes in for form of a file which is suitable for copying directly onto target media, using a modern computer. It is generally easier to use these disk images than transferring files over individually. See the section Disk Images for further details.","title":"Disk Image"},{"location":"UserGuide/#startup-hardware-discovery","text":"During startup RomWBW performs detection for hardware supported by your platform. During startup you will see messages for any disk interface(s), listing device types (e.g. FD:, IDE:, SD:), and any media that has been found on these interfaces. The messages you see will vary depending on your hardware and the media you have installed. As an example, here are the messages you might see if you have an IDE interface in your system with a single disk drive connected to the primary side of the interface: IDE: IO=0x80 MODE=MK4 IDE0: 8-BIT LBA BLOCKS=0x00773800 SIZE=3815MB IDE1: NO MEDIA See RomWBW Hardware for a complete list of the different device types supported. If you do not see drive letters assigned as expected, refer to the prior system boot messages to ensure media has been detected in the interface. Each drive letter refers back to a specific disk hardware interface like IDE0. This is important as it is telling you what each drive letter refers to. Mass storage disks (like IDE) will normally have multiple drive letters assigned. The extra drive letters refer to additional \u201cslices\u201d on the disk. Once your system has working disk devices, they will be accessible from any operating system you choose to run. Disk storage is available whether you boot your OS from ROM or from the disk media itself.","title":"Startup Hardware Discovery"},{"location":"UserGuide/#drive-letter-assignment","text":"In legacy CP/M operating systems only 16 drive letters (A:-P:) available to be assigned to disks Drive letters were generally mapped to disk drives in a completely fixed way. For example, drive A: would always refer to the first floppy disk drive. RomWBW implements a much more flexible drive letter assignment mechanism so that any drive letter can dynamically be assigned to any disk device, or slice of media. For clarification, CP/M cannot refer directly to disk devices, CP/M only understands drive letters, so to access a given disk device it must first be assigned to a drive letter. As the operating system starts up, you should see a list of drive letters assigned to the disk media you have installed. Here is an example of the list of drive letter assignments made during the startup of Z-System: Configuring Drives... A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 Above you can see that: Drive A: has been assigned to MD0 which is the RAM disk device. Drive B: has been assigned to MD1 which is the ROM disk device. Drives C: and D: have been assigned to floppy disk drives. Drives E: thru H: have been assigned to the IDE0 hard disk device. The 4 entries for IDE0 are referring to the first 4 slices on that disk. CP/M 3 and ZPM3 do not automatically display the assignments at startup, but you can use ASSIGN to display them. The assignments at boot will stay the same on each boot as long as you do not make changes to your hardware configuration. i.e. If you insert or remove an SD Card, CF Card or USB Stick, the drive assignments will change at next boot. Since drive letter assignments can change, you must be careful when doing destructive things like using CLRDIR to make sure the drive letter you use is referring to the desired media. Drive assignments can be changed at any time, by the ASSIGN command. Please see the section Assign Drive Letters for further details.","title":"Drive Letter Assignment"},{"location":"UserGuide/#default-drive-letters","text":"When an operating system is booted, RomWBW will automatically assign drive letters to disk devices. The assignment process varies depending on: the disk/slice you choose to boot from, and the number, type, and sizes of mass storage devices available at boot The A: drive letter is considered special by most CP/M operating systems and is automatically used in some cases. e.g. submitting batch files, and is expected to be a writable volume. If you boot to a physical disk device, then the first drive letter (A:) will be assigned to the disk/slice that you are booting from, and the rest of the drive letters will be offset to accommodate this. By making the selected disk/slice the A: drive, you can setup different disks/slices for specific uses and just boot it, and the booted operating system will be the A: drive However when performing a ROM boot of an operating system, the first two drive letters will be assigned to your RAM disk (A:) and your ROM disk (B:). This provides the maximum compatibility with CP/M. After the first drive letter is assigned (as well as the second drive letter in the case of a ROM boot), RomWBW will assign additional drive letters based on the disk drives in the system. Additional drive letters will be assigned in the following order: RAM Disk ROM Disk Floppy Disk(s) Hard Disk(s) If a disk/slice was already assigned as the A: (or B:) drive letter, then it will not be assigned again. Floppy or removable disk drives will be assigned a drive letter regardless of whether there is any media inserted at the time of boot. In the case of hard disks, 1-8 drive letters will be assigned to the initial 1-8 slices of the disk drive. The number of drive letters assigned to each hard disk depends on the number of hard disks in the system: 1 Hard Disk: 8 drive letters (slices) 2 Hard Disks: 4 drive letters (slices) per disk 3+ Hard Disks: 2 drive letters (slices) per disk This somewhat complicated algorithm is used to try and maximize the limited number of operating system drive letters available (16) to the available disk devices as evenly as possible. For hard disk devices which are treated as non-removable media, drive letters will only be assigned to disk devices that actually contain media. i.e. No drive letters will be assigned to an SD Card slot that has no SD Card inserted.","title":"Default Drive Letters"},{"location":"UserGuide/#assign-drive-letters","text":"The ASSIGN command is used to view or change the current drive letter mappings. Any changes made to drive letter mappings take immediate effect Refer to RomWBW Applications for more information on use of the ASSIGN command. Since drive letter assignments are easily changed at any time using the ASSIGN command, you can customize your assignments as desired after starting the operating system. Even better, you can use an auto-submit batch file to customzie the assignments at startup without any user intervention.","title":"Assign Drive Letters"},{"location":"UserGuide/#disk-operationscommands","text":"With some understanding of how RomWBW presents disk space to the operating systems, we need to go over the options for actually setting up your disk(s) with content.","title":"Disk Operations/Commands"},{"location":"UserGuide/#preparing-media-for-first-use","text":"You can initialize the media in-place using your RomWBW system. Essentially, this means you are creating a set of blank directories on your disk so that files can be saved there. This is somewhat analogous to partitioning of a hard disk or doing a low level format of a floppy disk. Initilizing a Floppy disk is covered in the section Floppy Disk Formatting , or for a Hard disk the section Hard Disk Preparation covers the steps to manually setup a hard disk for first use.","title":"Preparing Media for First Use"},{"location":"UserGuide/#clearing-formatting-drives","text":"This is somewhat analogous to doing a FORMAT operation on other systems. With RomWBW you use the CLRDIR command to do this. This command is merely \u201cclearing out\u201d the directory space of the drive referred to by a drive letter and setting up the new empty directory. Refer to RomWBW Applications for more information on use of the CLRDIR command. Since CLRDIR works on drive letters, make absolutely sure you know what media and slice are assigned to that drive letter before using CLRDIR because CLRDIR will wipe out any pre-existing contents of the slice. After CLRDIR completes, the slice should be ready to use by the operating system via the drive letter assigned. Start by using the DIR command on the drive. This should return without error, but list no files. Here is an example of using CLRDIR . In this example, the ASSIGN command is used to show the current drive letter assignments. Then the CLRDIR command is used to initialize the directory of drive \u2018G\u2019 which is slice 2 of hard disk device IDE0 (\u201cIDE0:2\u201d). B>ASSIGN A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 B>CLDIR G: CLRDIR Version 1.2B May 2024 by Max Scane Warning - this utility will overwrite the directory sectors of Drive: G Type CAPITAL Y to proceed, any key other key to exit. Y Directory cleared. B>","title":"Clearing (Formatting) Drives"},{"location":"UserGuide/#checking-disk-layout","text":"If you are not sure which disk layout is used for your existing media, you can use the CP/M 2.2 STAT command to display information including the number of \u201c32 Byte Directory Entries\u201d for a drive letter on the corresponding hard disk. If it indicates 512, your disk layout is legacy (hd512). If it indicates 1024, your disk layout is modern (hd1k). Here is an example of checking the disk layout. B>STAT E:DSK: E: Drive Characteristics 65408: 128 Byte Record Capacity 8176: Kilobyte Drive Capacity 1024: 32 Byte Directory Entries 0: Checked Directory Entries 256: Records/ Extent 32: Records/ Block 64: Sectors/ Track 2: Reserved Tracks It is critical that you include DSK: after the drive letter in the STAT command line. The important line to look at is labeled \u201c32 Byte Directory Entries\u201d.","title":"Checking Disk Layout"},{"location":"UserGuide/#disk-types","text":"","title":"Disk Types"},{"location":"UserGuide/#ram-rom-disks","text":"A typical RomWBW system has 512KB of ROM and 512KB of RAM. Some portions of each are dedicated to loading and running applications and operating system. The space left over is available for an operating system to use as a pseudo-disk device (ROM Disk and RAM Disk). Unlike other types of disk devices, ROM and RAM Disks do not contain an actual operating system and are not \u201cbootable\u201d. However, they are accessible to any operating system (whether the operating system is loaded from ROM or a different disk device). Neither RAM nor ROM disks require explicit formatting or initialization. ROM disks are pre-formatted and RAM disks are formatted automatically with an empty directory when first used.","title":"RAM &amp; ROM Disks"},{"location":"UserGuide/#ram-disk","text":"The RAM disk provides a small CP/M filesystem that you can use for the temporary storage of files. Unless your system has a battery backed mechanism for persisting your RAM contents, the RAM disk contents will be lost at each power-off. The RAM disk is an excellent choice for storing temporary files because it is very fast. You will notice that the first time an operating system is started after the power was turned off, you will see a message indicating that the RAM disk is being formatted. If you reset your system without turning off power, the RAM disk will not be reformatted and it\u2019s contents will still be intact.","title":"RAM Disk"},{"location":"UserGuide/#rom-disk","text":"Like the RAM disk, the ROM disk also provides a small CP/M filesystem, but it\u2019s contents are static \u2013 they are part of the ROM. As such, you cannot save files to the ROM disk. Any attempt to do this will result in a disk I/O error. The contents of the ROM disk have been chosen to provide a core set of tools and applications that are helpful for either CP/M 2.2 or ZSDOS. Since ZSDOS is CP/M 2.2 compatible, this works fairly well. However, you will find some files on the ROM disk that will work with ZSDOS, but will not work on CP/M 2.2. For example, LDDS , which loads the ZSDOS date/time stamper will only run under ZSDOS.","title":"ROM Disk"},{"location":"UserGuide/#flash-rom-disks","text":"The limitation of ROM disks being read-only can be overcome on some platforms with the appropriate selection of Flash ROM chip and system configuration. In this case the flash-file system can be enabled which will allow the ROM disk to be read and written to. Flash devices have a limited write lifespan and continual usage will eventually wear out the device. It is not suited for high usage applications. Enabling ROM disk writing requires building a custom ROM.","title":"Flash ROM Disks"},{"location":"UserGuide/#floppy-disks","text":"If your system has the appropriate hardware, RomWBW will support the use of floppy disks. The supported floppy disk formats are generally derived from the IBM PC floppy disk formats: 5.25\u201d 360K Double-sided, Double-density 5.25\u201d 1.2M Double-sided, High-density 3.5\u201d 720K Double-sided, Double-density 3.5\u201d 1.44M Double-sided, High-density When supported, RomWBW is normally configured for 2 3.5\u201d floppy disk drives. If a high-density disk drive is used, then RomWBW automatically detects and adapts to double-density or high-density media. It cannot automatically detect 3.5\u201d vs. 5.25\u201d disk drive types \u2013 the ROM must be pre-configured for the disk drive type. WARNING: Some of the operating systems provided with RomWBW require that a soft-reset be performed when swapping floppy disk media. For example, under CP/M 2.2, you must press control-C at the CP/M prompt after inserting a new floppy disk. The consequences of failing to perform the soft-reset vary from unexpected error messages to full disk directory corruption.","title":"Floppy Disks"},{"location":"UserGuide/#hard-disks","text":"The concept of a hard disk in RomWBW applies to any storage device that provides at least 8MB of space. The actual media can be a real spinning hard disk, a CompactFlash Card, a SD Card, etc. In this document, the term hard disk will apply equally to all of these. The vintage operating systems included with RomWBW were produced at a time when mass storage devices were quite small. CP/M 2.2 could only handle filesystems up to 8MB. Since storage devices today are quite large, RomWBW implements a mechanism called slicing (see Hard Disk Slices ) to allow up to 256 8MB CP/M filesystems on a single large storage device, where each slice can be assigned to a drive letter in CPM, and be treated as its own hard disk drive (from a CPM perspective). In order to achieve compatibility across all of the operating systems supported by RomWBW, the hard disk filesystem format used is 8MB. This ensures any filesystem will be accessible to any of the operating systems. RomWBW uses Logical Block Addressing (LBA) to interact with all hard disks. The RomWBW operating systems use older Cylinder/Head/Sector (CHS) addressing. To accommodate the operating systems, RomWBW emulates CHS addressing. Specifically, it makes all hard disks look like they have 16 sectors and 16 heads. The number of tracks varies with the size of the physical hard disk.","title":"Hard Disks"},{"location":"UserGuide/#hard-disk-layouts","text":"When RomWBW uses a hard disk, it utilizes an area of the physical hard disk drive space to store a sequential series of slices that contain the actual CP/M filesystems referred to by drive letters by the operating system. Two hard disk layout schemes exist: Modern (hd1k) Legacy (hd512) You cannot mix disk layouts on a single disk device, however It is perfectly fine for one system to have multiple hard disks with different layouts \u2013 each physical disk device is handled separately. If you are setting up a new disk, the modern (hd1k) layout is recommended for the following reasons: Larger number of directory entries per filesystem Simplifies creation of coresident FAT filesystem Reduces chances of data corruption Each slice occupies exactly 8MB (an exact power of 2) in size Both the legacy and modern disk layouts continue to be fully supported by RomWBW. There are no plans to deprecate the legacy layout.","title":"Hard Disk Layouts"},{"location":"UserGuide/#modern-layout","text":"RomWBW (Starting with v3.2) supports the use of disk partitioning, utilising a Master Boot Record (MBR) partition tables. The Wikipedia article on the Master Boot Record is excellent if you are not familiar with them. RomWBW uses the partition type id 0x2E . This partition type id does not equate to any existing well-known partition types \u2013 it was chosen because it is not generally used. RomWBW does not support extended partitions \u2013 only a single primary partition can be used. The existence of a partition table entry for RomWBW on a hard disk makes it behave in the modern mode. Removing the RomWBW partition entry from a modern hard disk layout will cause the existing data to be unavailable and/or corrupted The CP/M filesystem in the slices of the modern disk layout contain 1024 directory entries.","title":"Modern Layout"},{"location":"UserGuide/#legacy-layout","text":"Originally, RomWBW always used the very start of the hard disk media for the location of the slices. In this layout, slice 0 referred to the first chunk of ~8MB on the disk, slice 1 referred to the second chunk of ~8MB on the disk, and so on. The number of slices is limited to the size of the disk media \u2013 if you attempted to read/write to a slice that would exceed the disk size, you would see I/O errors. The legacy format takes steps to allow a partition table to still be used for other types of filesystems such as DOS/FAT. It just does not use a partition table entry to determine the start of the RomWBW slices. The lack of a RomWBW partition table entry will cause legacy behaviour. Adding a partition table entry on an existing legacy RomWBW hard disk will cause the existing data to be unavailable and/or corrupted. The CP/M filesystem in the slices of the legacy disk layout contain 512 directory entries.","title":"Legacy Layout"},{"location":"UserGuide/#hard-disk-slices","text":"RomWBW implements a mechanism called slicing to allow multiple CP/M filesystem on a single large storage device. To say it another way, the media is \u201csliced up\u201d into many CP/M filesystems. You cannot use slices on any media less than 8MB in size. Specifically, you cannot slice RAM disks, ROM disks, floppy disks, etc. All of these are considered to have a single slice (0) It is very important to understand that RomWBW slices are not individually created or allocated on your hard disk. RomWBW uses a single partition on your hard disk to contain the slices. You should think of slices as just an index into a sequential set of 8MB areas that exist in this partition. RomWBW allows up to up to 256 slices each of 8MB in size on a single large storage device. This allows the use of up to 2GB of usable space on one media device. It is possible to create other partitions (typically FAT), for now, we are just talking about the slices within the single RomWBW partition.","title":"Hard Disk Slices"},{"location":"UserGuide/#slice-assignment","text":"When assigning Hard disks to drive letters you also need to assign the slice. Referring to slices within a storage device is done by appending a :<n> where \\<n> is the device relative slice number from 0-255. For example, if you have an IDE device, it will show up as IDE0: in the boot messages meaning the first IDE device. To refer to the fourth slice of IDE0, you would type \u201cIDE0:3\u201d. Here are some examples: IDE0:0 First slice of disk in IDE0 IDE0: First slice of disk in IDE0 IDE0:3 Fourth slice of disk in IDE0 So, if you wanted to use drive letter L: to refer to the fourth slice of IDE0, you could use the command ASSIGN L:=IDE0:3 . There are a couple of rules to be aware of when assigning drive letters. First, you may only refer to a specific device/slice with one drive letter at a time. Said another way, you cannot have multiple drive letters referring to a the same device/slice at the same time. Second, there must always be a drive assigned to A:. Any attempt to violate these rules will be blocked by the ASSIGN command. As you see, the name of a slice does not reference the hard disk partition containing the slices. Since there can only be a single RomWBW partition containing slices on any disk, the partition is determined automatically. RomWBW does not prevent you from assigning slices to drive letters even if the location of the slice does not fit on the physical disk. Any attempt to access a drive letter mapped to a slice that does not fit will result in an error such as \u201cno disk\u201d from the operating system. For example, a 64MB CF Card (which is typically a bit smaller than 64MB) will only fit 7 slices. At startup, you will typically see 8 drive letters assigned to the CF Card. Attempting to access the last drive letter will result in a \u201cno disk\u201d error from the operating system.","title":"Slice Assignment"},{"location":"UserGuide/#hard-disk-capacity","text":"The exact number of CP/M filesystem slices that will fit on your specific physical hard disk can be determined as follows: For modern (hd1k) disk layouts, it is 1024KB + (slices * 8192KB). Or equivalent to say 1MB + (slices * 8MB). For legacy (hd512) disk layouts, it is slices * 8,320KB. WARNING : In this document KB means 1024 bytes and MB means 1048576 bytes (frequently expressed as KiB and MiB in modern terminology). In general, hard disk capacities use KB to mean 1000 bytes and MB to mean 1,000,000 bytes. As an example, A \u201c64MB\u201d CF Card probably has less than 62.5MB of actual space (using the RomWBW definition that 1MB is 1048576 bytes). Such a drive will not support 8 slices. It will support 7 slices just fine because 1024KB + (7 * 8192MB) = 57MB (hd1k) or 7 * 8,320KB = 58.24MB (hd512) Although you can use up to 256 slices per physical disk, equating to 2GB of storage this large number of slices is rarely used. It is recommended that hard disk media used with RomWBW be 1GB or greater in capacity. This will support the RomWBW Combo Disk Image (see Combo Hard Disk Image ) that allows you to use 64 CP/M filesystem slices and a 384KB FAT filesystem.","title":"Hard Disk Capacity"},{"location":"UserGuide/#disk-preparation","text":"There are two approaches to preparing disks for use by RomWBW. Manual : Use RomWBW itself to format empty disks and then transfer files over to the disks. Images : Use a modern computer to write a pre-built disk image including files to a disk. This section of the document describes the manual process of preparing empty disks that are ready for use by an operating system. Alternatively, you can use the pre-built RomWBW disk images to quickly create disk media that already has a large selection of files and bootable operating system slices. Using images to prepare a disk is documented in Disk Images . You do not need to follow the instructions in this section if you want to use disk images.","title":"Disk Preparation"},{"location":"UserGuide/#floppy-disk-formatting","text":"Floppy media must be physically formatted before it can be used. This is normally accomplished by using the supplied Floppy Disk Utility FDU application. This application interacts directly with your hardware and therefore you must specify your floppy interface hardware at application startup. Additionally, you need to specify the floppy disk drive and media format to use for formatting. Refer to RomWBW Applications for more information on use of the FDU command. Since the physical format of floppy media is the same as that used in a standard MS-DOS/Windows computer, you can also format floppy disk media in a standard computer. However there are caveats: The directory format itself will NOT be compatible with CP/M OSes. You WILL need to use the CLRDIR command to reformat the directory area from CP/M. See section Clearing (Formatting) Drives FDU allows you to specify physical sector interleaving (defaults to 2) which will result in faster floppy disk I/O. Formatting on a modern computer may not optimize this. Below is a sample session using FDU to format a 1.44M floppy disk in the first (primary) floppy disk drive: B>FDU Floppy Disk Utility (FDU) v5.8, 26-Jul-2021 [HBIOS] Copyright (C) 2021, Wayne Warthen, GNU GPL v3 SELECT FLOPPY DISK CONTROLLER: (A) Disk IO ECB Board (B) Disk IO 3 ECB Board (C) Zeta SBC Onboard FDC (D) Zeta 2 SBC Onboard FDC (E) Dual IDE ECB Board (F) N8 Onboard FDC (G) RCBus SMC (SMB) (H) RCBus WDC (SMB) (I) SmallZ80 Expansion (J) Dyno-Card FDC, D1030 (K) RCBus EPFDC (L) Multi-Board Computer FDC (X) Exit === OPTION ===> D-IDE ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=720KB DS/DD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> SETUP ENTER UNIT [00-03] (00): 00: 3.5\" 720KB - 9 SECTORS, 2 SIDES, 80 TRACKS, DOUBLE DENSITY 01: 3.5\" 1.44MB - 18 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 02: 5.25\" 320KB - 8 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 03: 5.25\" 360KB - 9 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 04: 5.25\" 1.2MB - 15 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 05: 8\" 1.11MB - 15 SECTORS, 2 SIDES, 77 TRACKS, DOUBLE DENSITY 06: 5.25\" 160KB - 8 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 07: 5.25\" 180KB - 9 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 08: 5.25\" 320KB - 8 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY 09: 5.25\" 360KB - 9 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY ENTER MEDIA [00-09] (00): 01 00: POLLING (RECOMMENDED) 01: INTERRUPT (!!! READ MANUAL !!!) 02: FAST INTERRUPT (!!! READ MANUAL !!!) 03: INT/WAIT (!!! READ MANUAL !!!) 04: DRQ/WAIT (!!! NOT YET IMPLEMENTED!!!) ENTER MODE [00-04] (00): ENTER TRACE LEVEL [00-01] (00): ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> FORMAT (T)RACK, (D)ISK ===> DISK ENTER INTERLEAVE [01-12] (02): RESET DRIVE... PROGRESS: TRACK=4F HEAD=01 SECTOR=01 ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> EXIT You can confirm a floppy disk is ready for content by simply running a DIR command on it. The DIR command should complete without error and should list no files.","title":"Floppy Disk Formatting"},{"location":"UserGuide/#hard-disk-preparation","text":"This section deals with initializing hard disk media entirely from your RomWBW system. The following instructions are one way to proceed. This does not mean to imply it is the only possible way. First you need to understand The disk layout approach (either hd1k or the legacy hd512). See Hard Disk Layouts section if you are not sure. hd1k should be the preferred layout. The number of 8MB slices that you want to allocate, preferred is 64 slices. At least 1 slice of 8MB is required If you want to leave space for a FAT partition. See FAT Filesystem Preparation The total capacity of your drive, to hold the CP/M (and other) partition(s) Then you will need to start by inserting the disk media, booting RomWBW, and confirming that the media is being recognized. If RomWBW recognizes the media, it will indicate this in the boot messages even though the media may not yet been prepared for use. Then launch either CP/M 2.2 or Z-System from ROM using the Boot Loader C or Z commands respectively. You can now use the tools on the ROM disk to prepare your disks. Note that you may see the operating system assign disks/slices to drives letters even though the disks/slices are not yet initialized. This is normal and does not mean the disks/slices are ready to use.","title":"Hard Disk Preparation"},{"location":"UserGuide/#partition-setup","text":"To setup a partition you must run the FDISK80 utility. After FDISK80 starts, enter the disk unit number of the new media. The disk unit number was assigned at boot See Device Unit Assignments Refer to RomWBW Applications for more information on use of the FDISK80 utility. If you want to use the legacy hd512 layout skip down to the Legacy (hd512) section","title":"Partition Setup"},{"location":"UserGuide/#modern-hd1k","text":"At this point, use the I command to initialize (reset) the partition table to an empty state. You must create a partition for the RomWBW CP/M slices. Then create a partition using the N command. Importantly: The partition number should typically be 1 the first partition The partition can be placed anywhere you want, The typical location for the RomWBW partition is at 1MB. The partition size should be the total size of all the slices you require, and must be at least 8MB in size, in increments of 8MB makes sense. You must then set the type of partition to 2E using the T command. The P command can be used to display the partition before it is written Finally the partition can be written to disk using the W write command. WARNING : Modifying the partition table of existing media will make any data on the media inaccessible. Below is an example of creating a RomWBW partition following these guidelines. FDISK80 for RomWBW, UNA, Mini-M68k, KISS-68030, SBC-188 ---- Version 1.1-22 created 7-May-2020 (Running under RomWBW HBIOS) HBIOS unit number [0..11]: 4 Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 00 *** empty *** 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>i >>n New partition number: 1 Starting Cylinder (default 0): 1Mb Ending Cylinder (or Size= \"+nnn\"): +512Mb >>t Change type of partition number: 1 New type (in hex), \"L\" lists types: 2e >>p Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>w Do you really want to write to disk? [N/y]: y Okay FDISK exit. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again.","title":"Modern (hd1k)"},{"location":"UserGuide/#legacy-hd512","text":"At this point, use the I command to initialize (reset) the partition table to an empty state. To use the hd512 layout, use W to write the empty table to the disk and exit. Remember that the lack of a partition for RomWBW implies the legacy (hd512) layout. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again.","title":"Legacy (hd512)"},{"location":"UserGuide/#fat-partition","text":"At this point you may want to consider creating a FAT partition Please see the section FAT Filesystem Preparation for detils on how to setup the FAT partition.","title":"FAT Partition"},{"location":"UserGuide/#slice-initialization","text":"You need to initialize each slice for CP/M to use it. This is somewhat analogous to doing a FORMAT operation on other systems, and is done using the CLRDIR command. This is covered in the section Clearing (Formatting) Drives WARNING : Earlier versions of the CLRDIR application do not appear to check for disk errors when it runs. If you attempt to run CLRDIR on a drive that is mapped to a slice that does not actually fit on the physical disk, it may behave erratically. Assuming you want to use additional slices, you should initialize them using the same process. You may need to reassign drive letters to access some slices that are beyond the ones automatically assigned. You can use the ASSIGN command to handle this.","title":"Slice Initialization"},{"location":"UserGuide/#post-disk-preparation","text":"Once a disk (either floppy or hard disk) has been initialised and formattted you may optionally; * Make the disk bootable * Copy system (or other) files to the disk","title":"Post Disk Preparation"},{"location":"UserGuide/#making-a-disk-bootable","text":"To make a disk bootable you will need to follow the specific instructions in Operating Systems , as each operating system will be different. Generally you will need to use SYSCOPY to setup the system track(s) of the disk.As an example, If you wanted to setup C: as a bootable Z-System disk you would use: B>SYSCOPY C:=B:ZSYS.SYS SYSCOPY v2.0 for RomWBW CP/M, 17-Feb-2020 (CP/M 2 Mode) Copyright 2020, Wayne Warthen, GNU GPL v3 Transfer system image from B:ZSYS.SYS to C: (Y/N)? Y Reading image... Writing image... Done Once this process succeeds, you will be able to boot directly to the disk slice from the boot loader prompt. See the instructions in Starting Operating Systems from Disk for details on this.","title":"Making a Disk Bootable"},{"location":"UserGuide/#copying-system-files","text":"As well as making the disk bootable, you may need to transfer other system and application files to your disks. Refer to Transferring Files for more information on getting files onto your disks.","title":"Copying System Files"},{"location":"UserGuide/#disk-images","text":"Since it would be quite a bit of work to transfer over all the files you might want initially to your disk(s), It is generally easier to use these disk images than transferring your files over individually. RomWBW comes with a variety of ready to use disk images. You can use your modern Windows, Linux, or Mac computer to copy a disk image onto the disk media, then just move the media over to your RomWBW computer. The disk image files are found in the Binary directory of the distribution. Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. The following table shows the disk images available. Disk Image Description Boot xxx_aztec.img Aztec C Compiler No xxx_bascomp.img Microsoft Basic-80 Compiler No xxx_blank.img empty image No xxx_cowgol.img Cowgol 2.0 Compiler No xxx_cpm22.img DRI CP/M 2.2 Operating System Yes xxx_cpm3.img DRI CP/M 3 Operating System Yes xxx_dos65.img DOS/65 Operating System Yes xxx_fortran.img Microsoft Fortran-80 Compiler No xxx_games.img Games Disk for CP/M No xxx_hitechc.img HI-TECH Z80 CP/M C compiler No xxx_msxroms1.img MSX ROMs Disk 1 No xxx_msxroms2.img MSX ROMs Disk 2 No xxx_nzcom.img NZCOM ZCPR 3.4 Operating System Yes xxx_qpm.img QPM Operating System Yes xxx_tpascal.img Borland Turbo Pascal Compiler No xxx_ws4.img WordStar v4 & ZDE Applications No xxx_z80asm.img Relocating macro assembler for CP/M No xxx_zpm3.img ZPM3 Operating System Yes xxx_zsdos.img ZCPR-DJ & ZSDOS 1.1 Operating System Yes You will find 3 sets of these .img files in the distribution. The \u201cxxx\u201d portion of the filename will be: \u201cfd_\u201d for a floppy image. \u201chd1k_\u201d for a modern layout hard disk image. \u201chd512_\u201d for a legacy layout hard disk image. In the case of xxx_dos65.img, only an hd512 variant is provided. This is a constraint of the DOS65 distribution. There is also an image file called \u201cpsys.img\u201d which contains a bootable p-System hard disk image. It contains 6 p-System filesystem slices, but these are not interoperable with the CP/M slices described above. This file is discussed separately under UCSD p-System in Operating Systems section.","title":"Disk Images"},{"location":"UserGuide/#floppy-disk-images","text":"The floppy disk images are all intended to be used with 3.5\u201d high-density, double-sided 1.44 MB floppy disk media. This is ideal for the default floppy disk drive support included in RomWBW standard ROMs. For floppy disks, the .img file is written directly to the floppy media as is. The floppy .img files are 1.44 MB which is the exact size of a single 3.5\u201d high density floppy disk. You will need a floppy disk drive of the same type connected to your modern computer to write this image. Although modern computers do not come equipped with a floppy disk drive, you can still find USB floppy drives that work well for this. The floppy disk must be physically formatted before writing the image onto it. You can do this with RomWBW using FDU as described in the Floppy Disk Formatting section of this document. While you can also format the floppy using your modern computer, using FDU is preferable. RomWBW includes a Windows application called RawWriteWin in the Tools directory of the distribution. This simple application will let you choose a file and write it to an attached floppy disk drive. For Linux/MacOS, I think you can use the dd command (but I have not actually tried this). It is probably obvious, but writing an image to a floppy disk will overwrite and destroy all previous contents. Once the image has been written to the floppy disk, you can insert the floppy disk in your RomWBW floppy disk and read/write files on it according to the specific operating system instructions. If the image is bootable, then you will be able to boot from it by entering the floppy disk drive\u2019s corresponding unit number at the RomWBW Boot Loader command prompt.","title":"Floppy Disk Images"},{"location":"UserGuide/#hard-disk-images","text":"Keeping in mind that a RomWBW hard disk (including CF/SD/USB devices) allows you to have multiple slices (CP/M filesystems), there are a couple ways to image hard disk media. The easiest approach is to use the Combo Disk Image. This hard disk image is already prepared with 6 slices containing 5 ready-to-run OSes and a slice with the WordStar application files. Alternatively, you can create your own hard disk image with the specific slice contents you choose.","title":"Hard Disk Images"},{"location":"UserGuide/#standard-hard-disk-layout","text":"As previously described in Hard Disk Layouts , the exact placement of slices and optional FAT partition will vary depending on which disk layout (hd512 or hd1k) you are using and your partition table entries. To simplify the use of hard disk images, RomWBW has adopted a standard partition layout for disk image files provided. This standard layout is used to produce the Combo Disk Images described below. These partition sizes and locations were chosen to: Fit entirely on 1GB media Allow for 64 CP/M filesystem slices Allow for a 384KB FAT filesystem The standard partition table table entries are: \u2014 Modern (hd1k) \u2014 \u2014 Legacy (hd512) \u2014 Byte(s) Sector(s) Byte(s) Sector(s) RomWBW Partition Start 1 MB 2,048 \u2013 \u2013 RomWBW Partition Size 512 MB 1,048,576 \u2013 \u2013 FAT Filesystem Start 513 MB 1,050,624 520 MB 1,064,960 FAT Filesystem Size 384 MB 786,432 384 MB 786,432 \\<end> 897 MB 1,851,392 904 MB 1,837,056 NOTE: RomWBW is not limited to these partition table entries. You can change the size and location of the RomWBW and/or FAT partitions to increase/decrease the number of slices or FAT filesystem size. Doing so would require using FDISK80 to define your own custom disk layout and initializing your filesystems manually. The RomWBW System Guide has more information on the standard disk layouts as implemented in the Combo Disk Images. Additionally, there is a document called \u201cHard Disk Anatomy.pdf\u201d in the Doc directory of the RomWBW distribution with detailed information on the standard disk layouts.","title":"Standard Hard Disk Layout"},{"location":"UserGuide/#combo-hard-disk-image","text":"The Combo Disk Image is essentially just a single disk image that has several of the individual filesystem images (slices) already concatenated together using the standard disk layout described above. The Combo Disk Image includes the partition table of the standard disk layout and the following 6 slices in the positions indicated: Slice Description Slice 0 DRI CP/M 2.2 Operating System Slice 1 ZCPR-DJ & ZSDOS 1.1 Operating System Slice 2 NZCOM ZCPR 3.4 Operating System Slice 3 DRI CP/M 3 Operating System Slice 4 ZPM3 Operating System Slice 5 WordStar v4 & ZDE Applications Slice 6-63 blank unformatted There are actually 2 Combo Disk Images in the distribution. One for an hd512 disk layout (hd512_combo.img) and one for an hd1k disk layout (hd1k_combo.img). Simply use the image file that corresponds to your desired hard disk layout. Review the information in Hard Disk Layouts if you need more information of the disk layout options. Note : Apart from the hd512 and hd1k Combo Disk Images (mentioned above) there are actually a number of other hd1k_*_combo.img files. These additional combo files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct combo file The Combo Disk Image actually only contains the initial partition table, and the first 6 slices (Slice 0 to 5), this is approximately 49MB in size. While the partition table reserves space to store 64 CP/M filesystem slices as well as a single 384MB FAT filesystem, these areas remain empty, and must be initialized manually using CLRDIR for CP/M filesystems and FAT FORMAT for the FAT filesystem.","title":"Combo Hard Disk Image"},{"location":"UserGuide/#combo-disk-image-capacity","text":"The standard hard disk layout used by the Combo Disk Image was designed to fit well on a 1GB hard disk. The 64 CP/M slices (approximately 512MB) and 384MB FAT filesystem all fit well within a 1GB hard disk. This size choice was a bit arbitrary, but based on the idea that 1GB CF/SD/USB Media is easy and cheap to acquire. It is fine if your hard disk is smaller than 1GB. It just means that it will not be possible to use the pre-allocated FAT filesystem partition and any CP/M filesystem slices that don\u2019t fit. The true number of CP/M filesystem slices that will fit on your specific physical hard disk can be calculated as described in Hard Disk Capacity . If you attempt to access a slice past the end of the physical hard disk you will get \u201cno disk\u201d errors. You should calculate the maximum number of slices your hard disk will support and do not exceed this number.","title":"Combo Disk Image Capacity"},{"location":"UserGuide/#combo-disk-image-advice","text":"A great way to maintain your own data on a hard disk is to put your data in slices beyond the first 6. By doing so, you can always \u201cre-image\u201d your drive media with the Combo Disk Image without overlaying the data stored in the slices beyond the first 6. Just be very careful to use the same combo image layout (hd512 or hd1k) as you used originally.","title":"Combo Disk Image Advice"},{"location":"UserGuide/#custom-hard-disk-image","text":"For hard disks, each .img file represents a single slice (CP/M filesystem). Since a hard disk can contain many slices, you can just concatenate the slices (.img files) together to create your desired hard disk image. If you look in the Binary directory of the distribution, you will see that there are more disk (slice) images than the 6 that are included in the Combo Disk Images. These supplemental disk images are identified by looking for the files that start with hd1k_ or hd512_.","title":"Custom Hard Disk Image"},{"location":"UserGuide/#adding-slices-to-combo-image","text":"You can add slices to the Combo Disk Images simply by tacking slices onto the end. For example, if you want to add a slice containing the MSX ROMs to the end of the combo image, you could use one of the following command lines depending on your operating system: Windows: COPY /B hd1k_combo.img + hd1k_msxroms.img my_hd.img Linus/MaxOS: cat hd1k_combo.img hd1k_msxroms.img >my_hd.img Note that you must be sure to use either the hd1k_ or hd512_ prefixed files together. You cannot mix them.","title":"Adding Slices to Combo Image"},{"location":"UserGuide/#creating-a-new-custom-image","text":"If you want to create a completely custom hard disk image that is not based on the existing combo image, you can generate a disk image entirely from scratch using whatever slices you want in whatever order you like. For example, if you want to create a hard disk image that has slices for CP/M 2.2, CP/M 3, and WordStar in the hd512 format, you would use the command line of your modern computer to create the final image: Windows: COPY /B hd512_cpm22.img + hd512_cpm3.img + hd512_ws hd.img Linux/MacOS: cat hd512_cpm22.img hd512_cpm3.img hd512_ws >hd.img NOTE: For the hd1k disk layout, you must prepend the prefix file called hd1k_prefix.dat which contains the required partition table. So, for an hd1k layout you would use the following: Windows: COPY /B hd1k_prefix.dat + hd1k_cpm22.img + hd1k_cpm3.img + hd1k_ws hd.img Linux/MacOS: cat hd1k_prefix.dat hd1k_cpm22.img hd1k_cpm3.img hd1k_ws >hd.img Note : Apart from the hd1k_prefix.dat file (mentioned above) there are actaully a number of other hd1k_*_prefix.dat files. These additional prefix files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct prefix file In all of the examples above, the resulting file (hd.img) would now be written to your hard disk media and would be ready to use in a RomWBW system. If you wish to further customize or create new disk image definitions, please refer to the ReadMe.txt file in the Source/Images directory.","title":"Creating a new Custom Image"},{"location":"UserGuide/#writing-hard-disk-images","text":"Once you have chosen a Combo Hard Disk Image file or prepared your own custom hard disk image file, it will need to be written to the media using your modern computer. When using this method, the disk will be partitioned and setup with 1 or more slices containing ready-to-run bootable operating systems. To write a hard disk image file onto your actual media (actual hard disk or CF/SD/USB Media), you need to use an image writing utility on your modern computer. Your modern computer will need to have an appropriate interface or slot that accepts the media. To actually copy the image On Linux or MacOS , you can use the dd command. On Windows, in the \u201cTools\u201d directory of the distribution, there is an application called Win32DiskImager. In all cases, the image file should be written to the media starting at the very first block or sector of the media. This is the default behaviour on all software. To be entirely clear, writing a disk image file to your hard disk media will overwrite an pre-existing partition table and the number of slices that your image file contains. It will not overwrite or corrupt slices beyond those in the image file. As a result, you can use additional slices as a place to maintain your personal data because these slices will survive re-imaging of the media. If you setup a FAT partition on your media, it will also survive the imaging process.","title":"Writing Hard Disk Images"},{"location":"UserGuide/#media-usage-and-initialization","text":"Once you have copied the image onto the hard disk media, you can move the media over to your RomWBW system. You can then boot to the operating system slices by specifying ( \\<diskunit>.\\<slice> ) at the RomWBW Boot Loader command prompt. See the section Starting Operating Systems from Disk for further details You are not limited to the number of slices that are contained in the image that you write to your hard disk media. You can use additional slices as long your media has room for them. However, writing the disk image will not initialize the additional slices. You will need to use the CLRDIR application to initialize any un-initialized slice before its first use, and and optionally SYSCOPY if you want th slice to be bootable. If you use the combo image this applies to slices 6 thru 63. The procedure for this is documented in the Clearing (Formatting) Drives section. Likewise, the pre-allocated FAT partition must still be formatted using FAT FORMAT in order to actually use it (see FAT Filesystem Preparation ). Alternatively, the FAT partition can be formatted on a modern computer.","title":"Media Usage and Initialization"},{"location":"UserGuide/#re-imaging-existing-media","text":"In order for your additional slices and/or FAT partition to survive re-imaging, you must follow these rules: Do not modify the partition table of the media using FDISK80 or any other partition management tools. Ensure that your hard disk image file uses the same disk layout approach (hd512 or hd1k) as previously used on the media.","title":"Re-Imaging Existing Media"},{"location":"UserGuide/#writing-hard-disk-slices","text":"This section covers techniques to copy partial images onto pre-existing media, in effect performing a selective slice copy. These techniques currently only apply to hd1k formatted media, which has a partition table entry, and a convenient 1MB size metric. However adapting to hd512 is possible, but left to the user. You will need to have access to a Linux/MacOS machine, or have the Linux tools for Windows installed, including the dd command line tool. For Windows there are multiple options for installing dd including MSYS2 , CygWin , and dd for Windows . WARNING : The dd command is a low-level utility that writes directly to raw disk sectors with almost no safety checks. It is very easy to corrupt a disk if this tool is used incorrectly. The dd command supports options to define precisely source and destination offsets and sizes to copy. From the documentation of dd the following options are important. if=file Read input from file instead of the standard input. of=file Write output to file instead of the standard output. skip=n Skip n blocks from the beginning of the input before copying. seek=n Seek n blocks from the beginning of the output before copying. count=n Copy only n input blocks. bs=n Set both input and output block size to n bytes instead of the default 512 The best approach is to copy data to the RomWBW partition. To do this, you must first determine the name that your operating system is using for the RomWBW disk and partition. An easy way to determine this may be the linux mount command, which lists the currently mounted partitions. From here you can more easily determine the naming scheme used by your operating system. Typically disk devices are named something like /dev/disk9 or /dev/sdg , noting above the g is a alphabetic and it could be any letter. This naming is arbitrary and depend on the operating system, and the specific hardware connecting the device Partitions are typically named by simply adding a number after the name of the hard disk device. For example, the first partition could be /dev/disk9s1 , /dev/sdg1 , or /dev/sdgp1 . In the following examples we use the above dd options, noting the of= option is the RomWBW target partition. ** NOTE ** A second approach (Examples 3 and 4) is to address the hard disk as a raw disk device and we take explicit steps to calculate the start of the RomWBW partition. While this works, it is better to use the partition relative approach. The commands in the examples below are run from the Binary folder of RomWBW distribution.","title":"Writing Hard Disk Slices"},{"location":"UserGuide/#example-1-copy-the-games-image-to-an-empty-slice-of-our-media","text":"In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5). We are just copying the needed slice to the existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/sdg1 seek=6 bs=8M Password: 1+0 records in 1+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) Since bs=8MB the seek=6 skips the first 6 (8MB slices) slices (in the target image) and writes the games image to the 7th slice.","title":"Example 1 : Copy the Games image to an empty slice of our media"},{"location":"UserGuide/#example-2-copy-the-entire-combo-image-without-replacing-partition-table","text":"In all of the following examples we use bs=1MB to defines the block size used in other parameters. This is convenient since the combo image reserves 1MB for the partition table at the start of the disk. In this example we will copy the (hd1k) combo image (which includes a partition table) over our media without replacing the partition table. In this example we assume the media has already been formatted with the combo image, and we have modified the partition table, which we do not want to overwrite. Binary % sudo dd if=hd1k_combo.img of=/dev/sdg1 skip=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB (partition table) in the input file, effectively stripping out the combo images partition table, before overwriting the slices in the target partition.","title":"Example 2 : Copy the entire Combo Image without replacing partition table"},{"location":"UserGuide/#example-3-copy-the-combo-image-without-replacing-partition-table","text":"This example is identical to Example 2 except it writes to the target disk device itself ( of=/dev/disk9 ), not the target partition. Binary % sudo dd if=hd1k_combo.img of=/dev/disk9 skip=1 seek=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB in the input file, and likewise seek=1 skips the first 1MB of the target media file we are writing to, thus in effect we are skipping the first 1MB, which contains the partition table itself.","title":"Example 3 : Copy the Combo Image without replacing partition table"},{"location":"UserGuide/#example-4-copy-the-games-image-to-an-empty-slice-of-our-media","text":"In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5) We are just coping the needed slice to this existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/disk9 seek=49 bs=1M Password: 8+0 records in 8+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) The seek=49 skips the first 49MB of the media file we are writing to. 49 is calculated as (slice number * 8) + 1 , where 8 is the size of a slice and 1 is the size of the partition table im megabytes. Thus we are skipping 6 slices (in the combo image) and writing to the 7th slice.","title":"Example 4 : Copy the Games image to an empty slice of our media"},{"location":"UserGuide/#operating-systems","text":"One of the primary goals of RomWBW is to expose a set of generic hardware functions that make it easy to adapt operating systems to any hardware supported by RomWBW. As a result, there are now 8 operating systems that have been adapted to run under RomWBW. The adaptations are identical for all hardware supported by RomWBW because RomWBW hides all hardware specifics from the operating system. By design, the operating systems provided with RomWBW are original and unmodified from their original distribution. Patches published by the authors are generally included or applied. The various enhancements RomWBW provides (such as hard disk slices) are implemented entirely within the system adaptation component of each operating system (e.g., CP/M CBIOS). As a result, each operating system should function exactly as documented by the authors and retain maximum compatibility with original applications. Note that all of the operating systems included with RomWBW support the same basic filesystem format from DRI CP/M 2.2 (except for p-System). As a result, a formatted filesystem will be accessible to any operating system. The only possible issue is that if you turn on date/time stamping using the newer OSes, the older OSes will not understand this. The older OS will not corrupt the files, but the date/time stamps will not be maintained. The following sections briefly describe the operating system options currently available and brief operating notes.","title":"Operating Systems"},{"location":"UserGuide/#digital-research-cpm-22","text":"This is the most widely used variant of the Digital Research operating systems. It has the most basic feature set, but is essentially the compatibility metric for all other CP/M-like operating systems including those listed below. If you are new to the CP/M world, I would recommend using this CP/M variant to start with simply because it is the most stable and you are less likely to encounter compatibility issues.","title":"Digital Research CP/M 2.2"},{"location":"UserGuide/#documentation","text":"CPM Manual","title":"Documentation"},{"location":"UserGuide/#boot-disk","text":"To make a bootable CP/M disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cCPM.SYS\u201d. For example: SYSCOPY C:=B:CPM.SYS","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping","text":"Character device mapping under CP/M 2.2 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The CP/M Logical Devices are: Device Description CON: System console device, used by CCP for communication with the operator RDR: Paper tape reader device PUN: Paper tape punch device LST: Output list device The CP/M Physical Devices are: Device Description TTY: Teletype device (slow speed console) CRT: Cathode ray tube device (high speed console) BAT: Batch processing (input from RDR: , output to LST: ) UC1: User-defined console PTR: Paper tape reader (high speed reader) UR1: User-defined reader #1 UR2: User-defined reader #2 PTP: Paper tape punch (high speed punch) UP1: User-defined punch #1 UP2: User-defined punch #2 LPT: Line printer UL1: User-defined list device #1 CP/M Logical Devices are mapped to CP/M Physical Devices via the IOBYTE at 0x0003 as shown below. Logical Device LST: PUN: RDR: CON: IOBYTE Bits 7 6 5 4 3 2 1 0 0 (0b00) TTY: TTY: TTY: TTY: 1 (0b01) CRT: PTP: PTR: CRT: 2 (0b10) LPT: UP1: UR1: BAT: 3 (0b11) UL1: UP2: UR2: UC1: The mappings above can be managed using the STAT command. This command essentially just modifies the IOBYTE value. CP/M Physical Devices are mapped to RomWBW HBIOS devices during the boot process depending on the number of HBIOS Char devices in the system. All CP/M Physical Devices are initially mapped to HBIOS Char 0. If additional HBIOS Char devices are available in the system, they will be mapped as below: CP/M RomWBW HBIOS TTY: Char 0 CRT: CRT BAT: CP/M RDR/LST UC1: Char 1 PTR: Char 1 UR1: Char 2 UR2: Char 3 PTP: Char 1 UP1: Char 2 UP2: Char 3 LPT: Char 1 UL1: Char 2 Normally, the HBIOS Console device (Loader prompt) is on HBIOS Device Char 0. If it has been reassigned to a different HBIOS character device before launching CP/M, then the above mapping will be modified. TTY: will be assigned to the current HBIOS console Char device. The remaining assignments will be filled in with the other Char devices as available.","title":"Character Device Mapping"},{"location":"UserGuide/#notes","text":"You can change media, but it must be done while at the OS command prompt and you must warm start CP/M by pressing ctrl-C. This is a CP/M 2.2 constraint and is well documented in the DRI manual. SUBMIT.COM has been patched per DRI to always place submit files on A:. This ensures the submitted file will always be properly executed. The original versions of DDT, DDTZ, and ZSID used the RST 38 vector which conflicts with interrupt mode 1 use of this vector. The DDT, DDTZ, and ZSID applications in RomWBW have been modified to use RST 30 to avoid this issue. Z-System applications will not run under CP/M 2.2. For example, the LDDS date stamper will not work.","title":"Notes"},{"location":"UserGuide/#z-system","text":"Z-System is the most popular non-DRI CP/M workalike \u201cclone\u201d which is generally referred to as Z-System. Z-System is intended to be an enhanced version of CP/M and should run all CP/M 2.2 applications. It is optimized for the Z80 CPU (as opposed to 8080 for CP/M) and has some significant improvements such as date/time stamping of files. Z-System is a somewhat ambiguous term because there are multiple generations of this software. RomWBW Z-System is a combination of both ZCPR-DJ (the CCP) and ZSDOS 1.1 (the BDOS) when referring to Z-System. The latest version of Z-System (ZCPR 3.4) is also provided with RomWBW via the NZ-COM adaptation (see below).","title":"Z-System"},{"location":"UserGuide/#documentation_1","text":"ZCPR Manual ZCPR-DJ ZSDOS Manual","title":"Documentation"},{"location":"UserGuide/#boot-disk_1","text":"To make a bootable Z-System disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cZSYS.SYS\u201d. For example: SYSCOPY C:=B:ZSYS.SYS","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_1","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The CP/M 2.2 STAT command is used to manipulate the device mappings.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_1","text":"Although most CP/M 2.2 applications will run under Z-System, some may not work as expected. The best example is PIP which is not aware of the ZSDOS paths and will fail in some scenarios (use COPY instead). Although ZSDOS can recognize a media change in some cases, it will not always work. You should only change media at a command prompt and be sure to warm start the OS with a ctrl-C. ZSDOS has a concept of fast relog of drives. This means that after a warm start, it avoids the overhead of relogging all the disk drives. There are times when this causes issues. After using tools like CLRDIR or MAP, you may need to run \u201cRELOG\u201d to get the drive properly recognized by ZSDOS. ZSVSTAMP expects to be running under the ZCPR 3.X command processor. By default, RomWBW uses ZCPR 1.0 (intentionally, to reduce space usage) and ZSVSTAMP will just abort in this case. It will work fine if you implement NZCOM. ZSVSTAMP is included solely to facilitate usage if/when you install NZCOM. Many of the tools can be configured (using either ZCNFG or DSCONFIG). The configuration process modifies the actual application file itself. This will fail if you try to modify one that is on the ROM disk because it will not be able to update the image. DATSWEEP can be configured using DSCONFIG. However, DSCONFIG itself needs to be configured first for proper terminal emulation by using SETTERM. So, run SETTERM on DSCONFIG before using DSCONFIG to configure DATSWEEP! Generic CP/M PIP and ZSDOS path searching do not mix well if you use PIP to copy to or from a directory in the ZSDOS search path. Best to use COPY from the ZSDOS distribution.","title":"Notes"},{"location":"UserGuide/#nzcom-automatic-z-system","text":"NZCOM is a much further refined version of Z-System (ZCPR 3.4). NZCOM was sold as an enhancement for existing users of CP/M 2.2 or ZSDOS. For this reason, (by design) NZCOM does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into a host OS. On the RomWBW NZCOM disk images, the boot OS is ZSDOS 1.1. A PROFILE.SUB file is included which automatically launches NZCOM as soon as ZSDOS loads. NZCOM is a companion product to Z3PLUS, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. NZCOM is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation and use MKZCM as desired to customize your system. NZCOM has substantially more functionality than CP/M or basic Z-System. It is important to read the \u201cNZCOM Users Manual.pdf\u201d document in order to use this operating system effectively.","title":"NZCOM Automatic Z-System"},{"location":"UserGuide/#documentation_2","text":"NZCOM Users Manual Z-System Users Guide ZCPR3.3 User Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_2","text":"Since NZ-COM boots via Z-System, you can make a bootable NZ-COM disk using ZSYS.SYS as described in Z-System above. You will need to add a PROFILE.SUB file to auto-start NZ-COM itself.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_2","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . However, it is not possible to manipulate the CP/M Logical to Physical device mapping using the STAT command. The mapping is static. Note: A custom ZCPR IOP module could theoretically be used to manage the character device mappings. RomWBW does not provide this module and writing an IOP module is beyond the scope of this document.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_2","text":"All of the notes for Z-System above generally apply to NZCOM. There is no DIR command, you must use SDZ instead. If you don\u2019t like this, look into the ALIAS facility. For consistency with other ZCPR3 operating systems (ZPM3, Z3PLUS) the SHOW.COM and HELP.COM command files were renamed to ZSHOW.COM and ZHELP.COM","title":"Notes"},{"location":"UserGuide/#digital-research-cpm-3","text":"This is the Digital Research follow-up product to their very popular CP/M 2.2 operating system. While highly compatible with CP/M 2.2, it features many enhancements and is not 100% compatible. It makes direct use of banked memory to increase the user program space (TPA). It also has a new suite of support tools and help system.","title":"Digital Research CP/M 3"},{"location":"UserGuide/#documentation_3","text":"CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_3","text":"To create (or update) a CP/M 3 boot drive, you must place CPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS and CCP.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. CPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/CPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . CPMLDR.SYS CPM3.SYS or CPM3BNK.SYS CCP.COM The CPM3.SYS boot file is provided in 2 versions. In the Binary/CPM3 distribution directory, CPM3.SYS is the \u201cnon-banked\u201d version of CP/M 3. The CPM3BNK.SYS file is the \u201cbanked\u201d version of CP/M 3. You almost certainly want to transfer the banked CPM3BNK.SYS version. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place CPMLDR.SYS on the boot track of the target drive. CPM3.SYS and CCP.COM can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into CP/M 3 to create or update a CP/M 3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the CP/M 3 disk. Assuming the target CP/M 3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:CPMLDR.SYS COPY A:CPM3BNK.SYS F:CPM3.SYS COPY A:CCP.COM F: Note in the example above that CPM3BNK.SYS is renamed to CPM3.SYS in the copy command.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_3","text":"Character device mapping under CP/M 3 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The primary CP/M Logical Devices are: Device Description CON: Console input or output device AUX: Auxiliary Input or Output Device LST: List output device, usually the printer There are various aliases for these devices. Please refer to the CP/M 3 Users Guide for more information. The mapping of CP/M 3 Logical Devices to Physical Devices is performed using the DEVICE command. CP/M 3 refers to Physical Character Devices using the COM device label. These COM devices are mapped directly to the RomWBW HBIOS Char devices as described below: COM0: \u2013> HBIOS Char 0 COM1: \u2013> HBIOS Char 1 COM2: \u2013> HBIOS Char 2 . . . COMn: \u2013> HBIOS Char n","title":"Character Device Mapping"},{"location":"UserGuide/#notes_3","text":"The COPYSYS command described in the DRI CP/M 3 documentation is not provided with RomWBW. The RomWBW SYSCOPY command is used instead. Although CP/M 3 is generally able to run CP/M 2.2 programs, this is not universally true. This is especially true of the utility programs included with the operating system. For example, the SUBMIT program of CP/M 3 is completely different/incompatible from the SUBMIT program of CP/M 2.2. RomWBW fully supports CP/M 3 file date/time stamping, but this requires that the disk be properly initialized for it. This process has not been performed on the CP/M 3 disk image. Follow the CP/M 3 documentation to complete this process, if desired.","title":"Notes"},{"location":"UserGuide/#z3plus-z-system-for-cpm-plus","text":"Z3PLUS is a much further refined version of Z-System (ZCPR 3.4). Z3PLUS was sold as an enhancement for existing users of CP/M 3. For this reason, (by design) Z3PLUS does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into CP/M 3. A PROFILE.SUB file is included which automatically launches Z3PLUS as soon as CP/M 3 loads. Z3PLUS is a companion product to NZ-COM, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. Z3PLUS is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation to customize your system. Z3PLUS has substantially more functionality than CP/M 3 or the basic Z-System. It is important to read the \u201cZ3PLUS Users Manual.pdf\u201d document in order to use this operating system effectively.","title":"Z3PLUS Z-System for CP/M-Plus"},{"location":"UserGuide/#documentation_4","text":"Z3PLUS Users Manual Z-System Users Guide ZCPR3.3 User Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_4","text":"Since Z3PLUS boots via CP/M 3, you first must make the disk CP/M 3 bootable. This is not a simple process, as well as placing CPMLDR.SYS on the system track of the disk there are several files that are required on the disk itself.This is described in Digital Research CP/M 3 section above. You will need to add a PROFILE.SUB file to auto-start Z3PLUS itself.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_4","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_4","text":"All of the notes for Digital Research CP/M 3 above generally apply to Z3PLUS. Some applications in the Z3PLUS distribution have been upgraded with newer versions. This is done with in","title":"Notes"},{"location":"UserGuide/#zpm3","text":"Simeon Cran\u2019s ZPM3 is an interesting combination of the features of both CP/M 3 and ZCPR3. Essentially, it has the features of and compatibility with both. Due to this dual compatibility, the ZPM3 distribution image contains most of the standard CP/M 3 files as well as a variety of common ZCPR3 applications. However, you will notice that user area 0 of the disk has only a few files. Most of the files are distributed among other user areas which is standard practice for ZCPR3. Most importantly, you will see most of the applications in user area 15. The applications can be executed from any user area because ZPM3 has a default search path that includes User 15. The ZPM3 distribution comes with essentially no utility programs at all. In addition to the standard CP/M 3 utilities, RomWBW includes a variety of common ZCPR3 utilities.","title":"ZPM3"},{"location":"UserGuide/#documentation_5","text":"ZPM3 has no real documentation. You are expected to understand both CP/M 3 and ZCPR 3. The best source of information is: CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide Z-System Users Guide ZCPR3.3 User Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_5","text":"To create (or update) a ZPM3 boot drive, you must place ZPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS , ZCCP.COM , ZINSTAL.ZPM , and STARTZPM.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. ZPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/ZPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . ZPMLDR.SYS CPM3.SYS ZCCP.COM ZINSTAL.ZPM STARTZPM.COM You may be surprised to see the file called CPM3.SYS . This is not a typo. Although it is called CPM3.SYS , it is ZPM and not the same as CPM3.SYS in the CPM3 directory. Also, unlike CP/M 3, ZPM3 is always banked, so you will not find two versions of the file. CPM3.SYS is a banked implementation of ZPM3. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place ZPMLDR.SYS on the boot track of the target drive. The remaining boot files can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into ZPM3 to create or update a ZPM3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the ZPM disk. Assuming the target ZPM3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:ZPMLDR.SYS COPY A:CPM3.SYS F:CPM3.SYS COPY A:CCP.COM F: COPY A:ZINSTAL.ZPM F: COPY A:STARTZPM.COM F:","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_5","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_5","text":"The ZPM3 operating system is contained in the file called CPM3.SYS which is confusing, but this is as intended by the ZPM3 distribution. I believe it was done this way to make it easier for users to transition from CP/M 3 to ZPM3. The command line editing key bindings were slightly modified by Jon Saxton when he applied a few ZPM3 fixes. This is explained in the file zpm3fix.txt in the distribution folder Source/ZPM3. The current key bindings are from the \u201cNew\u201d column below. Old New Function ^A ^A one word left ^B ^B to beginning/end of line ^C ^C reboot if at start of line ^D ^D right one char ^E ^E get previous line ^F ^F right one word ^G ^G delete char at cursor ^H ^H destructive backspace ^I ^I (TAB) ignored here ^J ^J (LF) exit editor ^K ^K delete all to the right ^L ^L ignored ^M ^M (CR) exit editor ^N ^N ignored ^O ^O ignored ^P ^P toggle printer echoing ^Q ^Q toggle autoprompt (if enabled) ^R ^R ignored ^S ^S left one char ^T ^T delete word at cursor ^U ^U add line to history ^V ^V clear line, delete from history ^W ^X get next line from history ^X ^W delete all to the left ^Y ^Y clear line","title":"Notes"},{"location":"UserGuide/#qpm","text":"QP/M is another OS providing compatibility with and enhancements to CP/M 2.2. It is provided as a bootable disk image for RomWBW. Refer to the ReadMe.txt file in Source/Images/d_qpm for more details regarding the RomWBW adaptation and customizations.","title":"QP/M"},{"location":"UserGuide/#documentation_6","text":"QP/M 2.7 Installation Guide and Supplements QP/M 2.7 Interface Guide QP/M 2.7 Features and Facilities","title":"Documentation"},{"location":"UserGuide/#boot-disk_6","text":"To create or update a bootable QP/M Z-System disk, a special process is required. QP/M is not provided in source format. You are expected to install QP/M over an existing CP/M installation using the QINSTALL.COM application. To update an existing QP/M boot disk with the latest RomWBW CBIOS, you must use 2 steps: apply the generic CP/M system track, then reinstall the QP/M components. To do this, you can perform the following steps: Boot to the existing QP/M disk. At this point, drive A should be the QP/M disk that you wish to update. You may receive a warning about CBIOS/HBIOS version mismatch. Use RomWBW SYSCOPY to place the stock RomWBW CP/M OS image onto the system tracks of the QP/M boot disk: SYSCOPY A:=x:CPM.SYS where x is the drive letter of your ROM Disk. Run QINSTALL to overlay the QP/M OS components on your QP/M boot disk. WARNING : QINSTALL has no mechanism for retaining previous non-default settings. Any previous non-default settings you previously made with QINSTALL will need to be reapplied. The pre-built RomWBW QP/M disk image includes a couple of specific non-default settings to optimize use with RomWBW. Please review the notes in the ReadMe.txt file in Source/Images/d_qpm.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_6","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The mappings can be viewed or modified using the QP/M QSTAT command which is analogous to the CP/M 2.2 STAT command. Do not use the CP/M 2.2 STAT command under QP/M.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_6","text":"QPM is not available as source. This implementation was based on the QPM binary distribution and has been minimally customized for RomWBW. When booted, the QPM startup banner will indicate CP/M 2.2. This is because QPM uses the CP/M 2.2 CBIOS code. QINSTALL is used to customize QPM. It is included on the disk image. You should review the notes in the ReadMe.txt file in Source/Images/d_qpm before making changes. In addition to the QPM disk image, all of the QPM distribution files can be found in the RomWBW distribution in the Source/Images/d_qpm/u0 directory. The QPM disk image is not included as one of the slices on the RomWBW Combo Disk Image. If you want to include QPM, you can do so by following the directions in Source/Images/Readme.txt.","title":"Notes"},{"location":"UserGuide/#ucsd-p-system","text":"This is a full implementation of the UCSD p-System IV.0 for Z80 running under RomWBW. Unlike the OSes above, p-System uses its own unique filesystem and is not interoperable with other OSes. It was derived from the p-System Adaptable Z80 System. Unlike some other distributions, this implements a native p-System Z80 Extended BIOS, it does not rely on a CP/M BIOS layer. The p-System is provided on a hard disk image file called psys.img. This must be copied to its own dedicated hard disk media (CF Card, SD Card, etc.). It is booted by selecting slice 0 of the corresponding hard disk unit at the RomWBW Boot Loader prompt. Do not attempt to use CP/M slices on the same disk. Due to limitations in the p-System configuration mechanism, it does not recognize the arrow keys of an ANSI Terminal. To work around this, the following control keys have been defined: Function Key Up ctrl+E Down ctrl+X Left ctrl+S Right ctrl+D Refer to Source/pSys/ReadMe.txt for more details about the p-System adaptation.","title":"UCSD p-System"},{"location":"UserGuide/#documentation_7","text":"UCSD p-System Users Manual","title":"Documentation"},{"location":"UserGuide/#boot-disk_7","text":"There is no mechanism provided to create a p-System boot disk from scratch under RomWBW. This has already been done as part of the porting process. You must use the provided p-System hard disk image file which is bootable.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_7","text":"RomWBW Character Devices are automatically assigned to p-System devices at startup. The current HBIOS Console device is assigned to CONSOLE:. The next available HBIOS Char device is assigned to REMIN:/REMOUT:. The next available HBIOS Char devices is assigned to PRINTER:","title":"Character Device Mapping"},{"location":"UserGuide/#notes_7","text":"There is no floppy support at this time. The hard disk image contains 6 p-System slices which are assigned to p-System unit numbers 4, 5, 9, 10, 11, and 12 which is standard for p-System. Slices 0-5 are assigned sequentially to these p-System unit numbers and it is not possible to reassign them. Unit #4 (slice 0) is bootable and contains all of the p-System distribution files. Unit #5 (slice 1) is just a blank p-System filesystem. The other units (9-12) have not been initialized, but this can be done from Filer using the Zero command. p-System relies heavily on the use of a full screen terminal. This implementation has been setup to expect an ANSI or DEC VT-100 terminal or emulator. The screen output will be garbled if no such terminal or emulator is used for console output. There is no built-in mechanism to move files in and out of p-System. However, the .vol files in Source/pSys can be read and modified by CiderPress. CiderPress is able to add and remove individual files. Andrew Davidson has created a Python script that can extract p-System volumes from an existing disk image file. The script is also capable of inserting a modified volume back into the disk image file. This tool is available at https://github.com/robosnacks/psysimg .","title":"Notes"},{"location":"UserGuide/#freertos","text":"Phillip Stevens has ported FreeRTOS to run under RomWBW. FreeRTOS is not provided in the RomWBW distribution. FreeRTOS is available under the MIT licence and further general information is available at FreeRTOS . Phillip may be contacted via his GitHub Page .","title":"FreeRTOS"},{"location":"UserGuide/#fuzix","text":"Fuzix is a Unix-ish operating system for small systems. It is the work of Alan Cox and is hosted on GitHub at https://github.com/EtchedPixels/FUZIX . Fuzix itself is a stand-alone operating system, but it frequently utilizes RomWBW to boot and launch on RomWBW-supported platforms. For those Fuzix platforms that leverage RomWBW for startup, you will program your ROM with the normal RomWBW ROM \u2013 there is no Fuzix-specific ROM. A Fuzix disk image for your system is then written to your disk media. After booting your system via the normal RomWBW ROM, you start Fuzix simply by choosing the disk device containing the Fuzix image at the RomWBW Loader prompt. To create a Fuzix disk image: Locate and download the Fuzix disk image for your system from https://www.fuzix.org/ . For each platform, you will typically find two image files. An emulator image ( emu-xxx.img ) and a disk image ( disk.img ). You want the disk image file. Write the disk image file to your physical media (CF Card, SD Card, etc.) starting at the beginning of the media (first sector). Do not combine the Fuzix image with the RomWBW disk images \u2013 they are entirely separate. To boot into Fuzix: Insert your Fuzix disk media. Power-up or reset your system. RomWBW should load normally and bring you to the RomWBW Boot Loader prompt. Depending on the platform, Fuzix may be built to run at a different baud rate that the default RomWBW baud rate. If so, it is best to change your RomWBW baud rate prior to initiating the Fuzix startup. You can do this at the loader prompt with a command like this: I 0 38400 Replace 38400 with the desired baud rate for Fuzix. You will be prompted to change your terminal\u2019s baud rate at this time. At the RomWBW Boot Loader prompt, enter the disk unit number of the Fuzix media. Fuzix should load and you will see device discovery/information messages that vary depending on your platform. This is a typical example: RCBus [RCZ180_nat_wbw] Boot Loader FP Switches = 0x00 Boot [H=Help]: 2 Booting Disk Unit 2, Slice 0, Sector 0x00000000... Volume \"Fuzix 126 Loader\" [0xF200-0xF400, entry @ 0xF200]... FUZIX version 0.4 Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha Copyright (c) 2013-2015 Will Sowerbutts wi...@sowerbutts.com Copyright (c) 2014-2023 Alan Cox al...@etchedpixels.co.uk Devboot 512kB total RAM, 448kB available to processes (15 processes max) Enabling interrupts ... ok. 0000 : CF Card - OK 0001 : - absent hda: hda1 hda2 (swap) bootdev: At the bootdev: prompt, enter hda1 . Fuzix should load and you will be prompted for a date/time. Here is a typical example: bootdev: hda1 Mounting root fs (root_dev=1, ro): OK Starting /init init version 0.9.1 Checking root file system. Current date is Fri 2023-08-18 Enter new date: Current time is 13:30:24 Enter new time: ^ ^ n n Fuzix 0.4 @< Welcome to Fuzix m m login: At the login: prompt, enter root . No password is required. You should then get a Fuzix # command prompt. login: root Welcome to FUZIX. # You may now use Fuzix as desired. The general operation and use of Fuzix is outside of the scope of this document.","title":"Fuzix"},{"location":"UserGuide/#custom-applications","text":"The operation of the RomWBW hosted operating systems is enhanced through several custom applications. You have already read about one of these \u2013 the ASSIGN command. These applications are functional on all of the OS variants included with RomWBW. The applications discussed here are not the same as the built-in ROM applications mentioned previously. These applications run as commands within the operating systems provided by RomWBW. So, these commands are only available at an operating system prompt after an operating system has been loaded. All of the RomWBW Custom Applications are built to function under all of the RomWBW Operating Systems (except for p-System). In general, the applications will automatically adapt as needed to the currently running operating system. One exception is FDU \u2013 the Floppy Disk Utility. This application requires that you pick the floppy disk interface you want to interact with. There is more complete documentation of all of these applications in the related RomWBW manual \u201c RomWBW Applications \u201d found in the Doc directory of the distribution. The following custom applications are found on the ROM disk and are, therefore, globally available. Application **Description ASSIGN Add, change, and delete drive letter assignments. Use ASSIGN /? for usage instructions. SYSCOPY Copy system image to a device to make it bootable. Use SYSCOPY with no parms for usage instructions. MODE Reconfigures serial ports dynamically. FDU Format and test floppy disks. Menu driven interface. FORMAT Will someday be a command line tool to format floppy disks. Currently does nothing! XM XModem file transfer program adapted to hardware. Automatically uses primary serial port on system. FLASH Will Sowerbutts\u2019 in-situ ROM programming utility. FDISK80 John Coffman\u2019s Z80 hard disk partitioning tool. See documentation in Doc directory. FAT Access MS-DOS FAT filesystems from RomWBW (based on FatFs). TALK Direct console I/O to a specified character device. RTC Manage and test the Real Time Clock hardware. TIMER Display value of running periodic system timer. CPUSPD Change the running CPU speed and wait states of the system. Some custom applications do not fit on the ROM disk. They are found on the disk image files or the individual files can be found in the Binary/Apps directory of the distribution. They are also included on the floppy disk and hard disk images. Application Description TUNE Play .PT2, .PT3, .MYM audio files. INTTEST Test interrupt vector hooking.","title":"Custom Applications"},{"location":"UserGuide/#real-time-clock-datetime-stamping","text":"RomWBW supports a variety of real time clock hardware. If your system has this hardware, then it will be able to maintain the current date and time even while your system is turned off. Additionally, depending on the operating system being used, you may be able to utilize date/time stamping of files. To facilitate this a CP/M clock driver (WBWCLK) has been included inside CLOCKS.DAT that will read the clock via a RomWBW HBIOS call You can determine if your system has a real time clock present (and functioning) by looking at the boot messages. Here is an example of a boot message reflecting the detection of a valid real time clock module: DSRTC: MODE=STD IO=0x8A Thu 2023-10-19 14:07:11 CHARGE=ON This example is from a DSRTC clock module. You may have a different one, but it will always display the current date/time. In some cases, your real time clock will support charging of the battery or super-capacitor while the system has power. The status of this charging is displayed. If the date/time of your RTC needs to be updated, you will need to do this with one of the utilities described below. There is no ability to update the date/time of the RTC in the RomWBW Boot Loader or Monitor.","title":"Real Time Clock &amp; Date/Time Stamping"},{"location":"UserGuide/#datetime-utilities","text":"RomwWBW includes two utilities for displaying or setting the date/time stored by the RTC. They are both a bit different and are briefly described below. A third utility TESTCLOK is also included as part of ZSDOS","title":"Date/Time Utilities"},{"location":"UserGuide/#wdate-utility","text":"The WDATE utility (contributed by Kevin Boone) is an application that will display and/or update the current date/time. Its operation is described in RomWBW Applications . This utility works with any of the supported RomWBW RTC hardware. Here is an example of displaying and updating the date/time with this utility: A>wdate Thursday 19 October 14:14:43 2023 A>wdate 23 10 19 14 24 30 A>wdate Thursday 19 October 14:24:34 2023 Note that WDATE does not have anything to do with date/time stamping of files. It merely displays and sets the real time clock value.","title":"WDATE Utility"},{"location":"UserGuide/#rtc-utility","text":"Like WDATE , the RTC utility (contributed by Andrew Lynch) will let you display and set the current date/time. However, this utility only works with the DSRTC hardware (DS1302 chip). It is a \u201cdirect to hardware application\u201d. Its operation is described in RomWBW Applications . Here is an example of displaying and updatting the date/time with this utility: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>t Current time: 23-10-19 14:30:25-05 RTC>i Init date/time. YEAR:23 MONTH:10 DATE:19 HOURS:14 MINUTES:31 SECONDS:00 DAY:05 The RTC utility is also capable of turning the charging feature of the DS1320 chip on or off. Here is an example of turning if off and back on: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>n Trickle charger disabled. RTC>c Trickle charger enabled. Do not enable charging unless you are sure that your system supports this. If your RTC is being powered by a normal battery, it would be dangerous to enable charging.","title":"RTC Utility"},{"location":"UserGuide/#testclok-utility","text":"The TESTCLOK utility is used to test a selected CPM clock driver loaded from the CLOCKS.DAT file. After selecting the location of CLOCKS.DAT and the clock driver (45. WBWCLK) it displays the currently configured time until a key is pressed. A>testclok TESTCLOK V1.0 Copyright (C) 1988 H.F. Bower / C.W. Cotrill Extract Clock from Library ([Y]/N) : Y Location of CLOCKS.DAT [A0:] : <RETURN> 1. ACTRIX 2. ALSPA 3. AMPRO-LB 4. ANLYTCL-PRD 5. AP2-CDZ180 6. AP2-THND/MT 7. AP2-TIMASTR 8. AP2E+PCP-TM 9. AP2E+PCPI 10. AP2E-THUNDR 11. AP2E-TMASTR 12. BIG-BD-II 13. BP-BIOS 14. CCS-WALLCLK 15. CPUPRO-SSB1 16. ELECTR-MFIO 17. EPSON-QX10 18. ETS180IO+ 19. H19-SUPER19 20. H19-ULTRA 21. H19-WATZMAN 22. H89-BITZERO 23. H89-PC12 24. H89-WIDGET 25. H89-WISE 26. H89UTI 27. HEATH-BIOS 28. HOUSEMASTER 29. K83-HOLMES 30. KAYPRO-84 31. KENMOR-ZTIM 32. KPRO-ADVENT 33. KPRO-LEGACY 34. MD3-MACK 35. MTN100K-DAY 36. ONEAC-ON! 37. OTRANA-ATCH 38. P&T-HEARTBT 39. QTSYS-S100 40. RELATIVE 41. S100-5832 42. SB180-HRTBT 43. SB180-XBIOS 44. SIMHCLOK 45. WBWCLK 46. XEROX-820 47. ZSDOS-BIOS Enter Clock Driver Selection : 45 ..Loading : WBWCLK ... Linking Clock Module... OK RomWBW HBIOS Clock 1.1 RomWBW Series HBIOS Clock Press any key to quit... 19 Oct 2023 14:24:34 Since this runs at the CPM driver level it is useful as an end-to-end test to prove that date time stamping is able to read the correct time The TESTCLOK utility is provided by ZSDOS, plese see the ZSDOS Manual for further information","title":"TESTCLOK Utility"},{"location":"UserGuide/#datetime-file-stamping","text":"If an RTC is available in your system, then most operating systems can use it to date/time stamp files. This just means recording the date/time of file creation, update, and or access in the directory. This capability is available in all of the RomWBW operating system except the original DRI CP/M 2.2. Three types of date/time stamping are supported using realtime clock supported by RomWBW HBIOS. DateStamper, NZT and P2DOS. In some cases (such as ZSDOS), you must load an RSX (memory resident utility) to enable date/time stamping of files. This could be automated using a PROFILE.SUB file. Preconfigured loaders are provided, bypassing the need to use SETUPZST. Additionally, you will need to initialize the directory. The procedure varies depending on the date/time stamping mechanism, so you must review the associated documentation. The date/time stamping mechanisms for each operating system are generally not compatible. If you initialize a directory for a type of stamping, you should be careful not to manipulate that directory with a different operating system with a different date/time stamping mechanism. Doing so may corrupt the directory. The RomWBW disk images do not have date/time stamping initialized. This is to avoid any chance of directory corruption.","title":"Date/Time File Stamping"},{"location":"UserGuide/#datestamper","text":"DateStamper datestamping follows the standard set by Plu*Perfect Systems. This method stores stamps in a disk file named !!!TIME&.DAT . Only DateStamper stamping stores full time and date stamps for file Creation, Last Modification, and Last Access, and may be used with any CP/M diskette format. In addition, the DateStamper protocol is supported by a mature set of compatible utilities. Key Utilities LDDS.COM - Load DateStamper date/time stamping resident extension. (RomWBW Provided) PUTDS.COM - Prepare disk for DateStamper date/time stamping. After using PUTDS to initialize a directory for ZDS date stamping, it may be necessary to run RELOG before the stamping routines will actually start working.","title":"DateStamper"},{"location":"UserGuide/#p2dos-cpm-plus-compatible","text":"CP/M Plus-type datestamping is also widely used due to the popularity of CP/M Plus (also know as CP/M 3). CP/M Plus-type file datestamping uses directory sectors to store file datestamps which may be accessed more quickly by programs, but there is no Last File Access stamp. Finally, the range of utilities for this type of stamps is more limited than for the DateStamper protocol. Key Utilities LDP2D.COM - Load P2DOS date/time stamping resident extension. (RomWBW Provided) INITDIR.COM - Prepares disks for P2DOS-type file stamping.","title":"P2DOS (CP/M Plus compatible)"},{"location":"UserGuide/#nzt","text":"The use of NZT needs to be further documented Key Utilities LDNZT.COM - Load NZT date/time stamping resident extension. (RomWBW Provided)","title":"NZT"},{"location":"UserGuide/#additional-notes","text":"The following files have been provided, customised and tested for for use in RomWBW CLOCKS.DAT - Library of clock drivers, which has been updated to include the RomWBW clock driver WBWCLK, and also includes the SIMHCLOK clock driver. The file is just a standard LU type library and is easily updated using NULU. The members are the relocatable binaries, but with the .REL extension removed. STAMPS.DAT - Library of available date/time stamping modules for SETUPZST. The file has been replaced with an updated version from the Walnut Creek CP/M CDROM. The original version has a bug that prevents RSX (resident system extension) mode to load properly. Additional Notes SETUPZST (provided by ZSDOS) Should not normally be needed since the creation of the appropriate LDTIM loaders has already been performed. FILEDATE only works with DateStamper style date stamping. If you run it on a drive that is not initialized for DateStamper, it will complain FILEDATE, !!!TIME&.DAT missing . This is normal and just means that you have not initialized that drive for DateStamper (using PUTDS). ZXD will handle either DateStamper or P2DOS type date stamping. However, it must be configured appropriately. As distributed, it will look for P2DOS date stamps. Use ZCNFG to reconfigure it for P2DOS if that is what you are using.","title":"Additional Notes"},{"location":"UserGuide/#timezone","text":"None of the operating systems distributed with RomWBW have any concept of timezone. When files are date/time stamped, the date/time will simply be whatever date/time the RTC currently has. The normal practice is to set the RTC to your local time. This implies that you would need to manually adjust the RTC for daylight savings time and/or when you travel to a different time zone. The date/time stamps of files in directories will also be stored in local time. This includes files stored in a FAT filesystem. If you subsequently view the directory from modern machines (Windows, Linux, etc.), the date/time displayed will depend on the behavior of the modern system. For example, Linux assumes that the date/time of files is UTC. So, if you create a file on a FAT filesystem with your RomWBW computer and then use Linux to view the directory, the date/time stamps will seem \u201coff\u201d by a few hours. The only alternative you may consider is setting the date/time of your RTC to UTC. Since UTC is consistent across all timezones and daylight savings time, your file date/time stamps will also be consistent. Of course, this will mean that your RomWBW computer will display a date/time that seems wrong because it is not local time.","title":"Timezone"},{"location":"UserGuide/#cpnet-networking","text":"Digital Research created a simple network file sharing system called CP/NET. This allowed a network server running CP/NOS to host files available to network attached CP/M computers. Essentially, the host becomes a simple file sharing server. RomWBW disk images include an adaptation of the DRI CP/NET client software provided by Douglas Miller. RomWBW does not support operation as a network server itself. However, Douglas has also developed a Java-based implementation of the DRI network server that can be used to provide host services from a modern computer. Both CP/NET 1.2 and 3.0 clients are provided. Version 1.2 is for use with CP/M 2.2 and compatible OSes. Version 3.0 is for use with CP/M 3 and compatible OSes. The CP/NET client software provided with RomWBW requires a supported ethernet interface module. At this time, the following are supported: RCBus MT011 w/ Ethernet Featherwing and (optionally) SPI FRAM (e.g., Adafruit SPI Non-Volatile FRAM Breakout) Duodyne Disk I/O w/ Wiz850IO and (optionally) SPI NVRAM (e.g., 25LC256) Generic Serial Interface NOTE: The Generic Serial Interface is supported by RomWBW, but is not documented here. You must refer to the CP/NET documentation referenced below. The client software interacts directly with this hardware. In a future version of RomWBW, I hope to add a generic networking API that will allow a greater range of network hardware to be used. To use CP/NET effectively, you will want to review the documentation provided by Douglas on at his cpnet-z80 GitHub Project . Additionally, you should consult the DRI documentation which is not included with RomWBW, but is available on the cpnet-z80 site. Below, I will provide the general steps involved in setting up a network using MT011 with RomWBW.","title":"CP/NET Networking"},{"location":"UserGuide/#cpnet-client-setup","text":"The CP/NET client files are included on the RomWBW disk images, but they are found in user area 4. They are placed there to avoid confusing anyone that is not specifically trying to run a network client. They are only found on the CPM 2.2 and CP/M 3 slices. Using CP/NET on alternative OSes may work, but is not officially supported. The CP/NET client files are packaged in .LBR library files. The library files are found in user area 4. 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 First, you need to merge the files from the correct library file into user area 0. This is done by extracting the files using the NULU library management utility application. Start NULU specifying desired CP/NET library for \\<filename>: A>NULU 4:<filename> At the NULU prompt, extract the files using the -E *.* command: -READY A0:>-E *.* Exit NULU using the -X command: -Extract members A0:>-x Here is an example of extracting the CP/NET 1.2 client files for an RCBus system w/ MT011. You should be in user area 0 when performing this operation. A>nulu 4:cpn12mt NULU 1.52 (07/12/87) Copyright (C) 1984, 1985 & 1987 by Martin Murray Bug fixes in version 1.52 by Mick Waters TYPE -H FOR HELP Library A4:CPN12MT.LBR open. (Buffer size: 259 sectors) Active entries: 27, Deleted: 0, Free: 5, Total: 32. -READY A0:>-e *.* Extracting... CCP .SPR to A0:CCP .SPR CPM2NET .HLP to A0:CPM2NET .HLP CPNBOOT .COM to A0:CPNBOOT .COM CPNET12 .HLP to A0:CPNET12 .HLP CPNETLDR.COM to A0:CPNETLDR.COM CPNETSTS.COM to A0:CPNETSTS.COM DSKRESET.COM to A0:DSKRESET.COM ENDLIST .COM to A0:ENDLIST .COM LOCAL .COM to A0:LOCAL .COM LOGIN .COM to A0:LOGIN .COM LOGOFF .COM to A0:LOGOFF .COM MAIL .COM to A0:MAIL .COM NDOS .SPR to A0:NDOS .SPR NETDOWN .COM to A0:NETDOWN .COM NETSTAT .COM to A0:NETSTAT .COM NETWORK .COM to A0:NETWORK .COM NVRAM .COM to A0:NVRAM .COM PIPNET .COM to A0:PIPNET .COM RDATE .COM to A0:RDATE .COM SNIOS .SPR to A0:SNIOS .SPR SRVSTAT .COM to A0:SRVSTAT .COM TR .COM to A0:TR .COM WIZCFG .COM to A0:WIZCFG .COM WIZDBG .COM to A0:WIZDBG .COM WIZTEST .COM to A0:WIZTEST .COM XSUBNET .COM to A0:XSUBNET .COM -Extract members A0:>-x Closing A4:CPN12MT.LBR... At this point, you will need to configure your ethernet adapter for your local network using WIZCFG . The definitive guide to the use of WIZCFG is on the cpnet-z80 site in the document called \u201cCPNET-WIZ850io.pdf\u201d. Here is an example of the commands needed to configure the WizNet: wizcfg w n F0 set CP/NET node id wizcfg w i 192.168.1.201 set WizNet IP address wizcfg w g 192.168.1.1 set local network gateway IP address wizcfg w s 255.255.255.0 set WizNet subnet mask wizcfg w 0 00 192.168.1.3 31100 set server node ID, IP address, & port You will need to use values appropriate for your local network. You can use the command wiznet w to display the current values which is useful to confirm they have been set as intended. A>wizcfg w Node ID: F0H IP Addr: 192.168.1.201 Gateway: 192.168.1.1 Subnet: 255.255.255.0 MAC: 98:76:B6:11:00:C4 Socket 0: 00H 192.168.1.3 31100 0 These values can be persisted across power-cycles if your system has NVRAM storage. To program the values into your NVRAM, you would use the same commands as above, but omit the w parameter. The \u201cCPNET-WIZ850io.pdf\u201d document is highly recommended to understand the operation of WIZCFG . If you do not utilize NVRAM to persist your configuration, you will need to reapply these commands every time you power cycle your RomWBW computer, so I recommend putting them into a SUBMIT file. After applying these commands, you should be able ping the WizNet from another computer on the local network. If this works, then the client-side is ready.","title":"CP/NET Client Setup"},{"location":"UserGuide/#cpnet-sever-setup","text":"These instructions will assume you are using Douglas Miller\u2019s CpnetSocketServer to implement a CP/NOS server on your network. The definitive guide to this software is also on the [cpnet-z80] (https://github.com/durgadas311/cpnet-z80) site and is called \u201cCpnetSocketServer.pdf\u201d. The software is a Java application, so it can generally run anywhere there is a Java runtime environment available. I have normally used it on a Linux system and have had good results with that. You will need to download the application called \u201cCpnetSocketServer.jar\u201d from the cpnet-z80 site. The application uses a configuration file. My configuration file is called \u201ccpnet00.rc\u201d and has these contents: cpnetserver_host = 192.168.1.3 cpnetserver_port = 31100 cpnetserver_temp = P cpnetserver_sid = 00 cpnetserver_max = 16 cpnetserver_root_dir = /home/wayne/cpnet/root You will also need to setup a directory structure with the drive letters per the documentation. To start the server, you would use a command like this: java -jar CpnetSocketServer.jar conf=cpnet00.rc At this point, the server should start and you should see the following: CpnetSocketServer v1.3 Using config in cpnet00.rc Server 00 Listening on 192.168.1.3 port 31100 debug false Your CP/NET server should now be ready to accept client connections.","title":"CP/NET Sever Setup"},{"location":"UserGuide/#cpnet-usage","text":"With both the client and server configured, you are ready to load and use CP/NET on your RomWBW system. CP/NET documentation is available on the cpnet-z80 site. The document is called \u201cdri-cpnet.pdf\u201d. Under CP/M 2.2, you will start the networking client using the command CPNETLDR . Under CP/M 3, you use the command NDOS3 . If that works, you can map network drives as local drives using the NETWORK command. The CPNETSTS command is useful for displaying the current status. Here is a sample session from CP/M 2.2: A>cpnetldr CP/NET 1.2 Loader ================= BIOS E600H 1A00H BDOS D800H 0E00H SNIOS SPR D400H 0400H NDOS SPR C800H 0C00H TPA 0000H C800H CP/NET 1.2 loading complete. A>network k:=c:[0] A>dir k: K: TELNET COM : ZDENST COM : CLRDIR COM : RTC COM K: DDTZ COM : MBASIC COM : XSUBNET COM : NETWORK COM K: WGET COM : UNCR COM : FLASH COM : PIP COM K: TIMEZONE COM : COMPARE COM : ZAP COM A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = LOCAL Drive B: = LOCAL Drive C: = LOCAL Drive D: = LOCAL Drive E: = LOCAL Drive F: = LOCAL Drive G: = LOCAL Drive H: = LOCAL Drive I: = LOCAL Drive J: = LOCAL Drive K: = Drive C: on Network Server ID = 00H Drive L: = LOCAL Drive M: = LOCAL Drive N: = LOCAL Drive O: = LOCAL Drive P: = LOCAL Console Device = LOCAL List Device = LOCAL If you are using CpSocketServer to provide the CP/NOS server, then you will see some messages on your server console when clients connect. Here are the messages issued by the server in the above example: Connection from 192.168.1.201 (31100) Remote 192.168.1.201 is f0 Creating HostFileBdos 00 device with root dir /home/wayne/cpnet/root At this point CP/NET is ready for general use. You should be able to access files on the network mapped drives just like files on your local drives.","title":"CP/NET Usage"},{"location":"UserGuide/#network-boot","text":"It is possible to boot your RomWBW system directly from a network server if it has the required hardware. 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. The supported hardware is: RCBus System w/ MT011 including: Featherwing WizNet W5500 SPI FRAM on secondary SPI interface (CS2) Doudyne Disk I/O Board including: WIZ850io Module 25LCxxx Serial SPI EEPROM Unlike the CP/NET Client, the presence of dedicated non-volatile storage is required to hold the network configuration. This will be FRAM (for MT011) or Serial SPI EEPROM (Duodyne). The NVRAM is used to store your WizNet configuration values so they do not need to be re-entered every time you power-cycle your system. It is important to understand that the operating system that is loaded in this case is not a RomWBW enhanced operating system. Some commands (such as the ASSIGN command) will not be possible. Also, you will only have access to drives provided by the network server \u2013 no local disk drives will be available. Using the same values from the previous example, you would issue the WIZCFG commands: wizcfg n F0 wizcfg i 192.168.1.201 wizcfg g 192.168.1.1 wizcfg s 255.255.255.0 wizcfg 0 00 192.168.1.3 31100 Note that the \u2018w\u2019 parameter is now omitted which causes these values to be written to NVRAM. As before, your network server will need to be running CpnetSocketServer. However, you will need to setup a directory that contains some files that will be sent to your RomWBW system when the Network boot is performed. By default the directory will be ~/NetBoot . In this directory you need to place the following files: cpnos.sys ndos.spr snios.spr You also need to make sure CpnetSocketServer is configured with an \u2018A\u2019 drive and that drive must contain (at an absolute minimum) the following file: ccp.spr All of these files are found in the Binary/CPNET/NetBoot directory of the RomWBW distribution. You will find 2 sub-directories named MT and DUO. Get the files from the sub-directory corresponding to your specific hardware. Finally, you need to add the following line to your CpnetSocketServer configuration file: netboot_default = cpnos.sys To perform the network boot, you start your RomWBW system normally which should leave you at the Boot Loader prompt. The \u2018N\u2019 command will initiate the network boot. Here is an example of what this looks like: RCBus [RCZ180_nat_wbw] Boot Loader Boot [H=Help]: n Loading Network Boot... MT011 WizNET Network Boot WBWBIOS SPR FD00 0100 COBDOS SPR FA00 0300 SNIOS SPR F600 0400 NDOS SPR EA00 0C00 58K TPA A> The CP/M operating system and the CP/NET components have been loaded directly from the network server. All of your drive letters are automatically mapped directly to the drive letters configured with CpnetSocketServer. A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = Drive A: on Network Server ID = 00H Drive B: = Drive B: on Network Server ID = 00H Drive C: = Drive C: on Network Server ID = 00H Drive D: = Drive D: on Network Server ID = 00H Drive E: = Drive E: on Network Server ID = 00H Drive F: = Drive F: on Network Server ID = 00H Drive G: = Drive G: on Network Server ID = 00H Drive H: = Drive H: on Network Server ID = 00H Drive I: = Drive I: on Network Server ID = 00H Drive J: = Drive J: on Network Server ID = 00H Drive K: = Drive K: on Network Server ID = 00H Drive L: = Drive L: on Network Server ID = 00H Drive M: = Drive M: on Network Server ID = 00H Drive N: = Drive N: on Network Server ID = 00H Drive O: = Drive O: on Network Server ID = 00H Drive P: = Drive P: on Network Server ID = 00H Console Device = LOCAL List Device = LOCAL At this point you can use CP/M and CP/NET normally, but all disk access will be to/from the network drives. There is no access to your local disk drives in this boot mode.","title":"Network Boot"},{"location":"UserGuide/#transferring-files","text":"Transferring files between your modern computer and your RomWBW system can be achieved in a variety of ways. The most common of these are described below. All of these have a certain degree of complexity and I encourage new users to use the available community forums to seek assistance as needed.","title":"Transferring Files"},{"location":"UserGuide/#serial-port-transfers","text":"RomWBW provides an serial file transfer program called XModem that has been adapted to run under RomWBW hardware. The program is called XM and is on your ROM disk as well as all of the pre-built disk images. You can type XM by itself to get usage information. In general, you will run XM with parameters to indicate you want to send or receive a file on your RomWBW system. Then, you will use your modern computers terminal program to complete the process. The XM application generally tries to detect the hardware you are using and adapt to it. However, you must ensure that you have a reliable serial connection. You must also ensure that the speed of the connection is not too fast for XModem to service. If your file transfer attempts are failing, try either of the following: Check that hardware flow control is enabled in your terminal emulation software. Reduce the speed of your serial port connection. There is an odd interaction between XModem and partner terminal programs that can occur. Essentially, after launching XM , you must start the protocol on your modern computer fairly quickly (usually in about 20 seconds or so). So, if you do not pick a file on your modern computer quickly enough, you will find that the transfer completes about 16K, then hangs. The interaction that causes this is beyond the scope of this document.","title":"Serial Port Transfers"},{"location":"UserGuide/#disk-image-transfers","text":"It is possible to pass disk images between your RomWBW system and your modern computer. This assumes you have an appropriate media slot on your modern computer for the media you want to use (CF Card, SD Card, floppy drive, etc.). The general process to get files from your modern computer to a RomWBW computer is: Use cpmtools on your modern computer to create a RomWBW CP/M filesystem image. Insert your RomWBW media (CF Card, SD Card, floppy disk, etc.) in your modern computer. Use a disk imaging tool to copy the RomWBW filesystem image onto the media. Move the media back to the RomWBW computer. This process is a little complicated, but it has the benefit of allowing you to get a lot of files over to your RomWBW system quickly and with little chance of corruption. The process can be run in reverse to get files from your RomWBW computer to a modern computer. The exact use of these tools is a bit too much for this document, but the tools are all included in the RomWBW distribution along with usage documents. Note that the build scripts for RomWBW create the default disk images supplied with RomWBW. It is relatively easy to customize the contents of the disk images that are part of RomWBW. This is described in more detail in the Source/Images directory of the distribution.","title":"Disk Image Transfers"},{"location":"UserGuide/#fat-filesystem-transfers","text":"The FAT filesystem format that originated with MS-DOS is almost ubiquitous across modern computers. Virtually all operating systems now support reading and writing files to a FAT filesystem. For this reason, RomWBW now has the ability to read and write files on FAT filesystems. This capability means that you can generally use your modern computer to make an SD Card, CF Card, or USB Drive with a standard FAT filesystem on it, then place that media in your RomWBW computer and access the files. Files can be copied between a FAT filesystem and a CP/M filesystem, but you cannot execute files directly from a FAT filesystem. FAT12, FAT16, and FAT32 formats are supported. Long filenames are not supported. Files with long filenames will show up with their names truncated into the older 8.3 convention. If you have files on your modern computer with long filenames, it is usually easiest to rename them on the modern computer. A FAT filesystem can be located on floppy or hard disk media. For hard disk media, a valid FAT Filesystem partition must exist. Some additional Notes and WARNINGS Things to be careful about CP/M (and compatible) OSes do not support all of the filename characters that a modern computer does. The following characters are not permitted in a CP/M filename: < > . , ; : = ? * [ ] _ % | ( ) / \\ The FAT application does not auto-rename files when it encounters invalid filenames. It will just issue an error and quit. Additionally, the error message is not very clear about the problem. Microsoft Windows will sometimes suggest reformatting partitions that it does not recognize (e.g. RomWBW). If you are using media that contains both a FAT partition and a RomWBW partition you may prompted to format a partition of your SD/CF/USB Media when inserting the card into a Windows computer, you probably want to select Cancel.","title":"FAT Filesystem Transfers"},{"location":"UserGuide/#fat-filesystem-preparation","text":"In general, you can create media formatted with a FAT filesystem on your RomWBW computer or on your modern computer. We will only be discussing the RomWBW-based approach here.","title":"FAT Filesystem Preparation"},{"location":"UserGuide/#floppy-disk","text":"In the case of a floppy disk, you can use the FAT application to format the floppy disk. The floppy disk must already be physically formatted using RomWBW FDU or equivalent. If your floppy disk is on RomWBW disk unit 2, you could use FAT FORMAT 2: . This will overwrite the floppy with a FAT filesystem and all previous contents will be lost. Once formatted this way, the floppy disk can be used in a floppy drive attached to a modern computer or it can be used on RomWBW using the other FAT tool commands.","title":"Floppy Disk"},{"location":"UserGuide/#hard-disk","text":"In the case of hard disk media, it is necessary to have a FAT partition. If you prepared your RomWBW hard disk media using the disk image process, then this partition will already be defined and you do not need to recreate it. This default FAT partition is located at approximately 512MB from the start of your disk and it is 384MB in size. So, your hard disk media must be 1GB or greater to use this default FAT partition. You can confirm the existence of the FAT partition with FDISK80 by using the \u2018P\u2019 command to show the current partition table. Here is an example of a partition table listing from FDISK80 that includes the FAT partition (labelled \u201cFAT16\u201d): Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 FAT16 06 1023:0:1 1023:15:16 1050624 786432 384M 3 00 *** empty *** 4 00 *** empty *** If your hard disk media does not have a FAT partition already defined, you will need to define one using FDISK80 by using the \u2018N\u2019 command. Ensure that the location and size of the FAT partition does not overlap any of the CP/M slice area and that it fits within the size of your media. Once the partition is defined, you will still need to format it. Just as with a floppy disk, you use the FAT tool to do this. If your hard disk media is on RomWBW disk unit 4, you would use FAT FORMAT 4: . This will look something like this: E>fat format 4: About to format FAT Filesystem on Disk Unit #4. All existing FAT partition data will be destroyed!!! Continue (y/n)? Formatting... Done Your FAT filesystem is now ready to use. If your RomWBW system has multiple disk drives/slots, you can also just create a disk with your modern computer that is a dedicated FAT filesystem disk. You can use your modern computer to format the disk (floppy, CF Card, SD Card, etc.), then insert the disk in your RomWBW computer and access it using FAT based on its RomWBW unit number.","title":"Hard Disk"},{"location":"UserGuide/#fat-application-usage","text":"Transferring files is accomplished by running a RomWBW custom application called FAT . This application understands both FAT filesystems as well as CP/M filesystems. To copy files from your modern computer to your RomWBW computer, start by putting the disk media with the FAT filesystem in your modern computer. The modern computer should recognize it. Then copy the files you want to get to your RomWBW computer onto this media. Once done, remove the media from your modern computer and insert it in the RomWBW computer. Finally, use the FAT tool to copy the files onto a CP/M drive. This process works just fine in reverse if you want to copy files from a CP/M filesystem to your modern computer. Complete instructions for the FAT application are found in RomWBW Applications . Here, we will just provide a couple of simple examples. Note that the FAT application is not on the ROM disk because it is too large to include there. The most important thing to understand about the FAT application is how it refers to FAT filesystems vs. CP/M filesystems. It infers this based on the file specification provided. If you use a specification like C:SAMPLE.TXT , it will use the C: drive of your CP/M operating system. If you use a specification like 4:SAMPLE.TXT , it will use the FAT filesystem on the disk in RomWBW disk unit 4. Basically, if you start your file or directory specification with a number followed by a colon, it means FAT filesystem. Anything else will mean CP/M filesystem. Here are a few examples. This first example shows how to get a FAT directory listing from RomWBW disk unit 4: E>fat dir 4: Directory of 4: E> As you can see, there are currently no files there. Now let\u2019s copy a file from CP/M to the FAT directory: E>fat copy sample.txt 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT ... [OK] 1 File(s) Copied If we list the FAT directory again, you will see the file: E>fat dir 4: Directory of 4: 01/30/2023 17:50:14 29952 ---A SAMPLE.TXT Now let\u2019s copy the file from the FAT filesystem back to CP/M. This time we will get a warning about overwriting the file. For this example, we don\u2019t want to do that, so we abort and reissue the command specifying a new filename to use: E>fat copy 4:sample.txt e: Copying... 4:/SAMPLE.TXT ==> E:SAMPLE.TXT Overwrite? (Y/N) [Skipped] 0 File(s) Copied E>fat copy 4:sample.txt e:sample2.txt Copying... 4:/SAMPLE.TXT ==> E:SAMPLE2.TXT ... [OK] 1 File(s) Copied Finally, let\u2019s try using wildcards: E>fat copy sample*.* 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT Overwrite? (Y/N) ... [OK] SAMPLE2.TXT ==> 4:/SAMPLE2.TXT ... [OK] 2 File(s) Copied","title":"FAT Application Usage"},{"location":"UserGuide/#customizing-romwbw","text":"","title":"Customizing RomWBW"},{"location":"UserGuide/#startup-command-processing","text":"Most of the operating systems supported by RomWBW provide a mechanism to run commands at boot. This is similar to the AUTOEXEC.BAT files from MS-DOS. With the exception of ZPM3 and p-System, all operating systems will look for a file called PROFILE.SUB on the system drive at boot. If it is found, it will be processed as a standard CP/M submit file. You can read about the use of the SUBMIT facility in the CP/M manuals included in the RomWBW distribution. Note that the boot disk must also have a copy of SUBMIT.EXE . Note that the automatic startup processing generally requires booting to a disk drive. Since the ROM disk is not writable, there is no simple way to add/edit a PROFILE.SUB file there. If you want to customize your ROM and add a PROFILE.SUB file to the ROM Disk, it will work, but is a lot harder than using a boot disk. In the case of ZPM3, the file called STARTZPM.COM will be run at boot. To customize this file, you use the ZCPR ALIAS facility. You will need to refer to ZCPR documentation for more information on the ALIAS facility. p-System has its own startup command processing mechanism that is covered in the p-System documentation.","title":"Startup Command Processing"},{"location":"UserGuide/#nvram-configuration","text":"See section Setting NVRAM Options for information about how to apply NVRAM configuration.","title":"NVRAM Configuration"},{"location":"UserGuide/#rom-customization","text":"The pre-built ROM images are configured for the basic capabilities of each platform. Additionally, some of the typical add-on hardware for each platform will be automatically detected and used. If you want to go beyond this, RomWBW provides a very flexible configuration mechanism based on configuration files. Creating a customized ROM requires running a build script, but it is quite easy to do. Essentially, the creation of a custom ROM is accomplished by updating a small configuration file, then running a script to compile the software and generate the custom ROM and disk images. There are build scripts for Windows, Linux, and MacOS to accommodate virtually all users. All required build tools (compilers, assemblers, etc.) are included in the distribution, so it is not necessary to setup a build environment on your computer. RomWBW can be built on modern Windows, Linux, or MacOS computers. The process for building a custom ROM is documented in the ReadMe.txt file in the Source directory of the distribution. Any modern version of Windows (32-bit or 64-bit), MacOS, or Linux released in the last 10 years should be able to run the build process. For those who are interested in more than basic system customization, note that all source code is provided (including the operating systems). Modification of the source code is considered an expert level task and is left to the reader to pursue. Note that the ROM customization process does not apply to UNA. All UNA customization is performed within the ROM setup script that is built into the ROM.","title":"ROM Customization"},{"location":"UserGuide/#rom-user-application","text":"The User App is provided as a way to access a custom written ROM application. 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 instead, review the \u201cusrrom.asm\u201d file in the Source/HBIOS folder of the distribution.","title":"ROM User Application"},{"location":"UserGuide/#upgrading","text":"Upgrading to a newer release of RomWBW is essentially just a matter of updating the ROM chip in your system. If you have spare ROM chips for your system and a ROM programmer, it is always safest to retain your existing, working ROM chip and program a new one with the new firmware. If the new one fails to boot, you can easily return to the known working ROM. For each ROM that comes with the RomWBW distribution, you will find that there are actually 3 different variants: .rom contains the complete ROM chip image .upd contains the system code, but omits the ROM Disk contents .com contains a CP/M executable version of the ROM code So, for example, RCZ80_std contains the following files: SBC_std.rom SBC_std.upd SBC_std.com The use of the .com variant is described below in Application Boot . As previously discussed, the ROM in most RomWBW systems contains both the system code as well as a ROM Disk with files on it. The .rom variant of the ROM contains a full ROM chip image including both the system code and the Rom Disk contents. The .upd variant of the ROM contains only the system code portion of the ROM. If you apply the .upd variant to your system, it will overlay the system code, but will not overlay the ROM Disk contents (they remain intact). You may use either the .rom or the .upd file when updating your ROM chip (this does not apply to Application Boot). It is best to use the .rom file for your upgrade because the files on your ROM Disk should be updated whenever you update your system code. The advantage of the .upd variant is that is much smaller, so you can upload and apply it faster. The ROM update instructions below generally refer to using the .rom variant. However, you may substitute the .upd variant if desired.","title":"Upgrading"},{"location":"UserGuide/#application-boot","text":"Prior to attempting to reprogram your actual ROM chip, you may wish to \u201ctry\u201d the update to ensure it will work on your system. With RomWBW, you can upload a new ROM image executable and load it from the command line. For each ROM image file (.rom) in the Binary directory, you will find a corresponding application file (.com). For example, for SBC_std.rom, there is also an SBC_std.com file. You can upload the .com file to your system using XModem, then simply run the .com file. You will see your system go through the normal startup process just like it was started from ROM. However, your physical ROM has not been updated and the next time you boot your system, it will revert to the system image contained in ROM. Using this .com version of a ROM is an excellent way to confirm that the new ROM code you intend to program will work correctly. If it does not, then you can just reboot and your old ROM will be loaded. When the .com file is loaded, you will be taken to the normal Boot Loader menu. However, you will find that the only OS that is available to boot from ROM is ZSDOS. There is only room for a single OS in the .com file. Even if you don\u2019t normally use ZSDOS, this will still confirm that your system operates well under the new ROM code.","title":"Application Boot"},{"location":"UserGuide/#upgrading-via-flash-utility","text":"If you do not have easy access to a ROM programmer, it is usually possible to reprogram your system ROM using the FLASH utility from Will Sowerbutts. This application, called FLASH.COM, can be found on the ROM drive of any running system. In this case, you would need to transfer the new ROM image (.rom) over to your system using XModem (or one of the other mechanisms described in the Transferring Files section). The ROM image is too large to fit on your RAM drive, so you will need to transfer it to a larger storage drive. Once the ROM image is on your system, you can use the FLASH application to update your ROM. The following is a typical example of transferring ROM image using XModem and flashing the chip in-situ. NOTE : The FLASH utility can not determine the type of your ROM chip if it is write protected. Additionally, it has no way to determine if it is write protected. If the FLASH utility indicates it does not recognize your ROM chip, check to ensure the chip is not write protected. E>xm r rom.rom XMODEM v12.5 - 07/13/86 RBC, 28-Aug-2019 [WBW], ASCI Receiving: E0:ROM.IMG 7312k available for uploads File open - ready to receive To cancel: Ctrl-X, pause, Ctrl-X Thanks for the upload E>flash write rom.rom FLASH4 by Will Sowerbutts <will@sowerbutts.com> version 1.2.3 Using RomWBW (v2.6+) bank switching. Flash memory chip ID is 0xBFB7: 39F040 Flash memory has 128 sectors of 4096 bytes, total 512KB Write complete: Reprogrammed 2/128 sectors. Verify (128 sectors) complete: OK! Obviously, there is some risk to this approach since any issues with the programming or ROM image could result in a non-functional system. To confirm your ROM chip has been successfully updated, restart your system and boot an operating system from ROM. Do not boot from a disk device yet. Review the boot messages to see if any issues have occurred.","title":"Upgrading via Flash Utility"},{"location":"UserGuide/#upgrading-via-xmodem-flash-updater","text":"Similar to using the Flash utility, the system ROM can be updated or upgraded through the ROM-based updater utility. This works by reprogramming the flash ROM as the file is being transferred. Using the ROM-based updater has the advantage that secondary storage is not required to hold the new image. In other words, it is not necessary to have a mass storage device available to store the ROM image. From the Boot Loader menu select X (Xmodem Flash Updater) and then U (Begin Update). Then initiate the Xmodem transfer of the .rom file. Since the XModem Flash Updater will be relatively slow, you may wish to use the .upd varient of the ROM. More information can be found in the ROM Applications document.","title":"Upgrading via XModem Flash Updater"},{"location":"UserGuide/#post-upgrade-update","text":"Once you are satisfied that the ROM is working well, you will need to update the system images and RomWBW custom applications on your disk drives. The system images and custom applications are matched to the RomWBW ROM firmware in use. If you attempt to boot a disk or run applications that have not been updated to match the current ROM firmware, you are likely to have odd problems. The simplest way to update your disk media is to just use your modern computer to overwrite the entire media with the latest disk image of your choice. This process is described below in the Disk Images section. If you wish to update existing disk media in your system, you need to perform the following steps. If the disk is bootable, you need to update the system image on the disk using the procedure described in the Operating Systems section of this document. Finally, if you have copies of any of the RomWBW custom applications on your hard disk, you need to update them with the latest copies. The following applications are found on your ROM disk. Use COPY to copy them over any older versions of the app on your disk: ASSIGN.COM SYSCOPY.COM MODE.COM FDU.COM FORMAT.COM XM.COM FLASH.COM FDISK80.COM TALK.COM RTC.COM TIMER.COM FAT.COM For example: B>COPY ASSIGN.COM C: Some RomWBW custom applications are too large to fit on the ROM disk. If you are using any of these you will need to transfer them to your system and then update all copies. These applications are found in the Binary/Apps directory of the distribution and in all of the disk images. TUNE.COM The files normally contained on the standard ROM Disk is based on a 512K ROM. If your system has a smaller size ROM, then not all of these files will be included on your ROM Disk. You will need to copy them to your system from the /Binary/Apps folder of the RomWBW distribution. WARNING : If you run a RomWBW-specific application that is not the appropriate for the version of RomWBW you are running, the application will generate an error message and abort.","title":"Post Upgrade Update"},{"location":"UserGuide/#system-update","text":"As previously described, a RomWBW ROM contains ROM applications as well as a ROM disk image. If you are upgrading your ROM with a new patch level release, you may wish to upgrade just the application portion of the ROM. This is referred to as a System Update. If the system running ROMWBW utilizes the SST39SF040 Flash chip then it is possible to do a System Update in place of a System Upgrade in some cases. A System Update would involve only updating the BIOS, ROM applications and ROM-hosted operating systems. A System Update may be more favorable than a System Upgrade in cases such as: Overwriting of the ROM drive contents is not desired. Temporary disk space is unavailable to hold a full ROM image. To reduce the time taken to transfer and flash a full ROM. Configuration changes are only minor and do not impact disk applications. The RomWBW build process generates a system update file along with the normal ROM image and can be identified by the extension \u201c.upd\u201d. It will be 128Kb in size. In comparison the normal ROM image will have the extension \u201c.rom\u201d and be 512Kb or 1024Kb in size. Transferring and flashing the System Update is accomplished in the same manner as described above in Upgrading via Flash Utility with the required difference being that the flash application needs to be directed to complete a partial flash using the /P command line switch. E>FLASH WRITE ROM.UPD /P","title":"System Update"}]}
\ No newline at end of file
+{"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 &amp; 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 <u> [<c>] - Set Console Interface/Baud code V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 <drv> = ASSIGN ASSIGN [ <drv> ],... ASSIGN <drv> =[ <device> :[ <slice> ]],... ASSIGN <tgtdrv> = <srcdrv> ,... ASSIGN /B='*'<option>'*'['*'<option>'*'['*'<option>'*'...]] 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 <drv> will display the assignment for the specific drive For example, ASSIGN C: will display the assignment for drive C:. ASSIGN <drv> = <device> [: <slice> ] 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 <drv> = 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 <tgtdrv> = <srcdrv> 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= <option><option> \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 [ \\<filename> ] 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 <drv> Usage CLRDIR <drv> 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 [ <speed> [,[ <memws> ][,[ <iows> ]]] CPUSPD (W)armBoot CPUSPD (C)oldBoot <speed> is one of (H)alf, (F)ull, (D)ouble, or (Q)uad. <memws> is a number specifying the desired memory wait states. <iows> 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 \\<disk>.\\<unit> format. The syntax (similar to copy) for the command is: COPYSL \\<destunit> [ . \\<slice> ] = \\<srcunit> [ . \\<slice> ] [ / \\<options> ] 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 <path> FAT COPY <src> <dst> FAT REN <from> <to> FAT DEL <path>[<file>|<dir>] FAT MD <path> FAT FORMAT <drv> <path> is a FAT path <src> , <dst> are FAT or CP/M filenames <from> , <to> are FAT filenames <file> is a FAT filename <dir> is a FAT directory name <drv> is a RomWBW disk unit number CP/M filespec: <d> :FILENAME.EXT ( <d> is CP/M drive letter A-P) FAT filespec: <u> :/DIR/FILENAME.EXT ( <u> 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 <filename> [options] FLASH VERIFY <filename> [options] FLASH WRITE <filename> [options] <filename> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/P] /? displays command usage and version information <n> is the character device unit number <baud> is numerical baudrate <parity> is (N)one, (O)dd, (E)ven, (M)ark, or (S)pace <databits> is number of data bits, typically 7 or 8 <stopbits> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/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 <dest> = <src> <dest> is the drive to receive the operating system image or alternatively a filename to save the operating system image <src> is the drive containing an operating system image or alternatively a filename containing the system image to be placed on the destination Usage Both <dest> and <src> 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 [ \\<filename> ] 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 <filename> * * <filename> 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 <filename> <filename> 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 <hr> <min> WDATE <hr> <min> <sec> WDATE <year> <month> <day> <hr> <min> <sec> 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 <filename> XM SK <filename> XM L <library> <filename> XM LK <library> <filename> XM R <filename> 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 <filename> is the name of a file to send or receive <library> 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 \\<mode>\\<protocol>\\<unit> [ \\<filename> ] where \\<mode> 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 \\<protocol> can be: X - Xmodem 128 byte blocks (CRC) C - Xmodem 128 byte blocks (Checksum) K - Ymodem 1024 byte blocks (CRC only) and \\<unit> 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 [\\<unit>] \\<unit> 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 \\<unit> 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 <u> [<c>] - Set Console Interface/Baud code V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 &amp; 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 <drv> = ASSIGN ASSIGN [ <drv> ],... ASSIGN <drv> =[ <device> :[ <slice> ]],... ASSIGN <tgtdrv> = <srcdrv> ,... ASSIGN /B='*'<option>'*'['*'<option>'*'['*'<option>'*'...]]","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 <drv> will display the assignment for the specific drive For example, ASSIGN C: will display the assignment for drive C:. ASSIGN <drv> = <device> [: <slice> ] 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 <drv> = 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 <tgtdrv> = <srcdrv> 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= <option><option> \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 [ \\<filename> ]","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 <drv>","title":"Syntax"},{"location":"Applications/#usage_3","text":"CLRDIR <drv> 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 [ <speed> [,[ <memws> ][,[ <iows> ]]] CPUSPD (W)armBoot CPUSPD (C)oldBoot <speed> is one of (H)alf, (F)ull, (D)ouble, or (Q)uad. <memws> is a number specifying the desired memory wait states. <iows> 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 \\<disk>.\\<unit> format. The syntax (similar to copy) for the command is: COPYSL \\<destunit> [ . \\<slice> ] = \\<srcunit> [ . \\<slice> ] [ / \\<options> ] 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 <path> FAT COPY <src> <dst> FAT REN <from> <to> FAT DEL <path>[<file>|<dir>] FAT MD <path> FAT FORMAT <drv> <path> is a FAT path <src> , <dst> are FAT or CP/M filenames <from> , <to> are FAT filenames <file> is a FAT filename <dir> is a FAT directory name <drv> is a RomWBW disk unit number CP/M filespec: <d> :FILENAME.EXT ( <d> is CP/M drive letter A-P) FAT filespec: <u> :/DIR/FILENAME.EXT ( <u> 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 <filename> [options] FLASH VERIFY <filename> [options] FLASH WRITE <filename> [options] <filename> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/P] /? displays command usage and version information <n> is the character device unit number <baud> is numerical baudrate <parity> is (N)one, (O)dd, (E)ven, (M)ark, or (S)pace <databits> is number of data bits, typically 7 or 8 <stopbits> 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 <n> : [ <baud> [, <parity> [, <databits> [, <stopbits> ]]]] [/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 <dest> = <src> <dest> is the drive to receive the operating system image or alternatively a filename to save the operating system image <src> 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 <dest> and <src> 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 [ \\<filename> ]","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 <filename> * * <filename> 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 <filename> <filename> 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 <hr> <min> WDATE <hr> <min> <sec> WDATE <year> <month> <day> <hr> <min> <sec>","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 <filename> XM SK <filename> XM L <library> <filename> XM LK <library> <filename> XM R <filename> 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 <filename> is the name of a file to send or receive <library> 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 \\<mode>\\<protocol>\\<unit> [ \\<filename> ] where \\<mode> 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 \\<protocol> can be: X - Xmodem 128 byte blocks (CRC) C - Xmodem 128 byte blocks (Checksum) K - Ymodem 1024 byte blocks (CRC only) and \\<unit> 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 [\\<unit>] \\<unit> 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 \\<unit> 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 &amp; 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 \\<Reserved> 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 \\<Reserved> 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 <enter> for help. You can type L <enter> 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 \\<enter> . For example, typing H<enter> will display a short command summary: Boot [H=Help]: h L - List ROM Applications D - Device Inventory R - Reboot System W - RomWBW Configure I <u> [<c>] - Set Console Interface/Baud Rate V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 ( \\<diskunit> ) and optionally a dot followed by a second number ( \\<slice> ). The \\<disk unit> 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 \\<slice> 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 \\<enter> . Boot [H=Help]: 4 Booting Disk Unit 4, Slice 0, Sector 0x00000800... Volume \"Unlabelled\" [0xD000-0xFE00, entry @ 0xE600]... CBIOS v3.1.1-pre.194 [WBW] Formatting RAMDISK... Configuring Drives... A:=IDE0:0 B:=MD0:0 C:=MD1:0 D:=FD0:0 E:=FD1:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 I:=PRPSD0:0 J:=PRPSD0:1 K:=PRPSD0:2 L:=PRPSD0:3 1081 Disk Buffer Bytes Free CP/M-80 v2.2, 54.0K TPA A> Notice that a list of drive letters and their assignments to RomWBW devices and slices is displayed during the initialization of the operating system. Here is another example where we are booting disk unit 4, slice 3 which is the CP/M 3 operating system on this disk: Boot [H=Help]: 4.3 Booting Disk Unit 4, Slice 3, Sector 0x0000C800... Volume \"Unlabelled\" [0x0100-0x1000, entry @ 0x0100]... CP/M V3.0 Loader Copyright (C) 1998, Caldera Inc. BNKBIOS3 SPR F600 0800 BNKBIOS3 SPR 4500 3B00 RESBDOS3 SPR F000 0600 BNKBDOS3 SPR 1700 2E00 60K TPA CP/M v3.0 [BANKED] for HBIOS v3.5 A> Some operating systems (such as CP/M 3 shown above) do not list the drive assignments during initialization. In this case, you can use the ASSIGN command to display the current assignments. The Boot Loader simply launches whatever is in the disk unit/slice you have specified. It does not know what operating system is at that location. The layout of operating systems on disk media is described in the Disk Images section of this document. Auto-Submit Batch Files All of the operating systems supplied with RomWBW have the ability to execute a \u201cbatch\u201d of commands by creating a batch submission file containing the commands to be executed. The mechanism for running commands automatically at startup varies by operating system. In some cases, it was built into the original operating system. In other cases, I have added this capability in the RomWBW BIOS of the operating system. In all cases, the file containing the commands to run at startup must be on the boot drive (A:). RomWBW automatically assigns A: to the disk slice you choose to boot. Adding a startup command file to the ROM Disk is not recommended because it would require customizing and building a new ROM. Use of bootable disk slices is preferred since the startup command files can be added/edited without any special system customization. Here is an overview for each operating system: CP/M 2.2 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Note that original CP/M 2.2 itself did not have this ability \u2013 it was added to the RomWBW CP/M 2.2 BIOS. The use of SUBMIT files is documented in Section 1.6.7 SUBMIT Command of the CPM Manual included in the Doc/CPM folder of the RomWBW distribution. Z-System (ZSDOS 1.1) - Will run run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Works exactly the same as CP/M 2.2. The original Z-System ZSDOS 1.1 did not have this ability \u2013 it was added to the RomWBW Z-System BIOS. The Z-System documentation does not cover the use of SUBMIT files \u2013 please refer to the CP/M 2.2 documentation. NZCOM - Will run the command STARTZCM at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the NZCOM Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the NZCOM boot process. Note that NZCOM itself is launched from ZSDOS via the included PROFILE.SUB file. CP/M 3 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. This mechanism is built into the CP/M 3 operating system. Please see Section 4.5 Executing Multiple Commands and Section 5.2.74 Executing the SUBMIT Command of the CPM3 Users Guide included in the Doc/CPM folder of the RomWBW distribution. Z3PLUS - Will run the command STARTZ3P at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the Z3PLUS Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the Z3PLUS boot process. Note that Z3PLUS itself is launched from CP/M 3 via the included PROFILE.SUB file. ZPM3 - Will run the command STARTZPM at startup. This is normally an alias file. You use SALIAS to edit such files. ZPM3 has no real documentation. The NZCOM documentation of STARTZCM is generally correct for ZPM3. Since RomWBW can utilize many disk slices, it is very easy to create slices for specific workflows (editing, software development, games, etc.). You can then just boot to the slice that is optimized for the task you want to perform. Each such slice may have its own startup command batch file that customizes the environment for the specific workflow desired. System Management Listing Device Inventory The device units available in your system are listed in the boot messages. However, if that list has scrolled off of your screen, you can use the \u2018D\u2019 command to display a list of them at any time from the Boot Loader prompt. Unit Device Type Capacity/Mode ---------- ---------- ---------------- -------------------- Char 0 ASCI0: RS-232 38400,8,N,1 Char 1 ASCI1: RS-232 38400,8,N,1 Char 2 UART0: RS-232 38400,8,N,1 Char 3 UART1: RS-232 38400,8,N,1 Char 4 UART2: RS-232 38400,8,N,1 Char 5 UART3: RS-232 38400,8,N,1 Char 6 TERM0: Terminal Video 0,ANSI Char 7 PRPCON0: Terminal Term Module,ANSI Disk 0 MD0: RAM Disk 352KB,LBA Disk 1 MD1: Flash Drive 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 IDE2: CompactFlash 3823MB,LBA Disk 7 IDE3: Hard Disk -- Disk 8 IDE4: Hard Disk -- Disk 9 IDE5: Hard Disk -- Disk 10 SD0: SD Card -- Disk 11 PRPSD0: SD Card 15193MB,LBA Video 0 TMS0: CRT Text,40x24 Sound 0 SND0: AY-3-8910 3+1 CHANNELS Rebooting the System The \u2018R\u2019 command within the Boot Loader performs a software reset of the system. The system will perform a startup just like powering up or pressing the hardware reset button (although the hardware is not physically reset). There is generally no need to do this, but it can be convenient when you want to see the boot messages again or ensure your system is in a clean state. Boot [H=Help]: r Restarting System... Setting NVRAM Options On systems with RTC devices (that have Non-Volatile RAM), RomWBW supports storing some limited configuration option options inside this NVRAM. Several configuration options are currently supported, these are known as Switches Specify Automatic boot at startup, after an optional delay (AB) Define the Disk or ROM App to be booted at for automatic boot (BO) RomWBW uses bytes located at the start of RTC NVRAM, and includes a checksum of the bytes in NVRAM to check for integrity before using the configuration. Initially NVRAM has to be reset (with default values), before it can be used. As well as setting defaults, it also writes the correct checksum, and allows the NVRAM to be accessed and to store the RomWBW config. This is an explicit step that must be done, as any existing data stored is overwritten. If you are using NVRAM for other purposes, then you can continue to do so so long as you do NOT perform this Reset step. NVRAM may also need to be reset in these circumstances: When there has been a loss of power to the NVRAM. When upgrading to a new RomWBW version, or a RomWBW version that has new switches. If the NVRAM has been overwritten by another application. If you want to continue to use NVRAM in your applications you may want to consider storing your data above the RomWBW Switch data. To configure these options an inbuilt ROM application is provided which can be accessed by the command \u201c W \u201d from the RomWBW boot menu. This application is also built as a CP/M utility, but is not included on an disk image, it is found in the Binary/Applications folder of the RomWBW distribution. For further guidance on using this application please see the section \u201cRomWBW System Configuration\u201d in the RomWBW Applications document. If your system has both a Front Panel as well as NVRAM, be aware that the Front Panel switches take precedence over the NVRAM configuration settings. Note that the WizNet class of Network devices also contain NVRAM which is entirely separate from the RomWBW configuration NVRAM described here. A separate utility is used to set the WizNet NVRAM (see CP/NET Client Setup ). RomWBW Applications Changing Console and Console Speed Your system can support a number of devices for the console. They may be VDU type devices or serial devices. If you want to change which device is the console, the I menu option can be used to choose the unit and its speed. The command format is I <unit> [<baudrate>] where \\<unit> is the character unit to select and \\<baudrate> is the optional baud rate. Supported baud rates are: 75 450 1800 7200 38400 115200 460800 1843200 150 600 2400 9600 28800 153600 614400 2457600 225 900 3600 14400 57600 230400 921600 3686400 300 1200 4800 19200 76800 307200 1228800 7372800 Here is an example of changing the console to unit #1 (the second serial port) and switching the port to 9600 baud: Boot [H=Help]: i 1 9600 Change speed now. Press a key to resume. Console on Unit #1 At this point, the Boot Loader prompt will be displayed on character unit #1. Note that not all character devices support changing baud rates and some only support a limited subset of the baud rates listed. If you attempt to select an invalid baud rate for your system, you will get an error message. HBIOS Diagnostic Verbosity The \u2018V\u2019 command of the Boot Loader allows you to view and optionally change the level of diagnostic messages that RomWBW will produce. The normal verbosity level is 4, which means to display only fatal errors. You can increase this level to see more warnings when function calls to RomWBW HBIOS detect problems. The use of diagnostic levels above 4 are really intended only for software developers. I do not recommend changing this under normal circumstances. Console Takeover If your system has more than one character unit, then the Boot Loader will \u201cpoll\u201d all of the character devices for a request to make any of the alternate character devices the active console. This is called a console takeover request. This functionality must be enabled in the ROM build configuration, but currently it is for all standard ROMs. To request a console takeover, you just press the \\<space> character twice in a row at the port or terminal that you want to move the console to. The terminal or communication software must be configured for the default serial port speed and data bits for this to work. A takeover request is only possible while the active console is showing the Boot Loader prompt prior to typing any characters at the active console. In other words, once you start typing at the active console prompt, the takeover polling is suspended. If you have started typing characters, you can press \\<enter> at the active console to get a fresh Boot Loader prompt and reactivate the polling. If you have built a custom ROM that includes an automatic boot command with a timeout, then performing a console takeover will abort the timeout process and the automatic boot command will not be performed. Front Panel RomWBW supports the concept of a simple front panel. The following image is a conceptual view of such a front panel. If your system has a front panel, it should look similar to the RomWBW Front Panel . RomWBW Front Panel The LEDs in the top row of the panel are used for multiple purposes. They are initially used to display the progress of the system boot. This may help in diagnosing a hardware or configuration issue in a system that does not progress far enough to display text output on the console. The meaning of the LEDs is: O------- System Boot has started OO------ Common RAM bank activated OOO----- HBIOS transitioned to RAM OOOO---- Basic initialization done OOOOO--- CPU detection complete OOOOOO-- System timer configured OOOOOOO- Pre-console device init done OOOOOOOO Console activation Once the system has booted, the LEDs are used to indicate disk device activity. Each LED numbered 7-0 represents disk units 7-0. As each disk device performs I/O, the LED will light while the disk is active. This is only possible for the first 8 disk units. The second row of the front panel is composed of switches that allow you to control a few aspects of the system startup. The switches are also re-read during warm boot, so confirm the switch settings are your desired boot configuration before executing \u2018REBOOT /W\u2019. The first two switches affect the device used as the initial console. CRT/Serial Sec/Pri Explanation CRT Pri Primary Cathode Ray Tube device (high speed console) CRT Sec Secondary Cathode Ray Tube device (high speed console) Serial Pri Boot Console is Primary Serial Port Serial Sec Boot Console is Secondary Serial Port If not available (default): \u201cChar Unit 0\u201d is used The final six switches allow you to select the desired boot device. Auto / Menu Disk / ROM Floppy / Hard ROM/App/Boot Slice 4 2 1 Explanation Menu \u2013 \u2013 \u2013 \u2013 \u2013 Boot to RomWBW Menu Auto Disk Floppy # # # Boot Selected Floppy Disk Index Auto Disk Hard # # # Boot Selected Hard Disk Index Auto ROM \u2013 # # # Boot selected ROM Index If not available: Boot Loader Command Prompt \u2018\u2013\u2019 Ignored \u2018#\u2019 bit flag to select any three bits 4,2,1 ROM or Hard Disk - First 8 Drive Images 4 2 1 Floppy / Hard Drive Index ROM Index 0 0 0 Zero Monitor 0 0 1 One BASIC 0 2 0 Two Forth 0 2 1 Three Game 4 0 0 Four CP/M 4 0 1 Five Z-System 4 2 0 Six Net Boot 4 2 1 Seven User Disk Management The systems supported by RomWBW all have the ability to use persistent disk media. Some systems have disk interfaces built-in, while others will require add-in cards. You will need to refer to the documentation for your system for your specific options. The RomWBW firmware provides a hardware abstraction layer, All disks will work on all hardware variations. This means you can remove disk media from one RomWBW system and put it in a different RomWBW system. The only constraint is that the applications on the disk media must be up to date with the firmware on the system being used. Key Terminology/Concepts The following important terminology applies Disk (or Disk Drive) The hardware storage device that RomWBW talks to. RomWBW supports a variety of storage disk device types. ROM Disk - RomWBW firmware - containing CPM utilities RAM Disk - A section of system RAM initially empty Floppy Disk(s) - Removable media Hard Disk(s) - Includes CF Cards, SD Cards, USB Stick, etc. The different disk types are further defined in the section Disk Types . Media The storage device inserted into a disk drive, e.g. a floppy disk, CF Card, SD Card, etc. Slice For hard disks a Slice is a smaller logical block of disk space that is allocated and formatted with a filesystem and typically allocated to a Drive letter. Slices allow large modern storage media to be sliced up into smaller units compatible with CP/M. Slices should not be confused with partitions, a slice is not a partition. The concept of slices is described in detail in the section Hard Disk Slices . Drive The mapping of a hardware disk (and slice) to a Drive letter in an operating system. A Drive has a file system installed on it Disk Image A disk image is a predefined image of a complete CP/M filesystem, or filesystem(s), including any partition tables (for hard disk images). Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. This comes in for form of a file which is suitable for copying directly onto target media, using a modern computer. It is generally easier to use these disk images than transferring files over individually. See the section Disk Images for further details. Startup Hardware Discovery During startup RomWBW performs detection for hardware supported by your platform. During startup you will see messages for any disk interface(s), listing device types (e.g. FD:, IDE:, SD:), and any media that has been found on these interfaces. The messages you see will vary depending on your hardware and the media you have installed. As an example, here are the messages you might see if you have an IDE interface in your system with a single disk drive connected to the primary side of the interface: IDE: IO=0x80 MODE=MK4 IDE0: 8-BIT LBA BLOCKS=0x00773800 SIZE=3815MB IDE1: NO MEDIA See RomWBW Hardware for a complete list of the different device types supported. If you do not see drive letters assigned as expected, refer to the prior system boot messages to ensure media has been detected in the interface. Each drive letter refers back to a specific disk hardware interface like IDE0. This is important as it is telling you what each drive letter refers to. Mass storage disks (like IDE) will normally have multiple drive letters assigned. The extra drive letters refer to additional \u201cslices\u201d on the disk. Once your system has working disk devices, they will be accessible from any operating system you choose to run. Disk storage is available whether you boot your OS from ROM or from the disk media itself. Drive Letter Assignment In legacy CP/M operating systems only 16 drive letters (A:-P:) available to be assigned to disks Drive letters were generally mapped to disk drives in a completely fixed way. For example, drive A: would always refer to the first floppy disk drive. RomWBW implements a much more flexible drive letter assignment mechanism so that any drive letter can dynamically be assigned to any disk device, or slice of media. For clarification, CP/M cannot refer directly to disk devices, CP/M only understands drive letters, so to access a given disk device it must first be assigned to a drive letter. As the operating system starts up, you should see a list of drive letters assigned to the disk media you have installed. Here is an example of the list of drive letter assignments made during the startup of Z-System: Configuring Drives... A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 Above you can see that: Drive A: has been assigned to MD0 which is the RAM disk device. Drive B: has been assigned to MD1 which is the ROM disk device. Drives C: and D: have been assigned to floppy disk drives. Drives E: thru H: have been assigned to the IDE0 hard disk device. The 4 entries for IDE0 are referring to the first 4 slices on that disk. CP/M 3 and ZPM3 do not automatically display the assignments at startup, but you can use ASSIGN to display them. The assignments at boot will stay the same on each boot as long as you do not make changes to your hardware configuration. i.e. If you insert or remove an SD Card, CF Card or USB Stick, the drive assignments will change at next boot. Since drive letter assignments can change, you must be careful when doing destructive things like using CLRDIR to make sure the drive letter you use is referring to the desired media. Drive assignments can be changed at any time, by the ASSIGN command. Please see the section Assign Drive Letters for further details. Default Drive Letters When an operating system is booted, RomWBW will automatically assign drive letters to disk devices. The assignment process varies depending on: the disk/slice you choose to boot from, and the number, type, and sizes of mass storage devices available at boot The A: drive letter is considered special by most CP/M operating systems and is automatically used in some cases. e.g. submitting batch files, and is expected to be a writable volume. If you boot to a physical disk device, then the first drive letter (A:) will be assigned to the disk/slice that you are booting from, and the rest of the drive letters will be offset to accommodate this. By making the selected disk/slice the A: drive, you can setup different disks/slices for specific uses and just boot it, and the booted operating system will be the A: drive However when performing a ROM boot of an operating system, the first two drive letters will be assigned to your RAM disk (A:) and your ROM disk (B:). This provides the maximum compatibility with CP/M. After the first drive letter is assigned (as well as the second drive letter in the case of a ROM boot), RomWBW will assign additional drive letters based on the disk drives in the system. Additional drive letters will be assigned in the following order: RAM Disk ROM Disk Floppy Disk(s) Hard Disk(s) If a disk/slice was already assigned as the A: (or B:) drive letter, then it will not be assigned again. Floppy or removable disk drives will be assigned a drive letter regardless of whether there is any media inserted at the time of boot. In the case of hard disks, 1-8 drive letters will be assigned to the initial 1-8 slices of the disk drive. The number of drive letters assigned to each hard disk depends on the number of hard disks in the system: 1 Hard Disk: 8 drive letters (slices) 2 Hard Disks: 4 drive letters (slices) per disk 3+ Hard Disks: 2 drive letters (slices) per disk This somewhat complicated algorithm is used to try and maximize the limited number of operating system drive letters available (16) to the available disk devices as evenly as possible. For hard disk devices which are treated as non-removable media, drive letters will only be assigned to disk devices that actually contain media. i.e. No drive letters will be assigned to an SD Card slot that has no SD Card inserted. Assign Drive Letters The ASSIGN command is used to view or change the current drive letter mappings. Any changes made to drive letter mappings take immediate effect Refer to RomWBW Applications for more information on use of the ASSIGN command. Since drive letter assignments are easily changed at any time using the ASSIGN command, you can customize your assignments as desired after starting the operating system. Even better, you can use an auto-submit batch file to customzie the assignments at startup without any user intervention. Disk Operations/Commands With some understanding of how RomWBW presents disk space to the operating systems, we need to go over the options for actually setting up your disk(s) with content. Preparing Media for First Use You can initialize the media in-place using your RomWBW system. Essentially, this means you are creating a set of blank directories on your disk so that files can be saved there. This is somewhat analogous to partitioning of a hard disk or doing a low level format of a floppy disk. Initilizing a Floppy disk is covered in the section Floppy Disk Formatting , or for a Hard disk the section Hard Disk Preparation covers the steps to manually setup a hard disk for first use. Clearing (Formatting) Drives This is somewhat analogous to doing a FORMAT operation on other systems. With RomWBW you use the CLRDIR command to do this. This command is merely \u201cclearing out\u201d the directory space of the drive referred to by a drive letter and setting up the new empty directory. Refer to RomWBW Applications for more information on use of the CLRDIR command. Since CLRDIR works on drive letters, make absolutely sure you know what media and slice are assigned to that drive letter before using CLRDIR because CLRDIR will wipe out any pre-existing contents of the slice. After CLRDIR completes, the slice should be ready to use by the operating system via the drive letter assigned. Start by using the DIR command on the drive. This should return without error, but list no files. Here is an example of using CLRDIR . In this example, the ASSIGN command is used to show the current drive letter assignments. Then the CLRDIR command is used to initialize the directory of drive \u2018G\u2019 which is slice 2 of hard disk device IDE0 (\u201cIDE0:2\u201d). B>ASSIGN A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 B>CLDIR G: CLRDIR Version 1.2B May 2024 by Max Scane Warning - this utility will overwrite the directory sectors of Drive: G Type CAPITAL Y to proceed, any key other key to exit. Y Directory cleared. B> Checking Disk Layout If you are not sure which disk layout is used for your existing media, you can use the CP/M 2.2 STAT command to display information including the number of \u201c32 Byte Directory Entries\u201d for a drive letter on the corresponding hard disk. If it indicates 512, your disk layout is legacy (hd512). If it indicates 1024, your disk layout is modern (hd1k). Here is an example of checking the disk layout. B>STAT E:DSK: E: Drive Characteristics 65408: 128 Byte Record Capacity 8176: Kilobyte Drive Capacity 1024: 32 Byte Directory Entries 0: Checked Directory Entries 256: Records/ Extent 32: Records/ Block 64: Sectors/ Track 2: Reserved Tracks It is critical that you include DSK: after the drive letter in the STAT command line. The important line to look at is labeled \u201c32 Byte Directory Entries\u201d. Disk Types RAM & ROM Disks A typical RomWBW system has 512KB of ROM and 512KB of RAM. Some portions of each are dedicated to loading and running applications and operating system. The space left over is available for an operating system to use as a pseudo-disk device (ROM Disk and RAM Disk). Unlike other types of disk devices, ROM and RAM Disks do not contain an actual operating system and are not \u201cbootable\u201d. However, they are accessible to any operating system (whether the operating system is loaded from ROM or a different disk device). Neither RAM nor ROM disks require explicit formatting or initialization. ROM disks are pre-formatted and RAM disks are formatted automatically with an empty directory when first used. RAM Disk The RAM disk provides a small CP/M filesystem that you can use for the temporary storage of files. Unless your system has a battery backed mechanism for persisting your RAM contents, the RAM disk contents will be lost at each power-off. The RAM disk is an excellent choice for storing temporary files because it is very fast. You will notice that the first time an operating system is started after the power was turned off, you will see a message indicating that the RAM disk is being formatted. If you reset your system without turning off power, the RAM disk will not be reformatted and it\u2019s contents will still be intact. ROM Disk Like the RAM disk, the ROM disk also provides a small CP/M filesystem, but it\u2019s contents are static \u2013 they are part of the ROM. As such, you cannot save files to the ROM disk. Any attempt to do this will result in a disk I/O error. The contents of the ROM disk have been chosen to provide a core set of tools and applications that are helpful for either CP/M 2.2 or ZSDOS. Since ZSDOS is CP/M 2.2 compatible, this works fairly well. However, you will find some files on the ROM disk that will work with ZSDOS, but will not work on CP/M 2.2. For example, LDDS , which loads the ZSDOS date/time stamper will only run under ZSDOS. Flash ROM Disks The limitation of ROM disks being read-only can be overcome on some platforms with the appropriate selection of Flash ROM chip and system configuration. In this case the flash-file system can be enabled which will allow the ROM disk to be read and written to. Flash devices have a limited write lifespan and continual usage will eventually wear out the device. It is not suited for high usage applications. Enabling ROM disk writing requires building a custom ROM. Floppy Disks If your system has the appropriate hardware, RomWBW will support the use of floppy disks. The supported floppy disk formats are generally derived from the IBM PC floppy disk formats: 5.25\u201d 360K Double-sided, Double-density 5.25\u201d 1.2M Double-sided, High-density 3.5\u201d 720K Double-sided, Double-density 3.5\u201d 1.44M Double-sided, High-density When supported, RomWBW is normally configured for 2 3.5\u201d floppy disk drives. If a high-density disk drive is used, then RomWBW automatically detects and adapts to double-density or high-density media. It cannot automatically detect 3.5\u201d vs. 5.25\u201d disk drive types \u2013 the ROM must be pre-configured for the disk drive type. WARNING: Some of the operating systems provided with RomWBW require that a soft-reset be performed when swapping floppy disk media. For example, under CP/M 2.2, you must press control-C at the CP/M prompt after inserting a new floppy disk. The consequences of failing to perform the soft-reset vary from unexpected error messages to full disk directory corruption. Hard Disks The concept of a hard disk in RomWBW applies to any storage device that provides at least 8MB of space. The actual media can be a real spinning hard disk, a CompactFlash Card, a SD Card, etc. In this document, the term hard disk will apply equally to all of these. The vintage operating systems included with RomWBW were produced at a time when mass storage devices were quite small. CP/M 2.2 could only handle filesystems up to 8MB. Since storage devices today are quite large, RomWBW implements a mechanism called slicing (see Hard Disk Slices ) to allow up to 256 8MB CP/M filesystems on a single large storage device, where each slice can be assigned to a drive letter in CPM, and be treated as its own hard disk drive (from a CPM perspective). In order to achieve compatibility across all of the operating systems supported by RomWBW, the hard disk filesystem format used is 8MB. This ensures any filesystem will be accessible to any of the operating systems. RomWBW uses Logical Block Addressing (LBA) to interact with all hard disks. The RomWBW operating systems use older Cylinder/Head/Sector (CHS) addressing. To accommodate the operating systems, RomWBW emulates CHS addressing. Specifically, it makes all hard disks look like they have 16 sectors and 16 heads. The number of tracks varies with the size of the physical hard disk. Hard Disk Layouts When RomWBW uses a hard disk, it utilizes an area of the physical hard disk drive space to store a sequential series of slices that contain the actual CP/M filesystems referred to by drive letters by the operating system. Two hard disk layout schemes exist: Modern (hd1k) Legacy (hd512) You cannot mix disk layouts on a single disk device, however It is perfectly fine for one system to have multiple hard disks with different layouts \u2013 each physical disk device is handled separately. If you are setting up a new disk, the modern (hd1k) layout is recommended for the following reasons: Larger number of directory entries per filesystem Simplifies creation of coresident FAT filesystem Reduces chances of data corruption Each slice occupies exactly 8MB (an exact power of 2) in size Both the legacy and modern disk layouts continue to be fully supported by RomWBW. There are no plans to deprecate the legacy layout. Modern Layout RomWBW (Starting with v3.2) supports the use of disk partitioning, utilising a Master Boot Record (MBR) partition tables. The Wikipedia article on the Master Boot Record is excellent if you are not familiar with them. RomWBW uses the partition type id 0x2E . This partition type id does not equate to any existing well-known partition types \u2013 it was chosen because it is not generally used. RomWBW does not support extended partitions \u2013 only a single primary partition can be used. The existence of a partition table entry for RomWBW on a hard disk makes it behave in the modern mode. Removing the RomWBW partition entry from a modern hard disk layout will cause the existing data to be unavailable and/or corrupted The CP/M filesystem in the slices of the modern disk layout contain 1024 directory entries. Legacy Layout Originally, RomWBW always used the very start of the hard disk media for the location of the slices. In this layout, slice 0 referred to the first chunk of ~8MB on the disk, slice 1 referred to the second chunk of ~8MB on the disk, and so on. The number of slices is limited to the size of the disk media \u2013 if you attempted to read/write to a slice that would exceed the disk size, you would see I/O errors. The legacy format takes steps to allow a partition table to still be used for other types of filesystems such as DOS/FAT. It just does not use a partition table entry to determine the start of the RomWBW slices. The lack of a RomWBW partition table entry will cause legacy behaviour. Adding a partition table entry on an existing legacy RomWBW hard disk will cause the existing data to be unavailable and/or corrupted. The CP/M filesystem in the slices of the legacy disk layout contain 512 directory entries. Hard Disk Slices RomWBW implements a mechanism called slicing to allow multiple CP/M filesystem on a single large storage device. To say it another way, the media is \u201csliced up\u201d into many CP/M filesystems. You cannot use slices on any media less than 8MB in size. Specifically, you cannot slice RAM disks, ROM disks, floppy disks, etc. All of these are considered to have a single slice (0) It is very important to understand that RomWBW slices are not individually created or allocated on your hard disk. RomWBW uses a single partition on your hard disk to contain the slices. You should think of slices as just an index into a sequential set of 8MB areas that exist in this partition. RomWBW allows up to up to 256 slices each of 8MB in size on a single large storage device. This allows the use of up to 2GB of usable space on one media device. It is possible to create other partitions (typically FAT), for now, we are just talking about the slices within the single RomWBW partition. Slice Assignment When assigning Hard disks to drive letters you also need to assign the slice. Referring to slices within a storage device is done by appending a :<n> where \\<n> is the device relative slice number from 0-255. For example, if you have an IDE device, it will show up as IDE0: in the boot messages meaning the first IDE device. To refer to the fourth slice of IDE0, you would type \u201cIDE0:3\u201d. Here are some examples: IDE0:0 First slice of disk in IDE0 IDE0: First slice of disk in IDE0 IDE0:3 Fourth slice of disk in IDE0 So, if you wanted to use drive letter L: to refer to the fourth slice of IDE0, you could use the command ASSIGN L:=IDE0:3 . There are a couple of rules to be aware of when assigning drive letters. First, you may only refer to a specific device/slice with one drive letter at a time. Said another way, you cannot have multiple drive letters referring to a the same device/slice at the same time. Second, there must always be a drive assigned to A:. Any attempt to violate these rules will be blocked by the ASSIGN command. As you see, the name of a slice does not reference the hard disk partition containing the slices. Since there can only be a single RomWBW partition containing slices on any disk, the partition is determined automatically. RomWBW does not prevent you from assigning slices to drive letters even if the location of the slice does not fit on the physical disk. Any attempt to access a drive letter mapped to a slice that does not fit will result in an error such as \u201cno disk\u201d from the operating system. For example, a 64MB CF Card (which is typically a bit smaller than 64MB) will only fit 7 slices. At startup, you will typically see 8 drive letters assigned to the CF Card. Attempting to access the last drive letter will result in a \u201cno disk\u201d error from the operating system. Hard Disk Capacity The exact number of CP/M filesystem slices that will fit on your specific physical hard disk can be determined as follows: For modern (hd1k) disk layouts, it is 1024KB + (slices * 8192KB). Or equivalent to say 1MB + (slices * 8MB). For legacy (hd512) disk layouts, it is slices * 8,320KB. WARNING : In this document KB means 1024 bytes and MB means 1048576 bytes (frequently expressed as KiB and MiB in modern terminology). In general, hard disk capacities use KB to mean 1000 bytes and MB to mean 1,000,000 bytes. As an example, A \u201c64MB\u201d CF Card probably has less than 62.5MB of actual space (using the RomWBW definition that 1MB is 1048576 bytes). Such a drive will not support 8 slices. It will support 7 slices just fine because 1024KB + (7 * 8192MB) = 57MB (hd1k) or 7 * 8,320KB = 58.24MB (hd512) Although you can use up to 256 slices per physical disk, equating to 2GB of storage this large number of slices is rarely used. It is recommended that hard disk media used with RomWBW be 1GB or greater in capacity. This will support the RomWBW Combo Disk Image (see Combo Hard Disk Image ) that allows you to use 64 CP/M filesystem slices and a 384KB FAT filesystem. Disk Preparation There are two approaches to preparing disks for use by RomWBW. Manual : Use RomWBW itself to format empty disks and then transfer files over to the disks. Images : Use a modern computer to write a pre-built disk image including files to a disk. This section of the document describes the manual process of preparing empty disks that are ready for use by an operating system. Alternatively, you can use the pre-built RomWBW disk images to quickly create disk media that already has a large selection of files and bootable operating system slices. Using images to prepare a disk is documented in Disk Images . You do not need to follow the instructions in this section if you want to use disk images. Floppy Disk Formatting Floppy media must be physically formatted before it can be used. This is normally accomplished by using the supplied Floppy Disk Utility FDU application. This application interacts directly with your hardware and therefore you must specify your floppy interface hardware at application startup. Additionally, you need to specify the floppy disk drive and media format to use for formatting. Refer to RomWBW Applications for more information on use of the FDU command. Since the physical format of floppy media is the same as that used in a standard MS-DOS/Windows computer, you can also format floppy disk media in a standard computer. However there are caveats: The directory format itself will NOT be compatible with CP/M OSes. You WILL need to use the CLRDIR command to reformat the directory area from CP/M. See section Clearing (Formatting) Drives FDU allows you to specify physical sector interleaving (defaults to 2) which will result in faster floppy disk I/O. Formatting on a modern computer may not optimize this. Below is a sample session using FDU to format a 1.44M floppy disk in the first (primary) floppy disk drive: B>FDU Floppy Disk Utility (FDU) v5.8, 26-Jul-2021 [HBIOS] Copyright (C) 2021, Wayne Warthen, GNU GPL v3 SELECT FLOPPY DISK CONTROLLER: (A) Disk IO ECB Board (B) Disk IO 3 ECB Board (C) Zeta SBC Onboard FDC (D) Zeta 2 SBC Onboard FDC (E) Dual IDE ECB Board (F) N8 Onboard FDC (G) RCBus SMC (SMB) (H) RCBus WDC (SMB) (I) SmallZ80 Expansion (J) Dyno-Card FDC, D1030 (K) RCBus EPFDC (L) Multi-Board Computer FDC (X) Exit === OPTION ===> D-IDE ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=720KB DS/DD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> SETUP ENTER UNIT [00-03] (00): 00: 3.5\" 720KB - 9 SECTORS, 2 SIDES, 80 TRACKS, DOUBLE DENSITY 01: 3.5\" 1.44MB - 18 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 02: 5.25\" 320KB - 8 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 03: 5.25\" 360KB - 9 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 04: 5.25\" 1.2MB - 15 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 05: 8\" 1.11MB - 15 SECTORS, 2 SIDES, 77 TRACKS, DOUBLE DENSITY 06: 5.25\" 160KB - 8 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 07: 5.25\" 180KB - 9 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 08: 5.25\" 320KB - 8 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY 09: 5.25\" 360KB - 9 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY ENTER MEDIA [00-09] (00): 01 00: POLLING (RECOMMENDED) 01: INTERRUPT (!!! READ MANUAL !!!) 02: FAST INTERRUPT (!!! READ MANUAL !!!) 03: INT/WAIT (!!! READ MANUAL !!!) 04: DRQ/WAIT (!!! NOT YET IMPLEMENTED!!!) ENTER MODE [00-04] (00): ENTER TRACE LEVEL [00-01] (00): ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> FORMAT (T)RACK, (D)ISK ===> DISK ENTER INTERLEAVE [01-12] (02): RESET DRIVE... PROGRESS: TRACK=4F HEAD=01 SECTOR=01 ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> EXIT You can confirm a floppy disk is ready for content by simply running a DIR command on it. The DIR command should complete without error and should list no files. Hard Disk Preparation This section deals with initializing hard disk media entirely from your RomWBW system. The following instructions are one way to proceed. This does not mean to imply it is the only possible way. First you need to understand The disk layout approach (either hd1k or the legacy hd512). See Hard Disk Layouts section if you are not sure. hd1k should be the preferred layout. The number of 8MB slices that you want to allocate, preferred is 64 slices. At least 1 slice of 8MB is required If you want to leave space for a FAT partition. See FAT Filesystem Preparation The total capacity of your drive, to hold the CP/M (and other) partition(s) Then you will need to start by inserting the disk media, booting RomWBW, and confirming that the media is being recognized. If RomWBW recognizes the media, it will indicate this in the boot messages even though the media may not yet been prepared for use. Then launch either CP/M 2.2 or Z-System from ROM using the Boot Loader C or Z commands respectively. You can now use the tools on the ROM disk to prepare your disks. Note that you may see the operating system assign disks/slices to drives letters even though the disks/slices are not yet initialized. This is normal and does not mean the disks/slices are ready to use. Partition Setup To setup a partition you must run the FDISK80 utility. After FDISK80 starts, enter the disk unit number of the new media. The disk unit number was assigned at boot See Device Unit Assignments Refer to RomWBW Applications for more information on use of the FDISK80 utility. If you want to use the legacy hd512 layout skip down to the Legacy (hd512) section Modern (hd1k) At this point, use the I command to initialize (reset) the partition table to an empty state. You must create a partition for the RomWBW CP/M slices. Then create a partition using the N command. Importantly: The partition number should typically be 1 the first partition The partition can be placed anywhere you want, The typical location for the RomWBW partition is at 1MB. The partition size should be the total size of all the slices you require, and must be at least 8MB in size, in increments of 8MB makes sense. You must then set the type of partition to 2E using the T command. The P command can be used to display the partition before it is written Finally the partition can be written to disk using the W write command. WARNING : Modifying the partition table of existing media will make any data on the media inaccessible. Below is an example of creating a RomWBW partition following these guidelines. FDISK80 for RomWBW, UNA, Mini-M68k, KISS-68030, SBC-188 ---- Version 1.1-22 created 7-May-2020 (Running under RomWBW HBIOS) HBIOS unit number [0..11]: 4 Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 00 *** empty *** 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>i >>n New partition number: 1 Starting Cylinder (default 0): 1Mb Ending Cylinder (or Size= \"+nnn\"): +512Mb >>t Change type of partition number: 1 New type (in hex), \"L\" lists types: 2e >>p Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>w Do you really want to write to disk? [N/y]: y Okay FDISK exit. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again. Legacy (hd512) At this point, use the I command to initialize (reset) the partition table to an empty state. To use the hd512 layout, use W to write the empty table to the disk and exit. Remember that the lack of a partition for RomWBW implies the legacy (hd512) layout. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again. FAT Partition At this point you may want to consider creating a FAT partition Please see the section FAT Filesystem Preparation for detils on how to setup the FAT partition. Slice Initialization You need to initialize each slice for CP/M to use it. This is somewhat analogous to doing a FORMAT operation on other systems, and is done using the CLRDIR command. This is covered in the section Clearing (Formatting) Drives WARNING : Earlier versions of the CLRDIR application do not appear to check for disk errors when it runs. If you attempt to run CLRDIR on a drive that is mapped to a slice that does not actually fit on the physical disk, it may behave erratically. Assuming you want to use additional slices, you should initialize them using the same process. You may need to reassign drive letters to access some slices that are beyond the ones automatically assigned. You can use the ASSIGN command to handle this. Post Disk Preparation Once a disk (either floppy or hard disk) has been initialised and formattted you may optionally; * Make the disk bootable * Copy system (or other) files to the disk Making a Disk Bootable To make a disk bootable you will need to follow the specific instructions in Operating Systems , as each operating system will be different. Generally you will need to use SYSCOPY to setup the system track(s) of the disk.As an example, If you wanted to setup C: as a bootable Z-System disk you would use: B>SYSCOPY C:=B:ZSYS.SYS SYSCOPY v2.0 for RomWBW CP/M, 17-Feb-2020 (CP/M 2 Mode) Copyright 2020, Wayne Warthen, GNU GPL v3 Transfer system image from B:ZSYS.SYS to C: (Y/N)? Y Reading image... Writing image... Done Once this process succeeds, you will be able to boot directly to the disk slice from the boot loader prompt. See the instructions in Starting Operating Systems from Disk for details on this. Copying System Files As well as making the disk bootable, you may need to transfer other system and application files to your disks. Refer to Transferring Files for more information on getting files onto your disks. Disk Images Since it would be quite a bit of work to transfer over all the files you might want initially to your disk(s), It is generally easier to use these disk images than transferring your files over individually. RomWBW comes with a variety of ready to use disk images. You can use your modern Windows, Linux, or Mac computer to copy a disk image onto the disk media, then just move the media over to your RomWBW computer. The disk image files are found in the Binary directory of the distribution. Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. The following table shows the disk images available. Disk Image Description Boot xxx_aztec.img Aztec C Compiler No xxx_bascomp.img Microsoft Basic-80 Compiler No xxx_blank.img empty image No xxx_cowgol.img Cowgol 2.0 Compiler No xxx_cpm22.img DRI CP/M 2.2 Operating System Yes xxx_cpm3.img DRI CP/M 3 Operating System Yes xxx_dos65.img DOS/65 Operating System Yes xxx_fortran.img Microsoft Fortran-80 Compiler No xxx_games.img Games Disk for CP/M No xxx_hitechc.img HI-TECH Z80 CP/M C compiler No xxx_msxroms1.img MSX ROMs Disk 1 No xxx_msxroms2.img MSX ROMs Disk 2 No xxx_nzcom.img NZCOM ZCPR 3.4 Operating System Yes xxx_qpm.img QPM Operating System Yes xxx_tpascal.img Borland Turbo Pascal Compiler No xxx_ws4.img WordStar v4 & ZDE Applications No xxx_z80asm.img Relocating macro assembler for CP/M No xxx_zpm3.img ZPM3 Operating System Yes xxx_zsdos.img ZCPR-DJ & ZSDOS 1.1 Operating System Yes You will find 3 sets of these .img files in the distribution. The \u201cxxx\u201d portion of the filename will be: \u201cfd_\u201d for a floppy image. \u201chd1k_\u201d for a modern layout hard disk image. \u201chd512_\u201d for a legacy layout hard disk image. In the case of xxx_dos65.img, only an hd512 variant is provided. This is a constraint of the DOS65 distribution. There is also an image file called \u201cpsys.img\u201d which contains a bootable p-System hard disk image. It contains 6 p-System filesystem slices, but these are not interoperable with the CP/M slices described above. This file is discussed separately under UCSD p-System in Operating Systems section. Floppy Disk Images The floppy disk images are all intended to be used with 3.5\u201d high-density, double-sided 1.44 MB floppy disk media. This is ideal for the default floppy disk drive support included in RomWBW standard ROMs. For floppy disks, the .img file is written directly to the floppy media as is. The floppy .img files are 1.44 MB which is the exact size of a single 3.5\u201d high density floppy disk. You will need a floppy disk drive of the same type connected to your modern computer to write this image. Although modern computers do not come equipped with a floppy disk drive, you can still find USB floppy drives that work well for this. The floppy disk must be physically formatted before writing the image onto it. You can do this with RomWBW using FDU as described in the Floppy Disk Formatting section of this document. While you can also format the floppy using your modern computer, using FDU is preferable. RomWBW includes a Windows application called RawWriteWin in the Tools directory of the distribution. This simple application will let you choose a file and write it to an attached floppy disk drive. For Linux/MacOS, I think you can use the dd command (but I have not actually tried this). It is probably obvious, but writing an image to a floppy disk will overwrite and destroy all previous contents. Once the image has been written to the floppy disk, you can insert the floppy disk in your RomWBW floppy disk and read/write files on it according to the specific operating system instructions. If the image is bootable, then you will be able to boot from it by entering the floppy disk drive\u2019s corresponding unit number at the RomWBW Boot Loader command prompt. Hard Disk Images Keeping in mind that a RomWBW hard disk (including CF/SD/USB devices) allows you to have multiple slices (CP/M filesystems), there are a couple ways to image hard disk media. The easiest approach is to use the Combo Disk Image. This hard disk image is already prepared with 6 slices containing 5 ready-to-run OSes and a slice with the WordStar application files. Alternatively, you can create your own hard disk image with the specific slice contents you choose. Standard Hard Disk Layout As previously described in Hard Disk Layouts , the exact placement of slices and optional FAT partition will vary depending on which disk layout (hd512 or hd1k) you are using and your partition table entries. To simplify the use of hard disk images, RomWBW has adopted a standard partition layout for disk image files provided. This standard layout is used to produce the Combo Disk Images described below. These partition sizes and locations were chosen to: Fit entirely on 1GB media Allow for 64 CP/M filesystem slices Allow for a 384KB FAT filesystem The standard partition table table entries are: \u2014 Modern (hd1k) \u2014 \u2014 Legacy (hd512) \u2014 Byte(s) Sector(s) Byte(s) Sector(s) RomWBW Partition Start 1 MB 2,048 \u2013 \u2013 RomWBW Partition Size 512 MB 1,048,576 \u2013 \u2013 FAT Filesystem Start 513 MB 1,050,624 520 MB 1,064,960 FAT Filesystem Size 384 MB 786,432 384 MB 786,432 \\<end> 897 MB 1,851,392 904 MB 1,837,056 NOTE: RomWBW is not limited to these partition table entries. You can change the size and location of the RomWBW and/or FAT partitions to increase/decrease the number of slices or FAT filesystem size. Doing so would require using FDISK80 to define your own custom disk layout and initializing your filesystems manually. The RomWBW System Guide has more information on the standard disk layouts as implemented in the Combo Disk Images. Additionally, there is a document called \u201cHard Disk Anatomy.pdf\u201d in the Doc directory of the RomWBW distribution with detailed information on the standard disk layouts. Combo Hard Disk Image The Combo Disk Image is essentially just a single disk image that has several of the individual filesystem images (slices) already concatenated together using the standard disk layout described above. The Combo Disk Image includes the partition table of the standard disk layout and the following 6 slices in the positions indicated: Slice Description Slice 0 DRI CP/M 2.2 Operating System Slice 1 ZCPR-DJ & ZSDOS 1.1 Operating System Slice 2 NZCOM ZCPR 3.4 Operating System Slice 3 DRI CP/M 3 Operating System Slice 4 ZPM3 Operating System Slice 5 WordStar v4 & ZDE Applications Slice 6-63 blank unformatted There are actually 2 Combo Disk Images in the distribution. One for an hd512 disk layout (hd512_combo.img) and one for an hd1k disk layout (hd1k_combo.img). Simply use the image file that corresponds to your desired hard disk layout. Review the information in Hard Disk Layouts if you need more information of the disk layout options. Note : Apart from the hd512 and hd1k Combo Disk Images (mentioned above) there are actually a number of other hd1k_*_combo.img files. These additional combo files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct combo file The Combo Disk Image actually only contains the initial partition table, and the first 6 slices (Slice 0 to 5), this is approximately 49MB in size. While the partition table reserves space to store 64 CP/M filesystem slices as well as a single 384MB FAT filesystem, these areas remain empty, and must be initialized manually using CLRDIR for CP/M filesystems and FAT FORMAT for the FAT filesystem. Combo Disk Image Capacity The standard hard disk layout used by the Combo Disk Image was designed to fit well on a 1GB hard disk. The 64 CP/M slices (approximately 512MB) and 384MB FAT filesystem all fit well within a 1GB hard disk. This size choice was a bit arbitrary, but based on the idea that 1GB CF/SD/USB Media is easy and cheap to acquire. It is fine if your hard disk is smaller than 1GB. It just means that it will not be possible to use the pre-allocated FAT filesystem partition and any CP/M filesystem slices that don\u2019t fit. The true number of CP/M filesystem slices that will fit on your specific physical hard disk can be calculated as described in Hard Disk Capacity . If you attempt to access a slice past the end of the physical hard disk you will get \u201cno disk\u201d errors. You should calculate the maximum number of slices your hard disk will support and do not exceed this number. Combo Disk Image Advice A great way to maintain your own data on a hard disk is to put your data in slices beyond the first 6. By doing so, you can always \u201cre-image\u201d your drive media with the Combo Disk Image without overlaying the data stored in the slices beyond the first 6. Just be very careful to use the same combo image layout (hd512 or hd1k) as you used originally. Custom Hard Disk Image For hard disks, each .img file represents a single slice (CP/M filesystem). Since a hard disk can contain many slices, you can just concatenate the slices (.img files) together to create your desired hard disk image. If you look in the Binary directory of the distribution, you will see that there are more disk (slice) images than the 6 that are included in the Combo Disk Images. These supplemental disk images are identified by looking for the files that start with hd1k_ or hd512_. Adding Slices to Combo Image You can add slices to the Combo Disk Images simply by tacking slices onto the end. For example, if you want to add a slice containing the MSX ROMs to the end of the combo image, you could use one of the following command lines depending on your operating system: Windows: COPY /B hd1k_combo.img + hd1k_msxroms.img my_hd.img Linus/MaxOS: cat hd1k_combo.img hd1k_msxroms.img >my_hd.img Note that you must be sure to use either the hd1k_ or hd512_ prefixed files together. You cannot mix them. Creating a new Custom Image If you want to create a completely custom hard disk image that is not based on the existing combo image, you can generate a disk image entirely from scratch using whatever slices you want in whatever order you like. For example, if you want to create a hard disk image that has slices for CP/M 2.2, CP/M 3, and WordStar in the hd512 format, you would use the command line of your modern computer to create the final image: Windows: COPY /B hd512_cpm22.img + hd512_cpm3.img + hd512_ws hd.img Linux/MacOS: cat hd512_cpm22.img hd512_cpm3.img hd512_ws >hd.img NOTE: For the hd1k disk layout, you must prepend the prefix file called hd1k_prefix.dat which contains the required partition table. So, for an hd1k layout you would use the following: Windows: COPY /B hd1k_prefix.dat + hd1k_cpm22.img + hd1k_cpm3.img + hd1k_ws hd.img Linux/MacOS: cat hd1k_prefix.dat hd1k_cpm22.img hd1k_cpm3.img hd1k_ws >hd.img Note : Apart from the hd1k_prefix.dat file (mentioned above) there are actaully a number of other hd1k_*_prefix.dat files. These additional prefix files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct prefix file In all of the examples above, the resulting file (hd.img) would now be written to your hard disk media and would be ready to use in a RomWBW system. If you wish to further customize or create new disk image definitions, please refer to the ReadMe.txt file in the Source/Images directory. Writing Hard Disk Images Once you have chosen a Combo Hard Disk Image file or prepared your own custom hard disk image file, it will need to be written to the media using your modern computer. When using this method, the disk will be partitioned and setup with 1 or more slices containing ready-to-run bootable operating systems. To write a hard disk image file onto your actual media (actual hard disk or CF/SD/USB Media), you need to use an image writing utility on your modern computer. Your modern computer will need to have an appropriate interface or slot that accepts the media. To actually copy the image On Linux or MacOS , you can use the dd command. On Windows, in the \u201cTools\u201d directory of the distribution, there is an application called Win32DiskImager. In all cases, the image file should be written to the media starting at the very first block or sector of the media. This is the default behaviour on all software. To be entirely clear, writing a disk image file to your hard disk media will overwrite an pre-existing partition table and the number of slices that your image file contains. It will not overwrite or corrupt slices beyond those in the image file. As a result, you can use additional slices as a place to maintain your personal data because these slices will survive re-imaging of the media. If you setup a FAT partition on your media, it will also survive the imaging process. Media Usage and Initialization Once you have copied the image onto the hard disk media, you can move the media over to your RomWBW system. You can then boot to the operating system slices by specifying ( \\<diskunit>.\\<slice> ) at the RomWBW Boot Loader command prompt. See the section Starting Operating Systems from Disk for further details You are not limited to the number of slices that are contained in the image that you write to your hard disk media. You can use additional slices as long your media has room for them. However, writing the disk image will not initialize the additional slices. You will need to use the CLRDIR application to initialize any un-initialized slice before its first use, and and optionally SYSCOPY if you want th slice to be bootable. If you use the combo image this applies to slices 6 thru 63. The procedure for this is documented in the Clearing (Formatting) Drives section. Likewise, the pre-allocated FAT partition must still be formatted using FAT FORMAT in order to actually use it (see FAT Filesystem Preparation ). Alternatively, the FAT partition can be formatted on a modern computer. Re-Imaging Existing Media In order for your additional slices and/or FAT partition to survive re-imaging, you must follow these rules: Do not modify the partition table of the media using FDISK80 or any other partition management tools. Ensure that your hard disk image file uses the same disk layout approach (hd512 or hd1k) as previously used on the media. Writing Hard Disk Slices This section covers techniques to copy partial images onto pre-existing media, in effect performing a selective slice copy. These techniques currently only apply to hd1k formatted media, which has a partition table entry, and a convenient 1MB size metric. However adapting to hd512 is possible, but left to the user. You will need to have access to a Linux/MacOS machine, or have the Linux tools for Windows installed, including the dd command line tool. For Windows there are multiple options for installing dd including MSYS2 , CygWin , and dd for Windows . WARNING : The dd command is a low-level utility that writes directly to raw disk sectors with almost no safety checks. It is very easy to corrupt a disk if this tool is used incorrectly. The dd command supports options to define precisely source and destination offsets and sizes to copy. From the documentation of dd the following options are important. if=file Read input from file instead of the standard input. of=file Write output to file instead of the standard output. skip=n Skip n blocks from the beginning of the input before copying. seek=n Seek n blocks from the beginning of the output before copying. count=n Copy only n input blocks. bs=n Set both input and output block size to n bytes instead of the default 512 The best approach is to copy data to the RomWBW partition. To do this, you must first determine the name that your operating system is using for the RomWBW disk and partition. An easy way to determine this may be the linux mount command, which lists the currently mounted partitions. From here you can more easily determine the naming scheme used by your operating system. Typically disk devices are named something like /dev/disk9 or /dev/sdg , noting above the g is a alphabetic and it could be any letter. This naming is arbitrary and depend on the operating system, and the specific hardware connecting the device Partitions are typically named by simply adding a number after the name of the hard disk device. For example, the first partition could be /dev/disk9s1 , /dev/sdg1 , or /dev/sdgp1 . In the following examples we use the above dd options, noting the of= option is the RomWBW target partition. ** NOTE ** A second approach (Examples 3 and 4) is to address the hard disk as a raw disk device and we take explicit steps to calculate the start of the RomWBW partition. While this works, it is better to use the partition relative approach. The commands in the examples below are run from the Binary folder of RomWBW distribution. Example 1 : Copy the Games image to an empty slice of our media In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5). We are just copying the needed slice to the existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/sdg1 seek=6 bs=8M Password: 1+0 records in 1+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) Since bs=8MB the seek=6 skips the first 6 (8MB slices) slices (in the target image) and writes the games image to the 7th slice. Example 2 : Copy the entire Combo Image without replacing partition table In all of the following examples we use bs=1MB to defines the block size used in other parameters. This is convenient since the combo image reserves 1MB for the partition table at the start of the disk. In this example we will copy the (hd1k) combo image (which includes a partition table) over our media without replacing the partition table. In this example we assume the media has already been formatted with the combo image, and we have modified the partition table, which we do not want to overwrite. Binary % sudo dd if=hd1k_combo.img of=/dev/sdg1 skip=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB (partition table) in the input file, effectively stripping out the combo images partition table, before overwriting the slices in the target partition. Example 3 : Copy the Combo Image without replacing partition table This example is identical to Example 2 except it writes to the target disk device itself ( of=/dev/disk9 ), not the target partition. Binary % sudo dd if=hd1k_combo.img of=/dev/disk9 skip=1 seek=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB in the input file, and likewise seek=1 skips the first 1MB of the target media file we are writing to, thus in effect we are skipping the first 1MB, which contains the partition table itself. Example 4 : Copy the Games image to an empty slice of our media In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5) We are just coping the needed slice to this existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/disk9 seek=49 bs=1M Password: 8+0 records in 8+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) The seek=49 skips the first 49MB of the media file we are writing to. 49 is calculated as (slice number * 8) + 1 , where 8 is the size of a slice and 1 is the size of the partition table im megabytes. Thus we are skipping 6 slices (in the combo image) and writing to the 7th slice. Operating Systems One of the primary goals of RomWBW is to expose a set of generic hardware functions that make it easy to adapt operating systems to any hardware supported by RomWBW. As a result, there are now 8 operating systems that have been adapted to run under RomWBW. The adaptations are identical for all hardware supported by RomWBW because RomWBW hides all hardware specifics from the operating system. By design, the operating systems provided with RomWBW are original and unmodified from their original distribution. Patches published by the authors are generally included or applied. The various enhancements RomWBW provides (such as hard disk slices) are implemented entirely within the system adaptation component of each operating system (e.g., CP/M CBIOS). As a result, each operating system should function exactly as documented by the authors and retain maximum compatibility with original applications. Note that all of the operating systems included with RomWBW support the same basic filesystem format from DRI CP/M 2.2 (except for p-System). As a result, a formatted filesystem will be accessible to any operating system. The only possible issue is that if you turn on date/time stamping using the newer OSes, the older OSes will not understand this. The older OS will not corrupt the files, but the date/time stamps will not be maintained. The following sections briefly describe the operating system options currently available and brief operating notes. Digital Research CP/M 2.2 This is the most widely used variant of the Digital Research operating systems. It has the most basic feature set, but is essentially the compatibility metric for all other CP/M-like operating systems including those listed below. If you are new to the CP/M world, I would recommend using this CP/M variant to start with simply because it is the most stable and you are less likely to encounter compatibility issues. Documentation CPM Manual Boot Disk To make a bootable CP/M disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cCPM.SYS\u201d. For example: SYSCOPY C:=B:CPM.SYS Character Device Mapping Character device mapping under CP/M 2.2 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The CP/M Logical Devices are: Device Description CON: System console device, used by CCP for communication with the operator RDR: Paper tape reader device PUN: Paper tape punch device LST: Output list device The CP/M Physical Devices are: Device Description TTY: Teletype device (slow speed console) CRT: Cathode ray tube device (high speed console) BAT: Batch processing (input from RDR: , output to LST: ) UC1: User-defined console PTR: Paper tape reader (high speed reader) UR1: User-defined reader #1 UR2: User-defined reader #2 PTP: Paper tape punch (high speed punch) UP1: User-defined punch #1 UP2: User-defined punch #2 LPT: Line printer UL1: User-defined list device #1 CP/M Logical Devices are mapped to CP/M Physical Devices via the IOBYTE at 0x0003 as shown below. Logical Device LST: PUN: RDR: CON: IOBYTE Bits 7 6 5 4 3 2 1 0 0 (0b00) TTY: TTY: TTY: TTY: 1 (0b01) CRT: PTP: PTR: CRT: 2 (0b10) LPT: UP1: UR1: BAT: 3 (0b11) UL1: UP2: UR2: UC1: The mappings above can be managed using the STAT command. This command essentially just modifies the IOBYTE value. CP/M Physical Devices are mapped to RomWBW HBIOS devices during the boot process depending on the number of HBIOS Char devices in the system. All CP/M Physical Devices are initially mapped to HBIOS Char 0. If additional HBIOS Char devices are available in the system, they will be mapped as below: CP/M RomWBW HBIOS TTY: Char 0 CRT: CRT BAT: CP/M RDR/LST UC1: Char 1 PTR: Char 1 UR1: Char 2 UR2: Char 3 PTP: Char 1 UP1: Char 2 UP2: Char 3 LPT: Char 1 UL1: Char 2 Normally, the HBIOS Console device (Loader prompt) is on HBIOS Device Char 0. If it has been reassigned to a different HBIOS character device before launching CP/M, then the above mapping will be modified. TTY: will be assigned to the current HBIOS console Char device. The remaining assignments will be filled in with the other Char devices as available. Notes You can change media, but it must be done while at the OS command prompt and you must warm start CP/M by pressing ctrl-C. This is a CP/M 2.2 constraint and is well documented in the DRI manual. SUBMIT.COM has been patched per DRI to always place submit files on A:. This ensures the submitted file will always be properly executed. The original versions of DDT, DDTZ, and ZSID used the RST 38 vector which conflicts with interrupt mode 1 use of this vector. The DDT, DDTZ, and ZSID applications in RomWBW have been modified to use RST 30 to avoid this issue. Z-System applications will not run under CP/M 2.2. For example, the LDDS date stamper will not work. Z-System Z-System is the most popular non-DRI CP/M workalike \u201cclone\u201d which is generally referred to as Z-System. Z-System is intended to be an enhanced version of CP/M and should run all CP/M 2.2 applications. It is optimized for the Z80 CPU (as opposed to 8080 for CP/M) and has some significant improvements such as date/time stamping of files. Z-System is a somewhat ambiguous term because there are multiple generations of this software. RomWBW Z-System is a combination of both ZCPR-DJ (the CCP) and ZSDOS 1.1 (the BDOS) when referring to Z-System. The latest version of Z-System (ZCPR 3.4) is also provided with RomWBW via the NZ-COM adaptation (see below). Documentation ZCPR Manual ZCPR-DJ ZSDOS Manual Boot Disk To make a bootable Z-System disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cZSYS.SYS\u201d. For example: SYSCOPY C:=B:ZSYS.SYS Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The CP/M 2.2 STAT command is used to manipulate the device mappings. Notes Although most CP/M 2.2 applications will run under Z-System, some may not work as expected. The best example is PIP which is not aware of the ZSDOS paths and will fail in some scenarios (use COPY instead). Although ZSDOS can recognize a media change in some cases, it will not always work. You should only change media at a command prompt and be sure to warm start the OS with a ctrl-C. ZSDOS has a concept of fast relog of drives. This means that after a warm start, it avoids the overhead of relogging all the disk drives. There are times when this causes issues. After using tools like CLRDIR or MAP, you may need to run \u201cRELOG\u201d to get the drive properly recognized by ZSDOS. ZSVSTAMP expects to be running under the ZCPR 3.X command processor. By default, RomWBW uses ZCPR 1.0 (intentionally, to reduce space usage) and ZSVSTAMP will just abort in this case. It will work fine if you implement NZCOM. ZSVSTAMP is included solely to facilitate usage if/when you install NZCOM. Many of the tools can be configured (using either ZCNFG or DSCONFIG). The configuration process modifies the actual application file itself. This will fail if you try to modify one that is on the ROM disk because it will not be able to update the image. DATSWEEP can be configured using DSCONFIG. However, DSCONFIG itself needs to be configured first for proper terminal emulation by using SETTERM. So, run SETTERM on DSCONFIG before using DSCONFIG to configure DATSWEEP! Generic CP/M PIP and ZSDOS path searching do not mix well if you use PIP to copy to or from a directory in the ZSDOS search path. Best to use COPY from the ZSDOS distribution. NZCOM Automatic Z-System NZCOM is a much further refined version of Z-System (ZCPR 3.4). NZCOM was sold as an enhancement for existing users of CP/M 2.2 or ZSDOS. For this reason, (by design) NZCOM does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into a host OS. On the RomWBW NZCOM disk images, the boot OS is ZSDOS 1.1. A PROFILE.SUB file is included which automatically launches NZCOM as soon as ZSDOS loads. NZCOM is a companion product to Z3PLUS, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. NZCOM is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation and use MKZCM as desired to customize your system. NZCOM has substantially more functionality than CP/M or basic Z-System. It is important to read the \u201cNZCOM Users Manual.pdf\u201d document in order to use this operating system effectively. Documentation NZCOM Users Manual Z-System Users Guide ZCPR3.3 User Guide Boot Disk Since NZ-COM boots via Z-System, you can make a bootable NZ-COM disk using ZSYS.SYS as described in Z-System above. You will need to add a PROFILE.SUB file to auto-start NZ-COM itself. Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . However, it is not possible to manipulate the CP/M Logical to Physical device mapping using the STAT command. The mapping is static. Note: A custom ZCPR IOP module could theoretically be used to manage the character device mappings. RomWBW does not provide this module and writing an IOP module is beyond the scope of this document. Notes All of the notes for Z-System above generally apply to NZCOM. There is no DIR command, you must use SDZ instead. If you don\u2019t like this, look into the ALIAS facility. For consistency with other ZCPR3 operating systems (ZPM3, Z3PLUS) the SHOW.COM and HELP.COM command files were renamed to ZSHOW.COM and ZHELP.COM Digital Research CP/M 3 This is the Digital Research follow-up product to their very popular CP/M 2.2 operating system. While highly compatible with CP/M 2.2, it features many enhancements and is not 100% compatible. It makes direct use of banked memory to increase the user program space (TPA). It also has a new suite of support tools and help system. Documentation CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide Boot Disk To create (or update) a CP/M 3 boot drive, you must place CPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS and CCP.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. CPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/CPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . CPMLDR.SYS CPM3.SYS or CPM3BNK.SYS CCP.COM The CPM3.SYS boot file is provided in 2 versions. In the Binary/CPM3 distribution directory, CPM3.SYS is the \u201cnon-banked\u201d version of CP/M 3. The CPM3BNK.SYS file is the \u201cbanked\u201d version of CP/M 3. You almost certainly want to transfer the banked CPM3BNK.SYS version. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place CPMLDR.SYS on the boot track of the target drive. CPM3.SYS and CCP.COM can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into CP/M 3 to create or update a CP/M 3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the CP/M 3 disk. Assuming the target CP/M 3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:CPMLDR.SYS COPY A:CPM3BNK.SYS F:CPM3.SYS COPY A:CCP.COM F: Note in the example above that CPM3BNK.SYS is renamed to CPM3.SYS in the copy command. Character Device Mapping Character device mapping under CP/M 3 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The primary CP/M Logical Devices are: Device Description CON: Console input or output device AUX: Auxiliary Input or Output Device LST: List output device, usually the printer There are various aliases for these devices. Please refer to the CP/M 3 Users Guide for more information. The mapping of CP/M 3 Logical Devices to Physical Devices is performed using the DEVICE command. CP/M 3 refers to Physical Character Devices using the COM device label. These COM devices are mapped directly to the RomWBW HBIOS Char devices as described below: COM0: \u2013> HBIOS Char 0 COM1: \u2013> HBIOS Char 1 COM2: \u2013> HBIOS Char 2 . . . COMn: \u2013> HBIOS Char n Notes The COPYSYS command described in the DRI CP/M 3 documentation is not provided with RomWBW. The RomWBW SYSCOPY command is used instead. Although CP/M 3 is generally able to run CP/M 2.2 programs, this is not universally true. This is especially true of the utility programs included with the operating system. For example, the SUBMIT program of CP/M 3 is completely different/incompatible from the SUBMIT program of CP/M 2.2. RomWBW fully supports CP/M 3 file date/time stamping, but this requires that the disk be properly initialized for it. This process has not been performed on the CP/M 3 disk image. Follow the CP/M 3 documentation to complete this process, if desired. Z3PLUS Z-System for CP/M-Plus Z3PLUS is a much further refined version of Z-System (ZCPR 3.4). Z3PLUS was sold as an enhancement for existing users of CP/M 3. For this reason, (by design) Z3PLUS does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into CP/M 3. A PROFILE.SUB file is included which automatically launches Z3PLUS as soon as CP/M 3 loads. Z3PLUS is a companion product to NZ-COM, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. Z3PLUS is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation to customize your system. Z3PLUS has substantially more functionality than CP/M 3 or the basic Z-System. It is important to read the \u201cZ3PLUS Users Manual.pdf\u201d document in order to use this operating system effectively. Documentation Z3PLUS Users Manual Z-System Users Guide ZCPR3.3 User Guide Boot Disk Since Z3PLUS boots via CP/M 3, you first must make the disk CP/M 3 bootable. This is not a simple process, as well as placing CPMLDR.SYS on the system track of the disk there are several files that are required on the disk itself.This is described in Digital Research CP/M 3 section above. You will need to add a PROFILE.SUB file to auto-start Z3PLUS itself. Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings. Notes All of the notes for Digital Research CP/M 3 above generally apply to Z3PLUS. Some applications in the Z3PLUS distribution have been upgraded with newer versions. This is done with in ZPM3 Simeon Cran\u2019s ZPM3 is an interesting combination of the features of both CP/M 3 and ZCPR3. Essentially, it has the features of and compatibility with both. Due to this dual compatibility, the ZPM3 distribution image contains most of the standard CP/M 3 files as well as a variety of common ZCPR3 applications. However, you will notice that user area 0 of the disk has only a few files. Most of the files are distributed among other user areas which is standard practice for ZCPR3. Most importantly, you will see most of the applications in user area 15. The applications can be executed from any user area because ZPM3 has a default search path that includes User 15. The ZPM3 distribution comes with essentially no utility programs at all. In addition to the standard CP/M 3 utilities, RomWBW includes a variety of common ZCPR3 utilities. Documentation ZPM3 has no real documentation. You are expected to understand both CP/M 3 and ZCPR 3. The best source of information is: CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide Z-System Users Guide ZCPR3.3 User Guide Boot Disk To create (or update) a ZPM3 boot drive, you must place ZPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS , ZCCP.COM , ZINSTAL.ZPM , and STARTZPM.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. ZPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/ZPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . ZPMLDR.SYS CPM3.SYS ZCCP.COM ZINSTAL.ZPM STARTZPM.COM You may be surprised to see the file called CPM3.SYS . This is not a typo. Although it is called CPM3.SYS , it is ZPM and not the same as CPM3.SYS in the CPM3 directory. Also, unlike CP/M 3, ZPM3 is always banked, so you will not find two versions of the file. CPM3.SYS is a banked implementation of ZPM3. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place ZPMLDR.SYS on the boot track of the target drive. The remaining boot files can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into ZPM3 to create or update a ZPM3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the ZPM disk. Assuming the target ZPM3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:ZPMLDR.SYS COPY A:CPM3.SYS F:CPM3.SYS COPY A:CCP.COM F: COPY A:ZINSTAL.ZPM F: COPY A:STARTZPM.COM F: Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings. Notes The ZPM3 operating system is contained in the file called CPM3.SYS which is confusing, but this is as intended by the ZPM3 distribution. I believe it was done this way to make it easier for users to transition from CP/M 3 to ZPM3. The command line editing key bindings were slightly modified by Jon Saxton when he applied a few ZPM3 fixes. This is explained in the file zpm3fix.txt in the distribution folder Source/ZPM3. The current key bindings are from the \u201cNew\u201d column below. Old New Function ^A ^A one word left ^B ^B to beginning/end of line ^C ^C reboot if at start of line ^D ^D right one char ^E ^E get previous line ^F ^F right one word ^G ^G delete char at cursor ^H ^H destructive backspace ^I ^I (TAB) ignored here ^J ^J (LF) exit editor ^K ^K delete all to the right ^L ^L ignored ^M ^M (CR) exit editor ^N ^N ignored ^O ^O ignored ^P ^P toggle printer echoing ^Q ^Q toggle autoprompt (if enabled) ^R ^R ignored ^S ^S left one char ^T ^T delete word at cursor ^U ^U add line to history ^V ^V clear line, delete from history ^W ^X get next line from history ^X ^W delete all to the left ^Y ^Y clear line QP/M QP/M is another OS providing compatibility with and enhancements to CP/M 2.2. It is provided as a bootable disk image for RomWBW. Refer to the ReadMe.txt file in Source/Images/d_qpm for more details regarding the RomWBW adaptation and customizations. Documentation QP/M 2.7 Installation Guide and Supplements QP/M 2.7 Interface Guide QP/M 2.7 Features and Facilities Boot Disk To create or update a bootable QP/M Z-System disk, a special process is required. QP/M is not provided in source format. You are expected to install QP/M over an existing CP/M installation using the QINSTALL.COM application. To update an existing QP/M boot disk with the latest RomWBW CBIOS, you must use 2 steps: apply the generic CP/M system track, then reinstall the QP/M components. To do this, you can perform the following steps: Boot to the existing QP/M disk. At this point, drive A should be the QP/M disk that you wish to update. You may receive a warning about CBIOS/HBIOS version mismatch. Use RomWBW SYSCOPY to place the stock RomWBW CP/M OS image onto the system tracks of the QP/M boot disk: SYSCOPY A:=x:CPM.SYS where x is the drive letter of your ROM Disk. Run QINSTALL to overlay the QP/M OS components on your QP/M boot disk. WARNING : QINSTALL has no mechanism for retaining previous non-default settings. Any previous non-default settings you previously made with QINSTALL will need to be reapplied. The pre-built RomWBW QP/M disk image includes a couple of specific non-default settings to optimize use with RomWBW. Please review the notes in the ReadMe.txt file in Source/Images/d_qpm. Character Device Mapping Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The mappings can be viewed or modified using the QP/M QSTAT command which is analogous to the CP/M 2.2 STAT command. Do not use the CP/M 2.2 STAT command under QP/M. Notes QPM is not available as source. This implementation was based on the QPM binary distribution and has been minimally customized for RomWBW. When booted, the QPM startup banner will indicate CP/M 2.2. This is because QPM uses the CP/M 2.2 CBIOS code. QINSTALL is used to customize QPM. It is included on the disk image. You should review the notes in the ReadMe.txt file in Source/Images/d_qpm before making changes. In addition to the QPM disk image, all of the QPM distribution files can be found in the RomWBW distribution in the Source/Images/d_qpm/u0 directory. The QPM disk image is not included as one of the slices on the RomWBW Combo Disk Image. If you want to include QPM, you can do so by following the directions in Source/Images/Readme.txt. UCSD p-System This is a full implementation of the UCSD p-System IV.0 for Z80 running under RomWBW. Unlike the OSes above, p-System uses its own unique filesystem and is not interoperable with other OSes. It was derived from the p-System Adaptable Z80 System. Unlike some other distributions, this implements a native p-System Z80 Extended BIOS, it does not rely on a CP/M BIOS layer. The p-System is provided on a hard disk image file called psys.img. This must be copied to its own dedicated hard disk media (CF Card, SD Card, etc.). It is booted by selecting slice 0 of the corresponding hard disk unit at the RomWBW Boot Loader prompt. Do not attempt to use CP/M slices on the same disk. Due to limitations in the p-System configuration mechanism, it does not recognize the arrow keys of an ANSI Terminal. To work around this, the following control keys have been defined: Function Key Up ctrl+E Down ctrl+X Left ctrl+S Right ctrl+D Refer to Source/pSys/ReadMe.txt for more details about the p-System adaptation. Documentation UCSD p-System Users Manual Boot Disk There is no mechanism provided to create a p-System boot disk from scratch under RomWBW. This has already been done as part of the porting process. You must use the provided p-System hard disk image file which is bootable. Character Device Mapping RomWBW Character Devices are automatically assigned to p-System devices at startup. The current HBIOS Console device is assigned to CONSOLE:. The next available HBIOS Char device is assigned to REMIN:/REMOUT:. The next available HBIOS Char devices is assigned to PRINTER: Notes There is no floppy support at this time. The hard disk image contains 6 p-System slices which are assigned to p-System unit numbers 4, 5, 9, 10, 11, and 12 which is standard for p-System. Slices 0-5 are assigned sequentially to these p-System unit numbers and it is not possible to reassign them. Unit #4 (slice 0) is bootable and contains all of the p-System distribution files. Unit #5 (slice 1) is just a blank p-System filesystem. The other units (9-12) have not been initialized, but this can be done from Filer using the Zero command. p-System relies heavily on the use of a full screen terminal. This implementation has been setup to expect an ANSI or DEC VT-100 terminal or emulator. The screen output will be garbled if no such terminal or emulator is used for console output. There is no built-in mechanism to move files in and out of p-System. However, the .vol files in Source/pSys can be read and modified by CiderPress. CiderPress is able to add and remove individual files. Andrew Davidson has created a Python script that can extract p-System volumes from an existing disk image file. The script is also capable of inserting a modified volume back into the disk image file. This tool is available at https://github.com/robosnacks/psysimg . FreeRTOS Phillip Stevens has ported FreeRTOS to run under RomWBW. FreeRTOS is not provided in the RomWBW distribution. FreeRTOS is available under the MIT licence and further general information is available at FreeRTOS . Phillip may be contacted via his GitHub Page . Fuzix Fuzix is a Unix-ish operating system for small systems. It is the work of Alan Cox and is hosted on GitHub at https://github.com/EtchedPixels/FUZIX . Fuzix itself is a stand-alone operating system, but it frequently utilizes RomWBW to boot and launch on RomWBW-supported platforms. For those Fuzix platforms that leverage RomWBW for startup, you will program your ROM with the normal RomWBW ROM \u2013 there is no Fuzix-specific ROM. A Fuzix disk image for your system is then written to your disk media. After booting your system via the normal RomWBW ROM, you start Fuzix simply by choosing the disk device containing the Fuzix image at the RomWBW Loader prompt. To create a Fuzix disk image: Locate and download the Fuzix disk image for your system from https://www.fuzix.org/ . For each platform, you will typically find two image files. An emulator image ( emu-xxx.img ) and a disk image ( disk.img ). You want the disk image file. Write the disk image file to your physical media (CF Card, SD Card, etc.) starting at the beginning of the media (first sector). Do not combine the Fuzix image with the RomWBW disk images \u2013 they are entirely separate. To boot into Fuzix: Insert your Fuzix disk media. Power-up or reset your system. RomWBW should load normally and bring you to the RomWBW Boot Loader prompt. Depending on the platform, Fuzix may be built to run at a different baud rate that the default RomWBW baud rate. If so, it is best to change your RomWBW baud rate prior to initiating the Fuzix startup. You can do this at the loader prompt with a command like this: I 0 38400 Replace 38400 with the desired baud rate for Fuzix. You will be prompted to change your terminal\u2019s baud rate at this time. At the RomWBW Boot Loader prompt, enter the disk unit number of the Fuzix media. Fuzix should load and you will see device discovery/information messages that vary depending on your platform. This is a typical example: RCBus [RCZ180_nat_wbw] Boot Loader FP Switches = 0x00 Boot [H=Help]: 2 Booting Disk Unit 2, Slice 0, Sector 0x00000000... Volume \"Fuzix 126 Loader\" [0xF200-0xF400, entry @ 0xF200]... FUZIX version 0.4 Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha Copyright (c) 2013-2015 Will Sowerbutts wi...@sowerbutts.com Copyright (c) 2014-2023 Alan Cox al...@etchedpixels.co.uk Devboot 512kB total RAM, 448kB available to processes (15 processes max) Enabling interrupts ... ok. 0000 : CF Card - OK 0001 : - absent hda: hda1 hda2 (swap) bootdev: At the bootdev: prompt, enter hda1 . Fuzix should load and you will be prompted for a date/time. Here is a typical example: bootdev: hda1 Mounting root fs (root_dev=1, ro): OK Starting /init init version 0.9.1 Checking root file system. Current date is Fri 2023-08-18 Enter new date: Current time is 13:30:24 Enter new time: ^ ^ n n Fuzix 0.4 @< Welcome to Fuzix m m login: At the login: prompt, enter root . No password is required. You should then get a Fuzix # command prompt. login: root Welcome to FUZIX. # You may now use Fuzix as desired. The general operation and use of Fuzix is outside of the scope of this document. Custom Applications The operation of the RomWBW hosted operating systems is enhanced through several custom applications. You have already read about one of these \u2013 the ASSIGN command. These applications are functional on all of the OS variants included with RomWBW. The applications discussed here are not the same as the built-in ROM applications mentioned previously. These applications run as commands within the operating systems provided by RomWBW. So, these commands are only available at an operating system prompt after an operating system has been loaded. All of the RomWBW Custom Applications are built to function under all of the RomWBW Operating Systems (except for p-System). In general, the applications will automatically adapt as needed to the currently running operating system. One exception is FDU \u2013 the Floppy Disk Utility. This application requires that you pick the floppy disk interface you want to interact with. There is more complete documentation of all of these applications in the related RomWBW manual \u201c RomWBW Applications \u201d found in the Doc directory of the distribution. The following custom applications are found on the ROM disk and are, therefore, globally available. Application **Description ASSIGN Add, change, and delete drive letter assignments. Use ASSIGN /? for usage instructions. SYSCOPY Copy system image to a device to make it bootable. Use SYSCOPY with no parms for usage instructions. MODE Reconfigures serial ports dynamically. FDU Format and test floppy disks. Menu driven interface. FORMAT Will someday be a command line tool to format floppy disks. Currently does nothing! XM XModem file transfer program adapted to hardware. Automatically uses primary serial port on system. FLASH Will Sowerbutts\u2019 in-situ ROM programming utility. FDISK80 John Coffman\u2019s Z80 hard disk partitioning tool. See documentation in Doc directory. FAT Access MS-DOS FAT filesystems from RomWBW (based on FatFs). TALK Direct console I/O to a specified character device. RTC Manage and test the Real Time Clock hardware. TIMER Display value of running periodic system timer. CPUSPD Change the running CPU speed and wait states of the system. Some custom applications do not fit on the ROM disk. They are found on the disk image files or the individual files can be found in the Binary/Apps directory of the distribution. They are also included on the floppy disk and hard disk images. Application Description TUNE Play .PT2, .PT3, .MYM audio files. INTTEST Test interrupt vector hooking. Real Time Clock & Date/Time Stamping RomWBW supports a variety of real time clock hardware. If your system has this hardware, then it will be able to maintain the current date and time even while your system is turned off. Additionally, depending on the operating system being used, you may be able to utilize date/time stamping of files. To facilitate this a CP/M clock driver (WBWCLK) has been included inside CLOCKS.DAT that will read the clock via a RomWBW HBIOS call You can determine if your system has a real time clock present (and functioning) by looking at the boot messages. Here is an example of a boot message reflecting the detection of a valid real time clock module: DSRTC: MODE=STD IO=0x8A Thu 2023-10-19 14:07:11 CHARGE=ON This example is from a DSRTC clock module. You may have a different one, but it will always display the current date/time. In some cases, your real time clock will support charging of the battery or super-capacitor while the system has power. The status of this charging is displayed. If the date/time of your RTC needs to be updated, you will need to do this with one of the utilities described below. There is no ability to update the date/time of the RTC in the RomWBW Boot Loader or Monitor. Date/Time Utilities RomwWBW includes two utilities for displaying or setting the date/time stored by the RTC. They are both a bit different and are briefly described below. A third utility TESTCLOK is also included as part of ZSDOS WDATE Utility The WDATE utility (contributed by Kevin Boone) is an application that will display and/or update the current date/time. Its operation is described in RomWBW Applications . This utility works with any of the supported RomWBW RTC hardware. Here is an example of displaying and updating the date/time with this utility: A>wdate Thursday 19 October 14:14:43 2023 A>wdate 23 10 19 14 24 30 A>wdate Thursday 19 October 14:24:34 2023 Note that WDATE does not have anything to do with date/time stamping of files. It merely displays and sets the real time clock value. RTC Utility Like WDATE , the RTC utility (contributed by Andrew Lynch) will let you display and set the current date/time. However, this utility only works with the DSRTC hardware (DS1302 chip). It is a \u201cdirect to hardware application\u201d. Its operation is described in RomWBW Applications . Here is an example of displaying and updatting the date/time with this utility: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>t Current time: 23-10-19 14:30:25-05 RTC>i Init date/time. YEAR:23 MONTH:10 DATE:19 HOURS:14 MINUTES:31 SECONDS:00 DAY:05 The RTC utility is also capable of turning the charging feature of the DS1320 chip on or off. Here is an example of turning if off and back on: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>n Trickle charger disabled. RTC>c Trickle charger enabled. Do not enable charging unless you are sure that your system supports this. If your RTC is being powered by a normal battery, it would be dangerous to enable charging. TESTCLOK Utility The TESTCLOK utility is used to test a selected CPM clock driver loaded from the CLOCKS.DAT file. After selecting the location of CLOCKS.DAT and the clock driver (45. WBWCLK) it displays the currently configured time until a key is pressed. A>testclok TESTCLOK V1.0 Copyright (C) 1988 H.F. Bower / C.W. Cotrill Extract Clock from Library ([Y]/N) : Y Location of CLOCKS.DAT [A0:] : <RETURN> 1. ACTRIX 2. ALSPA 3. AMPRO-LB 4. ANLYTCL-PRD 5. AP2-CDZ180 6. AP2-THND/MT 7. AP2-TIMASTR 8. AP2E+PCP-TM 9. AP2E+PCPI 10. AP2E-THUNDR 11. AP2E-TMASTR 12. BIG-BD-II 13. BP-BIOS 14. CCS-WALLCLK 15. CPUPRO-SSB1 16. ELECTR-MFIO 17. EPSON-QX10 18. ETS180IO+ 19. H19-SUPER19 20. H19-ULTRA 21. H19-WATZMAN 22. H89-BITZERO 23. H89-PC12 24. H89-WIDGET 25. H89-WISE 26. H89UTI 27. HEATH-BIOS 28. HOUSEMASTER 29. K83-HOLMES 30. KAYPRO-84 31. KENMOR-ZTIM 32. KPRO-ADVENT 33. KPRO-LEGACY 34. MD3-MACK 35. MTN100K-DAY 36. ONEAC-ON! 37. OTRANA-ATCH 38. P&T-HEARTBT 39. QTSYS-S100 40. RELATIVE 41. S100-5832 42. SB180-HRTBT 43. SB180-XBIOS 44. SIMHCLOK 45. WBWCLK 46. XEROX-820 47. ZSDOS-BIOS Enter Clock Driver Selection : 45 ..Loading : WBWCLK ... Linking Clock Module... OK RomWBW HBIOS Clock 1.1 RomWBW Series HBIOS Clock Press any key to quit... 19 Oct 2023 14:24:34 Since this runs at the CPM driver level it is useful as an end-to-end test to prove that date time stamping is able to read the correct time The TESTCLOK utility is provided by ZSDOS, plese see the ZSDOS Manual for further information Date/Time File Stamping If an RTC is available in your system, then most operating systems can use it to date/time stamp files. This just means recording the date/time of file creation, update, and or access in the directory. This capability is available in all of the RomWBW operating system except the original DRI CP/M 2.2. Three types of date/time stamping are supported using realtime clock supported by RomWBW HBIOS. DateStamper, NZT and P2DOS. In some cases (such as ZSDOS), you must load an RSX (memory resident utility) to enable date/time stamping of files. This could be automated using a PROFILE.SUB file. Preconfigured loaders are provided, bypassing the need to use SETUPZST. Additionally, you will need to initialize the directory. The procedure varies depending on the date/time stamping mechanism, so you must review the associated documentation. The date/time stamping mechanisms for each operating system are generally not compatible. If you initialize a directory for a type of stamping, you should be careful not to manipulate that directory with a different operating system with a different date/time stamping mechanism. Doing so may corrupt the directory. The RomWBW disk images do not have date/time stamping initialized. This is to avoid any chance of directory corruption. DateStamper DateStamper datestamping follows the standard set by Plu*Perfect Systems. This method stores stamps in a disk file named !!!TIME&.DAT . Only DateStamper stamping stores full time and date stamps for file Creation, Last Modification, and Last Access, and may be used with any CP/M diskette format. In addition, the DateStamper protocol is supported by a mature set of compatible utilities. Key Utilities LDDS.COM - Load DateStamper date/time stamping resident extension. (RomWBW Provided) PUTDS.COM - Prepare disk for DateStamper date/time stamping. After using PUTDS to initialize a directory for ZDS date stamping, it may be necessary to run RELOG before the stamping routines will actually start working. P2DOS (CP/M Plus compatible) CP/M Plus-type datestamping is also widely used due to the popularity of CP/M Plus (also know as CP/M 3). CP/M Plus-type file datestamping uses directory sectors to store file datestamps which may be accessed more quickly by programs, but there is no Last File Access stamp. Finally, the range of utilities for this type of stamps is more limited than for the DateStamper protocol. Key Utilities LDP2D.COM - Load P2DOS date/time stamping resident extension. (RomWBW Provided) INITDIR.COM - Prepares disks for P2DOS-type file stamping. NZT The use of NZT needs to be further documented Key Utilities LDNZT.COM - Load NZT date/time stamping resident extension. (RomWBW Provided) Additional Notes The following files have been provided, customised and tested for for use in RomWBW CLOCKS.DAT - Library of clock drivers, which has been updated to include the RomWBW clock driver WBWCLK, and also includes the SIMHCLOK clock driver. The file is just a standard LU type library and is easily updated using NULU. The members are the relocatable binaries, but with the .REL extension removed. STAMPS.DAT - Library of available date/time stamping modules for SETUPZST. The file has been replaced with an updated version from the Walnut Creek CP/M CDROM. The original version has a bug that prevents RSX (resident system extension) mode to load properly. Additional Notes SETUPZST (provided by ZSDOS) Should not normally be needed since the creation of the appropriate LDTIM loaders has already been performed. FILEDATE only works with DateStamper style date stamping. If you run it on a drive that is not initialized for DateStamper, it will complain FILEDATE, !!!TIME&.DAT missing . This is normal and just means that you have not initialized that drive for DateStamper (using PUTDS). ZXD will handle either DateStamper or P2DOS type date stamping. However, it must be configured appropriately. As distributed, it will look for P2DOS date stamps. Use ZCNFG to reconfigure it for P2DOS if that is what you are using. Timezone None of the operating systems distributed with RomWBW have any concept of timezone. When files are date/time stamped, the date/time will simply be whatever date/time the RTC currently has. The normal practice is to set the RTC to your local time. This implies that you would need to manually adjust the RTC for daylight savings time and/or when you travel to a different time zone. The date/time stamps of files in directories will also be stored in local time. This includes files stored in a FAT filesystem. If you subsequently view the directory from modern machines (Windows, Linux, etc.), the date/time displayed will depend on the behavior of the modern system. For example, Linux assumes that the date/time of files is UTC. So, if you create a file on a FAT filesystem with your RomWBW computer and then use Linux to view the directory, the date/time stamps will seem \u201coff\u201d by a few hours. The only alternative you may consider is setting the date/time of your RTC to UTC. Since UTC is consistent across all timezones and daylight savings time, your file date/time stamps will also be consistent. Of course, this will mean that your RomWBW computer will display a date/time that seems wrong because it is not local time. CP/NET Networking Digital Research created a simple network file sharing system called CP/NET. This allowed a network server running CP/NOS to host files available to network attached CP/M computers. Essentially, the host becomes a simple file sharing server. RomWBW disk images include an adaptation of the DRI CP/NET client software provided by Douglas Miller. RomWBW does not support operation as a network server itself. However, Douglas has also developed a Java-based implementation of the DRI network server that can be used to provide host services from a modern computer. Both CP/NET 1.2 and 3.0 clients are provided. Version 1.2 is for use with CP/M 2.2 and compatible OSes. Version 3.0 is for use with CP/M 3 and compatible OSes. The CP/NET client software provided with RomWBW requires a supported ethernet interface module. At this time, the following are supported: RCBus MT011 w/ Ethernet Featherwing and (optionally) SPI FRAM (e.g., Adafruit SPI Non-Volatile FRAM Breakout) Duodyne Disk I/O w/ Wiz850IO and (optionally) SPI NVRAM (e.g., 25LC256) Generic Serial Interface NOTE: The Generic Serial Interface is supported by RomWBW, but is not documented here. You must refer to the CP/NET documentation referenced below. The client software interacts directly with this hardware. In a future version of RomWBW, I hope to add a generic networking API that will allow a greater range of network hardware to be used. To use CP/NET effectively, you will want to review the documentation provided by Douglas on at his cpnet-z80 GitHub Project . Additionally, you should consult the DRI documentation which is not included with RomWBW, but is available on the cpnet-z80 site. Below, I will provide the general steps involved in setting up a network using MT011 with RomWBW. CP/NET Client Setup The CP/NET client files are included on the RomWBW disk images, but they are found in user area 4. They are placed there to avoid confusing anyone that is not specifically trying to run a network client. They are only found on the CPM 2.2 and CP/M 3 slices. Using CP/NET on alternative OSes may work, but is not officially supported. The CP/NET client files are packaged in .LBR library files. The library files are found in user area 4. 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 First, you need to merge the files from the correct library file into user area 0. This is done by extracting the files using the NULU library management utility application. Start NULU specifying desired CP/NET library for \\<filename>: A>NULU 4:<filename> At the NULU prompt, extract the files using the -E *.* command: -READY A0:>-E *.* Exit NULU using the -X command: -Extract members A0:>-x Here is an example of extracting the CP/NET 1.2 client files for an RCBus system w/ MT011. You should be in user area 0 when performing this operation. A>nulu 4:cpn12mt NULU 1.52 (07/12/87) Copyright (C) 1984, 1985 & 1987 by Martin Murray Bug fixes in version 1.52 by Mick Waters TYPE -H FOR HELP Library A4:CPN12MT.LBR open. (Buffer size: 259 sectors) Active entries: 27, Deleted: 0, Free: 5, Total: 32. -READY A0:>-e *.* Extracting... CCP .SPR to A0:CCP .SPR CPM2NET .HLP to A0:CPM2NET .HLP CPNBOOT .COM to A0:CPNBOOT .COM CPNET12 .HLP to A0:CPNET12 .HLP CPNETLDR.COM to A0:CPNETLDR.COM CPNETSTS.COM to A0:CPNETSTS.COM DSKRESET.COM to A0:DSKRESET.COM ENDLIST .COM to A0:ENDLIST .COM LOCAL .COM to A0:LOCAL .COM LOGIN .COM to A0:LOGIN .COM LOGOFF .COM to A0:LOGOFF .COM MAIL .COM to A0:MAIL .COM NDOS .SPR to A0:NDOS .SPR NETDOWN .COM to A0:NETDOWN .COM NETSTAT .COM to A0:NETSTAT .COM NETWORK .COM to A0:NETWORK .COM NVRAM .COM to A0:NVRAM .COM PIPNET .COM to A0:PIPNET .COM RDATE .COM to A0:RDATE .COM SNIOS .SPR to A0:SNIOS .SPR SRVSTAT .COM to A0:SRVSTAT .COM TR .COM to A0:TR .COM WIZCFG .COM to A0:WIZCFG .COM WIZDBG .COM to A0:WIZDBG .COM WIZTEST .COM to A0:WIZTEST .COM XSUBNET .COM to A0:XSUBNET .COM -Extract members A0:>-x Closing A4:CPN12MT.LBR... At this point, you will need to configure your ethernet adapter for your local network using WIZCFG . The definitive guide to the use of WIZCFG is on the cpnet-z80 site in the document called \u201cCPNET-WIZ850io.pdf\u201d. Here is an example of the commands needed to configure the WizNet: wizcfg w n F0 set CP/NET node id wizcfg w i 192.168.1.201 set WizNet IP address wizcfg w g 192.168.1.1 set local network gateway IP address wizcfg w s 255.255.255.0 set WizNet subnet mask wizcfg w 0 00 192.168.1.3 31100 set server node ID, IP address, & port You will need to use values appropriate for your local network. You can use the command wiznet w to display the current values which is useful to confirm they have been set as intended. A>wizcfg w Node ID: F0H IP Addr: 192.168.1.201 Gateway: 192.168.1.1 Subnet: 255.255.255.0 MAC: 98:76:B6:11:00:C4 Socket 0: 00H 192.168.1.3 31100 0 These values can be persisted across power-cycles if your system has NVRAM storage. To program the values into your NVRAM, you would use the same commands as above, but omit the w parameter. The \u201cCPNET-WIZ850io.pdf\u201d document is highly recommended to understand the operation of WIZCFG . If you do not utilize NVRAM to persist your configuration, you will need to reapply these commands every time you power cycle your RomWBW computer, so I recommend putting them into a SUBMIT file. After applying these commands, you should be able ping the WizNet from another computer on the local network. If this works, then the client-side is ready. CP/NET Sever Setup These instructions will assume you are using Douglas Miller\u2019s CpnetSocketServer to implement a CP/NOS server on your network. The definitive guide to this software is also on the [cpnet-z80] (https://github.com/durgadas311/cpnet-z80) site and is called \u201cCpnetSocketServer.pdf\u201d. The software is a Java application, so it can generally run anywhere there is a Java runtime environment available. I have normally used it on a Linux system and have had good results with that. You will need to download the application called \u201cCpnetSocketServer.jar\u201d from the cpnet-z80 site. The application uses a configuration file. My configuration file is called \u201ccpnet00.rc\u201d and has these contents: cpnetserver_host = 192.168.1.3 cpnetserver_port = 31100 cpnetserver_temp = P cpnetserver_sid = 00 cpnetserver_max = 16 cpnetserver_root_dir = /home/wayne/cpnet/root You will also need to setup a directory structure with the drive letters per the documentation. To start the server, you would use a command like this: java -jar CpnetSocketServer.jar conf=cpnet00.rc At this point, the server should start and you should see the following: CpnetSocketServer v1.3 Using config in cpnet00.rc Server 00 Listening on 192.168.1.3 port 31100 debug false Your CP/NET server should now be ready to accept client connections. CP/NET Usage With both the client and server configured, you are ready to load and use CP/NET on your RomWBW system. CP/NET documentation is available on the cpnet-z80 site. The document is called \u201cdri-cpnet.pdf\u201d. Under CP/M 2.2, you will start the networking client using the command CPNETLDR . Under CP/M 3, you use the command NDOS3 . If that works, you can map network drives as local drives using the NETWORK command. The CPNETSTS command is useful for displaying the current status. Here is a sample session from CP/M 2.2: A>cpnetldr CP/NET 1.2 Loader ================= BIOS E600H 1A00H BDOS D800H 0E00H SNIOS SPR D400H 0400H NDOS SPR C800H 0C00H TPA 0000H C800H CP/NET 1.2 loading complete. A>network k:=c:[0] A>dir k: K: TELNET COM : ZDENST COM : CLRDIR COM : RTC COM K: DDTZ COM : MBASIC COM : XSUBNET COM : NETWORK COM K: WGET COM : UNCR COM : FLASH COM : PIP COM K: TIMEZONE COM : COMPARE COM : ZAP COM A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = LOCAL Drive B: = LOCAL Drive C: = LOCAL Drive D: = LOCAL Drive E: = LOCAL Drive F: = LOCAL Drive G: = LOCAL Drive H: = LOCAL Drive I: = LOCAL Drive J: = LOCAL Drive K: = Drive C: on Network Server ID = 00H Drive L: = LOCAL Drive M: = LOCAL Drive N: = LOCAL Drive O: = LOCAL Drive P: = LOCAL Console Device = LOCAL List Device = LOCAL If you are using CpSocketServer to provide the CP/NOS server, then you will see some messages on your server console when clients connect. Here are the messages issued by the server in the above example: Connection from 192.168.1.201 (31100) Remote 192.168.1.201 is f0 Creating HostFileBdos 00 device with root dir /home/wayne/cpnet/root At this point CP/NET is ready for general use. You should be able to access files on the network mapped drives just like files on your local drives. Network Boot It is possible to boot your RomWBW system directly from a network server if it has the required hardware. 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. The supported hardware is: RCBus System w/ MT011 including: Featherwing WizNet W5500 SPI FRAM on secondary SPI interface (CS2) Doudyne Disk I/O Board including: WIZ850io Module 25LCxxx Serial SPI EEPROM Unlike the CP/NET Client, the presence of dedicated non-volatile storage is required to hold the network configuration. This will be FRAM (for MT011) or Serial SPI EEPROM (Duodyne). The NVRAM is used to store your WizNet configuration values so they do not need to be re-entered every time you power-cycle your system. It is important to understand that the operating system that is loaded in this case is not a RomWBW enhanced operating system. Some commands (such as the ASSIGN command) will not be possible. Also, you will only have access to drives provided by the network server \u2013 no local disk drives will be available. Using the same values from the previous example, you would issue the WIZCFG commands: wizcfg n F0 wizcfg i 192.168.1.201 wizcfg g 192.168.1.1 wizcfg s 255.255.255.0 wizcfg 0 00 192.168.1.3 31100 Note that the \u2018w\u2019 parameter is now omitted which causes these values to be written to NVRAM. As before, your network server will need to be running CpnetSocketServer. However, you will need to setup a directory that contains some files that will be sent to your RomWBW system when the Network boot is performed. By default the directory will be ~/NetBoot . In this directory you need to place the following files: cpnos.sys ndos.spr snios.spr You also need to make sure CpnetSocketServer is configured with an \u2018A\u2019 drive and that drive must contain (at an absolute minimum) the following file: ccp.spr All of these files are found in the Binary/CPNET/NetBoot directory of the RomWBW distribution. You will find 2 sub-directories named MT and DUO. Get the files from the sub-directory corresponding to your specific hardware. Finally, you need to add the following line to your CpnetSocketServer configuration file: netboot_default = cpnos.sys To perform the network boot, you start your RomWBW system normally which should leave you at the Boot Loader prompt. The \u2018N\u2019 command will initiate the network boot. Here is an example of what this looks like: RCBus [RCZ180_nat_wbw] Boot Loader Boot [H=Help]: n Loading Network Boot... MT011 WizNET Network Boot WBWBIOS SPR FD00 0100 COBDOS SPR FA00 0300 SNIOS SPR F600 0400 NDOS SPR EA00 0C00 58K TPA A> The CP/M operating system and the CP/NET components have been loaded directly from the network server. All of your drive letters are automatically mapped directly to the drive letters configured with CpnetSocketServer. A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = Drive A: on Network Server ID = 00H Drive B: = Drive B: on Network Server ID = 00H Drive C: = Drive C: on Network Server ID = 00H Drive D: = Drive D: on Network Server ID = 00H Drive E: = Drive E: on Network Server ID = 00H Drive F: = Drive F: on Network Server ID = 00H Drive G: = Drive G: on Network Server ID = 00H Drive H: = Drive H: on Network Server ID = 00H Drive I: = Drive I: on Network Server ID = 00H Drive J: = Drive J: on Network Server ID = 00H Drive K: = Drive K: on Network Server ID = 00H Drive L: = Drive L: on Network Server ID = 00H Drive M: = Drive M: on Network Server ID = 00H Drive N: = Drive N: on Network Server ID = 00H Drive O: = Drive O: on Network Server ID = 00H Drive P: = Drive P: on Network Server ID = 00H Console Device = LOCAL List Device = LOCAL At this point you can use CP/M and CP/NET normally, but all disk access will be to/from the network drives. There is no access to your local disk drives in this boot mode. Transferring Files Transferring files between your modern computer and your RomWBW system can be achieved in a variety of ways. The most common of these are described below. All of these have a certain degree of complexity and I encourage new users to use the available community forums to seek assistance as needed. Serial Port Transfers RomWBW provides an serial file transfer program called XModem that has been adapted to run under RomWBW hardware. The program is called XM and is on your ROM disk as well as all of the pre-built disk images. You can type XM by itself to get usage information. In general, you will run XM with parameters to indicate you want to send or receive a file on your RomWBW system. Then, you will use your modern computers terminal program to complete the process. The XM application generally tries to detect the hardware you are using and adapt to it. However, you must ensure that you have a reliable serial connection. You must also ensure that the speed of the connection is not too fast for XModem to service. If your file transfer attempts are failing, try either of the following: Check that hardware flow control is enabled in your terminal emulation software. Reduce the speed of your serial port connection. There is an odd interaction between XModem and partner terminal programs that can occur. Essentially, after launching XM , you must start the protocol on your modern computer fairly quickly (usually in about 20 seconds or so). So, if you do not pick a file on your modern computer quickly enough, you will find that the transfer completes about 16K, then hangs. The interaction that causes this is beyond the scope of this document. Disk Image Transfers It is possible to pass disk images between your RomWBW system and your modern computer. This assumes you have an appropriate media slot on your modern computer for the media you want to use (CF Card, SD Card, floppy drive, etc.). The general process to get files from your modern computer to a RomWBW computer is: Use cpmtools on your modern computer to create a RomWBW CP/M filesystem image. Insert your RomWBW media (CF Card, SD Card, floppy disk, etc.) in your modern computer. Use a disk imaging tool to copy the RomWBW filesystem image onto the media. Move the media back to the RomWBW computer. This process is a little complicated, but it has the benefit of allowing you to get a lot of files over to your RomWBW system quickly and with little chance of corruption. The process can be run in reverse to get files from your RomWBW computer to a modern computer. The exact use of these tools is a bit too much for this document, but the tools are all included in the RomWBW distribution along with usage documents. Note that the build scripts for RomWBW create the default disk images supplied with RomWBW. It is relatively easy to customize the contents of the disk images that are part of RomWBW. This is described in more detail in the Source/Images directory of the distribution. FAT Filesystem Transfers The FAT filesystem format that originated with MS-DOS is almost ubiquitous across modern computers. Virtually all operating systems now support reading and writing files to a FAT filesystem. For this reason, RomWBW now has the ability to read and write files on FAT filesystems. This capability means that you can generally use your modern computer to make an SD Card, CF Card, or USB Drive with a standard FAT filesystem on it, then place that media in your RomWBW computer and access the files. Files can be copied between a FAT filesystem and a CP/M filesystem, but you cannot execute files directly from a FAT filesystem. FAT12, FAT16, and FAT32 formats are supported. Long filenames are not supported. Files with long filenames will show up with their names truncated into the older 8.3 convention. If you have files on your modern computer with long filenames, it is usually easiest to rename them on the modern computer. A FAT filesystem can be located on floppy or hard disk media. For hard disk media, a valid FAT Filesystem partition must exist. Some additional Notes and WARNINGS Things to be careful about CP/M (and compatible) OSes do not support all of the filename characters that a modern computer does. The following characters are not permitted in a CP/M filename: < > . , ; : = ? * [ ] _ % | ( ) / \\ The FAT application does not auto-rename files when it encounters invalid filenames. It will just issue an error and quit. Additionally, the error message is not very clear about the problem. Microsoft Windows will sometimes suggest reformatting partitions that it does not recognize (e.g. RomWBW). If you are using media that contains both a FAT partition and a RomWBW partition you may prompted to format a partition of your SD/CF/USB Media when inserting the card into a Windows computer, you probably want to select Cancel. FAT Filesystem Preparation In general, you can create media formatted with a FAT filesystem on your RomWBW computer or on your modern computer. We will only be discussing the RomWBW-based approach here. Floppy Disk In the case of a floppy disk, you can use the FAT application to format the floppy disk. The floppy disk must already be physically formatted using RomWBW FDU or equivalent. If your floppy disk is on RomWBW disk unit 2, you could use FAT FORMAT 2: . This will overwrite the floppy with a FAT filesystem and all previous contents will be lost. Once formatted this way, the floppy disk can be used in a floppy drive attached to a modern computer or it can be used on RomWBW using the other FAT tool commands. Hard Disk In the case of hard disk media, it is necessary to have a FAT partition. If you prepared your RomWBW hard disk media using the disk image process, then this partition will already be defined and you do not need to recreate it. This default FAT partition is located at approximately 512MB from the start of your disk and it is 384MB in size. So, your hard disk media must be 1GB or greater to use this default FAT partition. You can confirm the existence of the FAT partition with FDISK80 by using the \u2018P\u2019 command to show the current partition table. Here is an example of a partition table listing from FDISK80 that includes the FAT partition (labelled \u201cFAT16\u201d): Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 FAT16 06 1023:0:1 1023:15:16 1050624 786432 384M 3 00 *** empty *** 4 00 *** empty *** If your hard disk media does not have a FAT partition already defined, you will need to define one using FDISK80 by using the \u2018N\u2019 command. Ensure that the location and size of the FAT partition does not overlap any of the CP/M slice area and that it fits within the size of your media. Once the partition is defined, you will still need to format it. Just as with a floppy disk, you use the FAT tool to do this. If your hard disk media is on RomWBW disk unit 4, you would use FAT FORMAT 4: . This will look something like this: E>fat format 4: About to format FAT Filesystem on Disk Unit #4. All existing FAT partition data will be destroyed!!! Continue (y/n)? Formatting... Done Your FAT filesystem is now ready to use. If your RomWBW system has multiple disk drives/slots, you can also just create a disk with your modern computer that is a dedicated FAT filesystem disk. You can use your modern computer to format the disk (floppy, CF Card, SD Card, etc.), then insert the disk in your RomWBW computer and access it using FAT based on its RomWBW unit number. FAT Application Usage Transferring files is accomplished by running a RomWBW custom application called FAT . This application understands both FAT filesystems as well as CP/M filesystems. To copy files from your modern computer to your RomWBW computer, start by putting the disk media with the FAT filesystem in your modern computer. The modern computer should recognize it. Then copy the files you want to get to your RomWBW computer onto this media. Once done, remove the media from your modern computer and insert it in the RomWBW computer. Finally, use the FAT tool to copy the files onto a CP/M drive. This process works just fine in reverse if you want to copy files from a CP/M filesystem to your modern computer. Complete instructions for the FAT application are found in RomWBW Applications . Here, we will just provide a couple of simple examples. Note that the FAT application is not on the ROM disk because it is too large to include there. The most important thing to understand about the FAT application is how it refers to FAT filesystems vs. CP/M filesystems. It infers this based on the file specification provided. If you use a specification like C:SAMPLE.TXT , it will use the C: drive of your CP/M operating system. If you use a specification like 4:SAMPLE.TXT , it will use the FAT filesystem on the disk in RomWBW disk unit 4. Basically, if you start your file or directory specification with a number followed by a colon, it means FAT filesystem. Anything else will mean CP/M filesystem. Here are a few examples. This first example shows how to get a FAT directory listing from RomWBW disk unit 4: E>fat dir 4: Directory of 4: E> As you can see, there are currently no files there. Now let\u2019s copy a file from CP/M to the FAT directory: E>fat copy sample.txt 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT ... [OK] 1 File(s) Copied If we list the FAT directory again, you will see the file: E>fat dir 4: Directory of 4: 01/30/2023 17:50:14 29952 ---A SAMPLE.TXT Now let\u2019s copy the file from the FAT filesystem back to CP/M. This time we will get a warning about overwriting the file. For this example, we don\u2019t want to do that, so we abort and reissue the command specifying a new filename to use: E>fat copy 4:sample.txt e: Copying... 4:/SAMPLE.TXT ==> E:SAMPLE.TXT Overwrite? (Y/N) [Skipped] 0 File(s) Copied E>fat copy 4:sample.txt e:sample2.txt Copying... 4:/SAMPLE.TXT ==> E:SAMPLE2.TXT ... [OK] 1 File(s) Copied Finally, let\u2019s try using wildcards: E>fat copy sample*.* 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT Overwrite? (Y/N) ... [OK] SAMPLE2.TXT ==> 4:/SAMPLE2.TXT ... [OK] 2 File(s) Copied Customizing RomWBW Startup Command Processing Most of the operating systems supported by RomWBW provide a mechanism to run commands at boot. This is similar to the AUTOEXEC.BAT files from MS-DOS. With the exception of ZPM3 and p-System, all operating systems will look for a file called PROFILE.SUB on the system drive at boot. If it is found, it will be processed as a standard CP/M submit file. You can read about the use of the SUBMIT facility in the CP/M manuals included in the RomWBW distribution. Note that the boot disk must also have a copy of SUBMIT.EXE . Note that the automatic startup processing generally requires booting to a disk drive. Since the ROM disk is not writable, there is no simple way to add/edit a PROFILE.SUB file there. If you want to customize your ROM and add a PROFILE.SUB file to the ROM Disk, it will work, but is a lot harder than using a boot disk. In the case of ZPM3, the file called STARTZPM.COM will be run at boot. To customize this file, you use the ZCPR ALIAS facility. You will need to refer to ZCPR documentation for more information on the ALIAS facility. p-System has its own startup command processing mechanism that is covered in the p-System documentation. NVRAM Configuration See section Setting NVRAM Options for information about how to apply NVRAM configuration. ROM Customization The pre-built ROM images are configured for the basic capabilities of each platform. Additionally, some of the typical add-on hardware for each platform will be automatically detected and used. If you want to go beyond this, RomWBW provides a very flexible configuration mechanism based on configuration files. Creating a customized ROM requires running a build script, but it is quite easy to do. Essentially, the creation of a custom ROM is accomplished by updating a small configuration file, then running a script to compile the software and generate the custom ROM and disk images. There are build scripts for Windows, Linux, and MacOS to accommodate virtually all users. All required build tools (compilers, assemblers, etc.) are included in the distribution, so it is not necessary to setup a build environment on your computer. RomWBW can be built on modern Windows, Linux, or MacOS computers. The process for building a custom ROM is documented in the ReadMe.txt file in the Source directory of the distribution. Any modern version of Windows (32-bit or 64-bit), MacOS, or Linux released in the last 10 years should be able to run the build process. For those who are interested in more than basic system customization, note that all source code is provided (including the operating systems). Modification of the source code is considered an expert level task and is left to the reader to pursue. Note that the ROM customization process does not apply to UNA. All UNA customization is performed within the ROM setup script that is built into the ROM. ROM User Application The User App is provided as a way to access a custom written ROM application. 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 instead, review the \u201cusrrom.asm\u201d file in the Source/HBIOS folder of the distribution. Upgrading Upgrading to a newer release of RomWBW is essentially just a matter of updating the ROM chip in your system. If you have spare ROM chips for your system and a ROM programmer, it is always safest to retain your existing, working ROM chip and program a new one with the new firmware. If the new one fails to boot, you can easily return to the known working ROM. For each ROM that comes with the RomWBW distribution, you will find that there are actually 3 different variants: .rom contains the complete ROM chip image .upd contains the system code, but omits the ROM Disk contents .com contains a CP/M executable version of the ROM code So, for example, RCZ80_std contains the following files: SBC_std.rom SBC_std.upd SBC_std.com The use of the .com variant is described below in Application Boot . As previously discussed, the ROM in most RomWBW systems contains both the system code as well as a ROM Disk with files on it. The .rom variant of the ROM contains a full ROM chip image including both the system code and the Rom Disk contents. The .upd variant of the ROM contains only the system code portion of the ROM. If you apply the .upd variant to your system, it will overlay the system code, but will not overlay the ROM Disk contents (they remain intact). You may use either the .rom or the .upd file when updating your ROM chip (this does not apply to Application Boot). It is best to use the .rom file for your upgrade because the files on your ROM Disk should be updated whenever you update your system code. The advantage of the .upd variant is that is much smaller, so you can upload and apply it faster. The ROM update instructions below generally refer to using the .rom variant. However, you may substitute the .upd variant if desired. Application Boot Prior to attempting to reprogram your actual ROM chip, you may wish to \u201ctry\u201d the update to ensure it will work on your system. With RomWBW, you can upload a new ROM image executable and load it from the command line. For each ROM image file (.rom) in the Binary directory, you will find a corresponding application file (.com). For example, for SBC_std.rom, there is also an SBC_std.com file. You can upload the .com file to your system using XModem, then simply run the .com file. You will see your system go through the normal startup process just like it was started from ROM. However, your physical ROM has not been updated and the next time you boot your system, it will revert to the system image contained in ROM. Using this .com version of a ROM is an excellent way to confirm that the new ROM code you intend to program will work correctly. If it does not, then you can just reboot and your old ROM will be loaded. When the .com file is loaded, you will be taken to the normal Boot Loader menu. However, you will find that the only OS that is available to boot from ROM is ZSDOS. There is only room for a single OS in the .com file. Even if you don\u2019t normally use ZSDOS, this will still confirm that your system operates well under the new ROM code. Upgrading via Flash Utility If you do not have easy access to a ROM programmer, it is usually possible to reprogram your system ROM using the FLASH utility from Will Sowerbutts. This application, called FLASH.COM, can be found on the ROM drive of any running system. In this case, you would need to transfer the new ROM image (.rom) over to your system using XModem (or one of the other mechanisms described in the Transferring Files section). The ROM image is too large to fit on your RAM drive, so you will need to transfer it to a larger storage drive. Once the ROM image is on your system, you can use the FLASH application to update your ROM. The following is a typical example of transferring ROM image using XModem and flashing the chip in-situ. NOTE : The FLASH utility can not determine the type of your ROM chip if it is write protected. Additionally, it has no way to determine if it is write protected. If the FLASH utility indicates it does not recognize your ROM chip, check to ensure the chip is not write protected. E>xm r rom.rom XMODEM v12.5 - 07/13/86 RBC, 28-Aug-2019 [WBW], ASCI Receiving: E0:ROM.IMG 7312k available for uploads File open - ready to receive To cancel: Ctrl-X, pause, Ctrl-X Thanks for the upload E>flash write rom.rom FLASH4 by Will Sowerbutts <will@sowerbutts.com> version 1.2.3 Using RomWBW (v2.6+) bank switching. Flash memory chip ID is 0xBFB7: 39F040 Flash memory has 128 sectors of 4096 bytes, total 512KB Write complete: Reprogrammed 2/128 sectors. Verify (128 sectors) complete: OK! Obviously, there is some risk to this approach since any issues with the programming or ROM image could result in a non-functional system. To confirm your ROM chip has been successfully updated, restart your system and boot an operating system from ROM. Do not boot from a disk device yet. Review the boot messages to see if any issues have occurred. Upgrading via XModem Flash Updater Similar to using the Flash utility, the system ROM can be updated or upgraded through the ROM-based updater utility. This works by reprogramming the flash ROM as the file is being transferred. Using the ROM-based updater has the advantage that secondary storage is not required to hold the new image. In other words, it is not necessary to have a mass storage device available to store the ROM image. From the Boot Loader menu select X (Xmodem Flash Updater) and then U (Begin Update). Then initiate the Xmodem transfer of the .rom file. Since the XModem Flash Updater will be relatively slow, you may wish to use the .upd varient of the ROM. More information can be found in the ROM Applications document. Post Upgrade Update Once you are satisfied that the ROM is working well, you will need to update the system images and RomWBW custom applications on your disk drives. The system images and custom applications are matched to the RomWBW ROM firmware in use. If you attempt to boot a disk or run applications that have not been updated to match the current ROM firmware, you are likely to have odd problems. The simplest way to update your disk media is to just use your modern computer to overwrite the entire media with the latest disk image of your choice. This process is described below in the Disk Images section. If you wish to update existing disk media in your system, you need to perform the following steps. If the disk is bootable, you need to update the system image on the disk using the procedure described in the Operating Systems section of this document. Finally, if you have copies of any of the RomWBW custom applications on your hard disk, you need to update them with the latest copies. The following applications are found on your ROM disk. Use COPY to copy them over any older versions of the app on your disk: ASSIGN.COM SYSCOPY.COM MODE.COM FDU.COM FORMAT.COM XM.COM FLASH.COM FDISK80.COM TALK.COM RTC.COM TIMER.COM FAT.COM For example: B>COPY ASSIGN.COM C: Some RomWBW custom applications are too large to fit on the ROM disk. If you are using any of these you will need to transfer them to your system and then update all copies. These applications are found in the Binary/Apps directory of the distribution and in all of the disk images. TUNE.COM The files normally contained on the standard ROM Disk is based on a 512K ROM. If your system has a smaller size ROM, then not all of these files will be included on your ROM Disk. You will need to copy them to your system from the /Binary/Apps folder of the RomWBW distribution. WARNING : If you run a RomWBW-specific application that is not the appropriate for the version of RomWBW you are running, the application will generate an error message and abort. System Update As previously described, a RomWBW ROM contains ROM applications as well as a ROM disk image. If you are upgrading your ROM with a new patch level release, you may wish to upgrade just the application portion of the ROM. This is referred to as a System Update. If the system running ROMWBW utilizes the SST39SF040 Flash chip then it is possible to do a System Update in place of a System Upgrade in some cases. A System Update would involve only updating the BIOS, ROM applications and ROM-hosted operating systems. A System Update may be more favorable than a System Upgrade in cases such as: Overwriting of the ROM drive contents is not desired. Temporary disk space is unavailable to hold a full ROM image. To reduce the time taken to transfer and flash a full ROM. Configuration changes are only minor and do not impact disk applications. The RomWBW build process generates a system update file along with the normal ROM image and can be identified by the extension \u201c.upd\u201d. It will be 128Kb in size. In comparison the normal ROM image will have the extension \u201c.rom\u201d and be 512Kb or 1024Kb in size. Transferring and flashing the System Update is accomplished in the same manner as described above in Upgrading via Flash Utility with the required difference being that the flash application needs to be directed to complete a partial flash using the /P command line switch. E>FLASH WRITE ROM.UPD /P","title":"User Guide"},{"location":"UserGuide/#preface","text":"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.","title":"Preface"},{"location":"UserGuide/#conventions-used","text":"","title":"Conventions Used"},{"location":"UserGuide/#size-suffixes","text":"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","title":"Size Suffixes"},{"location":"UserGuide/#links-and-urls","text":"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).","title":"Links and URLs"},{"location":"UserGuide/#getting-started","text":"","title":"Getting Started"},{"location":"UserGuide/#installation","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. 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.","title":"Installation"},{"location":"UserGuide/#system-startup","text":"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.","title":"System Startup"},{"location":"UserGuide/#core-system-information","text":"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.","title":"Core System Information"},{"location":"UserGuide/#hardware-discovery","text":"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.","title":"Hardware Discovery"},{"location":"UserGuide/#device-unit-assignments","text":"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.","title":"Device Unit Assignments"},{"location":"UserGuide/#startup-example","text":"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 <enter> for help. You can type L <enter> 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.","title":"Startup Example"},{"location":"UserGuide/#boot-loader-operation","text":"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 \\<enter> . For example, typing H<enter> will display a short command summary: Boot [H=Help]: h L - List ROM Applications D - Device Inventory R - Reboot System W - RomWBW Configure I <u> [<c>] - Set Console Interface/Baud Rate V [<n>] - View/Set HBIOS Diagnostic Verbosity <u>[.<s>] - 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 .","title":"Boot Loader Operation"},{"location":"UserGuide/#starting-applications-from-rom","text":"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.","title":"Starting Applications from ROM"},{"location":"UserGuide/#starting-operating-systems-from-disk","text":"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 ( \\<diskunit> ) and optionally a dot followed by a second number ( \\<slice> ). The \\<disk unit> 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 \\<slice> 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 \\<enter> . Boot [H=Help]: 4 Booting Disk Unit 4, Slice 0, Sector 0x00000800... Volume \"Unlabelled\" [0xD000-0xFE00, entry @ 0xE600]... CBIOS v3.1.1-pre.194 [WBW] Formatting RAMDISK... Configuring Drives... A:=IDE0:0 B:=MD0:0 C:=MD1:0 D:=FD0:0 E:=FD1:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 I:=PRPSD0:0 J:=PRPSD0:1 K:=PRPSD0:2 L:=PRPSD0:3 1081 Disk Buffer Bytes Free CP/M-80 v2.2, 54.0K TPA A> Notice that a list of drive letters and their assignments to RomWBW devices and slices is displayed during the initialization of the operating system. Here is another example where we are booting disk unit 4, slice 3 which is the CP/M 3 operating system on this disk: Boot [H=Help]: 4.3 Booting Disk Unit 4, Slice 3, Sector 0x0000C800... Volume \"Unlabelled\" [0x0100-0x1000, entry @ 0x0100]... CP/M V3.0 Loader Copyright (C) 1998, Caldera Inc. BNKBIOS3 SPR F600 0800 BNKBIOS3 SPR 4500 3B00 RESBDOS3 SPR F000 0600 BNKBDOS3 SPR 1700 2E00 60K TPA CP/M v3.0 [BANKED] for HBIOS v3.5 A> Some operating systems (such as CP/M 3 shown above) do not list the drive assignments during initialization. In this case, you can use the ASSIGN command to display the current assignments. The Boot Loader simply launches whatever is in the disk unit/slice you have specified. It does not know what operating system is at that location. The layout of operating systems on disk media is described in the Disk Images section of this document.","title":"Starting Operating Systems from Disk"},{"location":"UserGuide/#auto-submit-batch-files","text":"All of the operating systems supplied with RomWBW have the ability to execute a \u201cbatch\u201d of commands by creating a batch submission file containing the commands to be executed. The mechanism for running commands automatically at startup varies by operating system. In some cases, it was built into the original operating system. In other cases, I have added this capability in the RomWBW BIOS of the operating system. In all cases, the file containing the commands to run at startup must be on the boot drive (A:). RomWBW automatically assigns A: to the disk slice you choose to boot. Adding a startup command file to the ROM Disk is not recommended because it would require customizing and building a new ROM. Use of bootable disk slices is preferred since the startup command files can be added/edited without any special system customization. Here is an overview for each operating system: CP/M 2.2 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Note that original CP/M 2.2 itself did not have this ability \u2013 it was added to the RomWBW CP/M 2.2 BIOS. The use of SUBMIT files is documented in Section 1.6.7 SUBMIT Command of the CPM Manual included in the Doc/CPM folder of the RomWBW distribution. Z-System (ZSDOS 1.1) - Will run run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. Works exactly the same as CP/M 2.2. The original Z-System ZSDOS 1.1 did not have this ability \u2013 it was added to the RomWBW Z-System BIOS. The Z-System documentation does not cover the use of SUBMIT files \u2013 please refer to the CP/M 2.2 documentation. NZCOM - Will run the command STARTZCM at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the NZCOM Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the NZCOM boot process. Note that NZCOM itself is launched from ZSDOS via the included PROFILE.SUB file. CP/M 3 - Will run PROFILE.SUB as a SUBMIT file if it exists in A: at startup. This mechanism is built into the CP/M 3 operating system. Please see Section 4.5 Executing Multiple Commands and Section 5.2.74 Executing the SUBMIT Command of the CPM3 Users Guide included in the Doc/CPM folder of the RomWBW distribution. Z3PLUS - Will run the command STARTZ3P at startup. This is normally an alias file, which you can edit using SALIAS. Please see Section 3.1 Creating an Alias of the Z3PLUS Users Manual included in the Doc/CPM folder of the RomWBW distribution. Do not modify this file unless you fully understand the Z3PLUS boot process. Note that Z3PLUS itself is launched from CP/M 3 via the included PROFILE.SUB file. ZPM3 - Will run the command STARTZPM at startup. This is normally an alias file. You use SALIAS to edit such files. ZPM3 has no real documentation. The NZCOM documentation of STARTZCM is generally correct for ZPM3. Since RomWBW can utilize many disk slices, it is very easy to create slices for specific workflows (editing, software development, games, etc.). You can then just boot to the slice that is optimized for the task you want to perform. Each such slice may have its own startup command batch file that customizes the environment for the specific workflow desired.","title":"Auto-Submit Batch Files"},{"location":"UserGuide/#system-management","text":"","title":"System Management"},{"location":"UserGuide/#listing-device-inventory","text":"The device units available in your system are listed in the boot messages. However, if that list has scrolled off of your screen, you can use the \u2018D\u2019 command to display a list of them at any time from the Boot Loader prompt. Unit Device Type Capacity/Mode ---------- ---------- ---------------- -------------------- Char 0 ASCI0: RS-232 38400,8,N,1 Char 1 ASCI1: RS-232 38400,8,N,1 Char 2 UART0: RS-232 38400,8,N,1 Char 3 UART1: RS-232 38400,8,N,1 Char 4 UART2: RS-232 38400,8,N,1 Char 5 UART3: RS-232 38400,8,N,1 Char 6 TERM0: Terminal Video 0,ANSI Char 7 PRPCON0: Terminal Term Module,ANSI Disk 0 MD0: RAM Disk 352KB,LBA Disk 1 MD1: Flash Drive 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 IDE2: CompactFlash 3823MB,LBA Disk 7 IDE3: Hard Disk -- Disk 8 IDE4: Hard Disk -- Disk 9 IDE5: Hard Disk -- Disk 10 SD0: SD Card -- Disk 11 PRPSD0: SD Card 15193MB,LBA Video 0 TMS0: CRT Text,40x24 Sound 0 SND0: AY-3-8910 3+1 CHANNELS","title":"Listing Device Inventory"},{"location":"UserGuide/#rebooting-the-system","text":"The \u2018R\u2019 command within the Boot Loader performs a software reset of the system. The system will perform a startup just like powering up or pressing the hardware reset button (although the hardware is not physically reset). There is generally no need to do this, but it can be convenient when you want to see the boot messages again or ensure your system is in a clean state. Boot [H=Help]: r Restarting System...","title":"Rebooting the System"},{"location":"UserGuide/#setting-nvram-options","text":"On systems with RTC devices (that have Non-Volatile RAM), RomWBW supports storing some limited configuration option options inside this NVRAM. Several configuration options are currently supported, these are known as Switches Specify Automatic boot at startup, after an optional delay (AB) Define the Disk or ROM App to be booted at for automatic boot (BO) RomWBW uses bytes located at the start of RTC NVRAM, and includes a checksum of the bytes in NVRAM to check for integrity before using the configuration. Initially NVRAM has to be reset (with default values), before it can be used. As well as setting defaults, it also writes the correct checksum, and allows the NVRAM to be accessed and to store the RomWBW config. This is an explicit step that must be done, as any existing data stored is overwritten. If you are using NVRAM for other purposes, then you can continue to do so so long as you do NOT perform this Reset step. NVRAM may also need to be reset in these circumstances: When there has been a loss of power to the NVRAM. When upgrading to a new RomWBW version, or a RomWBW version that has new switches. If the NVRAM has been overwritten by another application. If you want to continue to use NVRAM in your applications you may want to consider storing your data above the RomWBW Switch data. To configure these options an inbuilt ROM application is provided which can be accessed by the command \u201c W \u201d from the RomWBW boot menu. This application is also built as a CP/M utility, but is not included on an disk image, it is found in the Binary/Applications folder of the RomWBW distribution. For further guidance on using this application please see the section \u201cRomWBW System Configuration\u201d in the RomWBW Applications document. If your system has both a Front Panel as well as NVRAM, be aware that the Front Panel switches take precedence over the NVRAM configuration settings. Note that the WizNet class of Network devices also contain NVRAM which is entirely separate from the RomWBW configuration NVRAM described here. A separate utility is used to set the WizNet NVRAM (see CP/NET Client Setup ). RomWBW Applications","title":"Setting NVRAM Options"},{"location":"UserGuide/#changing-console-and-console-speed","text":"Your system can support a number of devices for the console. They may be VDU type devices or serial devices. If you want to change which device is the console, the I menu option can be used to choose the unit and its speed. The command format is I <unit> [<baudrate>] where \\<unit> is the character unit to select and \\<baudrate> is the optional baud rate. Supported baud rates are: 75 450 1800 7200 38400 115200 460800 1843200 150 600 2400 9600 28800 153600 614400 2457600 225 900 3600 14400 57600 230400 921600 3686400 300 1200 4800 19200 76800 307200 1228800 7372800 Here is an example of changing the console to unit #1 (the second serial port) and switching the port to 9600 baud: Boot [H=Help]: i 1 9600 Change speed now. Press a key to resume. Console on Unit #1 At this point, the Boot Loader prompt will be displayed on character unit #1. Note that not all character devices support changing baud rates and some only support a limited subset of the baud rates listed. If you attempt to select an invalid baud rate for your system, you will get an error message.","title":"Changing Console and Console Speed"},{"location":"UserGuide/#hbios-diagnostic-verbosity","text":"The \u2018V\u2019 command of the Boot Loader allows you to view and optionally change the level of diagnostic messages that RomWBW will produce. The normal verbosity level is 4, which means to display only fatal errors. You can increase this level to see more warnings when function calls to RomWBW HBIOS detect problems. The use of diagnostic levels above 4 are really intended only for software developers. I do not recommend changing this under normal circumstances.","title":"HBIOS Diagnostic Verbosity"},{"location":"UserGuide/#console-takeover","text":"If your system has more than one character unit, then the Boot Loader will \u201cpoll\u201d all of the character devices for a request to make any of the alternate character devices the active console. This is called a console takeover request. This functionality must be enabled in the ROM build configuration, but currently it is for all standard ROMs. To request a console takeover, you just press the \\<space> character twice in a row at the port or terminal that you want to move the console to. The terminal or communication software must be configured for the default serial port speed and data bits for this to work. A takeover request is only possible while the active console is showing the Boot Loader prompt prior to typing any characters at the active console. In other words, once you start typing at the active console prompt, the takeover polling is suspended. If you have started typing characters, you can press \\<enter> at the active console to get a fresh Boot Loader prompt and reactivate the polling. If you have built a custom ROM that includes an automatic boot command with a timeout, then performing a console takeover will abort the timeout process and the automatic boot command will not be performed.","title":"Console Takeover"},{"location":"UserGuide/#front-panel","text":"RomWBW supports the concept of a simple front panel. The following image is a conceptual view of such a front panel. If your system has a front panel, it should look similar to the RomWBW Front Panel . RomWBW Front Panel The LEDs in the top row of the panel are used for multiple purposes. They are initially used to display the progress of the system boot. This may help in diagnosing a hardware or configuration issue in a system that does not progress far enough to display text output on the console. The meaning of the LEDs is: O------- System Boot has started OO------ Common RAM bank activated OOO----- HBIOS transitioned to RAM OOOO---- Basic initialization done OOOOO--- CPU detection complete OOOOOO-- System timer configured OOOOOOO- Pre-console device init done OOOOOOOO Console activation Once the system has booted, the LEDs are used to indicate disk device activity. Each LED numbered 7-0 represents disk units 7-0. As each disk device performs I/O, the LED will light while the disk is active. This is only possible for the first 8 disk units. The second row of the front panel is composed of switches that allow you to control a few aspects of the system startup. The switches are also re-read during warm boot, so confirm the switch settings are your desired boot configuration before executing \u2018REBOOT /W\u2019. The first two switches affect the device used as the initial console. CRT/Serial Sec/Pri Explanation CRT Pri Primary Cathode Ray Tube device (high speed console) CRT Sec Secondary Cathode Ray Tube device (high speed console) Serial Pri Boot Console is Primary Serial Port Serial Sec Boot Console is Secondary Serial Port If not available (default): \u201cChar Unit 0\u201d is used The final six switches allow you to select the desired boot device. Auto / Menu Disk / ROM Floppy / Hard ROM/App/Boot Slice 4 2 1 Explanation Menu \u2013 \u2013 \u2013 \u2013 \u2013 Boot to RomWBW Menu Auto Disk Floppy # # # Boot Selected Floppy Disk Index Auto Disk Hard # # # Boot Selected Hard Disk Index Auto ROM \u2013 # # # Boot selected ROM Index If not available: Boot Loader Command Prompt \u2018\u2013\u2019 Ignored \u2018#\u2019 bit flag to select any three bits 4,2,1 ROM or Hard Disk - First 8 Drive Images 4 2 1 Floppy / Hard Drive Index ROM Index 0 0 0 Zero Monitor 0 0 1 One BASIC 0 2 0 Two Forth 0 2 1 Three Game 4 0 0 Four CP/M 4 0 1 Five Z-System 4 2 0 Six Net Boot 4 2 1 Seven User","title":"Front Panel"},{"location":"UserGuide/#disk-management","text":"The systems supported by RomWBW all have the ability to use persistent disk media. Some systems have disk interfaces built-in, while others will require add-in cards. You will need to refer to the documentation for your system for your specific options. The RomWBW firmware provides a hardware abstraction layer, All disks will work on all hardware variations. This means you can remove disk media from one RomWBW system and put it in a different RomWBW system. The only constraint is that the applications on the disk media must be up to date with the firmware on the system being used.","title":"Disk Management"},{"location":"UserGuide/#key-terminologyconcepts","text":"The following important terminology applies","title":"Key Terminology/Concepts"},{"location":"UserGuide/#disk-or-disk-drive","text":"The hardware storage device that RomWBW talks to. RomWBW supports a variety of storage disk device types. ROM Disk - RomWBW firmware - containing CPM utilities RAM Disk - A section of system RAM initially empty Floppy Disk(s) - Removable media Hard Disk(s) - Includes CF Cards, SD Cards, USB Stick, etc. The different disk types are further defined in the section Disk Types .","title":"Disk (or Disk Drive)"},{"location":"UserGuide/#media","text":"The storage device inserted into a disk drive, e.g. a floppy disk, CF Card, SD Card, etc.","title":"Media"},{"location":"UserGuide/#slice","text":"For hard disks a Slice is a smaller logical block of disk space that is allocated and formatted with a filesystem and typically allocated to a Drive letter. Slices allow large modern storage media to be sliced up into smaller units compatible with CP/M. Slices should not be confused with partitions, a slice is not a partition. The concept of slices is described in detail in the section Hard Disk Slices .","title":"Slice"},{"location":"UserGuide/#drive","text":"The mapping of a hardware disk (and slice) to a Drive letter in an operating system. A Drive has a file system installed on it","title":"Drive"},{"location":"UserGuide/#disk-image","text":"A disk image is a predefined image of a complete CP/M filesystem, or filesystem(s), including any partition tables (for hard disk images). Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. This comes in for form of a file which is suitable for copying directly onto target media, using a modern computer. It is generally easier to use these disk images than transferring files over individually. See the section Disk Images for further details.","title":"Disk Image"},{"location":"UserGuide/#startup-hardware-discovery","text":"During startup RomWBW performs detection for hardware supported by your platform. During startup you will see messages for any disk interface(s), listing device types (e.g. FD:, IDE:, SD:), and any media that has been found on these interfaces. The messages you see will vary depending on your hardware and the media you have installed. As an example, here are the messages you might see if you have an IDE interface in your system with a single disk drive connected to the primary side of the interface: IDE: IO=0x80 MODE=MK4 IDE0: 8-BIT LBA BLOCKS=0x00773800 SIZE=3815MB IDE1: NO MEDIA See RomWBW Hardware for a complete list of the different device types supported. If you do not see drive letters assigned as expected, refer to the prior system boot messages to ensure media has been detected in the interface. Each drive letter refers back to a specific disk hardware interface like IDE0. This is important as it is telling you what each drive letter refers to. Mass storage disks (like IDE) will normally have multiple drive letters assigned. The extra drive letters refer to additional \u201cslices\u201d on the disk. Once your system has working disk devices, they will be accessible from any operating system you choose to run. Disk storage is available whether you boot your OS from ROM or from the disk media itself.","title":"Startup Hardware Discovery"},{"location":"UserGuide/#drive-letter-assignment","text":"In legacy CP/M operating systems only 16 drive letters (A:-P:) available to be assigned to disks Drive letters were generally mapped to disk drives in a completely fixed way. For example, drive A: would always refer to the first floppy disk drive. RomWBW implements a much more flexible drive letter assignment mechanism so that any drive letter can dynamically be assigned to any disk device, or slice of media. For clarification, CP/M cannot refer directly to disk devices, CP/M only understands drive letters, so to access a given disk device it must first be assigned to a drive letter. As the operating system starts up, you should see a list of drive letters assigned to the disk media you have installed. Here is an example of the list of drive letter assignments made during the startup of Z-System: Configuring Drives... A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 Above you can see that: Drive A: has been assigned to MD0 which is the RAM disk device. Drive B: has been assigned to MD1 which is the ROM disk device. Drives C: and D: have been assigned to floppy disk drives. Drives E: thru H: have been assigned to the IDE0 hard disk device. The 4 entries for IDE0 are referring to the first 4 slices on that disk. CP/M 3 and ZPM3 do not automatically display the assignments at startup, but you can use ASSIGN to display them. The assignments at boot will stay the same on each boot as long as you do not make changes to your hardware configuration. i.e. If you insert or remove an SD Card, CF Card or USB Stick, the drive assignments will change at next boot. Since drive letter assignments can change, you must be careful when doing destructive things like using CLRDIR to make sure the drive letter you use is referring to the desired media. Drive assignments can be changed at any time, by the ASSIGN command. Please see the section Assign Drive Letters for further details.","title":"Drive Letter Assignment"},{"location":"UserGuide/#default-drive-letters","text":"When an operating system is booted, RomWBW will automatically assign drive letters to disk devices. The assignment process varies depending on: the disk/slice you choose to boot from, and the number, type, and sizes of mass storage devices available at boot The A: drive letter is considered special by most CP/M operating systems and is automatically used in some cases. e.g. submitting batch files, and is expected to be a writable volume. If you boot to a physical disk device, then the first drive letter (A:) will be assigned to the disk/slice that you are booting from, and the rest of the drive letters will be offset to accommodate this. By making the selected disk/slice the A: drive, you can setup different disks/slices for specific uses and just boot it, and the booted operating system will be the A: drive However when performing a ROM boot of an operating system, the first two drive letters will be assigned to your RAM disk (A:) and your ROM disk (B:). This provides the maximum compatibility with CP/M. After the first drive letter is assigned (as well as the second drive letter in the case of a ROM boot), RomWBW will assign additional drive letters based on the disk drives in the system. Additional drive letters will be assigned in the following order: RAM Disk ROM Disk Floppy Disk(s) Hard Disk(s) If a disk/slice was already assigned as the A: (or B:) drive letter, then it will not be assigned again. Floppy or removable disk drives will be assigned a drive letter regardless of whether there is any media inserted at the time of boot. In the case of hard disks, 1-8 drive letters will be assigned to the initial 1-8 slices of the disk drive. The number of drive letters assigned to each hard disk depends on the number of hard disks in the system: 1 Hard Disk: 8 drive letters (slices) 2 Hard Disks: 4 drive letters (slices) per disk 3+ Hard Disks: 2 drive letters (slices) per disk This somewhat complicated algorithm is used to try and maximize the limited number of operating system drive letters available (16) to the available disk devices as evenly as possible. For hard disk devices which are treated as non-removable media, drive letters will only be assigned to disk devices that actually contain media. i.e. No drive letters will be assigned to an SD Card slot that has no SD Card inserted.","title":"Default Drive Letters"},{"location":"UserGuide/#assign-drive-letters","text":"The ASSIGN command is used to view or change the current drive letter mappings. Any changes made to drive letter mappings take immediate effect Refer to RomWBW Applications for more information on use of the ASSIGN command. Since drive letter assignments are easily changed at any time using the ASSIGN command, you can customize your assignments as desired after starting the operating system. Even better, you can use an auto-submit batch file to customzie the assignments at startup without any user intervention.","title":"Assign Drive Letters"},{"location":"UserGuide/#disk-operationscommands","text":"With some understanding of how RomWBW presents disk space to the operating systems, we need to go over the options for actually setting up your disk(s) with content.","title":"Disk Operations/Commands"},{"location":"UserGuide/#preparing-media-for-first-use","text":"You can initialize the media in-place using your RomWBW system. Essentially, this means you are creating a set of blank directories on your disk so that files can be saved there. This is somewhat analogous to partitioning of a hard disk or doing a low level format of a floppy disk. Initilizing a Floppy disk is covered in the section Floppy Disk Formatting , or for a Hard disk the section Hard Disk Preparation covers the steps to manually setup a hard disk for first use.","title":"Preparing Media for First Use"},{"location":"UserGuide/#clearing-formatting-drives","text":"This is somewhat analogous to doing a FORMAT operation on other systems. With RomWBW you use the CLRDIR command to do this. This command is merely \u201cclearing out\u201d the directory space of the drive referred to by a drive letter and setting up the new empty directory. Refer to RomWBW Applications for more information on use of the CLRDIR command. Since CLRDIR works on drive letters, make absolutely sure you know what media and slice are assigned to that drive letter before using CLRDIR because CLRDIR will wipe out any pre-existing contents of the slice. After CLRDIR completes, the slice should be ready to use by the operating system via the drive letter assigned. Start by using the DIR command on the drive. This should return without error, but list no files. Here is an example of using CLRDIR . In this example, the ASSIGN command is used to show the current drive letter assignments. Then the CLRDIR command is used to initialize the directory of drive \u2018G\u2019 which is slice 2 of hard disk device IDE0 (\u201cIDE0:2\u201d). B>ASSIGN A:=MD0:0 B:=MD1:0 C:=FD0:0 D:=FD1:0 E:=IDE0:0 F:=IDE0:1 G:=IDE0:2 H:=IDE0:3 B>CLDIR G: CLRDIR Version 1.2B May 2024 by Max Scane Warning - this utility will overwrite the directory sectors of Drive: G Type CAPITAL Y to proceed, any key other key to exit. Y Directory cleared. B>","title":"Clearing (Formatting) Drives"},{"location":"UserGuide/#checking-disk-layout","text":"If you are not sure which disk layout is used for your existing media, you can use the CP/M 2.2 STAT command to display information including the number of \u201c32 Byte Directory Entries\u201d for a drive letter on the corresponding hard disk. If it indicates 512, your disk layout is legacy (hd512). If it indicates 1024, your disk layout is modern (hd1k). Here is an example of checking the disk layout. B>STAT E:DSK: E: Drive Characteristics 65408: 128 Byte Record Capacity 8176: Kilobyte Drive Capacity 1024: 32 Byte Directory Entries 0: Checked Directory Entries 256: Records/ Extent 32: Records/ Block 64: Sectors/ Track 2: Reserved Tracks It is critical that you include DSK: after the drive letter in the STAT command line. The important line to look at is labeled \u201c32 Byte Directory Entries\u201d.","title":"Checking Disk Layout"},{"location":"UserGuide/#disk-types","text":"","title":"Disk Types"},{"location":"UserGuide/#ram-rom-disks","text":"A typical RomWBW system has 512KB of ROM and 512KB of RAM. Some portions of each are dedicated to loading and running applications and operating system. The space left over is available for an operating system to use as a pseudo-disk device (ROM Disk and RAM Disk). Unlike other types of disk devices, ROM and RAM Disks do not contain an actual operating system and are not \u201cbootable\u201d. However, they are accessible to any operating system (whether the operating system is loaded from ROM or a different disk device). Neither RAM nor ROM disks require explicit formatting or initialization. ROM disks are pre-formatted and RAM disks are formatted automatically with an empty directory when first used.","title":"RAM &amp; ROM Disks"},{"location":"UserGuide/#ram-disk","text":"The RAM disk provides a small CP/M filesystem that you can use for the temporary storage of files. Unless your system has a battery backed mechanism for persisting your RAM contents, the RAM disk contents will be lost at each power-off. The RAM disk is an excellent choice for storing temporary files because it is very fast. You will notice that the first time an operating system is started after the power was turned off, you will see a message indicating that the RAM disk is being formatted. If you reset your system without turning off power, the RAM disk will not be reformatted and it\u2019s contents will still be intact.","title":"RAM Disk"},{"location":"UserGuide/#rom-disk","text":"Like the RAM disk, the ROM disk also provides a small CP/M filesystem, but it\u2019s contents are static \u2013 they are part of the ROM. As such, you cannot save files to the ROM disk. Any attempt to do this will result in a disk I/O error. The contents of the ROM disk have been chosen to provide a core set of tools and applications that are helpful for either CP/M 2.2 or ZSDOS. Since ZSDOS is CP/M 2.2 compatible, this works fairly well. However, you will find some files on the ROM disk that will work with ZSDOS, but will not work on CP/M 2.2. For example, LDDS , which loads the ZSDOS date/time stamper will only run under ZSDOS.","title":"ROM Disk"},{"location":"UserGuide/#flash-rom-disks","text":"The limitation of ROM disks being read-only can be overcome on some platforms with the appropriate selection of Flash ROM chip and system configuration. In this case the flash-file system can be enabled which will allow the ROM disk to be read and written to. Flash devices have a limited write lifespan and continual usage will eventually wear out the device. It is not suited for high usage applications. Enabling ROM disk writing requires building a custom ROM.","title":"Flash ROM Disks"},{"location":"UserGuide/#floppy-disks","text":"If your system has the appropriate hardware, RomWBW will support the use of floppy disks. The supported floppy disk formats are generally derived from the IBM PC floppy disk formats: 5.25\u201d 360K Double-sided, Double-density 5.25\u201d 1.2M Double-sided, High-density 3.5\u201d 720K Double-sided, Double-density 3.5\u201d 1.44M Double-sided, High-density When supported, RomWBW is normally configured for 2 3.5\u201d floppy disk drives. If a high-density disk drive is used, then RomWBW automatically detects and adapts to double-density or high-density media. It cannot automatically detect 3.5\u201d vs. 5.25\u201d disk drive types \u2013 the ROM must be pre-configured for the disk drive type. WARNING: Some of the operating systems provided with RomWBW require that a soft-reset be performed when swapping floppy disk media. For example, under CP/M 2.2, you must press control-C at the CP/M prompt after inserting a new floppy disk. The consequences of failing to perform the soft-reset vary from unexpected error messages to full disk directory corruption.","title":"Floppy Disks"},{"location":"UserGuide/#hard-disks","text":"The concept of a hard disk in RomWBW applies to any storage device that provides at least 8MB of space. The actual media can be a real spinning hard disk, a CompactFlash Card, a SD Card, etc. In this document, the term hard disk will apply equally to all of these. The vintage operating systems included with RomWBW were produced at a time when mass storage devices were quite small. CP/M 2.2 could only handle filesystems up to 8MB. Since storage devices today are quite large, RomWBW implements a mechanism called slicing (see Hard Disk Slices ) to allow up to 256 8MB CP/M filesystems on a single large storage device, where each slice can be assigned to a drive letter in CPM, and be treated as its own hard disk drive (from a CPM perspective). In order to achieve compatibility across all of the operating systems supported by RomWBW, the hard disk filesystem format used is 8MB. This ensures any filesystem will be accessible to any of the operating systems. RomWBW uses Logical Block Addressing (LBA) to interact with all hard disks. The RomWBW operating systems use older Cylinder/Head/Sector (CHS) addressing. To accommodate the operating systems, RomWBW emulates CHS addressing. Specifically, it makes all hard disks look like they have 16 sectors and 16 heads. The number of tracks varies with the size of the physical hard disk.","title":"Hard Disks"},{"location":"UserGuide/#hard-disk-layouts","text":"When RomWBW uses a hard disk, it utilizes an area of the physical hard disk drive space to store a sequential series of slices that contain the actual CP/M filesystems referred to by drive letters by the operating system. Two hard disk layout schemes exist: Modern (hd1k) Legacy (hd512) You cannot mix disk layouts on a single disk device, however It is perfectly fine for one system to have multiple hard disks with different layouts \u2013 each physical disk device is handled separately. If you are setting up a new disk, the modern (hd1k) layout is recommended for the following reasons: Larger number of directory entries per filesystem Simplifies creation of coresident FAT filesystem Reduces chances of data corruption Each slice occupies exactly 8MB (an exact power of 2) in size Both the legacy and modern disk layouts continue to be fully supported by RomWBW. There are no plans to deprecate the legacy layout.","title":"Hard Disk Layouts"},{"location":"UserGuide/#modern-layout","text":"RomWBW (Starting with v3.2) supports the use of disk partitioning, utilising a Master Boot Record (MBR) partition tables. The Wikipedia article on the Master Boot Record is excellent if you are not familiar with them. RomWBW uses the partition type id 0x2E . This partition type id does not equate to any existing well-known partition types \u2013 it was chosen because it is not generally used. RomWBW does not support extended partitions \u2013 only a single primary partition can be used. The existence of a partition table entry for RomWBW on a hard disk makes it behave in the modern mode. Removing the RomWBW partition entry from a modern hard disk layout will cause the existing data to be unavailable and/or corrupted The CP/M filesystem in the slices of the modern disk layout contain 1024 directory entries.","title":"Modern Layout"},{"location":"UserGuide/#legacy-layout","text":"Originally, RomWBW always used the very start of the hard disk media for the location of the slices. In this layout, slice 0 referred to the first chunk of ~8MB on the disk, slice 1 referred to the second chunk of ~8MB on the disk, and so on. The number of slices is limited to the size of the disk media \u2013 if you attempted to read/write to a slice that would exceed the disk size, you would see I/O errors. The legacy format takes steps to allow a partition table to still be used for other types of filesystems such as DOS/FAT. It just does not use a partition table entry to determine the start of the RomWBW slices. The lack of a RomWBW partition table entry will cause legacy behaviour. Adding a partition table entry on an existing legacy RomWBW hard disk will cause the existing data to be unavailable and/or corrupted. The CP/M filesystem in the slices of the legacy disk layout contain 512 directory entries.","title":"Legacy Layout"},{"location":"UserGuide/#hard-disk-slices","text":"RomWBW implements a mechanism called slicing to allow multiple CP/M filesystem on a single large storage device. To say it another way, the media is \u201csliced up\u201d into many CP/M filesystems. You cannot use slices on any media less than 8MB in size. Specifically, you cannot slice RAM disks, ROM disks, floppy disks, etc. All of these are considered to have a single slice (0) It is very important to understand that RomWBW slices are not individually created or allocated on your hard disk. RomWBW uses a single partition on your hard disk to contain the slices. You should think of slices as just an index into a sequential set of 8MB areas that exist in this partition. RomWBW allows up to up to 256 slices each of 8MB in size on a single large storage device. This allows the use of up to 2GB of usable space on one media device. It is possible to create other partitions (typically FAT), for now, we are just talking about the slices within the single RomWBW partition.","title":"Hard Disk Slices"},{"location":"UserGuide/#slice-assignment","text":"When assigning Hard disks to drive letters you also need to assign the slice. Referring to slices within a storage device is done by appending a :<n> where \\<n> is the device relative slice number from 0-255. For example, if you have an IDE device, it will show up as IDE0: in the boot messages meaning the first IDE device. To refer to the fourth slice of IDE0, you would type \u201cIDE0:3\u201d. Here are some examples: IDE0:0 First slice of disk in IDE0 IDE0: First slice of disk in IDE0 IDE0:3 Fourth slice of disk in IDE0 So, if you wanted to use drive letter L: to refer to the fourth slice of IDE0, you could use the command ASSIGN L:=IDE0:3 . There are a couple of rules to be aware of when assigning drive letters. First, you may only refer to a specific device/slice with one drive letter at a time. Said another way, you cannot have multiple drive letters referring to a the same device/slice at the same time. Second, there must always be a drive assigned to A:. Any attempt to violate these rules will be blocked by the ASSIGN command. As you see, the name of a slice does not reference the hard disk partition containing the slices. Since there can only be a single RomWBW partition containing slices on any disk, the partition is determined automatically. RomWBW does not prevent you from assigning slices to drive letters even if the location of the slice does not fit on the physical disk. Any attempt to access a drive letter mapped to a slice that does not fit will result in an error such as \u201cno disk\u201d from the operating system. For example, a 64MB CF Card (which is typically a bit smaller than 64MB) will only fit 7 slices. At startup, you will typically see 8 drive letters assigned to the CF Card. Attempting to access the last drive letter will result in a \u201cno disk\u201d error from the operating system.","title":"Slice Assignment"},{"location":"UserGuide/#hard-disk-capacity","text":"The exact number of CP/M filesystem slices that will fit on your specific physical hard disk can be determined as follows: For modern (hd1k) disk layouts, it is 1024KB + (slices * 8192KB). Or equivalent to say 1MB + (slices * 8MB). For legacy (hd512) disk layouts, it is slices * 8,320KB. WARNING : In this document KB means 1024 bytes and MB means 1048576 bytes (frequently expressed as KiB and MiB in modern terminology). In general, hard disk capacities use KB to mean 1000 bytes and MB to mean 1,000,000 bytes. As an example, A \u201c64MB\u201d CF Card probably has less than 62.5MB of actual space (using the RomWBW definition that 1MB is 1048576 bytes). Such a drive will not support 8 slices. It will support 7 slices just fine because 1024KB + (7 * 8192MB) = 57MB (hd1k) or 7 * 8,320KB = 58.24MB (hd512) Although you can use up to 256 slices per physical disk, equating to 2GB of storage this large number of slices is rarely used. It is recommended that hard disk media used with RomWBW be 1GB or greater in capacity. This will support the RomWBW Combo Disk Image (see Combo Hard Disk Image ) that allows you to use 64 CP/M filesystem slices and a 384KB FAT filesystem.","title":"Hard Disk Capacity"},{"location":"UserGuide/#disk-preparation","text":"There are two approaches to preparing disks for use by RomWBW. Manual : Use RomWBW itself to format empty disks and then transfer files over to the disks. Images : Use a modern computer to write a pre-built disk image including files to a disk. This section of the document describes the manual process of preparing empty disks that are ready for use by an operating system. Alternatively, you can use the pre-built RomWBW disk images to quickly create disk media that already has a large selection of files and bootable operating system slices. Using images to prepare a disk is documented in Disk Images . You do not need to follow the instructions in this section if you want to use disk images.","title":"Disk Preparation"},{"location":"UserGuide/#floppy-disk-formatting","text":"Floppy media must be physically formatted before it can be used. This is normally accomplished by using the supplied Floppy Disk Utility FDU application. This application interacts directly with your hardware and therefore you must specify your floppy interface hardware at application startup. Additionally, you need to specify the floppy disk drive and media format to use for formatting. Refer to RomWBW Applications for more information on use of the FDU command. Since the physical format of floppy media is the same as that used in a standard MS-DOS/Windows computer, you can also format floppy disk media in a standard computer. However there are caveats: The directory format itself will NOT be compatible with CP/M OSes. You WILL need to use the CLRDIR command to reformat the directory area from CP/M. See section Clearing (Formatting) Drives FDU allows you to specify physical sector interleaving (defaults to 2) which will result in faster floppy disk I/O. Formatting on a modern computer may not optimize this. Below is a sample session using FDU to format a 1.44M floppy disk in the first (primary) floppy disk drive: B>FDU Floppy Disk Utility (FDU) v5.8, 26-Jul-2021 [HBIOS] Copyright (C) 2021, Wayne Warthen, GNU GPL v3 SELECT FLOPPY DISK CONTROLLER: (A) Disk IO ECB Board (B) Disk IO 3 ECB Board (C) Zeta SBC Onboard FDC (D) Zeta 2 SBC Onboard FDC (E) Dual IDE ECB Board (F) N8 Onboard FDC (G) RCBus SMC (SMB) (H) RCBus WDC (SMB) (I) SmallZ80 Expansion (J) Dyno-Card FDC, D1030 (K) RCBus EPFDC (L) Multi-Board Computer FDC (X) Exit === OPTION ===> D-IDE ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=720KB DS/DD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> SETUP ENTER UNIT [00-03] (00): 00: 3.5\" 720KB - 9 SECTORS, 2 SIDES, 80 TRACKS, DOUBLE DENSITY 01: 3.5\" 1.44MB - 18 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 02: 5.25\" 320KB - 8 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 03: 5.25\" 360KB - 9 SECTORS, 2 SIDES, 40 TRACKS, DOUBLE DENSITY 04: 5.25\" 1.2MB - 15 SECTORS, 2 SIDES, 80 TRACKS, HIGH DENSITY 05: 8\" 1.11MB - 15 SECTORS, 2 SIDES, 77 TRACKS, DOUBLE DENSITY 06: 5.25\" 160KB - 8 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 07: 5.25\" 180KB - 9 SECTORS, 1 SIDE, 40 TRACKS, DOUBLE DENSITY 08: 5.25\" 320KB - 8 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY 09: 5.25\" 360KB - 9 SECTORS, 1 SIDE, 80 TRACKS, DOUBLE DENSITY ENTER MEDIA [00-09] (00): 01 00: POLLING (RECOMMENDED) 01: INTERRUPT (!!! READ MANUAL !!!) 02: FAST INTERRUPT (!!! READ MANUAL !!!) 03: INT/WAIT (!!! READ MANUAL !!!) 04: DRQ/WAIT (!!! NOT YET IMPLEMENTED!!!) ENTER MODE [00-04] (00): ENTER TRACE LEVEL [00-01] (00): ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> FORMAT (T)RACK, (D)ISK ===> DISK ENTER INTERLEAVE [01-12] (02): RESET DRIVE... PROGRESS: TRACK=4F HEAD=01 SECTOR=01 ===== D-IDE ===========<< FDU MAIN MENU >>====================== (S)ETUP: UNIT=00 MEDIA=1.44MB DS/HD MODE=POLL TRACE=00 ---------------------------------------------------------------- (R)EAD (W)RITE (F)ORMAT (V)ERIFY (I)NIT BUFFER (D)UMP BUFFER FDC (C)MDS E(X)IT === OPTION ===> EXIT You can confirm a floppy disk is ready for content by simply running a DIR command on it. The DIR command should complete without error and should list no files.","title":"Floppy Disk Formatting"},{"location":"UserGuide/#hard-disk-preparation","text":"This section deals with initializing hard disk media entirely from your RomWBW system. The following instructions are one way to proceed. This does not mean to imply it is the only possible way. First you need to understand The disk layout approach (either hd1k or the legacy hd512). See Hard Disk Layouts section if you are not sure. hd1k should be the preferred layout. The number of 8MB slices that you want to allocate, preferred is 64 slices. At least 1 slice of 8MB is required If you want to leave space for a FAT partition. See FAT Filesystem Preparation The total capacity of your drive, to hold the CP/M (and other) partition(s) Then you will need to start by inserting the disk media, booting RomWBW, and confirming that the media is being recognized. If RomWBW recognizes the media, it will indicate this in the boot messages even though the media may not yet been prepared for use. Then launch either CP/M 2.2 or Z-System from ROM using the Boot Loader C or Z commands respectively. You can now use the tools on the ROM disk to prepare your disks. Note that you may see the operating system assign disks/slices to drives letters even though the disks/slices are not yet initialized. This is normal and does not mean the disks/slices are ready to use.","title":"Hard Disk Preparation"},{"location":"UserGuide/#partition-setup","text":"To setup a partition you must run the FDISK80 utility. After FDISK80 starts, enter the disk unit number of the new media. The disk unit number was assigned at boot See Device Unit Assignments Refer to RomWBW Applications for more information on use of the FDISK80 utility. If you want to use the legacy hd512 layout skip down to the Legacy (hd512) section","title":"Partition Setup"},{"location":"UserGuide/#modern-hd1k","text":"At this point, use the I command to initialize (reset) the partition table to an empty state. You must create a partition for the RomWBW CP/M slices. Then create a partition using the N command. Importantly: The partition number should typically be 1 the first partition The partition can be placed anywhere you want, The typical location for the RomWBW partition is at 1MB. The partition size should be the total size of all the slices you require, and must be at least 8MB in size, in increments of 8MB makes sense. You must then set the type of partition to 2E using the T command. The P command can be used to display the partition before it is written Finally the partition can be written to disk using the W write command. WARNING : Modifying the partition table of existing media will make any data on the media inaccessible. Below is an example of creating a RomWBW partition following these guidelines. FDISK80 for RomWBW, UNA, Mini-M68k, KISS-68030, SBC-188 ---- Version 1.1-22 created 7-May-2020 (Running under RomWBW HBIOS) HBIOS unit number [0..11]: 4 Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 00 *** empty *** 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>i >>n New partition number: 1 Starting Cylinder (default 0): 1Mb Ending Cylinder (or Size= \"+nnn\"): +512Mb >>t Change type of partition number: 1 New type (in hex), \"L\" lists types: 2e >>p Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 00 *** empty *** 3 00 *** empty *** 4 00 *** empty *** >>w Do you really want to write to disk? [N/y]: y Okay FDISK exit. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again.","title":"Modern (hd1k)"},{"location":"UserGuide/#legacy-hd512","text":"At this point, use the I command to initialize (reset) the partition table to an empty state. To use the hd512 layout, use W to write the empty table to the disk and exit. Remember that the lack of a partition for RomWBW implies the legacy (hd512) layout. At this point, it is best to restart your system to make sure that the operating system is aware of the partition table updates. Start CP/M 2.2 or Z-System from ROM again.","title":"Legacy (hd512)"},{"location":"UserGuide/#fat-partition","text":"At this point you may want to consider creating a FAT partition Please see the section FAT Filesystem Preparation for detils on how to setup the FAT partition.","title":"FAT Partition"},{"location":"UserGuide/#slice-initialization","text":"You need to initialize each slice for CP/M to use it. This is somewhat analogous to doing a FORMAT operation on other systems, and is done using the CLRDIR command. This is covered in the section Clearing (Formatting) Drives WARNING : Earlier versions of the CLRDIR application do not appear to check for disk errors when it runs. If you attempt to run CLRDIR on a drive that is mapped to a slice that does not actually fit on the physical disk, it may behave erratically. Assuming you want to use additional slices, you should initialize them using the same process. You may need to reassign drive letters to access some slices that are beyond the ones automatically assigned. You can use the ASSIGN command to handle this.","title":"Slice Initialization"},{"location":"UserGuide/#post-disk-preparation","text":"Once a disk (either floppy or hard disk) has been initialised and formattted you may optionally; * Make the disk bootable * Copy system (or other) files to the disk","title":"Post Disk Preparation"},{"location":"UserGuide/#making-a-disk-bootable","text":"To make a disk bootable you will need to follow the specific instructions in Operating Systems , as each operating system will be different. Generally you will need to use SYSCOPY to setup the system track(s) of the disk.As an example, If you wanted to setup C: as a bootable Z-System disk you would use: B>SYSCOPY C:=B:ZSYS.SYS SYSCOPY v2.0 for RomWBW CP/M, 17-Feb-2020 (CP/M 2 Mode) Copyright 2020, Wayne Warthen, GNU GPL v3 Transfer system image from B:ZSYS.SYS to C: (Y/N)? Y Reading image... Writing image... Done Once this process succeeds, you will be able to boot directly to the disk slice from the boot loader prompt. See the instructions in Starting Operating Systems from Disk for details on this.","title":"Making a Disk Bootable"},{"location":"UserGuide/#copying-system-files","text":"As well as making the disk bootable, you may need to transfer other system and application files to your disks. Refer to Transferring Files for more information on getting files onto your disks.","title":"Copying System Files"},{"location":"UserGuide/#disk-images","text":"Since it would be quite a bit of work to transfer over all the files you might want initially to your disk(s), It is generally easier to use these disk images than transferring your files over individually. RomWBW comes with a variety of ready to use disk images. You can use your modern Windows, Linux, or Mac computer to copy a disk image onto the disk media, then just move the media over to your RomWBW computer. The disk image files are found in the Binary directory of the distribution. Each disk image has the complete set of normal applications and tools distributed with the associated operating system or application suite. The following table shows the disk images available. Disk Image Description Boot xxx_aztec.img Aztec C Compiler No xxx_bascomp.img Microsoft Basic-80 Compiler No xxx_blank.img empty image No xxx_cowgol.img Cowgol 2.0 Compiler No xxx_cpm22.img DRI CP/M 2.2 Operating System Yes xxx_cpm3.img DRI CP/M 3 Operating System Yes xxx_dos65.img DOS/65 Operating System Yes xxx_fortran.img Microsoft Fortran-80 Compiler No xxx_games.img Games Disk for CP/M No xxx_hitechc.img HI-TECH Z80 CP/M C compiler No xxx_msxroms1.img MSX ROMs Disk 1 No xxx_msxroms2.img MSX ROMs Disk 2 No xxx_nzcom.img NZCOM ZCPR 3.4 Operating System Yes xxx_qpm.img QPM Operating System Yes xxx_tpascal.img Borland Turbo Pascal Compiler No xxx_ws4.img WordStar v4 & ZDE Applications No xxx_z80asm.img Relocating macro assembler for CP/M No xxx_zpm3.img ZPM3 Operating System Yes xxx_zsdos.img ZCPR-DJ & ZSDOS 1.1 Operating System Yes You will find 3 sets of these .img files in the distribution. The \u201cxxx\u201d portion of the filename will be: \u201cfd_\u201d for a floppy image. \u201chd1k_\u201d for a modern layout hard disk image. \u201chd512_\u201d for a legacy layout hard disk image. In the case of xxx_dos65.img, only an hd512 variant is provided. This is a constraint of the DOS65 distribution. There is also an image file called \u201cpsys.img\u201d which contains a bootable p-System hard disk image. It contains 6 p-System filesystem slices, but these are not interoperable with the CP/M slices described above. This file is discussed separately under UCSD p-System in Operating Systems section.","title":"Disk Images"},{"location":"UserGuide/#floppy-disk-images","text":"The floppy disk images are all intended to be used with 3.5\u201d high-density, double-sided 1.44 MB floppy disk media. This is ideal for the default floppy disk drive support included in RomWBW standard ROMs. For floppy disks, the .img file is written directly to the floppy media as is. The floppy .img files are 1.44 MB which is the exact size of a single 3.5\u201d high density floppy disk. You will need a floppy disk drive of the same type connected to your modern computer to write this image. Although modern computers do not come equipped with a floppy disk drive, you can still find USB floppy drives that work well for this. The floppy disk must be physically formatted before writing the image onto it. You can do this with RomWBW using FDU as described in the Floppy Disk Formatting section of this document. While you can also format the floppy using your modern computer, using FDU is preferable. RomWBW includes a Windows application called RawWriteWin in the Tools directory of the distribution. This simple application will let you choose a file and write it to an attached floppy disk drive. For Linux/MacOS, I think you can use the dd command (but I have not actually tried this). It is probably obvious, but writing an image to a floppy disk will overwrite and destroy all previous contents. Once the image has been written to the floppy disk, you can insert the floppy disk in your RomWBW floppy disk and read/write files on it according to the specific operating system instructions. If the image is bootable, then you will be able to boot from it by entering the floppy disk drive\u2019s corresponding unit number at the RomWBW Boot Loader command prompt.","title":"Floppy Disk Images"},{"location":"UserGuide/#hard-disk-images","text":"Keeping in mind that a RomWBW hard disk (including CF/SD/USB devices) allows you to have multiple slices (CP/M filesystems), there are a couple ways to image hard disk media. The easiest approach is to use the Combo Disk Image. This hard disk image is already prepared with 6 slices containing 5 ready-to-run OSes and a slice with the WordStar application files. Alternatively, you can create your own hard disk image with the specific slice contents you choose.","title":"Hard Disk Images"},{"location":"UserGuide/#standard-hard-disk-layout","text":"As previously described in Hard Disk Layouts , the exact placement of slices and optional FAT partition will vary depending on which disk layout (hd512 or hd1k) you are using and your partition table entries. To simplify the use of hard disk images, RomWBW has adopted a standard partition layout for disk image files provided. This standard layout is used to produce the Combo Disk Images described below. These partition sizes and locations were chosen to: Fit entirely on 1GB media Allow for 64 CP/M filesystem slices Allow for a 384KB FAT filesystem The standard partition table table entries are: \u2014 Modern (hd1k) \u2014 \u2014 Legacy (hd512) \u2014 Byte(s) Sector(s) Byte(s) Sector(s) RomWBW Partition Start 1 MB 2,048 \u2013 \u2013 RomWBW Partition Size 512 MB 1,048,576 \u2013 \u2013 FAT Filesystem Start 513 MB 1,050,624 520 MB 1,064,960 FAT Filesystem Size 384 MB 786,432 384 MB 786,432 \\<end> 897 MB 1,851,392 904 MB 1,837,056 NOTE: RomWBW is not limited to these partition table entries. You can change the size and location of the RomWBW and/or FAT partitions to increase/decrease the number of slices or FAT filesystem size. Doing so would require using FDISK80 to define your own custom disk layout and initializing your filesystems manually. The RomWBW System Guide has more information on the standard disk layouts as implemented in the Combo Disk Images. Additionally, there is a document called \u201cHard Disk Anatomy.pdf\u201d in the Doc directory of the RomWBW distribution with detailed information on the standard disk layouts.","title":"Standard Hard Disk Layout"},{"location":"UserGuide/#combo-hard-disk-image","text":"The Combo Disk Image is essentially just a single disk image that has several of the individual filesystem images (slices) already concatenated together using the standard disk layout described above. The Combo Disk Image includes the partition table of the standard disk layout and the following 6 slices in the positions indicated: Slice Description Slice 0 DRI CP/M 2.2 Operating System Slice 1 ZCPR-DJ & ZSDOS 1.1 Operating System Slice 2 NZCOM ZCPR 3.4 Operating System Slice 3 DRI CP/M 3 Operating System Slice 4 ZPM3 Operating System Slice 5 WordStar v4 & ZDE Applications Slice 6-63 blank unformatted There are actually 2 Combo Disk Images in the distribution. One for an hd512 disk layout (hd512_combo.img) and one for an hd1k disk layout (hd1k_combo.img). Simply use the image file that corresponds to your desired hard disk layout. Review the information in Hard Disk Layouts if you need more information of the disk layout options. Note : Apart from the hd512 and hd1k Combo Disk Images (mentioned above) there are actually a number of other hd1k_*_combo.img files. These additional combo files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct combo file The Combo Disk Image actually only contains the initial partition table, and the first 6 slices (Slice 0 to 5), this is approximately 49MB in size. While the partition table reserves space to store 64 CP/M filesystem slices as well as a single 384MB FAT filesystem, these areas remain empty, and must be initialized manually using CLRDIR for CP/M filesystems and FAT FORMAT for the FAT filesystem.","title":"Combo Hard Disk Image"},{"location":"UserGuide/#combo-disk-image-capacity","text":"The standard hard disk layout used by the Combo Disk Image was designed to fit well on a 1GB hard disk. The 64 CP/M slices (approximately 512MB) and 384MB FAT filesystem all fit well within a 1GB hard disk. This size choice was a bit arbitrary, but based on the idea that 1GB CF/SD/USB Media is easy and cheap to acquire. It is fine if your hard disk is smaller than 1GB. It just means that it will not be possible to use the pre-allocated FAT filesystem partition and any CP/M filesystem slices that don\u2019t fit. The true number of CP/M filesystem slices that will fit on your specific physical hard disk can be calculated as described in Hard Disk Capacity . If you attempt to access a slice past the end of the physical hard disk you will get \u201cno disk\u201d errors. You should calculate the maximum number of slices your hard disk will support and do not exceed this number.","title":"Combo Disk Image Capacity"},{"location":"UserGuide/#combo-disk-image-advice","text":"A great way to maintain your own data on a hard disk is to put your data in slices beyond the first 6. By doing so, you can always \u201cre-image\u201d your drive media with the Combo Disk Image without overlaying the data stored in the slices beyond the first 6. Just be very careful to use the same combo image layout (hd512 or hd1k) as you used originally.","title":"Combo Disk Image Advice"},{"location":"UserGuide/#custom-hard-disk-image","text":"For hard disks, each .img file represents a single slice (CP/M filesystem). Since a hard disk can contain many slices, you can just concatenate the slices (.img files) together to create your desired hard disk image. If you look in the Binary directory of the distribution, you will see that there are more disk (slice) images than the 6 that are included in the Combo Disk Images. These supplemental disk images are identified by looking for the files that start with hd1k_ or hd512_.","title":"Custom Hard Disk Image"},{"location":"UserGuide/#adding-slices-to-combo-image","text":"You can add slices to the Combo Disk Images simply by tacking slices onto the end. For example, if you want to add a slice containing the MSX ROMs to the end of the combo image, you could use one of the following command lines depending on your operating system: Windows: COPY /B hd1k_combo.img + hd1k_msxroms.img my_hd.img Linus/MaxOS: cat hd1k_combo.img hd1k_msxroms.img >my_hd.img Note that you must be sure to use either the hd1k_ or hd512_ prefixed files together. You cannot mix them.","title":"Adding Slices to Combo Image"},{"location":"UserGuide/#creating-a-new-custom-image","text":"If you want to create a completely custom hard disk image that is not based on the existing combo image, you can generate a disk image entirely from scratch using whatever slices you want in whatever order you like. For example, if you want to create a hard disk image that has slices for CP/M 2.2, CP/M 3, and WordStar in the hd512 format, you would use the command line of your modern computer to create the final image: Windows: COPY /B hd512_cpm22.img + hd512_cpm3.img + hd512_ws hd.img Linux/MacOS: cat hd512_cpm22.img hd512_cpm3.img hd512_ws >hd.img NOTE: For the hd1k disk layout, you must prepend the prefix file called hd1k_prefix.dat which contains the required partition table. So, for an hd1k layout you would use the following: Windows: COPY /B hd1k_prefix.dat + hd1k_cpm22.img + hd1k_cpm3.img + hd1k_ws hd.img Linux/MacOS: cat hd1k_prefix.dat hd1k_cpm22.img hd1k_cpm3.img hd1k_ws >hd.img Note : Apart from the hd1k_prefix.dat file (mentioned above) there are actaully a number of other hd1k_*_prefix.dat files. These additional prefix files are platform (generally romless) specific, and should be ignored unless you are on one of these platforms. If you are on one of these platforms you must use the correct prefix file In all of the examples above, the resulting file (hd.img) would now be written to your hard disk media and would be ready to use in a RomWBW system. If you wish to further customize or create new disk image definitions, please refer to the ReadMe.txt file in the Source/Images directory.","title":"Creating a new Custom Image"},{"location":"UserGuide/#writing-hard-disk-images","text":"Once you have chosen a Combo Hard Disk Image file or prepared your own custom hard disk image file, it will need to be written to the media using your modern computer. When using this method, the disk will be partitioned and setup with 1 or more slices containing ready-to-run bootable operating systems. To write a hard disk image file onto your actual media (actual hard disk or CF/SD/USB Media), you need to use an image writing utility on your modern computer. Your modern computer will need to have an appropriate interface or slot that accepts the media. To actually copy the image On Linux or MacOS , you can use the dd command. On Windows, in the \u201cTools\u201d directory of the distribution, there is an application called Win32DiskImager. In all cases, the image file should be written to the media starting at the very first block or sector of the media. This is the default behaviour on all software. To be entirely clear, writing a disk image file to your hard disk media will overwrite an pre-existing partition table and the number of slices that your image file contains. It will not overwrite or corrupt slices beyond those in the image file. As a result, you can use additional slices as a place to maintain your personal data because these slices will survive re-imaging of the media. If you setup a FAT partition on your media, it will also survive the imaging process.","title":"Writing Hard Disk Images"},{"location":"UserGuide/#media-usage-and-initialization","text":"Once you have copied the image onto the hard disk media, you can move the media over to your RomWBW system. You can then boot to the operating system slices by specifying ( \\<diskunit>.\\<slice> ) at the RomWBW Boot Loader command prompt. See the section Starting Operating Systems from Disk for further details You are not limited to the number of slices that are contained in the image that you write to your hard disk media. You can use additional slices as long your media has room for them. However, writing the disk image will not initialize the additional slices. You will need to use the CLRDIR application to initialize any un-initialized slice before its first use, and and optionally SYSCOPY if you want th slice to be bootable. If you use the combo image this applies to slices 6 thru 63. The procedure for this is documented in the Clearing (Formatting) Drives section. Likewise, the pre-allocated FAT partition must still be formatted using FAT FORMAT in order to actually use it (see FAT Filesystem Preparation ). Alternatively, the FAT partition can be formatted on a modern computer.","title":"Media Usage and Initialization"},{"location":"UserGuide/#re-imaging-existing-media","text":"In order for your additional slices and/or FAT partition to survive re-imaging, you must follow these rules: Do not modify the partition table of the media using FDISK80 or any other partition management tools. Ensure that your hard disk image file uses the same disk layout approach (hd512 or hd1k) as previously used on the media.","title":"Re-Imaging Existing Media"},{"location":"UserGuide/#writing-hard-disk-slices","text":"This section covers techniques to copy partial images onto pre-existing media, in effect performing a selective slice copy. These techniques currently only apply to hd1k formatted media, which has a partition table entry, and a convenient 1MB size metric. However adapting to hd512 is possible, but left to the user. You will need to have access to a Linux/MacOS machine, or have the Linux tools for Windows installed, including the dd command line tool. For Windows there are multiple options for installing dd including MSYS2 , CygWin , and dd for Windows . WARNING : The dd command is a low-level utility that writes directly to raw disk sectors with almost no safety checks. It is very easy to corrupt a disk if this tool is used incorrectly. The dd command supports options to define precisely source and destination offsets and sizes to copy. From the documentation of dd the following options are important. if=file Read input from file instead of the standard input. of=file Write output to file instead of the standard output. skip=n Skip n blocks from the beginning of the input before copying. seek=n Seek n blocks from the beginning of the output before copying. count=n Copy only n input blocks. bs=n Set both input and output block size to n bytes instead of the default 512 The best approach is to copy data to the RomWBW partition. To do this, you must first determine the name that your operating system is using for the RomWBW disk and partition. An easy way to determine this may be the linux mount command, which lists the currently mounted partitions. From here you can more easily determine the naming scheme used by your operating system. Typically disk devices are named something like /dev/disk9 or /dev/sdg , noting above the g is a alphabetic and it could be any letter. This naming is arbitrary and depend on the operating system, and the specific hardware connecting the device Partitions are typically named by simply adding a number after the name of the hard disk device. For example, the first partition could be /dev/disk9s1 , /dev/sdg1 , or /dev/sdgp1 . In the following examples we use the above dd options, noting the of= option is the RomWBW target partition. ** NOTE ** A second approach (Examples 3 and 4) is to address the hard disk as a raw disk device and we take explicit steps to calculate the start of the RomWBW partition. While this works, it is better to use the partition relative approach. The commands in the examples below are run from the Binary folder of RomWBW distribution.","title":"Writing Hard Disk Slices"},{"location":"UserGuide/#example-1-copy-the-games-image-to-an-empty-slice-of-our-media","text":"In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5). We are just copying the needed slice to the existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/sdg1 seek=6 bs=8M Password: 1+0 records in 1+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) Since bs=8MB the seek=6 skips the first 6 (8MB slices) slices (in the target image) and writes the games image to the 7th slice.","title":"Example 1 : Copy the Games image to an empty slice of our media"},{"location":"UserGuide/#example-2-copy-the-entire-combo-image-without-replacing-partition-table","text":"In all of the following examples we use bs=1MB to defines the block size used in other parameters. This is convenient since the combo image reserves 1MB for the partition table at the start of the disk. In this example we will copy the (hd1k) combo image (which includes a partition table) over our media without replacing the partition table. In this example we assume the media has already been formatted with the combo image, and we have modified the partition table, which we do not want to overwrite. Binary % sudo dd if=hd1k_combo.img of=/dev/sdg1 skip=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB (partition table) in the input file, effectively stripping out the combo images partition table, before overwriting the slices in the target partition.","title":"Example 2 : Copy the entire Combo Image without replacing partition table"},{"location":"UserGuide/#example-3-copy-the-combo-image-without-replacing-partition-table","text":"This example is identical to Example 2 except it writes to the target disk device itself ( of=/dev/disk9 ), not the target partition. Binary % sudo dd if=hd1k_combo.img of=/dev/disk9 skip=1 seek=1 bs=1M Password: 48+0 records in 48+0 records out 50331648 bytes transferred in 11.503776 secs (4745528 bytes/sec) The skip=1 skips the first 1MB in the input file, and likewise seek=1 skips the first 1MB of the target media file we are writing to, thus in effect we are skipping the first 1MB, which contains the partition table itself.","title":"Example 3 : Copy the Combo Image without replacing partition table"},{"location":"UserGuide/#example-4-copy-the-games-image-to-an-empty-slice-of-our-media","text":"In this example we will copy the (hd1k) games image to Slice 6 (free) of our existing media. In this example we assume the media has already been formatted with the combo image, which already contains 6 slices (numbered from 0 to 5) We are just coping the needed slice to this existing media as a new slice (number 6) after the existing slices making it the 7th slice. Binary % sudo dd if=hd1k_games.img of=/dev/disk9 seek=49 bs=1M Password: 8+0 records in 8+0 records out 8388608 bytes transferred in 1.917296 secs (4375228 bytes/sec) The seek=49 skips the first 49MB of the media file we are writing to. 49 is calculated as (slice number * 8) + 1 , where 8 is the size of a slice and 1 is the size of the partition table im megabytes. Thus we are skipping 6 slices (in the combo image) and writing to the 7th slice.","title":"Example 4 : Copy the Games image to an empty slice of our media"},{"location":"UserGuide/#operating-systems","text":"One of the primary goals of RomWBW is to expose a set of generic hardware functions that make it easy to adapt operating systems to any hardware supported by RomWBW. As a result, there are now 8 operating systems that have been adapted to run under RomWBW. The adaptations are identical for all hardware supported by RomWBW because RomWBW hides all hardware specifics from the operating system. By design, the operating systems provided with RomWBW are original and unmodified from their original distribution. Patches published by the authors are generally included or applied. The various enhancements RomWBW provides (such as hard disk slices) are implemented entirely within the system adaptation component of each operating system (e.g., CP/M CBIOS). As a result, each operating system should function exactly as documented by the authors and retain maximum compatibility with original applications. Note that all of the operating systems included with RomWBW support the same basic filesystem format from DRI CP/M 2.2 (except for p-System). As a result, a formatted filesystem will be accessible to any operating system. The only possible issue is that if you turn on date/time stamping using the newer OSes, the older OSes will not understand this. The older OS will not corrupt the files, but the date/time stamps will not be maintained. The following sections briefly describe the operating system options currently available and brief operating notes.","title":"Operating Systems"},{"location":"UserGuide/#digital-research-cpm-22","text":"This is the most widely used variant of the Digital Research operating systems. It has the most basic feature set, but is essentially the compatibility metric for all other CP/M-like operating systems including those listed below. If you are new to the CP/M world, I would recommend using this CP/M variant to start with simply because it is the most stable and you are less likely to encounter compatibility issues.","title":"Digital Research CP/M 2.2"},{"location":"UserGuide/#documentation","text":"CPM Manual","title":"Documentation"},{"location":"UserGuide/#boot-disk","text":"To make a bootable CP/M disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cCPM.SYS\u201d. For example: SYSCOPY C:=B:CPM.SYS","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping","text":"Character device mapping under CP/M 2.2 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The CP/M Logical Devices are: Device Description CON: System console device, used by CCP for communication with the operator RDR: Paper tape reader device PUN: Paper tape punch device LST: Output list device The CP/M Physical Devices are: Device Description TTY: Teletype device (slow speed console) CRT: Cathode ray tube device (high speed console) BAT: Batch processing (input from RDR: , output to LST: ) UC1: User-defined console PTR: Paper tape reader (high speed reader) UR1: User-defined reader #1 UR2: User-defined reader #2 PTP: Paper tape punch (high speed punch) UP1: User-defined punch #1 UP2: User-defined punch #2 LPT: Line printer UL1: User-defined list device #1 CP/M Logical Devices are mapped to CP/M Physical Devices via the IOBYTE at 0x0003 as shown below. Logical Device LST: PUN: RDR: CON: IOBYTE Bits 7 6 5 4 3 2 1 0 0 (0b00) TTY: TTY: TTY: TTY: 1 (0b01) CRT: PTP: PTR: CRT: 2 (0b10) LPT: UP1: UR1: BAT: 3 (0b11) UL1: UP2: UR2: UC1: The mappings above can be managed using the STAT command. This command essentially just modifies the IOBYTE value. CP/M Physical Devices are mapped to RomWBW HBIOS devices during the boot process depending on the number of HBIOS Char devices in the system. All CP/M Physical Devices are initially mapped to HBIOS Char 0. If additional HBIOS Char devices are available in the system, they will be mapped as below: CP/M RomWBW HBIOS TTY: Char 0 CRT: CRT BAT: CP/M RDR/LST UC1: Char 1 PTR: Char 1 UR1: Char 2 UR2: Char 3 PTP: Char 1 UP1: Char 2 UP2: Char 3 LPT: Char 1 UL1: Char 2 Normally, the HBIOS Console device (Loader prompt) is on HBIOS Device Char 0. If it has been reassigned to a different HBIOS character device before launching CP/M, then the above mapping will be modified. TTY: will be assigned to the current HBIOS console Char device. The remaining assignments will be filled in with the other Char devices as available.","title":"Character Device Mapping"},{"location":"UserGuide/#notes","text":"You can change media, but it must be done while at the OS command prompt and you must warm start CP/M by pressing ctrl-C. This is a CP/M 2.2 constraint and is well documented in the DRI manual. SUBMIT.COM has been patched per DRI to always place submit files on A:. This ensures the submitted file will always be properly executed. The original versions of DDT, DDTZ, and ZSID used the RST 38 vector which conflicts with interrupt mode 1 use of this vector. The DDT, DDTZ, and ZSID applications in RomWBW have been modified to use RST 30 to avoid this issue. Z-System applications will not run under CP/M 2.2. For example, the LDDS date stamper will not work.","title":"Notes"},{"location":"UserGuide/#z-system","text":"Z-System is the most popular non-DRI CP/M workalike \u201cclone\u201d which is generally referred to as Z-System. Z-System is intended to be an enhanced version of CP/M and should run all CP/M 2.2 applications. It is optimized for the Z80 CPU (as opposed to 8080 for CP/M) and has some significant improvements such as date/time stamping of files. Z-System is a somewhat ambiguous term because there are multiple generations of this software. RomWBW Z-System is a combination of both ZCPR-DJ (the CCP) and ZSDOS 1.1 (the BDOS) when referring to Z-System. The latest version of Z-System (ZCPR 3.4) is also provided with RomWBW via the NZ-COM adaptation (see below).","title":"Z-System"},{"location":"UserGuide/#documentation_1","text":"ZCPR Manual ZCPR-DJ ZSDOS Manual","title":"Documentation"},{"location":"UserGuide/#boot-disk_1","text":"To make a bootable Z-System disk, use the RomWBW SYSCOPY tool to place a copy of the operating system on the boot track of the disk. The RomWBW ROM disk has a copy of the boot track call \u201cZSYS.SYS\u201d. For example: SYSCOPY C:=B:ZSYS.SYS","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_1","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The CP/M 2.2 STAT command is used to manipulate the device mappings.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_1","text":"Although most CP/M 2.2 applications will run under Z-System, some may not work as expected. The best example is PIP which is not aware of the ZSDOS paths and will fail in some scenarios (use COPY instead). Although ZSDOS can recognize a media change in some cases, it will not always work. You should only change media at a command prompt and be sure to warm start the OS with a ctrl-C. ZSDOS has a concept of fast relog of drives. This means that after a warm start, it avoids the overhead of relogging all the disk drives. There are times when this causes issues. After using tools like CLRDIR or MAP, you may need to run \u201cRELOG\u201d to get the drive properly recognized by ZSDOS. ZSVSTAMP expects to be running under the ZCPR 3.X command processor. By default, RomWBW uses ZCPR 1.0 (intentionally, to reduce space usage) and ZSVSTAMP will just abort in this case. It will work fine if you implement NZCOM. ZSVSTAMP is included solely to facilitate usage if/when you install NZCOM. Many of the tools can be configured (using either ZCNFG or DSCONFIG). The configuration process modifies the actual application file itself. This will fail if you try to modify one that is on the ROM disk because it will not be able to update the image. DATSWEEP can be configured using DSCONFIG. However, DSCONFIG itself needs to be configured first for proper terminal emulation by using SETTERM. So, run SETTERM on DSCONFIG before using DSCONFIG to configure DATSWEEP! Generic CP/M PIP and ZSDOS path searching do not mix well if you use PIP to copy to or from a directory in the ZSDOS search path. Best to use COPY from the ZSDOS distribution.","title":"Notes"},{"location":"UserGuide/#nzcom-automatic-z-system","text":"NZCOM is a much further refined version of Z-System (ZCPR 3.4). NZCOM was sold as an enhancement for existing users of CP/M 2.2 or ZSDOS. For this reason, (by design) NZCOM does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into a host OS. On the RomWBW NZCOM disk images, the boot OS is ZSDOS 1.1. A PROFILE.SUB file is included which automatically launches NZCOM as soon as ZSDOS loads. NZCOM is a companion product to Z3PLUS, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. NZCOM is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation and use MKZCM as desired to customize your system. NZCOM has substantially more functionality than CP/M or basic Z-System. It is important to read the \u201cNZCOM Users Manual.pdf\u201d document in order to use this operating system effectively.","title":"NZCOM Automatic Z-System"},{"location":"UserGuide/#documentation_2","text":"NZCOM Users Manual Z-System Users Guide ZCPR3.3 User Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_2","text":"Since NZ-COM boots via Z-System, you can make a bootable NZ-COM disk using ZSYS.SYS as described in Z-System above. You will need to add a PROFILE.SUB file to auto-start NZ-COM itself.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_2","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . However, it is not possible to manipulate the CP/M Logical to Physical device mapping using the STAT command. The mapping is static. Note: A custom ZCPR IOP module could theoretically be used to manage the character device mappings. RomWBW does not provide this module and writing an IOP module is beyond the scope of this document.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_2","text":"All of the notes for Z-System above generally apply to NZCOM. There is no DIR command, you must use SDZ instead. If you don\u2019t like this, look into the ALIAS facility. For consistency with other ZCPR3 operating systems (ZPM3, Z3PLUS) the SHOW.COM and HELP.COM command files were renamed to ZSHOW.COM and ZHELP.COM","title":"Notes"},{"location":"UserGuide/#digital-research-cpm-3","text":"This is the Digital Research follow-up product to their very popular CP/M 2.2 operating system. While highly compatible with CP/M 2.2, it features many enhancements and is not 100% compatible. It makes direct use of banked memory to increase the user program space (TPA). It also has a new suite of support tools and help system.","title":"Digital Research CP/M 3"},{"location":"UserGuide/#documentation_3","text":"CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_3","text":"To create (or update) a CP/M 3 boot drive, you must place CPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS and CCP.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. CPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/CPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . CPMLDR.SYS CPM3.SYS or CPM3BNK.SYS CCP.COM The CPM3.SYS boot file is provided in 2 versions. In the Binary/CPM3 distribution directory, CPM3.SYS is the \u201cnon-banked\u201d version of CP/M 3. The CPM3BNK.SYS file is the \u201cbanked\u201d version of CP/M 3. You almost certainly want to transfer the banked CPM3BNK.SYS version. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place CPMLDR.SYS on the boot track of the target drive. CPM3.SYS and CCP.COM can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into CP/M 3 to create or update a CP/M 3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the CP/M 3 disk. Assuming the target CP/M 3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:CPMLDR.SYS COPY A:CPM3BNK.SYS F:CPM3.SYS COPY A:CCP.COM F: Note in the example above that CPM3BNK.SYS is renamed to CPM3.SYS in the copy command.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_3","text":"Character device mapping under CP/M 3 has 3 layers: CP/M Logical Device \u2013> CP/M Physical Device \u2013> RomWBW HBIOS Device The primary CP/M Logical Devices are: Device Description CON: Console input or output device AUX: Auxiliary Input or Output Device LST: List output device, usually the printer There are various aliases for these devices. Please refer to the CP/M 3 Users Guide for more information. The mapping of CP/M 3 Logical Devices to Physical Devices is performed using the DEVICE command. CP/M 3 refers to Physical Character Devices using the COM device label. These COM devices are mapped directly to the RomWBW HBIOS Char devices as described below: COM0: \u2013> HBIOS Char 0 COM1: \u2013> HBIOS Char 1 COM2: \u2013> HBIOS Char 2 . . . COMn: \u2013> HBIOS Char n","title":"Character Device Mapping"},{"location":"UserGuide/#notes_3","text":"The COPYSYS command described in the DRI CP/M 3 documentation is not provided with RomWBW. The RomWBW SYSCOPY command is used instead. Although CP/M 3 is generally able to run CP/M 2.2 programs, this is not universally true. This is especially true of the utility programs included with the operating system. For example, the SUBMIT program of CP/M 3 is completely different/incompatible from the SUBMIT program of CP/M 2.2. RomWBW fully supports CP/M 3 file date/time stamping, but this requires that the disk be properly initialized for it. This process has not been performed on the CP/M 3 disk image. Follow the CP/M 3 documentation to complete this process, if desired.","title":"Notes"},{"location":"UserGuide/#z3plus-z-system-for-cpm-plus","text":"Z3PLUS is a much further refined version of Z-System (ZCPR 3.4). Z3PLUS was sold as an enhancement for existing users of CP/M 3. For this reason, (by design) Z3PLUS does not provide a way to boot directly from disk. Rather, it is loaded after the system boots into CP/M 3. A PROFILE.SUB file is included which automatically launches Z3PLUS as soon as CP/M 3 loads. Z3PLUS is a companion product to NZ-COM, they are almost identical having been written by the same team. The only difference is the base operating system on which they run, but the architecture, the tools, libraries, files, etc are all primarily the same. Z3PLUS is highly configurable. The RomWBW distribution has been configured in the most basic way possible. You should refer to the documentation to customize your system. Z3PLUS has substantially more functionality than CP/M 3 or the basic Z-System. It is important to read the \u201cZ3PLUS Users Manual.pdf\u201d document in order to use this operating system effectively.","title":"Z3PLUS Z-System for CP/M-Plus"},{"location":"UserGuide/#documentation_4","text":"Z3PLUS Users Manual Z-System Users Guide ZCPR3.3 User Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_4","text":"Since Z3PLUS boots via CP/M 3, you first must make the disk CP/M 3 bootable. This is not a simple process, as well as placing CPMLDR.SYS on the system track of the disk there are several files that are required on the disk itself.This is described in Digital Research CP/M 3 section above. You will need to add a PROFILE.SUB file to auto-start Z3PLUS itself.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_4","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_4","text":"All of the notes for Digital Research CP/M 3 above generally apply to Z3PLUS. Some applications in the Z3PLUS distribution have been upgraded with newer versions. This is done with in","title":"Notes"},{"location":"UserGuide/#zpm3","text":"Simeon Cran\u2019s ZPM3 is an interesting combination of the features of both CP/M 3 and ZCPR3. Essentially, it has the features of and compatibility with both. Due to this dual compatibility, the ZPM3 distribution image contains most of the standard CP/M 3 files as well as a variety of common ZCPR3 applications. However, you will notice that user area 0 of the disk has only a few files. Most of the files are distributed among other user areas which is standard practice for ZCPR3. Most importantly, you will see most of the applications in user area 15. The applications can be executed from any user area because ZPM3 has a default search path that includes User 15. The ZPM3 distribution comes with essentially no utility programs at all. In addition to the standard CP/M 3 utilities, RomWBW includes a variety of common ZCPR3 utilities.","title":"ZPM3"},{"location":"UserGuide/#documentation_5","text":"ZPM3 has no real documentation. You are expected to understand both CP/M 3 and ZCPR 3. The best source of information is: CPM3 Users Guide CPM3 Command Summary CPM3 Programmers Guide CPM3 System Guide Z-System Users Guide ZCPR3.3 User Guide","title":"Documentation"},{"location":"UserGuide/#boot-disk_5","text":"To create (or update) a ZPM3 boot drive, you must place ZPMLDR.SYS on the system track of the disk. You must also place CPM3.SYS , ZCCP.COM , ZINSTAL.ZPM , and STARTZPM.COM on the target drive as regular files. Do not place CPM3.SYS on the boot track. ZPMLDR.SYS chain loads CPM3.SYS which must exist as a regular file on the disk. Subsequently, CPM3.SYS loads CCP.COM . The CP/M 3 boot files are not included on the ROM disk due to space constraints. You will need to transfer the following files to your system from the RomWBW distribution directory Binary/ZPM3. You can use XModem for this (or any of the mechanisms in Transferring Files . ZPMLDR.SYS CPM3.SYS ZCCP.COM ZINSTAL.ZPM STARTZPM.COM You may be surprised to see the file called CPM3.SYS . This is not a typo. Although it is called CPM3.SYS , it is ZPM and not the same as CPM3.SYS in the CPM3 directory. Also, unlike CP/M 3, ZPM3 is always banked, so you will not find two versions of the file. CPM3.SYS is a banked implementation of ZPM3. After transferring the boot files to your RomWBW system, you will need to use SYSCOPY to place ZPMLDR.SYS on the boot track of the target drive. The remaining boot files can be copied to the target drive using any standard file copy tool such as PIP or COPY . You do not need to be booted into ZPM3 to create or update a ZPM3 disk. The recommended approach is to boot CP/M 2.2 or Z-System from ROM. Transfer the boot files to the RAM disk. Then simply copy the files onto the ZPM disk. Assuming the target ZPM3 disk is F:, you can use the following commands to place the files on the target drive: SYSCOPY F:=A:ZPMLDR.SYS COPY A:CPM3.SYS F:CPM3.SYS COPY A:CCP.COM F: COPY A:ZINSTAL.ZPM F: COPY A:STARTZPM.COM F:","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_5","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 3 . The CP/M 3 DEVICE command is used to manipulate the device mappings.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_5","text":"The ZPM3 operating system is contained in the file called CPM3.SYS which is confusing, but this is as intended by the ZPM3 distribution. I believe it was done this way to make it easier for users to transition from CP/M 3 to ZPM3. The command line editing key bindings were slightly modified by Jon Saxton when he applied a few ZPM3 fixes. This is explained in the file zpm3fix.txt in the distribution folder Source/ZPM3. The current key bindings are from the \u201cNew\u201d column below. Old New Function ^A ^A one word left ^B ^B to beginning/end of line ^C ^C reboot if at start of line ^D ^D right one char ^E ^E get previous line ^F ^F right one word ^G ^G delete char at cursor ^H ^H destructive backspace ^I ^I (TAB) ignored here ^J ^J (LF) exit editor ^K ^K delete all to the right ^L ^L ignored ^M ^M (CR) exit editor ^N ^N ignored ^O ^O ignored ^P ^P toggle printer echoing ^Q ^Q toggle autoprompt (if enabled) ^R ^R ignored ^S ^S left one char ^T ^T delete word at cursor ^U ^U add line to history ^V ^V clear line, delete from history ^W ^X get next line from history ^X ^W delete all to the left ^Y ^Y clear line","title":"Notes"},{"location":"UserGuide/#qpm","text":"QP/M is another OS providing compatibility with and enhancements to CP/M 2.2. It is provided as a bootable disk image for RomWBW. Refer to the ReadMe.txt file in Source/Images/d_qpm for more details regarding the RomWBW adaptation and customizations.","title":"QP/M"},{"location":"UserGuide/#documentation_6","text":"QP/M 2.7 Installation Guide and Supplements QP/M 2.7 Interface Guide QP/M 2.7 Features and Facilities","title":"Documentation"},{"location":"UserGuide/#boot-disk_6","text":"To create or update a bootable QP/M Z-System disk, a special process is required. QP/M is not provided in source format. You are expected to install QP/M over an existing CP/M installation using the QINSTALL.COM application. To update an existing QP/M boot disk with the latest RomWBW CBIOS, you must use 2 steps: apply the generic CP/M system track, then reinstall the QP/M components. To do this, you can perform the following steps: Boot to the existing QP/M disk. At this point, drive A should be the QP/M disk that you wish to update. You may receive a warning about CBIOS/HBIOS version mismatch. Use RomWBW SYSCOPY to place the stock RomWBW CP/M OS image onto the system tracks of the QP/M boot disk: SYSCOPY A:=x:CPM.SYS where x is the drive letter of your ROM Disk. Run QINSTALL to overlay the QP/M OS components on your QP/M boot disk. WARNING : QINSTALL has no mechanism for retaining previous non-default settings. Any previous non-default settings you previously made with QINSTALL will need to be reapplied. The pre-built RomWBW QP/M disk image includes a couple of specific non-default settings to optimize use with RomWBW. Please review the notes in the ReadMe.txt file in Source/Images/d_qpm.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_6","text":"Mapping of character devices to RomWBW HBIOS Character devices operates exactly the same as described in Digital Research CP/M 2.2 . The mappings can be viewed or modified using the QP/M QSTAT command which is analogous to the CP/M 2.2 STAT command. Do not use the CP/M 2.2 STAT command under QP/M.","title":"Character Device Mapping"},{"location":"UserGuide/#notes_6","text":"QPM is not available as source. This implementation was based on the QPM binary distribution and has been minimally customized for RomWBW. When booted, the QPM startup banner will indicate CP/M 2.2. This is because QPM uses the CP/M 2.2 CBIOS code. QINSTALL is used to customize QPM. It is included on the disk image. You should review the notes in the ReadMe.txt file in Source/Images/d_qpm before making changes. In addition to the QPM disk image, all of the QPM distribution files can be found in the RomWBW distribution in the Source/Images/d_qpm/u0 directory. The QPM disk image is not included as one of the slices on the RomWBW Combo Disk Image. If you want to include QPM, you can do so by following the directions in Source/Images/Readme.txt.","title":"Notes"},{"location":"UserGuide/#ucsd-p-system","text":"This is a full implementation of the UCSD p-System IV.0 for Z80 running under RomWBW. Unlike the OSes above, p-System uses its own unique filesystem and is not interoperable with other OSes. It was derived from the p-System Adaptable Z80 System. Unlike some other distributions, this implements a native p-System Z80 Extended BIOS, it does not rely on a CP/M BIOS layer. The p-System is provided on a hard disk image file called psys.img. This must be copied to its own dedicated hard disk media (CF Card, SD Card, etc.). It is booted by selecting slice 0 of the corresponding hard disk unit at the RomWBW Boot Loader prompt. Do not attempt to use CP/M slices on the same disk. Due to limitations in the p-System configuration mechanism, it does not recognize the arrow keys of an ANSI Terminal. To work around this, the following control keys have been defined: Function Key Up ctrl+E Down ctrl+X Left ctrl+S Right ctrl+D Refer to Source/pSys/ReadMe.txt for more details about the p-System adaptation.","title":"UCSD p-System"},{"location":"UserGuide/#documentation_7","text":"UCSD p-System Users Manual","title":"Documentation"},{"location":"UserGuide/#boot-disk_7","text":"There is no mechanism provided to create a p-System boot disk from scratch under RomWBW. This has already been done as part of the porting process. You must use the provided p-System hard disk image file which is bootable.","title":"Boot Disk"},{"location":"UserGuide/#character-device-mapping_7","text":"RomWBW Character Devices are automatically assigned to p-System devices at startup. The current HBIOS Console device is assigned to CONSOLE:. The next available HBIOS Char device is assigned to REMIN:/REMOUT:. The next available HBIOS Char devices is assigned to PRINTER:","title":"Character Device Mapping"},{"location":"UserGuide/#notes_7","text":"There is no floppy support at this time. The hard disk image contains 6 p-System slices which are assigned to p-System unit numbers 4, 5, 9, 10, 11, and 12 which is standard for p-System. Slices 0-5 are assigned sequentially to these p-System unit numbers and it is not possible to reassign them. Unit #4 (slice 0) is bootable and contains all of the p-System distribution files. Unit #5 (slice 1) is just a blank p-System filesystem. The other units (9-12) have not been initialized, but this can be done from Filer using the Zero command. p-System relies heavily on the use of a full screen terminal. This implementation has been setup to expect an ANSI or DEC VT-100 terminal or emulator. The screen output will be garbled if no such terminal or emulator is used for console output. There is no built-in mechanism to move files in and out of p-System. However, the .vol files in Source/pSys can be read and modified by CiderPress. CiderPress is able to add and remove individual files. Andrew Davidson has created a Python script that can extract p-System volumes from an existing disk image file. The script is also capable of inserting a modified volume back into the disk image file. This tool is available at https://github.com/robosnacks/psysimg .","title":"Notes"},{"location":"UserGuide/#freertos","text":"Phillip Stevens has ported FreeRTOS to run under RomWBW. FreeRTOS is not provided in the RomWBW distribution. FreeRTOS is available under the MIT licence and further general information is available at FreeRTOS . Phillip may be contacted via his GitHub Page .","title":"FreeRTOS"},{"location":"UserGuide/#fuzix","text":"Fuzix is a Unix-ish operating system for small systems. It is the work of Alan Cox and is hosted on GitHub at https://github.com/EtchedPixels/FUZIX . Fuzix itself is a stand-alone operating system, but it frequently utilizes RomWBW to boot and launch on RomWBW-supported platforms. For those Fuzix platforms that leverage RomWBW for startup, you will program your ROM with the normal RomWBW ROM \u2013 there is no Fuzix-specific ROM. A Fuzix disk image for your system is then written to your disk media. After booting your system via the normal RomWBW ROM, you start Fuzix simply by choosing the disk device containing the Fuzix image at the RomWBW Loader prompt. To create a Fuzix disk image: Locate and download the Fuzix disk image for your system from https://www.fuzix.org/ . For each platform, you will typically find two image files. An emulator image ( emu-xxx.img ) and a disk image ( disk.img ). You want the disk image file. Write the disk image file to your physical media (CF Card, SD Card, etc.) starting at the beginning of the media (first sector). Do not combine the Fuzix image with the RomWBW disk images \u2013 they are entirely separate. To boot into Fuzix: Insert your Fuzix disk media. Power-up or reset your system. RomWBW should load normally and bring you to the RomWBW Boot Loader prompt. Depending on the platform, Fuzix may be built to run at a different baud rate that the default RomWBW baud rate. If so, it is best to change your RomWBW baud rate prior to initiating the Fuzix startup. You can do this at the loader prompt with a command like this: I 0 38400 Replace 38400 with the desired baud rate for Fuzix. You will be prompted to change your terminal\u2019s baud rate at this time. At the RomWBW Boot Loader prompt, enter the disk unit number of the Fuzix media. Fuzix should load and you will see device discovery/information messages that vary depending on your platform. This is a typical example: RCBus [RCZ180_nat_wbw] Boot Loader FP Switches = 0x00 Boot [H=Help]: 2 Booting Disk Unit 2, Slice 0, Sector 0x00000000... Volume \"Fuzix 126 Loader\" [0xF200-0xF400, entry @ 0xF200]... FUZIX version 0.4 Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha Copyright (c) 2013-2015 Will Sowerbutts wi...@sowerbutts.com Copyright (c) 2014-2023 Alan Cox al...@etchedpixels.co.uk Devboot 512kB total RAM, 448kB available to processes (15 processes max) Enabling interrupts ... ok. 0000 : CF Card - OK 0001 : - absent hda: hda1 hda2 (swap) bootdev: At the bootdev: prompt, enter hda1 . Fuzix should load and you will be prompted for a date/time. Here is a typical example: bootdev: hda1 Mounting root fs (root_dev=1, ro): OK Starting /init init version 0.9.1 Checking root file system. Current date is Fri 2023-08-18 Enter new date: Current time is 13:30:24 Enter new time: ^ ^ n n Fuzix 0.4 @< Welcome to Fuzix m m login: At the login: prompt, enter root . No password is required. You should then get a Fuzix # command prompt. login: root Welcome to FUZIX. # You may now use Fuzix as desired. The general operation and use of Fuzix is outside of the scope of this document.","title":"Fuzix"},{"location":"UserGuide/#custom-applications","text":"The operation of the RomWBW hosted operating systems is enhanced through several custom applications. You have already read about one of these \u2013 the ASSIGN command. These applications are functional on all of the OS variants included with RomWBW. The applications discussed here are not the same as the built-in ROM applications mentioned previously. These applications run as commands within the operating systems provided by RomWBW. So, these commands are only available at an operating system prompt after an operating system has been loaded. All of the RomWBW Custom Applications are built to function under all of the RomWBW Operating Systems (except for p-System). In general, the applications will automatically adapt as needed to the currently running operating system. One exception is FDU \u2013 the Floppy Disk Utility. This application requires that you pick the floppy disk interface you want to interact with. There is more complete documentation of all of these applications in the related RomWBW manual \u201c RomWBW Applications \u201d found in the Doc directory of the distribution. The following custom applications are found on the ROM disk and are, therefore, globally available. Application **Description ASSIGN Add, change, and delete drive letter assignments. Use ASSIGN /? for usage instructions. SYSCOPY Copy system image to a device to make it bootable. Use SYSCOPY with no parms for usage instructions. MODE Reconfigures serial ports dynamically. FDU Format and test floppy disks. Menu driven interface. FORMAT Will someday be a command line tool to format floppy disks. Currently does nothing! XM XModem file transfer program adapted to hardware. Automatically uses primary serial port on system. FLASH Will Sowerbutts\u2019 in-situ ROM programming utility. FDISK80 John Coffman\u2019s Z80 hard disk partitioning tool. See documentation in Doc directory. FAT Access MS-DOS FAT filesystems from RomWBW (based on FatFs). TALK Direct console I/O to a specified character device. RTC Manage and test the Real Time Clock hardware. TIMER Display value of running periodic system timer. CPUSPD Change the running CPU speed and wait states of the system. Some custom applications do not fit on the ROM disk. They are found on the disk image files or the individual files can be found in the Binary/Apps directory of the distribution. They are also included on the floppy disk and hard disk images. Application Description TUNE Play .PT2, .PT3, .MYM audio files. INTTEST Test interrupt vector hooking.","title":"Custom Applications"},{"location":"UserGuide/#real-time-clock-datetime-stamping","text":"RomWBW supports a variety of real time clock hardware. If your system has this hardware, then it will be able to maintain the current date and time even while your system is turned off. Additionally, depending on the operating system being used, you may be able to utilize date/time stamping of files. To facilitate this a CP/M clock driver (WBWCLK) has been included inside CLOCKS.DAT that will read the clock via a RomWBW HBIOS call You can determine if your system has a real time clock present (and functioning) by looking at the boot messages. Here is an example of a boot message reflecting the detection of a valid real time clock module: DSRTC: MODE=STD IO=0x8A Thu 2023-10-19 14:07:11 CHARGE=ON This example is from a DSRTC clock module. You may have a different one, but it will always display the current date/time. In some cases, your real time clock will support charging of the battery or super-capacitor while the system has power. The status of this charging is displayed. If the date/time of your RTC needs to be updated, you will need to do this with one of the utilities described below. There is no ability to update the date/time of the RTC in the RomWBW Boot Loader or Monitor.","title":"Real Time Clock &amp; Date/Time Stamping"},{"location":"UserGuide/#datetime-utilities","text":"RomwWBW includes two utilities for displaying or setting the date/time stored by the RTC. They are both a bit different and are briefly described below. A third utility TESTCLOK is also included as part of ZSDOS","title":"Date/Time Utilities"},{"location":"UserGuide/#wdate-utility","text":"The WDATE utility (contributed by Kevin Boone) is an application that will display and/or update the current date/time. Its operation is described in RomWBW Applications . This utility works with any of the supported RomWBW RTC hardware. Here is an example of displaying and updating the date/time with this utility: A>wdate Thursday 19 October 14:14:43 2023 A>wdate 23 10 19 14 24 30 A>wdate Thursday 19 October 14:24:34 2023 Note that WDATE does not have anything to do with date/time stamping of files. It merely displays and sets the real time clock value.","title":"WDATE Utility"},{"location":"UserGuide/#rtc-utility","text":"Like WDATE , the RTC utility (contributed by Andrew Lynch) will let you display and set the current date/time. However, this utility only works with the DSRTC hardware (DS1302 chip). It is a \u201cdirect to hardware application\u201d. Its operation is described in RomWBW Applications . Here is an example of displaying and updatting the date/time with this utility: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>t Current time: 23-10-19 14:30:25-05 RTC>i Init date/time. YEAR:23 MONTH:10 DATE:19 HOURS:14 MINUTES:31 SECONDS:00 DAY:05 The RTC utility is also capable of turning the charging feature of the DS1320 chip on or off. Here is an example of turning if off and back on: A>rtc Start RTC Program RomWBW HBIOS, Mark 4 RTC Latch Port 0x8A RTC: Version 1.9 Commands: E)xit T)ime st(A)rt S)et R)aw L)oop C)harge N)ocharge D)elay I)nit G)et P)ut B)oot W)arm-start H)elp RTC>n Trickle charger disabled. RTC>c Trickle charger enabled. Do not enable charging unless you are sure that your system supports this. If your RTC is being powered by a normal battery, it would be dangerous to enable charging.","title":"RTC Utility"},{"location":"UserGuide/#testclok-utility","text":"The TESTCLOK utility is used to test a selected CPM clock driver loaded from the CLOCKS.DAT file. After selecting the location of CLOCKS.DAT and the clock driver (45. WBWCLK) it displays the currently configured time until a key is pressed. A>testclok TESTCLOK V1.0 Copyright (C) 1988 H.F. Bower / C.W. Cotrill Extract Clock from Library ([Y]/N) : Y Location of CLOCKS.DAT [A0:] : <RETURN> 1. ACTRIX 2. ALSPA 3. AMPRO-LB 4. ANLYTCL-PRD 5. AP2-CDZ180 6. AP2-THND/MT 7. AP2-TIMASTR 8. AP2E+PCP-TM 9. AP2E+PCPI 10. AP2E-THUNDR 11. AP2E-TMASTR 12. BIG-BD-II 13. BP-BIOS 14. CCS-WALLCLK 15. CPUPRO-SSB1 16. ELECTR-MFIO 17. EPSON-QX10 18. ETS180IO+ 19. H19-SUPER19 20. H19-ULTRA 21. H19-WATZMAN 22. H89-BITZERO 23. H89-PC12 24. H89-WIDGET 25. H89-WISE 26. H89UTI 27. HEATH-BIOS 28. HOUSEMASTER 29. K83-HOLMES 30. KAYPRO-84 31. KENMOR-ZTIM 32. KPRO-ADVENT 33. KPRO-LEGACY 34. MD3-MACK 35. MTN100K-DAY 36. ONEAC-ON! 37. OTRANA-ATCH 38. P&T-HEARTBT 39. QTSYS-S100 40. RELATIVE 41. S100-5832 42. SB180-HRTBT 43. SB180-XBIOS 44. SIMHCLOK 45. WBWCLK 46. XEROX-820 47. ZSDOS-BIOS Enter Clock Driver Selection : 45 ..Loading : WBWCLK ... Linking Clock Module... OK RomWBW HBIOS Clock 1.1 RomWBW Series HBIOS Clock Press any key to quit... 19 Oct 2023 14:24:34 Since this runs at the CPM driver level it is useful as an end-to-end test to prove that date time stamping is able to read the correct time The TESTCLOK utility is provided by ZSDOS, plese see the ZSDOS Manual for further information","title":"TESTCLOK Utility"},{"location":"UserGuide/#datetime-file-stamping","text":"If an RTC is available in your system, then most operating systems can use it to date/time stamp files. This just means recording the date/time of file creation, update, and or access in the directory. This capability is available in all of the RomWBW operating system except the original DRI CP/M 2.2. Three types of date/time stamping are supported using realtime clock supported by RomWBW HBIOS. DateStamper, NZT and P2DOS. In some cases (such as ZSDOS), you must load an RSX (memory resident utility) to enable date/time stamping of files. This could be automated using a PROFILE.SUB file. Preconfigured loaders are provided, bypassing the need to use SETUPZST. Additionally, you will need to initialize the directory. The procedure varies depending on the date/time stamping mechanism, so you must review the associated documentation. The date/time stamping mechanisms for each operating system are generally not compatible. If you initialize a directory for a type of stamping, you should be careful not to manipulate that directory with a different operating system with a different date/time stamping mechanism. Doing so may corrupt the directory. The RomWBW disk images do not have date/time stamping initialized. This is to avoid any chance of directory corruption.","title":"Date/Time File Stamping"},{"location":"UserGuide/#datestamper","text":"DateStamper datestamping follows the standard set by Plu*Perfect Systems. This method stores stamps in a disk file named !!!TIME&.DAT . Only DateStamper stamping stores full time and date stamps for file Creation, Last Modification, and Last Access, and may be used with any CP/M diskette format. In addition, the DateStamper protocol is supported by a mature set of compatible utilities. Key Utilities LDDS.COM - Load DateStamper date/time stamping resident extension. (RomWBW Provided) PUTDS.COM - Prepare disk for DateStamper date/time stamping. After using PUTDS to initialize a directory for ZDS date stamping, it may be necessary to run RELOG before the stamping routines will actually start working.","title":"DateStamper"},{"location":"UserGuide/#p2dos-cpm-plus-compatible","text":"CP/M Plus-type datestamping is also widely used due to the popularity of CP/M Plus (also know as CP/M 3). CP/M Plus-type file datestamping uses directory sectors to store file datestamps which may be accessed more quickly by programs, but there is no Last File Access stamp. Finally, the range of utilities for this type of stamps is more limited than for the DateStamper protocol. Key Utilities LDP2D.COM - Load P2DOS date/time stamping resident extension. (RomWBW Provided) INITDIR.COM - Prepares disks for P2DOS-type file stamping.","title":"P2DOS (CP/M Plus compatible)"},{"location":"UserGuide/#nzt","text":"The use of NZT needs to be further documented Key Utilities LDNZT.COM - Load NZT date/time stamping resident extension. (RomWBW Provided)","title":"NZT"},{"location":"UserGuide/#additional-notes","text":"The following files have been provided, customised and tested for for use in RomWBW CLOCKS.DAT - Library of clock drivers, which has been updated to include the RomWBW clock driver WBWCLK, and also includes the SIMHCLOK clock driver. The file is just a standard LU type library and is easily updated using NULU. The members are the relocatable binaries, but with the .REL extension removed. STAMPS.DAT - Library of available date/time stamping modules for SETUPZST. The file has been replaced with an updated version from the Walnut Creek CP/M CDROM. The original version has a bug that prevents RSX (resident system extension) mode to load properly. Additional Notes SETUPZST (provided by ZSDOS) Should not normally be needed since the creation of the appropriate LDTIM loaders has already been performed. FILEDATE only works with DateStamper style date stamping. If you run it on a drive that is not initialized for DateStamper, it will complain FILEDATE, !!!TIME&.DAT missing . This is normal and just means that you have not initialized that drive for DateStamper (using PUTDS). ZXD will handle either DateStamper or P2DOS type date stamping. However, it must be configured appropriately. As distributed, it will look for P2DOS date stamps. Use ZCNFG to reconfigure it for P2DOS if that is what you are using.","title":"Additional Notes"},{"location":"UserGuide/#timezone","text":"None of the operating systems distributed with RomWBW have any concept of timezone. When files are date/time stamped, the date/time will simply be whatever date/time the RTC currently has. The normal practice is to set the RTC to your local time. This implies that you would need to manually adjust the RTC for daylight savings time and/or when you travel to a different time zone. The date/time stamps of files in directories will also be stored in local time. This includes files stored in a FAT filesystem. If you subsequently view the directory from modern machines (Windows, Linux, etc.), the date/time displayed will depend on the behavior of the modern system. For example, Linux assumes that the date/time of files is UTC. So, if you create a file on a FAT filesystem with your RomWBW computer and then use Linux to view the directory, the date/time stamps will seem \u201coff\u201d by a few hours. The only alternative you may consider is setting the date/time of your RTC to UTC. Since UTC is consistent across all timezones and daylight savings time, your file date/time stamps will also be consistent. Of course, this will mean that your RomWBW computer will display a date/time that seems wrong because it is not local time.","title":"Timezone"},{"location":"UserGuide/#cpnet-networking","text":"Digital Research created a simple network file sharing system called CP/NET. This allowed a network server running CP/NOS to host files available to network attached CP/M computers. Essentially, the host becomes a simple file sharing server. RomWBW disk images include an adaptation of the DRI CP/NET client software provided by Douglas Miller. RomWBW does not support operation as a network server itself. However, Douglas has also developed a Java-based implementation of the DRI network server that can be used to provide host services from a modern computer. Both CP/NET 1.2 and 3.0 clients are provided. Version 1.2 is for use with CP/M 2.2 and compatible OSes. Version 3.0 is for use with CP/M 3 and compatible OSes. The CP/NET client software provided with RomWBW requires a supported ethernet interface module. At this time, the following are supported: RCBus MT011 w/ Ethernet Featherwing and (optionally) SPI FRAM (e.g., Adafruit SPI Non-Volatile FRAM Breakout) Duodyne Disk I/O w/ Wiz850IO and (optionally) SPI NVRAM (e.g., 25LC256) Generic Serial Interface NOTE: The Generic Serial Interface is supported by RomWBW, but is not documented here. You must refer to the CP/NET documentation referenced below. The client software interacts directly with this hardware. In a future version of RomWBW, I hope to add a generic networking API that will allow a greater range of network hardware to be used. To use CP/NET effectively, you will want to review the documentation provided by Douglas on at his cpnet-z80 GitHub Project . Additionally, you should consult the DRI documentation which is not included with RomWBW, but is available on the cpnet-z80 site. Below, I will provide the general steps involved in setting up a network using MT011 with RomWBW.","title":"CP/NET Networking"},{"location":"UserGuide/#cpnet-client-setup","text":"The CP/NET client files are included on the RomWBW disk images, but they are found in user area 4. They are placed there to avoid confusing anyone that is not specifically trying to run a network client. They are only found on the CPM 2.2 and CP/M 3 slices. Using CP/NET on alternative OSes may work, but is not officially supported. The CP/NET client files are packaged in .LBR library files. The library files are found in user area 4. 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 First, you need to merge the files from the correct library file into user area 0. This is done by extracting the files using the NULU library management utility application. Start NULU specifying desired CP/NET library for \\<filename>: A>NULU 4:<filename> At the NULU prompt, extract the files using the -E *.* command: -READY A0:>-E *.* Exit NULU using the -X command: -Extract members A0:>-x Here is an example of extracting the CP/NET 1.2 client files for an RCBus system w/ MT011. You should be in user area 0 when performing this operation. A>nulu 4:cpn12mt NULU 1.52 (07/12/87) Copyright (C) 1984, 1985 & 1987 by Martin Murray Bug fixes in version 1.52 by Mick Waters TYPE -H FOR HELP Library A4:CPN12MT.LBR open. (Buffer size: 259 sectors) Active entries: 27, Deleted: 0, Free: 5, Total: 32. -READY A0:>-e *.* Extracting... CCP .SPR to A0:CCP .SPR CPM2NET .HLP to A0:CPM2NET .HLP CPNBOOT .COM to A0:CPNBOOT .COM CPNET12 .HLP to A0:CPNET12 .HLP CPNETLDR.COM to A0:CPNETLDR.COM CPNETSTS.COM to A0:CPNETSTS.COM DSKRESET.COM to A0:DSKRESET.COM ENDLIST .COM to A0:ENDLIST .COM LOCAL .COM to A0:LOCAL .COM LOGIN .COM to A0:LOGIN .COM LOGOFF .COM to A0:LOGOFF .COM MAIL .COM to A0:MAIL .COM NDOS .SPR to A0:NDOS .SPR NETDOWN .COM to A0:NETDOWN .COM NETSTAT .COM to A0:NETSTAT .COM NETWORK .COM to A0:NETWORK .COM NVRAM .COM to A0:NVRAM .COM PIPNET .COM to A0:PIPNET .COM RDATE .COM to A0:RDATE .COM SNIOS .SPR to A0:SNIOS .SPR SRVSTAT .COM to A0:SRVSTAT .COM TR .COM to A0:TR .COM WIZCFG .COM to A0:WIZCFG .COM WIZDBG .COM to A0:WIZDBG .COM WIZTEST .COM to A0:WIZTEST .COM XSUBNET .COM to A0:XSUBNET .COM -Extract members A0:>-x Closing A4:CPN12MT.LBR... At this point, you will need to configure your ethernet adapter for your local network using WIZCFG . The definitive guide to the use of WIZCFG is on the cpnet-z80 site in the document called \u201cCPNET-WIZ850io.pdf\u201d. Here is an example of the commands needed to configure the WizNet: wizcfg w n F0 set CP/NET node id wizcfg w i 192.168.1.201 set WizNet IP address wizcfg w g 192.168.1.1 set local network gateway IP address wizcfg w s 255.255.255.0 set WizNet subnet mask wizcfg w 0 00 192.168.1.3 31100 set server node ID, IP address, & port You will need to use values appropriate for your local network. You can use the command wiznet w to display the current values which is useful to confirm they have been set as intended. A>wizcfg w Node ID: F0H IP Addr: 192.168.1.201 Gateway: 192.168.1.1 Subnet: 255.255.255.0 MAC: 98:76:B6:11:00:C4 Socket 0: 00H 192.168.1.3 31100 0 These values can be persisted across power-cycles if your system has NVRAM storage. To program the values into your NVRAM, you would use the same commands as above, but omit the w parameter. The \u201cCPNET-WIZ850io.pdf\u201d document is highly recommended to understand the operation of WIZCFG . If you do not utilize NVRAM to persist your configuration, you will need to reapply these commands every time you power cycle your RomWBW computer, so I recommend putting them into a SUBMIT file. After applying these commands, you should be able ping the WizNet from another computer on the local network. If this works, then the client-side is ready.","title":"CP/NET Client Setup"},{"location":"UserGuide/#cpnet-sever-setup","text":"These instructions will assume you are using Douglas Miller\u2019s CpnetSocketServer to implement a CP/NOS server on your network. The definitive guide to this software is also on the [cpnet-z80] (https://github.com/durgadas311/cpnet-z80) site and is called \u201cCpnetSocketServer.pdf\u201d. The software is a Java application, so it can generally run anywhere there is a Java runtime environment available. I have normally used it on a Linux system and have had good results with that. You will need to download the application called \u201cCpnetSocketServer.jar\u201d from the cpnet-z80 site. The application uses a configuration file. My configuration file is called \u201ccpnet00.rc\u201d and has these contents: cpnetserver_host = 192.168.1.3 cpnetserver_port = 31100 cpnetserver_temp = P cpnetserver_sid = 00 cpnetserver_max = 16 cpnetserver_root_dir = /home/wayne/cpnet/root You will also need to setup a directory structure with the drive letters per the documentation. To start the server, you would use a command like this: java -jar CpnetSocketServer.jar conf=cpnet00.rc At this point, the server should start and you should see the following: CpnetSocketServer v1.3 Using config in cpnet00.rc Server 00 Listening on 192.168.1.3 port 31100 debug false Your CP/NET server should now be ready to accept client connections.","title":"CP/NET Sever Setup"},{"location":"UserGuide/#cpnet-usage","text":"With both the client and server configured, you are ready to load and use CP/NET on your RomWBW system. CP/NET documentation is available on the cpnet-z80 site. The document is called \u201cdri-cpnet.pdf\u201d. Under CP/M 2.2, you will start the networking client using the command CPNETLDR . Under CP/M 3, you use the command NDOS3 . If that works, you can map network drives as local drives using the NETWORK command. The CPNETSTS command is useful for displaying the current status. Here is a sample session from CP/M 2.2: A>cpnetldr CP/NET 1.2 Loader ================= BIOS E600H 1A00H BDOS D800H 0E00H SNIOS SPR D400H 0400H NDOS SPR C800H 0C00H TPA 0000H C800H CP/NET 1.2 loading complete. A>network k:=c:[0] A>dir k: K: TELNET COM : ZDENST COM : CLRDIR COM : RTC COM K: DDTZ COM : MBASIC COM : XSUBNET COM : NETWORK COM K: WGET COM : UNCR COM : FLASH COM : PIP COM K: TIMEZONE COM : COMPARE COM : ZAP COM A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = LOCAL Drive B: = LOCAL Drive C: = LOCAL Drive D: = LOCAL Drive E: = LOCAL Drive F: = LOCAL Drive G: = LOCAL Drive H: = LOCAL Drive I: = LOCAL Drive J: = LOCAL Drive K: = Drive C: on Network Server ID = 00H Drive L: = LOCAL Drive M: = LOCAL Drive N: = LOCAL Drive O: = LOCAL Drive P: = LOCAL Console Device = LOCAL List Device = LOCAL If you are using CpSocketServer to provide the CP/NOS server, then you will see some messages on your server console when clients connect. Here are the messages issued by the server in the above example: Connection from 192.168.1.201 (31100) Remote 192.168.1.201 is f0 Creating HostFileBdos 00 device with root dir /home/wayne/cpnet/root At this point CP/NET is ready for general use. You should be able to access files on the network mapped drives just like files on your local drives.","title":"CP/NET Usage"},{"location":"UserGuide/#network-boot","text":"It is possible to boot your RomWBW system directly from a network server if it has the required hardware. 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. The supported hardware is: RCBus System w/ MT011 including: Featherwing WizNet W5500 SPI FRAM on secondary SPI interface (CS2) Doudyne Disk I/O Board including: WIZ850io Module 25LCxxx Serial SPI EEPROM Unlike the CP/NET Client, the presence of dedicated non-volatile storage is required to hold the network configuration. This will be FRAM (for MT011) or Serial SPI EEPROM (Duodyne). The NVRAM is used to store your WizNet configuration values so they do not need to be re-entered every time you power-cycle your system. It is important to understand that the operating system that is loaded in this case is not a RomWBW enhanced operating system. Some commands (such as the ASSIGN command) will not be possible. Also, you will only have access to drives provided by the network server \u2013 no local disk drives will be available. Using the same values from the previous example, you would issue the WIZCFG commands: wizcfg n F0 wizcfg i 192.168.1.201 wizcfg g 192.168.1.1 wizcfg s 255.255.255.0 wizcfg 0 00 192.168.1.3 31100 Note that the \u2018w\u2019 parameter is now omitted which causes these values to be written to NVRAM. As before, your network server will need to be running CpnetSocketServer. However, you will need to setup a directory that contains some files that will be sent to your RomWBW system when the Network boot is performed. By default the directory will be ~/NetBoot . In this directory you need to place the following files: cpnos.sys ndos.spr snios.spr You also need to make sure CpnetSocketServer is configured with an \u2018A\u2019 drive and that drive must contain (at an absolute minimum) the following file: ccp.spr All of these files are found in the Binary/CPNET/NetBoot directory of the RomWBW distribution. You will find 2 sub-directories named MT and DUO. Get the files from the sub-directory corresponding to your specific hardware. Finally, you need to add the following line to your CpnetSocketServer configuration file: netboot_default = cpnos.sys To perform the network boot, you start your RomWBW system normally which should leave you at the Boot Loader prompt. The \u2018N\u2019 command will initiate the network boot. Here is an example of what this looks like: RCBus [RCZ180_nat_wbw] Boot Loader Boot [H=Help]: n Loading Network Boot... MT011 WizNET Network Boot WBWBIOS SPR FD00 0100 COBDOS SPR FA00 0300 SNIOS SPR F600 0400 NDOS SPR EA00 0C00 58K TPA A> The CP/M operating system and the CP/NET components have been loaded directly from the network server. All of your drive letters are automatically mapped directly to the drive letters configured with CpnetSocketServer. A>cpnetsts CP/NET 1.2 Status ================= Requester ID = F0H Network Status Byte = 10H Disk device status: Drive A: = Drive A: on Network Server ID = 00H Drive B: = Drive B: on Network Server ID = 00H Drive C: = Drive C: on Network Server ID = 00H Drive D: = Drive D: on Network Server ID = 00H Drive E: = Drive E: on Network Server ID = 00H Drive F: = Drive F: on Network Server ID = 00H Drive G: = Drive G: on Network Server ID = 00H Drive H: = Drive H: on Network Server ID = 00H Drive I: = Drive I: on Network Server ID = 00H Drive J: = Drive J: on Network Server ID = 00H Drive K: = Drive K: on Network Server ID = 00H Drive L: = Drive L: on Network Server ID = 00H Drive M: = Drive M: on Network Server ID = 00H Drive N: = Drive N: on Network Server ID = 00H Drive O: = Drive O: on Network Server ID = 00H Drive P: = Drive P: on Network Server ID = 00H Console Device = LOCAL List Device = LOCAL At this point you can use CP/M and CP/NET normally, but all disk access will be to/from the network drives. There is no access to your local disk drives in this boot mode.","title":"Network Boot"},{"location":"UserGuide/#transferring-files","text":"Transferring files between your modern computer and your RomWBW system can be achieved in a variety of ways. The most common of these are described below. All of these have a certain degree of complexity and I encourage new users to use the available community forums to seek assistance as needed.","title":"Transferring Files"},{"location":"UserGuide/#serial-port-transfers","text":"RomWBW provides an serial file transfer program called XModem that has been adapted to run under RomWBW hardware. The program is called XM and is on your ROM disk as well as all of the pre-built disk images. You can type XM by itself to get usage information. In general, you will run XM with parameters to indicate you want to send or receive a file on your RomWBW system. Then, you will use your modern computers terminal program to complete the process. The XM application generally tries to detect the hardware you are using and adapt to it. However, you must ensure that you have a reliable serial connection. You must also ensure that the speed of the connection is not too fast for XModem to service. If your file transfer attempts are failing, try either of the following: Check that hardware flow control is enabled in your terminal emulation software. Reduce the speed of your serial port connection. There is an odd interaction between XModem and partner terminal programs that can occur. Essentially, after launching XM , you must start the protocol on your modern computer fairly quickly (usually in about 20 seconds or so). So, if you do not pick a file on your modern computer quickly enough, you will find that the transfer completes about 16K, then hangs. The interaction that causes this is beyond the scope of this document.","title":"Serial Port Transfers"},{"location":"UserGuide/#disk-image-transfers","text":"It is possible to pass disk images between your RomWBW system and your modern computer. This assumes you have an appropriate media slot on your modern computer for the media you want to use (CF Card, SD Card, floppy drive, etc.). The general process to get files from your modern computer to a RomWBW computer is: Use cpmtools on your modern computer to create a RomWBW CP/M filesystem image. Insert your RomWBW media (CF Card, SD Card, floppy disk, etc.) in your modern computer. Use a disk imaging tool to copy the RomWBW filesystem image onto the media. Move the media back to the RomWBW computer. This process is a little complicated, but it has the benefit of allowing you to get a lot of files over to your RomWBW system quickly and with little chance of corruption. The process can be run in reverse to get files from your RomWBW computer to a modern computer. The exact use of these tools is a bit too much for this document, but the tools are all included in the RomWBW distribution along with usage documents. Note that the build scripts for RomWBW create the default disk images supplied with RomWBW. It is relatively easy to customize the contents of the disk images that are part of RomWBW. This is described in more detail in the Source/Images directory of the distribution.","title":"Disk Image Transfers"},{"location":"UserGuide/#fat-filesystem-transfers","text":"The FAT filesystem format that originated with MS-DOS is almost ubiquitous across modern computers. Virtually all operating systems now support reading and writing files to a FAT filesystem. For this reason, RomWBW now has the ability to read and write files on FAT filesystems. This capability means that you can generally use your modern computer to make an SD Card, CF Card, or USB Drive with a standard FAT filesystem on it, then place that media in your RomWBW computer and access the files. Files can be copied between a FAT filesystem and a CP/M filesystem, but you cannot execute files directly from a FAT filesystem. FAT12, FAT16, and FAT32 formats are supported. Long filenames are not supported. Files with long filenames will show up with their names truncated into the older 8.3 convention. If you have files on your modern computer with long filenames, it is usually easiest to rename them on the modern computer. A FAT filesystem can be located on floppy or hard disk media. For hard disk media, a valid FAT Filesystem partition must exist. Some additional Notes and WARNINGS Things to be careful about CP/M (and compatible) OSes do not support all of the filename characters that a modern computer does. The following characters are not permitted in a CP/M filename: < > . , ; : = ? * [ ] _ % | ( ) / \\ The FAT application does not auto-rename files when it encounters invalid filenames. It will just issue an error and quit. Additionally, the error message is not very clear about the problem. Microsoft Windows will sometimes suggest reformatting partitions that it does not recognize (e.g. RomWBW). If you are using media that contains both a FAT partition and a RomWBW partition you may prompted to format a partition of your SD/CF/USB Media when inserting the card into a Windows computer, you probably want to select Cancel.","title":"FAT Filesystem Transfers"},{"location":"UserGuide/#fat-filesystem-preparation","text":"In general, you can create media formatted with a FAT filesystem on your RomWBW computer or on your modern computer. We will only be discussing the RomWBW-based approach here.","title":"FAT Filesystem Preparation"},{"location":"UserGuide/#floppy-disk","text":"In the case of a floppy disk, you can use the FAT application to format the floppy disk. The floppy disk must already be physically formatted using RomWBW FDU or equivalent. If your floppy disk is on RomWBW disk unit 2, you could use FAT FORMAT 2: . This will overwrite the floppy with a FAT filesystem and all previous contents will be lost. Once formatted this way, the floppy disk can be used in a floppy drive attached to a modern computer or it can be used on RomWBW using the other FAT tool commands.","title":"Floppy Disk"},{"location":"UserGuide/#hard-disk","text":"In the case of hard disk media, it is necessary to have a FAT partition. If you prepared your RomWBW hard disk media using the disk image process, then this partition will already be defined and you do not need to recreate it. This default FAT partition is located at approximately 512MB from the start of your disk and it is 384MB in size. So, your hard disk media must be 1GB or greater to use this default FAT partition. You can confirm the existence of the FAT partition with FDISK80 by using the \u2018P\u2019 command to show the current partition table. Here is an example of a partition table listing from FDISK80 that includes the FAT partition (labelled \u201cFAT16\u201d): Capacity of disk 4: ( 4G) 7813120 Geom 77381010 Nr ---Type- A -- Start End LBA start LBA count Size 1 RomWBW 2e 8:0:1 1023:15:16 2048 1048576 512M 2 FAT16 06 1023:0:1 1023:15:16 1050624 786432 384M 3 00 *** empty *** 4 00 *** empty *** If your hard disk media does not have a FAT partition already defined, you will need to define one using FDISK80 by using the \u2018N\u2019 command. Ensure that the location and size of the FAT partition does not overlap any of the CP/M slice area and that it fits within the size of your media. Once the partition is defined, you will still need to format it. Just as with a floppy disk, you use the FAT tool to do this. If your hard disk media is on RomWBW disk unit 4, you would use FAT FORMAT 4: . This will look something like this: E>fat format 4: About to format FAT Filesystem on Disk Unit #4. All existing FAT partition data will be destroyed!!! Continue (y/n)? Formatting... Done Your FAT filesystem is now ready to use. If your RomWBW system has multiple disk drives/slots, you can also just create a disk with your modern computer that is a dedicated FAT filesystem disk. You can use your modern computer to format the disk (floppy, CF Card, SD Card, etc.), then insert the disk in your RomWBW computer and access it using FAT based on its RomWBW unit number.","title":"Hard Disk"},{"location":"UserGuide/#fat-application-usage","text":"Transferring files is accomplished by running a RomWBW custom application called FAT . This application understands both FAT filesystems as well as CP/M filesystems. To copy files from your modern computer to your RomWBW computer, start by putting the disk media with the FAT filesystem in your modern computer. The modern computer should recognize it. Then copy the files you want to get to your RomWBW computer onto this media. Once done, remove the media from your modern computer and insert it in the RomWBW computer. Finally, use the FAT tool to copy the files onto a CP/M drive. This process works just fine in reverse if you want to copy files from a CP/M filesystem to your modern computer. Complete instructions for the FAT application are found in RomWBW Applications . Here, we will just provide a couple of simple examples. Note that the FAT application is not on the ROM disk because it is too large to include there. The most important thing to understand about the FAT application is how it refers to FAT filesystems vs. CP/M filesystems. It infers this based on the file specification provided. If you use a specification like C:SAMPLE.TXT , it will use the C: drive of your CP/M operating system. If you use a specification like 4:SAMPLE.TXT , it will use the FAT filesystem on the disk in RomWBW disk unit 4. Basically, if you start your file or directory specification with a number followed by a colon, it means FAT filesystem. Anything else will mean CP/M filesystem. Here are a few examples. This first example shows how to get a FAT directory listing from RomWBW disk unit 4: E>fat dir 4: Directory of 4: E> As you can see, there are currently no files there. Now let\u2019s copy a file from CP/M to the FAT directory: E>fat copy sample.txt 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT ... [OK] 1 File(s) Copied If we list the FAT directory again, you will see the file: E>fat dir 4: Directory of 4: 01/30/2023 17:50:14 29952 ---A SAMPLE.TXT Now let\u2019s copy the file from the FAT filesystem back to CP/M. This time we will get a warning about overwriting the file. For this example, we don\u2019t want to do that, so we abort and reissue the command specifying a new filename to use: E>fat copy 4:sample.txt e: Copying... 4:/SAMPLE.TXT ==> E:SAMPLE.TXT Overwrite? (Y/N) [Skipped] 0 File(s) Copied E>fat copy 4:sample.txt e:sample2.txt Copying... 4:/SAMPLE.TXT ==> E:SAMPLE2.TXT ... [OK] 1 File(s) Copied Finally, let\u2019s try using wildcards: E>fat copy sample*.* 4: Copying... SAMPLE.TXT ==> 4:/SAMPLE.TXT Overwrite? (Y/N) ... [OK] SAMPLE2.TXT ==> 4:/SAMPLE2.TXT ... [OK] 2 File(s) Copied","title":"FAT Application Usage"},{"location":"UserGuide/#customizing-romwbw","text":"","title":"Customizing RomWBW"},{"location":"UserGuide/#startup-command-processing","text":"Most of the operating systems supported by RomWBW provide a mechanism to run commands at boot. This is similar to the AUTOEXEC.BAT files from MS-DOS. With the exception of ZPM3 and p-System, all operating systems will look for a file called PROFILE.SUB on the system drive at boot. If it is found, it will be processed as a standard CP/M submit file. You can read about the use of the SUBMIT facility in the CP/M manuals included in the RomWBW distribution. Note that the boot disk must also have a copy of SUBMIT.EXE . Note that the automatic startup processing generally requires booting to a disk drive. Since the ROM disk is not writable, there is no simple way to add/edit a PROFILE.SUB file there. If you want to customize your ROM and add a PROFILE.SUB file to the ROM Disk, it will work, but is a lot harder than using a boot disk. In the case of ZPM3, the file called STARTZPM.COM will be run at boot. To customize this file, you use the ZCPR ALIAS facility. You will need to refer to ZCPR documentation for more information on the ALIAS facility. p-System has its own startup command processing mechanism that is covered in the p-System documentation.","title":"Startup Command Processing"},{"location":"UserGuide/#nvram-configuration","text":"See section Setting NVRAM Options for information about how to apply NVRAM configuration.","title":"NVRAM Configuration"},{"location":"UserGuide/#rom-customization","text":"The pre-built ROM images are configured for the basic capabilities of each platform. Additionally, some of the typical add-on hardware for each platform will be automatically detected and used. If you want to go beyond this, RomWBW provides a very flexible configuration mechanism based on configuration files. Creating a customized ROM requires running a build script, but it is quite easy to do. Essentially, the creation of a custom ROM is accomplished by updating a small configuration file, then running a script to compile the software and generate the custom ROM and disk images. There are build scripts for Windows, Linux, and MacOS to accommodate virtually all users. All required build tools (compilers, assemblers, etc.) are included in the distribution, so it is not necessary to setup a build environment on your computer. RomWBW can be built on modern Windows, Linux, or MacOS computers. The process for building a custom ROM is documented in the ReadMe.txt file in the Source directory of the distribution. Any modern version of Windows (32-bit or 64-bit), MacOS, or Linux released in the last 10 years should be able to run the build process. For those who are interested in more than basic system customization, note that all source code is provided (including the operating systems). Modification of the source code is considered an expert level task and is left to the reader to pursue. Note that the ROM customization process does not apply to UNA. All UNA customization is performed within the ROM setup script that is built into the ROM.","title":"ROM Customization"},{"location":"UserGuide/#rom-user-application","text":"The User App is provided as a way to access a custom written ROM application. 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 instead, review the \u201cusrrom.asm\u201d file in the Source/HBIOS folder of the distribution.","title":"ROM User Application"},{"location":"UserGuide/#upgrading","text":"Upgrading to a newer release of RomWBW is essentially just a matter of updating the ROM chip in your system. If you have spare ROM chips for your system and a ROM programmer, it is always safest to retain your existing, working ROM chip and program a new one with the new firmware. If the new one fails to boot, you can easily return to the known working ROM. For each ROM that comes with the RomWBW distribution, you will find that there are actually 3 different variants: .rom contains the complete ROM chip image .upd contains the system code, but omits the ROM Disk contents .com contains a CP/M executable version of the ROM code So, for example, RCZ80_std contains the following files: SBC_std.rom SBC_std.upd SBC_std.com The use of the .com variant is described below in Application Boot . As previously discussed, the ROM in most RomWBW systems contains both the system code as well as a ROM Disk with files on it. The .rom variant of the ROM contains a full ROM chip image including both the system code and the Rom Disk contents. The .upd variant of the ROM contains only the system code portion of the ROM. If you apply the .upd variant to your system, it will overlay the system code, but will not overlay the ROM Disk contents (they remain intact). You may use either the .rom or the .upd file when updating your ROM chip (this does not apply to Application Boot). It is best to use the .rom file for your upgrade because the files on your ROM Disk should be updated whenever you update your system code. The advantage of the .upd variant is that is much smaller, so you can upload and apply it faster. The ROM update instructions below generally refer to using the .rom variant. However, you may substitute the .upd variant if desired.","title":"Upgrading"},{"location":"UserGuide/#application-boot","text":"Prior to attempting to reprogram your actual ROM chip, you may wish to \u201ctry\u201d the update to ensure it will work on your system. With RomWBW, you can upload a new ROM image executable and load it from the command line. For each ROM image file (.rom) in the Binary directory, you will find a corresponding application file (.com). For example, for SBC_std.rom, there is also an SBC_std.com file. You can upload the .com file to your system using XModem, then simply run the .com file. You will see your system go through the normal startup process just like it was started from ROM. However, your physical ROM has not been updated and the next time you boot your system, it will revert to the system image contained in ROM. Using this .com version of a ROM is an excellent way to confirm that the new ROM code you intend to program will work correctly. If it does not, then you can just reboot and your old ROM will be loaded. When the .com file is loaded, you will be taken to the normal Boot Loader menu. However, you will find that the only OS that is available to boot from ROM is ZSDOS. There is only room for a single OS in the .com file. Even if you don\u2019t normally use ZSDOS, this will still confirm that your system operates well under the new ROM code.","title":"Application Boot"},{"location":"UserGuide/#upgrading-via-flash-utility","text":"If you do not have easy access to a ROM programmer, it is usually possible to reprogram your system ROM using the FLASH utility from Will Sowerbutts. This application, called FLASH.COM, can be found on the ROM drive of any running system. In this case, you would need to transfer the new ROM image (.rom) over to your system using XModem (or one of the other mechanisms described in the Transferring Files section). The ROM image is too large to fit on your RAM drive, so you will need to transfer it to a larger storage drive. Once the ROM image is on your system, you can use the FLASH application to update your ROM. The following is a typical example of transferring ROM image using XModem and flashing the chip in-situ. NOTE : The FLASH utility can not determine the type of your ROM chip if it is write protected. Additionally, it has no way to determine if it is write protected. If the FLASH utility indicates it does not recognize your ROM chip, check to ensure the chip is not write protected. E>xm r rom.rom XMODEM v12.5 - 07/13/86 RBC, 28-Aug-2019 [WBW], ASCI Receiving: E0:ROM.IMG 7312k available for uploads File open - ready to receive To cancel: Ctrl-X, pause, Ctrl-X Thanks for the upload E>flash write rom.rom FLASH4 by Will Sowerbutts <will@sowerbutts.com> version 1.2.3 Using RomWBW (v2.6+) bank switching. Flash memory chip ID is 0xBFB7: 39F040 Flash memory has 128 sectors of 4096 bytes, total 512KB Write complete: Reprogrammed 2/128 sectors. Verify (128 sectors) complete: OK! Obviously, there is some risk to this approach since any issues with the programming or ROM image could result in a non-functional system. To confirm your ROM chip has been successfully updated, restart your system and boot an operating system from ROM. Do not boot from a disk device yet. Review the boot messages to see if any issues have occurred.","title":"Upgrading via Flash Utility"},{"location":"UserGuide/#upgrading-via-xmodem-flash-updater","text":"Similar to using the Flash utility, the system ROM can be updated or upgraded through the ROM-based updater utility. This works by reprogramming the flash ROM as the file is being transferred. Using the ROM-based updater has the advantage that secondary storage is not required to hold the new image. In other words, it is not necessary to have a mass storage device available to store the ROM image. From the Boot Loader menu select X (Xmodem Flash Updater) and then U (Begin Update). Then initiate the Xmodem transfer of the .rom file. Since the XModem Flash Updater will be relatively slow, you may wish to use the .upd varient of the ROM. More information can be found in the ROM Applications document.","title":"Upgrading via XModem Flash Updater"},{"location":"UserGuide/#post-upgrade-update","text":"Once you are satisfied that the ROM is working well, you will need to update the system images and RomWBW custom applications on your disk drives. The system images and custom applications are matched to the RomWBW ROM firmware in use. If you attempt to boot a disk or run applications that have not been updated to match the current ROM firmware, you are likely to have odd problems. The simplest way to update your disk media is to just use your modern computer to overwrite the entire media with the latest disk image of your choice. This process is described below in the Disk Images section. If you wish to update existing disk media in your system, you need to perform the following steps. If the disk is bootable, you need to update the system image on the disk using the procedure described in the Operating Systems section of this document. Finally, if you have copies of any of the RomWBW custom applications on your hard disk, you need to update them with the latest copies. The following applications are found on your ROM disk. Use COPY to copy them over any older versions of the app on your disk: ASSIGN.COM SYSCOPY.COM MODE.COM FDU.COM FORMAT.COM XM.COM FLASH.COM FDISK80.COM TALK.COM RTC.COM TIMER.COM FAT.COM For example: B>COPY ASSIGN.COM C: Some RomWBW custom applications are too large to fit on the ROM disk. If you are using any of these you will need to transfer them to your system and then update all copies. These applications are found in the Binary/Apps directory of the distribution and in all of the disk images. TUNE.COM The files normally contained on the standard ROM Disk is based on a 512K ROM. If your system has a smaller size ROM, then not all of these files will be included on your ROM Disk. You will need to copy them to your system from the /Binary/Apps folder of the RomWBW distribution. WARNING : If you run a RomWBW-specific application that is not the appropriate for the version of RomWBW you are running, the application will generate an error message and abort.","title":"Post Upgrade Update"},{"location":"UserGuide/#system-update","text":"As previously described, a RomWBW ROM contains ROM applications as well as a ROM disk image. If you are upgrading your ROM with a new patch level release, you may wish to upgrade just the application portion of the ROM. This is referred to as a System Update. If the system running ROMWBW utilizes the SST39SF040 Flash chip then it is possible to do a System Update in place of a System Upgrade in some cases. A System Update would involve only updating the BIOS, ROM applications and ROM-hosted operating systems. A System Update may be more favorable than a System Upgrade in cases such as: Overwriting of the ROM drive contents is not desired. Temporary disk space is unavailable to hold a full ROM image. To reduce the time taken to transfer and flash a full ROM. Configuration changes are only minor and do not impact disk applications. The RomWBW build process generates a system update file along with the normal ROM image and can be identified by the extension \u201c.upd\u201d. It will be 128Kb in size. In comparison the normal ROM image will have the extension \u201c.rom\u201d and be 512Kb or 1024Kb in size. Transferring and flashing the System Update is accomplished in the same manner as described above in Upgrading via Flash Utility with the required difference being that the flash application needs to be directed to complete a partial flash using the /P command line switch. E>FLASH WRITE ROM.UPD /P","title":"System Update"}]}
\ No newline at end of file