Minor Documentation Updates

Add Sample Hello World Source Code

.gitattributes

@@ -0,0 +1,2 @@
+# Leave all line endings alone!
+* -text

.github/pull_request_template.md

@@ -0,0 +1,13 @@
+<!--
+BEFORE YOU CREATE A PULL REQUEST:
+
+- Please base all pull requests against the master branch
+- Include a clear description of your change
+- Reference related Issue(s) (e.g., "Resolves Issue #123")
+
+Thank you for contributing to RomWBW!  I will review your pull request as soon as possible.
+
+-Wayne
+
+DELETE EVERYTHING IN THIS COMMENT BLOCK AND REPLACE WITH YOUR COMMENTS
+-->

.github/workflows/commit.yml

@@ -0,0 +1,75 @@
+name: Commit Build
+
+on:
+  push:
+    branches: 
+      - '**'
+    tags-ignore:
+      - '**'
+
+jobs:
+  buildLinux:
+
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.1
+
+      - name: Get Commit Ref
+        run: |
+          COMMIT_REF=$(git rev-parse --short $GITHUB_SHA)
+          echo "COMMIT_REF: $COMMIT_REF"
+          echo "COMMIT_REF=$COMMIT_REF" >>$GITHUB_ENV
+
+      - name: Build
+        run: |
+          export TZ='America/Los_Angeles'
+          sudo apt-get install srecord
+          make transpile-c-code
+          make distlog --trace
+          rm -rf .git*
+
+      - name: List Output
+        run: |
+          cd Binary
+          ls -l
+          find -type f -exec md5sum '{}' \;
+
+      - name: Upload Artifact
+        uses: actions/upload-artifact@v4.3.0
+        with:
+          name: RomWBW-${{env.COMMIT_REF}}-Linux
+          path: .
+
+  buildMacOS:
+    runs-on: macOS-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.1
+
+      - name: Get Commit Ref
+        run: |
+          COMMIT_REF=$(git rev-parse --short $GITHUB_SHA)
+          echo "COMMIT_REF: $COMMIT_REF"
+          echo "COMMIT_REF=$COMMIT_REF" >>$GITHUB_ENV
+
+      - name: Build
+        run: |
+          export TZ='America/Los_Angeles'
+          brew install srecord
+          make distlog
+          rm -rf .git*
+
+      - name: List Output
+        run: |
+          cd Binary
+          ls -l
+          find . -type f -exec md5 -r -- '{}' +;
+
+      - name: Upload Artifact
+        uses: actions/upload-artifact@v4.3.0
+        with:
+          name: RomWBW-${{env.COMMIT_REF}}-MacOS
+          path: .

.github/workflows/release.yml

@@ -0,0 +1,127 @@
+name: Release Build
+
+on:
+  push:
+    tags:
+      - '**'
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.1
+
+      - name: Build
+        run: |
+          export TZ='America/Los_Angeles'
+          sudo apt-get install libncurses-dev
+          sudo apt-get install srecord
+          make transpile-c-code
+          make distlog --trace
+          rm -rf .git*
+      
+      - name: Create Package Archive
+        run: |
+          zip -r RomWBW-${{github.ref_name}}-Package.zip .
+
+      - name: Set Title
+        run: |
+          echo "Tag: ${{github.ref_name}}"
+          if grep -q "dev" <<< "${{github.ref_name}}"; then
+            TITLE="RomWBW Development Snapshot"
+          elif grep -q "beta" <<< "${{github.ref_name}}"; then
+            TITLE="RomWBW Beta Release"
+          elif grep -q "pre" <<< "${{github.ref_name}}"; then
+            TITLE="RomWBW Prerelease"
+          elif grep -q "rc" <<< "${{github.ref_name}}"; then
+            TITLE="RomWBW Release Candidate"
+          else
+            TITLE="RomWBW"
+          fi
+          echo "Title: $TITLE"
+          echo "TITLE=$TITLE" >>$GITHUB_ENV
+
+      - name: Attach Package Archive
+        uses: wwarthen/actions/packages/automatic-releases@built-packages
+        with:
+          repo_token: "${{secrets.GITHUB_TOKEN}}"
+          draft: true
+          prerelease: true
+          title: "${{env.TITLE}} ${{github.ref_name}}"
+          files: |
+            RomWBW-${{github.ref_name}}-Package.zip
+
+      - name: Build Docs
+        run: |
+          export TZ='America/Los_Angeles'
+          sudo apt-get install gpp pandoc
+          pip install mkdocs
+          make -C Source/Doc deploy_mkdocs
+          mkdocs build -f Source/Doc/mkdocs.yml
+
+      - name: Deploy Docs
+        uses: peaceiris/actions-gh-pages@v4
+#       if: github.ref == 'refs/heads/master'
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: Source/Doc/site
+      
+#      - name: Upload Package Archive
+#        uses: AButler/upload-release-assets@v2.0.2
+#        with:
+#          repo-token: ${{secrets.github_token}}
+#          files: |
+#            RomWBW-${{env.PKGLBL}}-Package.zip
+
+
+#      - name: Post SnapShot
+#        uses: docker://antonyurchenko/git-release:latest
+#        env:
+#          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+#          RELEASE_NAME_PREFIX: "${{env.TITLE}} "
+#          CHANGELOG_FILE: "none"
+#        with:
+#          args: |
+#            RomWBW-SnapShot-Package.zip
+            
+#      - name: Post SnapShot
+#        uses: cb80/pubrel@latest
+#        with:
+#          replace: true
+#          files: |
+#            RomWBW-SnapShot-Package.zip
+
+#      - name: Post SnapShot
+#        uses: wwarthen/actions/packages/automatic-releases@built-packages
+#        with:
+#          repo_token: "${{ secrets.GITHUB_TOKEN }}"
+#          prerelease: true
+#          title: "RomWBW Development SnapShot ${{env.GITHUB_REF_SLUG}}"
+#          files: |
+#            RomWBW-SnapShot-Package.zip
+
+#      - name: Remove Older Releases
+#        uses: wwarthen/delete-release-action@v1.2
+#        with:
+#          release-drop: true
+#          release-keep-count: 0
+#          release-drop-tag: true
+#          pre-release-drop: false
+#          pre-release-keep-count: 0
+#          pre-release-drop-tag: true
+#          draft-drop: true
+#        env:
+#          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+#      - name: Remove Older Releases
+#        uses: s00d/delete-older-releases@0.2.1
+#        with:
+#          keep_latest: 1
+##          delete_tag_pattern: beta # defaults to ""
+#          delete_type: 'release'
+#          delete_branch: 'main'
+#        env:
+#          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -0,0 +1,204 @@
+# Not sure what patterns to apply
+# So ignoring all generated files explicitly
+
+**/*.[Bb][Ii][Nn]
+**/*.[Cc][Oo][Mm]
+**/*.[Rr][Oo][Mm]
+**/*.com
+**/*.eeprom
+**/*.hex
+**/*.img
+**/*.lib
+**/*.lst
+**/*.o
+**/*.prn
+**/*.rel
+**/*.sym
+**/*.sys
+**/*.tmp
+**/*/font*.asm
+
+Binary/**/*.mym
+Binary/**/*.pt3
+!Binary/CPNET/NetBoot/*/cpnos.sys
+
+Source/**/eeprom
+Source/Apps/Assign.com
+Source/Apps/FDU/FDU.COM
+Source/Apps/Format.com
+Source/Apps/IntTest.com
+Source/Apps/Mode.com
+Source/Apps/OSLdr.com
+Source/Apps/RTC.com
+Source/Apps/SysCopy.com
+Source/Apps/SysGen.com
+Source/Apps/Talk.com
+Source/Apps/Timer.com
+Source/Apps/Tune/Tune.com
+Source/BPBIOS/bpsys.bak
+Source/BPBIOS/bpsys.dat
+Source/BPBIOS/def-ww.lib
+Source/CPM3/bios3.spr
+Source/CPM3/bnkbios3.spr
+Source/CPM3/gencpm.dat
+Source/CPM3/options.lib
+Source/CPM3/zpmbios3.spr
+Source/HBIOS/Blank512KB.dat
+Source/HBIOS/build.inc
+Source/Images/blank144
+Source/Images/blankhd
+Source/Prop/Spin/ParPortProp.list
+Source/Prop/Spin/PropIO.list
+Source/Prop/Spin/PropIO2.list
+Source/Prop/ParPortProp.list
+Source/Prop/PropIO.list
+Source/Prop/PropIO2.list
+Source/ZPM3/bnkbios3.spr
+Source/ZPM3/gencpm.com
+Source/ZPM3/gencpm.com
+Source/ZPM3/gencpm.dat
+
+Tools/Linux
+Tools/Darwin
+
+Tools/unix/bin2asm/bin2asm
+Tools/unix/cpmtools/cpmchattr
+Tools/unix/cpmtools/cpmchmod
+Tools/unix/cpmtools/cpmcp
+Tools/unix/cpmtools/cpmls
+Tools/unix/cpmtools/cpmrm
+Tools/unix/cpmtools/fsck.cpm
+Tools/unix/cpmtools/fsed.cpm
+Tools/unix/cpmtools/mkfs.cpm
+Tools/unix/lzsa/lzsa
+Tools/unix/uz80as/uz80as
+Tools/unix/zx/config.h
+Tools/unix/zx/zx
+
+!Source/ver.lib
+!Source/Apps/FAT/FAT.COM
+!Source/Apps/ZMP/zmpx.com
+!Source/Apps/ZMD/zmdsubs.rel
+!Source/Apps/Test/vdctest/font.asm
+!Source/BPBIOS/bpbuild.com
+!Source/BPBIOS/movp112.com
+!Source/BPBIOS/*.lib
+!Source/BPBIOS/Z34RCP11/cledinst.com
+!Source/BPBIOS/Z34RCP11/cledsave.com
+!Source/CPNET/**
+!Source/Fonts/*
+!Source/Images/**
+!Source/RomDsk/**
+!Source/UBIOS/FSFAT.BIN
+!Source/UBIOS/UNA-BIOS.BIN
+!Source/ZCCP/*.[Cc][Oo][Mm]
+!Source/ZCPR-DJ/*.[Cc][Oo][Mm]
+!Source/ZPM3/*.[Cc][Oo][Mm]
+!Source/ZSDOS/*.[Cc][Oo][Mm]
+!Source/ZRC/*.bin
+!Source/ZRC512/*.bin
+!Source/EZ512/*.bin
+!Source/Z1RCC/*.bin
+!Source/ZZRCC/*.bin
+!Source/FZ80/*.bin
+!Tools/cpm/**
+!Tools/unix/zx/*
+!Tools/zx/*
+
+Source/ZPM3/gencpm.com
+Source/ZPM3/startzpm.com
+Source/ZPM3/zccp.com
+Source/ZPM3/zpmldr.com
+Source/ZPM3/genbnk.dat
+
+Source/ZSDOS/zsdos.err
+
+# Lets explicit list all generate untracked binary files
+Binary/*.upd
+Binary/Apps/bbcbasic.txt
+Binary/Apps/copysl.doc
+Binary/Apps/copysl.doc
+Binary/Apps/fdu.doc
+Binary/Apps/fdu.doc
+Binary/Apps/Tunes/bgm.vgm
+Binary/Apps/Tunes/ending.vgm
+Binary/Apps/Tunes/inchina.vgm
+Binary/Apps/Tunes/shirakaw.vgm
+Binary/Apps/Tunes/startdem.vgm
+Binary/Apps/Tunes/wonder01.vgm
+Binary/Apps/zmconfig.ovr
+Binary/Apps/zminit.ovr
+Binary/Apps/zmp.cfg
+Binary/Apps/zmp.doc
+Binary/Apps/zmp.fon
+Binary/Apps/zmp.hlp
+Binary/Apps/zmterm.ovr
+Binary/Apps/zmxfer.ovr
+Binary/CPM3/bdos3.spr
+Binary/CPM3/bios3.spr
+Binary/CPM3/bnkbdos3.spr
+Binary/CPM3/bnkbios3.spr
+Binary/CPM3/cpm3fix.pat
+Binary/CPM3/genbnk.dat
+Binary/CPM3/gencpm.dat
+Binary/CPM3/genres.dat
+Binary/CPM3/readme.1st
+Binary/CPM3/resbdos3.spr
+Binary/CPNET/cpn12duo.lbr
+Binary/CPNET/cpn12mt.lbr
+Binary/CPNET/cpn12ser.lbr
+Binary/CPNET/cpn3duo.lbr
+Binary/CPNET/cpn3mt.lbr
+Binary/CPNET/cpn3ser.lbr
+Binary/hd1k_prefix.dat
+Binary/ZPM3/bnkbdos3.spr
+Binary/ZPM3/bnkbios3.spr
+Binary/ZPM3/gencpm.dat
+Binary/ZPM3/resbdos3.spr
+Binary/ZPM3/zinstal.zpm
+Source/BPBIOS/def-ww.lib
+Source/CPNET/cpn12duo.lbr
+Source/CPNET/cpn12mt.lbr
+Source/CPNET/cpn12ser.lbr
+Source/CPNET/cpn3duo.lbr
+Source/CPNET/cpn3mt.lbr
+Source/CPNET/cpn3ser.lbr
+Source/Fonts/font8x11c.asm
+Source/Fonts/font8x11c.bin
+Source/Fonts/font8x11u.asm
+Source/Fonts/font8x16c.asm
+Source/Fonts/font8x16c.bin
+Source/Fonts/font8x16u.asm
+Source/Fonts/font8x8c.asm
+Source/Fonts/font8x8c.bin
+Source/Fonts/font8x8u.asm
+Source/Fonts/font6x8c.asm
+Source/Fonts/font6x8c.bin
+Source/Fonts/font6x8u.asm
+Source/Fonts/fontcgac.asm
+Source/Fonts/fontcgac.bin
+Source/Fonts/fontcgau.asm
+Source/Fonts/fontvgarcc.asm
+Source/Fonts/fontvgarcc.bin
+Source/Fonts/fontvgarcu.asm
+Source/HBIOS/*.upd
+Source/HBIOS/build_env.cmd
+Source/HBIOS/build_env.cmd
+Source/HBIOS/hbios_env.sh
+Source/HBIOS/hbios_env.sh
+Source/HBIOS/netboot.mod
+Source/Images/*.cat
+Source/Images/*.img
+Source/Images/blank144
+Source/Images/blankhd1k
+Source/Images/blankhd512
+Source/RomDsk/*.cat
+Source/RomDsk/*.dat
+Source/ZCPR-DJ/zcprdemo.com
+Source/ZPM3/autotog.com
+Source/ZPM3/clrhist.com
+Source/ZPM3/cpmldr.com
+Source/ZPM3/setz3.com
+Tools/unix/OpenSpin/build/
+Tools/unix/zxcc/config.h
+Tools/unix/zxcc/zxcc

.vscode/settings.json

@@ -0,0 +1,38 @@
+{
+  "z80-macroasm.format.enabled": true,
+  "z80-macroasm.format.baseIndent": 1,
+  "z80-macroasm.format.whitespaceAfterInstruction": "tab",
+  "z80-macroasm.format.uppercaseKeywords": true,
+  "z80-macroasm.format.spaceAfterArgument": true,
+  "z80-macroasm.format.hexaNumberStyle": "motorola",
+  "z80-macroasm.format.hexaNumberCase": true,
+  "files.trimTrailingWhitespace": false,
+  "files.eol": "\r\n",
+  "files.associations": {
+    "*.inc": "z80-macroasm",
+    "*.asm": "z80-macroasm",
+    "*.180": "z80-macroasm",
+    "*.asm.m4": "z80-macroasm",
+    "*.inc.m4": "z80-macroasm",
+    "*.mac": "z80-macroasm",
+    "*.asmpp": "z80-macroasm",
+    "*.zdsproj": "xml",
+    "*.Z80": "z80-macroasm",
+    "ch376.h": "c",
+    "protocol.h": "c",
+    "usb_state.h": "c",
+    "functional": "c",
+    "class_scsi.h": "c",
+    "z80.h": "c",
+    "dev_transfers.h": "c",
+    "usb-base-drv.h": "c",
+    "critical-section.h": "c",
+    "enumerate.h": "c",
+    "ch376inc.h": "c",
+    "enumerate_storage.h": "c",
+    "work-area.h": "c",
+    "hbios-driver-storage.h": "c",
+    "class_hid_keyboard.h": "c",
+    "print.h": "c"
+  }
+}

Binary/Apps/Clean.cmd

@@ -0,0 +1,16 @@
+@echo off
+setlocal
+
+if exist *.com del *.com
+if exist *.ovr del *.ovr
+if exist *.doc del *.doc
+if exist *.hlp del *.hlp
+if exist Tunes\*.pt? del Tunes\*.pt?
+if exist Tunes\*.mym del Tunes\*.mym
+if exist Tunes\*.vgm del Tunes\*.vgm
+if exist bbcbasic.txt del bbcbasic.txt
+if exist *.cfg del *.cfg
+if exist *.fon del *.fon
+
+pushd Test && call Clean || exit /b 1 & popd
+pushd ZDE && call Clean || exit /b 1 & popd

Binary/Apps/Makefile

@@ -0,0 +1,11 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.com)
+SUBDIRS = Test ZDE
+
+include $(TOOLS)/Makefile.inc
+
+all::
+	mkdir -p Tunes
+
+clean::
+	@rm -f *.bin *.com *.img *.rom *.pdf *.log *.eeprom *.ovr *.hlp *.doc *.COM *.BIN Tunes/*.mym Tunes/*.pt? Tunes/*.vgm bbcbasic.txt *.cfg *.fon

Binary/Apps/ReadMe.txt

@@ -0,0 +1,21 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the executable application files that
+are specific to RomWBW.  The source for these applications is found
+in the Source\Apps directory of the distribution.
+
+The Tunes subdirectory contains some sample ProTracker and MYM sound
+files that can be played by the TUNE application.
+
+All of these files are already included in the pre-built boot disk
+images.  They are also included on the ROM disk except for
+FAT.COM, TUNE.COM, and the sample tune files in the Tunes directory.
+
+If you upgrade your ROM to a new version, you should also copy
+these files over to any hard disk images you are using.

Binary/Apps/Test/Clean.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+
+if exist *.com del *.com

Binary/Apps/Test/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.com)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.com

Binary/Apps/Test/ReadMe.txt

@@ -0,0 +1,16 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains various hardware test application files that
+are specific to RomWBW.  The source for these applications is found
+in the Source\Apps\Test directory of the distribution.
+
+These files are included on the pre-built disk images in user area 2.
+
+N.B., these files may be specific to certain hardware.  They should
+be used as directred by the instructions for your specific hardware.

Binary/Apps/Test/inttest.doc

@@ -0,0 +1,44 @@
+INTTEST
+=======
+
+RomWBW includes an API allowing applications to "hook" interrupts.
+The `INTTEST` utility allows you to test this functionality.
+
+
+** Syntax **
+
+`INTTEST`
+
+
+** Usage **
+
+`INTTEST` is an interactive application.  At startup, it will display
+a list of the interrupt vector slots in your system along with the
+current vector address for each of them.
+
+It then prompts you to enter the slot number (in hex) of a vector to
+hook.  After entering this, the application will watch the hooked
+vector and countdown from 0xFF to 0x00 as interrupts are noted.
+
+When the counter reaches 0x00, the interrupt is unhooked and the
+application terminates.  The application can also be terminated by
+pressing <esc>.
+
+
+** Notes **
+
+If your system is running without interrupts active, the application
+will terminate immediately.
+
+All slots have vectors even if the corresponding interrupt is not
+doing anything.  In this case, the vector is pointing to the "bad
+interrupt" handler.
+
+If you hook a vector that is not receiving any interrupts, the
+down-counter will not do anything.
+
+
+** Etymology* *
+
+The `INTTEST` command is an original product and the source code is
+provided in the RomWBW distribution.

Binary/Apps/Tunes/ReadMe.txt

@@ -0,0 +1,10 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains some sample ProTracker and MYM sound
+files that can be played by the TUNE or VGMPLAY application.

Binary/Apps/ZDE/Clean.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+
+if exist *.com del *.com

Binary/Apps/ZDE/Makefile

@@ -0,0 +1,6 @@
+TOOLS = ../../../Tools
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.com

Binary/Apps/ZDE/ReadMe.txt

@@ -0,0 +1,10 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the ZDE executable binaries.  They are
+in their original, unconfigured state.

Binary/CPM22/Clean.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+
+if exist *.sys del *.sys

Binary/CPM22/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.spr)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.sys

Binary/CPM22/ReadMe.txt

@@ -0,0 +1,23 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the CP/M 2.2 system files for the RomWBW CP/M 2.2
+adaptation.  All of these files are already included on the CP/M
+boot disk images.  However if you are creating a CP/M boot disk
+manually, you should copy all of these files to the boot disk.
+
+Note: Two file have been provided one for RomWBW HBIOS, and one for UNA
+BIOS. One of these files must be installed on the system boot track.
+This is usually achieved by the SYSCOPY utility e.g.
+
+SYSCOPY a:=cpm_wbw.sys
+
+These files should also be copied to any CP/M 2.2 boot disks on your
+system when you upgrade your ROM firmware.  Some of these files
+*must* match the version of the RomWBW firmware you are using for
+proper operation of your system.

Binary/CPM3/Clean.cmd

@@ -0,0 +1,11 @@
+@echo off
+setlocal
+
+if exist *.spr del *.spr
+if exist *.com del *.com
+if exist *.sys del *.sys
+if exist *.pat del *.pat
+if exist *.dat del *.dat
+if exist *.1st del *.1st
+if exist *.spr del *.spr
+if exist *.pat del *.pat

Binary/CPM3/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.spr)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.spr *.com *.sys *.dat cpm3fix.pat readme.1st

Binary/CPM3/ReadMe.txt

@@ -0,0 +1,17 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the CP/M 3 system files for the RomWBW CP/M 3
+adaptation.  All of these files are already included on the CP/M 3
+boot disk images.  However if you are creating a CP/M 3 boot disk
+manually, you should copy all of these files to the boot disk.
+
+These files should also be copied to any CP/M 3 boot disks on your
+system when you upgrade your ROM firmware.  Some of these files
+*must* match the version of the RomWBW firmware you are using for
+proper operation of your system.

Binary/CPNET/Clean.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+
+if exist *.lbr del *.lbr

Binary/CPNET/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.lbr)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.lbr

Binary/CPNET/ReadMe.txt

@@ -0,0 +1,38 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the CP/NET client packages.  Please refer to 
+the RomWBW User Guide for instructions on installing these packages.  
+Either the MT011 RCBus module or the Duodyne Disk I/O board is required.
+
+All of these files come from Douglas Miller.  Please refer to
+https://github.com/durgadas311/cpnet-z80 for more information, complete
+documentation and the latest source code.  Refer to the RomWBW
+User Guide for basic installation and usage instructions under RomWBW.
+
+| 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   |
+
+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.  Refer to the RomWBW User Guide for more information.
+
+The libraries include enhanced help files appropriate for the version 
+of CP/NET.  Rename the desired topic collection to HELP.HLP on the
+target system.
+
+CPM2NET.HLP	CP/M 2.2 basic system with CP/NET 1.2
+CPNET12.HLP	CP/NET 1.2 help only
+CPM3NET.HLP	CP/M 3 basic system with CP/NET 3
+CPNET3.HLP	CP/NET 3 help only
+
+-- WBW 7:14 AM 2/11/2024

Binary/Clean.cmd

@@ -0,0 +1,20 @@
+@echo off
+setlocal
+
+if exist *.bin del *.bin
+if exist *.dat del *.dat
+if exist *.com del *.com
+if exist *.img del *.img
+if exist *.rom del *.rom
+if exist *.hex del *.hex
+if exist *.upd del *.upd
+if exist *.pdf del *.pdf
+if exist *.eeprom del *.eeprom
+
+pushd Apps && call Clean || exit /b 1 & popd
+pushd CPM22 && call Clean || exit /b 1 & popd
+pushd CPM3 && call Clean || exit /b 1 & popd
+pushd QPM && call Clean || exit /b 1 & popd
+pushd ZSDOS && call Clean || exit /b 1 & popd
+pushd ZPM3 && call Clean || exit /b 1 & popd
+pushd CPNET && call Clean || exit /b 1 & popd

Binary/GPL-3.0.txt

@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program 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.
+
+    This program 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 this program.  If not, see <http://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<http://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<http://www.gnu.org/philosophy/why-not-lgpl.html>.

Binary/Makefile

@@ -0,0 +1,8 @@
+TOOLS = ../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.img *.rom *.com *.eeprom)
+SUBDIRS = Apps CPM22 CPM3 QPM ZSDOS ZPM3 CPNET
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.bin *.com *.img *.rom *.upd *.hex *.pdf *.log *.eeprom *.dat

Binary/QPM/Clean.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+
+if exist *.sys del *.sys

Binary/QPM/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.spr)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.sys *.bin

Binary/QPM/ReadMe.txt

@@ -0,0 +1,21 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the QPM 2.7 system files for the RomWBW QPM 2.7
+adaptation.  All of these files are already included on the QPM
+boot disk images.  However if you are creating a QPM boot disk
+manually, you should copy all of these files to the boot disk.
+
+Note: Two file have been provided one for RomWBW HBIOS, and one for UNA
+BIOS. One of these files must be installed on the system boot track.
+Refer to the QPM Documentation for installing QPM
+
+These files should also be copied to any QPM boot disks on your
+system when you upgrade your ROM firmware.  Some of these files
+*must* match the version of the RomWBW firmware you are using for
+proper operation of your system.

Binary/ReadMe.txt

@@ -0,0 +1,194 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory ("Binary") is part of the RomWBW System Software
+distribution archive.  It contains the completed binary outputs of
+the build process.  As described below, these files are used to
+assemble a working RetroBrew Computers system.
+
+The files in this directory are created by the build process that is
+documented in the ReadMe.txt file in the Source directory.  When
+released the directory is populated with the default output files.
+However, the output of custom builds will be placed in this directory
+as well.
+
+If you only see a few files in this directory, then you downloaded
+just the source from GitHub.  To retrieve the full release download
+package, go to https://github.com/wwarthen/RomWBW.  On this page,
+look for the text "XX releases" where XX is a number. Click on this
+text to go to the releases page.  On this page, you will see the
+latest releases listed.  For each release, you will see a package
+file called something like "RomWBW-2.9.0-Package.zip".  Click on the
+package file for the release you want to download.
+
+ROM Firmware Images (<plt>_<cfg>.rom)
+-------------------------------------
+
+The files with a ".rom" extension are binary images ready to program
+into an appropriate PROM.  These files are named with the format
+<plt>_<cfg>.rom. <plt> refers to the primary platform such as Zeta,
+N8, Mark IV, etc.  <cfg> refers to the specific configuration.  In
+general, there will be a standard configuration ("std") for each
+platform.  So, for example, the file called MK4_std.rom is a ROM
+image for the Mark IV with the standard configuration. If a custom
+configuration called "custom" is created and built, a new file called
+MK4_custom.rom will be added to this directory.
+
+Documentation of the pre-built ROM Images is contained in
+"RomWBW User Guide.pdf" in the Doc directory.
+
+ROM Firmware Update Images (<plt>_<cfg>.upd)
+-------------------------------------
+
+The files with a ".upd" extension are binary images identical to the
+.rom files, but they only have the first 128K bytes.  The first 128K
+is the system image without the ROM disk contents.  These files can be
+used to update the system image without modifying the ROM disk
+contents.  Refer to the RomWBW User Guide for more information.
+
+ROM Executable Images (<plt>_<cfg>.com)
+---------------------------------------
+
+When a ROM image (".rom") is created, an executable version of the
+ROM is also created.  These files have the same naming convention as
+the ROM Image files, but have the extension ".com".  These files can
+be copied to a working system and run like a normal CP/M application.
+
+When run on the target system, they install in RAM just like they had
+been loaded from  ROM.  This allows a new ROM build to be tested
+without reprogramming the actual ROM.
+
+WARNING: In a few cases the .com file is too big to load.  If you get
+a message like "Full" or "BAD LOAD" when trying to load one of the
+.com files, it is too big.  In these cases, you will not be able to
+test the ROM prior to programming it.
+
+VDU ROM Image (vdu.rom)
+-----------------------
+
+The VDU video board requires a dedicated onboard ROM containing the
+font data.  The "vdu.rom" file contains the binary data to program
+onto that chip.
+
+Disk Images (fd_*.img, hd_*.img)
+--------------------------------
+
+RomWBW includes a mechanism for generating floppy disk and hard disk
+binary images that are ready to copy directly to a floppy, hard disk,
+CF Card, or SD Card which will then be ready for use in any
+RomWBW-based system.
+
+Essentially, these files contain prepared floppy and hard disk images
+with a large set of programs and related files.  By copying the
+contents of these files to appropriate media as described below, you
+can quickly create ready-to-use media.  Win32DiskImager or
+RawWriteWin can be used to copy images directly to media.  These
+programs are included in the RomWBW Tools directory.
+
+The fd_*.img files are floppy disk images.  They are sized for 1.44MB
+floppy media and can be copied to actual floppy disks using
+RawWriteWin (as long as you have access to a floppy drive on your
+Windows computer).  The resulting floppy disks will be usable on any
+RomWBW-based system with floppy drive(s).
+
+Likewise, the hd512_*.img and hd1k_*.img files are hard disk images.
+Each file is intended to be copied to the start of any type of hard
+disk media (typically a CF Card or SD Card). The resulting media will
+be usable on any RomWBW-based system that accepts the corresponding
+media type.
+
+NOTE: The hd512_*.img files are equivalent to the hd_*.img
+files in previous distributions.  The hd1k_*.img files
+contained a revised file system format that increases the
+maximum number of CP/M directory entries from 512 to 1024.
+Refer to the ReadMe.txt in the Source/Images directory
+for details.
+
+Documentation of the pre-built disk images is contained in the
+"RomWBW User Guide" found in the Doc directory.  The contents of
+the disk images is contained in the "RomWBW Disk Catalog", but it
+is significantly out-of-date.
+
+The contents of the floppy/hard disk images are created by
+the BuildImages.cmd script in the Source directory.  Additional
+information on how to generate custom disk images is found in the
+Source\Images ReadMe.txt file.
+
+Disk Images (hd512_combo.img, hd1k_combo.img, *_std_hd1k_combo.img)
+-------------------------------------------------------------------
+
+The hd512_combo.img and hd1k_combo.img file are the primary combo
+disk image files suitable for most platforms.
+
+The *_std_hd1k_combo.img files are platform specific combo files
+typically used in romless platforms, they also contain RomWBW binary code
+that is loaded at boot time into RAM
+
+Disk Images (hd1k_prefix.dat, *_std_hd1k_prefix.dat)
+----------------------------------------------------
+
+The hd1k_prefix.dat file is part of the combo disk images and is
+applied to hd1k image files as a prefix, it contains the standard
+partion table.
+
+The *_std_hd1k_prefix.dat files are platform specific prefixes
+typically used in romless platforms, they also contain RomWBW binary code
+that is loaded at boot time into RAM
+
+Disk Images (psys.img)
+----------------------
+
+The psys.img file contains a full implementation of the UCSD p-System
+for the Z80 running under RomWBW.  This image file must be placed on
+disk media by itself (not appended or concatenated with hd*.img files.
+Refer to the Source/pSys/ReadMe.txt file for more information on the
+p-System implementation.
+
+Propeller ROM Images (*.eeprom)
+-------------------------------
+
+The files with and extension of ".eeprom" contain the binary images
+to be programmed into the Propeller-based boards.  The list below
+indicates which file targets each of the Propeller board variants:
+
+	ParPortProp	ParPortProp.eeprom
+	PropIO V1	PropIO.eeprom
+	PropIO V2	PropIO2.eeprom
+
+Refer to the board documentation of the boards for more information
+on how to program the EEPROMs on these boards.
+
+SUB DIRECTORIES
+===============
+
+Apps Directory
+--------------
+
+The Apps subdirectory contains the executable application files that
+are specific to RomWBW.  The source for these applications is found
+in the Source\Apps directory of the distribution.
+
+CPNET Directory
+---------------
+
+This directory contains the CP/NET client packages.  Please refer to
+the RomWBW User Guide for instructions on installing these packages,
+or see the Readme.txt file in this sub-directory
+
+CPM22 CPM3 ZSDOS ZPM3 QPM Directories
+-------------------------------------
+
+These directories contains the system files for the RomWBW adaptations
+for each operating system.  All of these files are already included on
+the boot disk images.  However if you are creating a o/s boot disk
+manually, you will need copy all of these files to the boot disk.
+
+These files should also be copied to any boot disks on your
+system when you upgrade your ROM firmware.  Some of these files
+*must* match the version of the RomWBW firmware you are using for
+proper operation of your system.

Binary/ZPM3/Clean.cmd

@@ -0,0 +1,10 @@
+@echo off
+setlocal
+
+if exist *.spr del *.spr
+if exist *.com del *.com
+if exist *.sys del *.sys
+if exist *.pat del *.pat
+if exist *.dat del *.dat
+if exist *.zpm del *.zpm
+if exist *.spr del *.spr

Binary/ZPM3/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.spr)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.spr *.com *.sys *.dat *.zpm

Binary/ZPM3/ReadMe.txt

@@ -0,0 +1,17 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the ZPM3 system files for the RomWBW ZPM3
+adaptation.  All of these files are already included on the ZPM3
+boot disk images.  However if you are creating a CP/M 3 boot disk
+manually, you should copy all of these files to the boot disk.
+
+These files should also be copied to any ZPM3 boot disks on your
+system when you upgrade your ROM firmware.  Some of these files
+*must* match the version of the RomWBW firmware you are using for
+proper operation of your system.

Binary/ZSDOS/Clean.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+
+if exist *.sys del *.sys

Binary/ZSDOS/Makefile

@@ -0,0 +1,7 @@
+TOOLS = ../../Tools
+MOREDIFF := $(shell $(TOOLS)/unix/casefn.sh *.spr)
+
+include $(TOOLS)/Makefile.inc
+
+clean::
+	@rm -f *.sys

Binary/ZSDOS/ReadMe.txt

@@ -0,0 +1,23 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory contains the ZSDOS system files for the RomWBW ZSDOS
+adaptation.  All of these files are already included on the ZSDOS
+boot disk images.  However if you are creating a ZSDOS boot disk
+manually, you should copy all of these files to the boot disk.
+
+Note: Two file have been provided one for RomWBW HBIOS, and one for UNA
+BIOS. One of these files must be installed on the system boot track.
+This is usually achieved by the SYSCOPY utility e.g.
+
+SYSCOPY a:=zsys_wbw.sys
+
+These files should also be copied to any ZSDOS boot disks on your
+system when you upgrade your ROM firmware.  Some of these files
+*must* match the version of the RomWBW firmware you are using for
+proper operation of your system.

Build.cmd

@@ -1,4 +1,6 @@
 @echo off
 setlocal
-cd Source
-call Build %*
+
+pushd Source && call Build %* || exit /b & popd
+
+if "%*" == "" pause

BuildCommon.cmd

@@ -1,4 +0,0 @@
-@echo off
-setlocal
-cd Source
-call BuildCommon %*

CODE_OF_CONDUCT.md

@@ -0,0 +1,128 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+wwarthen@gmail.com.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.

CONTRIBUTING.md

@@ -0,0 +1,42 @@
+# Contributing to RomWBW
+
+> **WARNING**: The `dev` branch of RomWBW has been deprecated as of v3.4.  All Pull Requests should now target the `master` branch.
+
+Contributions of all kinds to RomWBW are welcomed and greatly appreciated.
+
+- Reporting bug(s) and suggesting new feature(s)
+- Discussing the current state of the code
+- Submitting a fixes and enhancements
+
+## RomWBW GitHub Repository
+
+The [RomWBW GitHub Repository](https://github.com/wwarthen/RomWBW) is the primary location for developing, supporting, and distributing RomWBW.  Although input is gladly accepted from almost any channel, the GitHub Repository is preferred.
+
+- Use **Issues** to report bugs, request enhancements, or ask usage questions.
+- Use **Discussions** to interact with others
+- Use **Pull Requests** to submit content (code, documentation, etc.)
+
+## Submitting Content
+
+This RomWBW Project uses the standard [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow).  Submission of content changes (including code) are ideally done via Pull Requests.
+
+- Submitters are advised to contact [Wayne Warthen](mailto:wwarthen@gmail.com) or start a GitHub Discussion prior to starting any significant work.  This is simply to ensure that submissions are consistent
+  with the overall goals and intentions of RomWBW.
+- All submissions should be based on the `master` branch.  To create your submission, fork the RomWBW repository and create your branch from `master`.  Make (and test) your changes in your personal fork.
+- Please update relevant documentation and the `ChangeLog` found in the `Doc` folder.
+- You are encouraged to comment your submissions to ensure your work is properly attributed.
+- When ready, submit a Pull Request to merge your forked branch into the RomWBW master branch.
+
+## Coding Style
+
+Due to the nature of the project, you will find a variety of coding styles.  When making changes to existing code, please try to be consistent with the existing coding style.  You may not like the current style, but no one likes mixed styles
+in one file/module.
+
+Be careful with white space.  RomWBW is primarily assembly langauge code.  The use of tab stops at every 8 characters is pretty standard for assembler.  If you use something else, then your code will look odd when viewed by others.
+
+In most cases, the use of `<cr><lf>` line endings is preferred.  This is standard for the operating systems of the era that RomWBW provides.  Also note that CP/M text files should end with a ctrl-Z (0x1A).  This is not magically added by the
+tools that generate the disk images.
+
+## License
+
+RomWBW is licensed under GPLv3.  When you submit code changes, your submissions are understood to be under the same [GPLv3 License](https://www.gnu.org/licenses/gpl-3.0.html) that covers the project.

Clean.cmd

@@ -1,9 +1,5 @@
 @echo off
 setlocal
 
-pushd Source && call Clean && popd
-
-if exist *.img del *.img /Q
-if exist debug.log del debug.log
-
-if exist Output\*.* del Output\*.* /Q
+pushd Binary && call Clean || exit /b 1 & popd
+pushd Source && call Clean || exit /b 1 & popd

Doc/Build.txt

@@ -1,340 +0,0 @@
-Building a Custom ROM
----------------------
-
-At present, the build environment assumes you are running
-a current version of Microsoft Windows (either 32-bit or
-64-bit).
-
-If you are using Linux, David Giles has contributed a Linux
-makefile that should work for you.  Please read the
-LinuxBuild.txt file for more information.
-
-All required tools are included in the distribution.  You
-should not need anything other than what comes as part of
-Windows or as part of the distribution.
-
-In summary, the process involves the 4 steps below:
-
-  1) Create/update configuration file
-
-  2) Update/Add/Delete any files you want incorporated in
-     the ROM Disk
-
-  3) Run the build script (or makefile if you prefer) and
-     confirm there are no errors.
-
-  4) Burn the resultant ROM image and try it.
-
-The process is really very simple.  In fact, you can
-essentially skip steps 1 & 2 if you want to try simply
-building one of the existing configurations.
-
-Each of the 4 steps above is described in more detail
-below.
-
-1. Create/Update Configuration File
------------------------------------
-
-The settings for a build are primarily controled by
-a configuration file that is included in the build
-process.  In order to customize your settings, you
-need to modify an existing configuration file or
-create your own.
-
-If you look in the Source directory, you will see
-a series of files named config_xxxx_yyyy.asm.  Each of
-them corresponds to one of the standard configurations
-listed in the ROMList.txt file.
-
-You have two choices.  You can simply modify the existing
-configuration file that is closest to your situation, or
-you can copy it to a new config_xxxx_yyyy.asm file and modify
-that.  I recommend that you copy one to your own name so
-that you will always have the unmodified standard configuration
-files left in place.  So, for example, you could just
-copy config_ZETA_std.asm to config_ZETA_wayne.asm.  You MUST
-name your config file as config_xxxx_yyyy.asm.  The xxxx's
-must match your platform (N8VEM, ZETA, N8, S2I, or S100).
-The yyyy's can be whatever you want.
-
-The config files are simply text files with various
-settings.  Open your target config file with your
-favorite text editor and modify the settings as desired.
-
-Unfortunately, I have not yet documented each of the
-settings in detail; that will be a separate document
-provided in the future.  However, there are comments
-in the config file that will probably be sufficient
-for the most part.
-
-2. Update/Add/Delete ROM Disk Files
------------------------------------
-
-The files that are included on the ROM Disk of your
-ROM are copied from a set of directories during the
-build process.  This allows you to have complete
-flexibility over the files you want included in your
-ROM.
-
-If you look at the RomDsk directory, you will see
-a variety of subdirectories.  These subdirectories
-contain the files that will be included in the
-ROM disk.  The build process will determine
-which subdirectories to include files from based
-on the following rules:
-
-First, all files from either std_512 or std_1024 will
-be incuded depending on on the size of the ROM you
-are building.  If you are building a 512KB ROM, then
-all the files from std_512KB will be included.  If you
-are building a 1MB ROM, then all the files from std_1024KB
-will be included.  Essentialy, the files in std_1204KB are
-a superset of the ones in std_512KB because there is more
-space available for the ROM drive.
-
-Second, all files from the directory that corresponds to
-your configuration file will be included.  If you build
-the "ZETA_std" configuration, all files in cfg_ZETA_std will
-be added.  Note that these files will be in addition
-to the files from the std_XXXKB directory.
-
-If you created your own config file (like config_ZETA_wayne.asm
-described above), you MUST create a subdirectory within
-the RomDsk directory and populate it with the files
-you want added.  Normally, you would include the
-files from the original standard config.  So, if
-you created config_ZETA_wayne.asm from config_ZETA_std.asm,
-then you would create a subdirectory in RomDsk called
-cfg_ZETA_wayne and copy all the files from cfg_ZETA_std to
-cfg_ZETA_wayne.
-
-3. Run the Build Process
-------------------------
-
-NOTE: The process described here is the more commonly
-used build script.  If you wish to use a makefile
-instead, refer to the comments in the makefile in
-the Source directory as an alternative to the
-process described here.
-
-The build involves running commands at the command
-prompt.  From a Command Prompt window, you will need
-to change to the high level directory for the build.
-Normally, you would be changing to the RomWBW directory
-unless you renamed it.
-
-First, you will need to build the components that are
-common to all configurations.  These components do not
-require any configuration.  To build these, use the
-following commands and ensure that they complete
-without error:
-
-	BuildZCPR-DJ
-	BuildApps2
-
-To run the main build and be prompted for required information,
-just enter "Build".  You will be prompted for the information
-described below and the build should run.  If an error is
-encountered, the build should stop and display an error
-in red text.
-
-If you immediately receive the error "the execution of 
-scripts is disabled on this system", then you will need to 
-change the PowerShell Execution-Polcy to "RemoteSigned".
-To do this, you need to right-click on FixPowerShell.cmd and
-choose "Run as Administrator" to make the change.  If is
-critical that you right-click and use "Run as Administrator"
-or the change will not work (you will get an error
-indicating "Access to the registry denied" if you fail to
-use "Run as Administrator".
-
-The build script will prompt you for the following information
-which you will need to provide (don't worry, it is simple):
-
-Platform:
-
-Respond with the name of the platform that you are targeting.
-It must be one of N8VEM, ZETA, N8, S2I, or S100.
-
-Configuration:
-
-Respond with the name of the configuration you wish to build.
-A list of all available configurations is displayed for your
-convenience.  For example, if you are building the provided
-ZETA_std configuration, just enter "std".  If you have created a
-custom configuration as described above, you would enter
-"wayne".
-
-ROM Size [512|1024]:
-
-Respond with either "512" for a 512KB ROM build or "1024" for a
-1MB ROM build.  Only the two choices are possible at this time.
-It is important that you choose a ROM size that is no larger than
-the szie of the ROM you will ultimately be burning.  This is 
-dependant on your hardware.
-
-At this point, the build should run and you will see output related
-to the assembler runs and some utility invocations.  Just review
-the output for any obvioius errors.  Normally, all errors will
-cause the build to stop immediately and display an error message
-in red.
-
-You will see some lines in the output indicating the amount of
-space variouis components have taken.  You should check these
-to make sure you do not see any negative numbers which would
-indicate that you have included too many features/drivers for
-the available memory space.  Here are examples of the lines
-showing the space used:
-
-	DATA space remaining: 39 bytes.
-	BOOT LOADER space remaining: 3503 bytes.
-	CBIOS space remaining: 161 bytes.
-	DBGMON space remaining: 860 bytes.
-	ROMX space remaining: 8191 bytes.
-	BOOT LOADER space remaining: 3503 bytes.
-
-4. Deploy the ROM
------------------
-
-If you look in the Output directory.  You should find the following files:
-
-     <config>.rom - binary ROM image to burn to EEPROM
-     <config>.sys - system image that can be written to the start of a
-                    disk to enable boot from disk functionality
-     <config>.com - executable version of the system image that can be
-                    copied via xmodem to a running system to test
-                    the build.
-
-The actual ROM image is the file ending in .rom.  It should be exactly
-512KB or 1MB depending on the ROM size you chose.  Simply burn the .rom
-image to your ROM and install it in your hardware.
-
-Specifying Build Options on Command Line
-----------------------------------------
-
-If you don't want to be prompted for the options to the "Build"
-command, you can specify the options right on the command line.
-
-For example:
-
-	Build ZETA std 512
-
-In this case, you will not be prompted.  This is useful if you
-wish to automate your build process.
-
-Example Build Run
------------------
-
-C:\Users\WWarthen\Projects\N8VEM\Build\RomWBW>Build.cmd
-Platform [N8VEM|ZETA|N8|S2I|S100]: ZETA
-Configurations available:
- > ppp
- > std
-Configuration: std
-ROM Size [512|1024]: 512
-
-Building ZETA_std: 512KB ROM configuration std for Z80...
-
-tasm -t80 -g3  ccpb03.asm cp.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  bdosb01.asm dos.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  syscfg.asm syscfg.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3 -dBLD_SYS=SYS_CPM cbios.asm cbios.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-INFOLIST occupies 18 bytes.
-UTIL occupies 484 bytes.
-FD_DATA occupies 340 bytes.
-PPIDE_DATA occupies 1116 bytes.
-CBIOS space remaining: 2092 bytes.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  dbgmon.asm dbgmon.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-DBGMON space remaining: 795 bytes.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  prefix.asm prefix.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  bootrom.asm bootrom.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  bootapp.asm bootapp.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  loader.asm loader.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-LOADER space remaining: 1205 bytes.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  pgzero.asm pgzero.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  hbios.asm hbios.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-UART occupies 146 bytes.
-FD occupies 2071 bytes.
-PPIDE occupies 809 bytes.
-HBIOS space remaining: 24428 bytes.
-STACK space remaining: 145 bytes.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  hbfill.asm hbfill.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-Configuration: ZETA Z80 SBC, FLOPPY (AUTOSIZE), PPIDE (STD)
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-tasm -t80 -g3  romfill.asm romfill.bin
-TASM Z80 Assembler.       Version 3.2 September, 2001.
- Copyright (C) 2001 Squak Valley Software
-tasm: pass 1 complete.
-tasm: pass 2 complete.
-tasm: Number of errors = 0
-Building ZETA_std output files...
-Building 512KB ZETA_std ROM disk data file...
-
-C:\Users\WWarthen\Projects\N8VEM\Build\RomWBW>

Doc/CPM/BPBIOS/BPBIOS_1_Introduction.md

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

Doc/CPM/BPBIOS/BPBIOS_2_Features.md

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

Doc/CPM/BPBIOS/BPBIOS_3_Tailoring.md

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

Doc/CPM/BPBIOS/BPBIOS_4_Installation.md

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

Doc/CPM/BPBIOS/BPBIOS_7_ZSDOS2.md

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

Doc/CPM/BPBIOS/BPBIOS_8_ZCPR4.md

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

Doc/CPM/BPBIOS/BPBIOS_9_Glossary.md

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

Doc/CPM/ReadMe.txt

@@ -0,0 +1,78 @@
+***********************************************************************
+***                                                                 ***
+***                          R o m W B W                            ***
+***                                                                 ***
+***                    Z80/Z180 System Software                     ***
+***                                                                 ***
+***********************************************************************
+
+This directory ("Doc/CPM") is part of the RomWBW System Software
+distribution archive.  It contains documentation for the CP/M and
+CP/M work-alike operating system components of the system.
+
+
+CPM Manual ("CPM Manual.pdf")
+-----------------------------
+
+The original DRI CP/M 2.x Operating System Manual.  This should be
+considered the primary reference for system operation.  The section
+on CP/M 2 Alteration can be ignored since this work has already been
+completed as part of the RomWBW distribution.
+
+
+CPM3 Command Summary ("CPM3 Command Summary.pdf")
+CPM3 Programmer's Guide ("CPM3 Programmers Guide.pdf")
+CPM3 System Guide ("CPM3 System Guide.pdf")
+CPM3 User's Guide ("CPM3 Users Guide.pdf")
+------------------------------------------------------
+
+The original DRI CP/M 3.0 Operating System Documentation Set.  This
+should be considered the primary reference for CP/M 3 system operation.
+
+
+NZCOM, Z3PLUS, and replace ZCPR3.3 Documentation
+------------------------------------------------
+
+NZCOM operating system operation manual. ("NZCOM Users Manual.pdf")
+Z3PLUS operating system operation manual.  ("Z3PLUS Users Manual.pdf")
+Z-System User Guide ("Z-System User Guide.pdf")
+ZCPR3.3 Users Guide ("ZCPR3.3 Users Guide.pdf")
+
+
+QP/M 2.7 Installation Guide and Supplements ("qpm27.pdf")
+QP/M 2.7 Interface Guide ("qdos27.pdf")
+QP/M 2.7 Features and Facilities ("qcp27.pdf")
+--------------------------------------------
+
+Official documentation set for QP/M 2.7 from original QP/M distribution.
+
+
+ZCPR Manual ("ZCPR Manual.pdf")
+-------------------------------
+
+ZCPR is the command proccessor portion of Z-System.  This is the
+manual for ZCPR 1.x as included in RomWBW.  The installation
+instructions can be ignored since that work has already been
+completed as part of the RomWBW distribution.
+
+ZCPR D&J Manual ("ZCPR-DJ.doc")
+-------------------------------
+
+ZCPR D&J User Manual.  This manual supplements the ZCPR Manual.
+
+
+ZSDOS Manual ("ZSDOS Manual.pdf")
+---------------------------------
+
+ZSDOS is the DOS portion of Z-System.  This is the manual for ZSDOS
+1.x as included in RomWBW.  The installation instructions can be
+ignored since that work has already been completed as part of the
+RomWBW distribution.
+
+ZPM3 ("ZPM3.txt")
+-----------------
+
+A Z80 coded CP/M 3.0 compatible BDOS replacement with ZCPR support.
+This minimal documentation is all that is provided with ZPM3.
+
+-- WBW 8:38 AM 6/6/2025

Doc/CPM/ZCPR-DJ.doc

@@ -0,0 +1,765 @@
+A Personal Note
+===============
+
+Somehow, I've managed to get by for the last 14 years using just ZCPR.
+But like some of you, I have fiddled with the standard ZCPR and
+modified it to suit my tastes.  As I added new commands or enriched old
+ones, I've always remained compatible with existing programs, all the
+BDOS replacements, and, most important of all, stayed within the 800H
+space allocation of the original Digital Research CCP.  Here are the
+fruits of my labors, I hope you enjoy this CCP replacement as much as I
+do.
+
+        Don Kirkpatrick
+        17595 S.W. Pheasant Lane
+        Beaverton, Oregon 97006
+        <Donald.C.Kirkpatrick@tek.com>
+
+
+Introduction
+============
+
+This console replacement is designed to run under CP/M 2.2 or any of
+the 2.2 BDOS replacements.  It requires a Z80 or better.  If you are
+running DRI's CCP or older versions of ZCPR1, this program is a
+significant improvement.  If you are running ZCPR3, CP/M 3.0, CP/M
+Plus, or MP/M, this will probably be a disappointment.
+
+If you are familiar with ZCPR3, you will recognize many of the
+enhancements here: comments on a command line, search path for the .com
+file, drive/user change with simple du:, CLEVEL3 command processing,
+proper SUBMIT file facility, and so on.  Nothing has been removed from
+DRI's CCP, only new features added.  AND IT ALL STILL FITS IN THE
+ORIGINAL 800H, THE SAME SPACE AS THE DIGITAL RESEARCH FIVE COMMAND
+CCP.
+
+Many of the standard commands have been enhanced.  For example, TYPE
+and LIST now have options to turn on or off page breaks.  Moreover, the
+console check for abort has been improved.
+
+Two commands have been added for use in submit files - SAK and BELL.
+These commands allow you to pause or ring the bell during submit file
+execution.
+
+Before you install this version of ZCPR onto your boot disks, try it by
+running it as a .com file.  Just edit the few customizing options and
+assemble the source.  After you decide it really is better, load it
+onto your boot track and make it your standard.  Complete instructions
+are located at the end of this document.
+
+The complete built-in command list is:
+
+    DIR - directory command enhanced to list optionally all user areas
+    REN - standard rename command
+    USER- move to new user number area on same drive
+    SAVE- save specified number of TPA pages or records in a file
+    TYPE- display a file on the console with optional page break pauses
+    LIST- print command plus optional form feed insertion
+    PAGE- send form feed to list device
+    ERA - standard file erase command
+    ERAQ- file erase with confirmation query at each file
+    DFU - set default user number for .com search path
+    BELL- send a bell character to the console
+    SAK - pause until a key is struck on the console (Strike Any Key)
+    SCL - toggle multiple commands per line (Single Command on a Line)
+    GET - load a file into the TPA at any specified location
+    JUMP- process command tail and execute program at specified address
+    GO  - process command tail and execute program loaded at 100H
+    PEEK- display hexadecimal byte string starting with specified address
+    POKE- load hexadecimal byte string starting with specified address
+    BOOT- execute BIOS cold boot routine
+
+
+Filename Processing
+===================
+
+The standard ZCPR3 du: drive/user file specification has been
+implemented.  Any filename can be in the du:fn.ft form.  For example:
+
+       A>era c4:junk*.*
+
+erases files on the C drive, user area 4 without leaving drive A user
+0.  When a user number is found in a filename, that user number is
+placed in S1 of the default FCB.  Bit 7 of S1 is set to inform the
+program using the FCB a user number was found.
+
+The * in an ambiguous file name has been improved.  Now a trailing *
+causes the remainder of the ambiguous name to be filled with '?', not
+just the fn field.  For example:
+
+       A>era c4:junk*
+
+is the same as the example above.  Previously, junk* was defined as
+'junk????.   '.  If you need the ft field blank, type 'junk*.'.  The
+question mark still works as a single character wild card.
+
+
+Command Line Processing
+=======================
+
+The  current user number is included as part of the command prompt for
+all non-zero user numbers.  The prompt is of the form du>, for example
+A2> or B10>.  If the SUPRES equate is true, the user number is
+suppressed for user 0 only.
+
+Multiple commands are typed on a single line separated by a command
+separator character.  Occasionally, you need to type the separator
+character in a command tail.  The SCL command toggles the multiple
+command enable.  The CMDCHR equate determines the command separator
+character.  A ';' has been chosen as the separator character in this
+distribution version.
+
+Comments are allowed on a command line.  When the comment separator
+character is encountered as the first character of a command, the
+remainder of the line is ignored.  The COMCHR equate determines the
+comment separator character.  A ';' has been chosen as the separator
+character in this distribution version.  Here is an example containing
+comments and multiple commands on a single line:
+
+   A>get 100 junk;peek 100;;this is a comment.
+   A>;this is also a comment.
+
+There exists a built-in search path for transient commands.  First, the
+current drive/user is searched.  Next, the current drive/default user
+is searched.  Last, drive A/default user is searched.  The DEFUSR
+equate determines the default user number, currently set to user 0 in
+this distribution version.  The default user is temporarily changed
+with the DFU command.  If a drive is specified in the transient
+command, the current and default user areas on the specified drive are
+searched.  If a user number is specified, that user area on the current
+and default drive are searched.  If both the drive and user number are
+specified, no search is performed.  The same drive/user area is never
+searched twice.
+
+Transient commands are always "called."  If a program terminates via a
+return rather than a warm boot, subsequent multiple commands on the
+command line are executed.  Any program exiting by a warm boot reloads
+ZCPR and the subsequent commands lost.
+
+A default command can be placed in the command buffer and control
+passed to ZCPR for processing.  The only thing required, besides
+placing the command in the buffer and jumping to CPRLOC, is to
+initialize the command character counter at the start of the buffer.
+The procedure is compatible with the original DRI CCP default command
+processing.  If ZCPR is entered at CPRLOC+3 jump, default command
+processing is suppressed.  Either way, register C must contain a valid
+drive/user, just like the original CCP.
+
+
+Submit File Processing
+======================
+
+A basic design choice had to be made in the design of ZCPR concerning
+the execution of submit files. The original CCP had a problem.  It
+ALWAYS looked for the $$$.SUB file on drive A and the submit program
+would place it on the current default drive.  When the you were logged
+onto drive B and you issued a submit command, the $$$.SUB was placed on
+drive B and not executed.
+
+After much debate it was decided to have ZCPR perform the same type of
+function as CCP (look for the $$$.SUB file on drive A), but the problem
+with SUBMIT.COM still exists.  Hence, RGF designed SuperSUB and RLC
+took his SuperSUB and designed SUB from it; both programs are set up to
+allow the selection at assembly time of creating the $$$.SUB on the
+default drive or on drive A.  If you don't have one of these newer
+submit programs, a procedure for patching the standard SUBMIT.COM has
+been included at the end.
+
+The fixed drive choice permits a submit file to contain a series of
+commands exactly as they would be entered from a CP/M console.  This
+permits things like:
+
+    A>dir
+    A>b:
+    B>dir
+
+to be executed, even though the currently default drive is changed
+during execution. If the $$$.SUB file were present on the default
+drive, the above series of commands would not work.  ZCPR would be
+looking for $$$.SUB on the default drive, and switching default drives
+without moving the $$$.SUB file would cause processing to abort.  Note
+that the same problem occurs if the user number of the $$$.SUB file is
+not predefined. ZCPR assumes that the $$$.SUB file is located on user 0
+of drive A.
+
+The trick of using the $ flag returned by the BDOS disk reset is used
+to speed the search for a $*.* file on drive A. This trick will not
+work if the $$$.SUB file were located on another drive.
+
+The '>' prompt character is replaced by a special character while a
+submit file is in execution.  The SPRMPT equate defines this special
+character, currently set to '$' in this distribution version.
+
+
+Command Syntax
+==============
+
+Multiple commands can be placed on one line.  If the comment character
+is encountered where a command should start, the rest of the line is
+ignored.  Any command can be renamed by editing the command table.
+Command names can be up to eight characters long and are terminated by
+bit 7 high.  If there is a conflict between an internal ZCPR command
+and a transient program of the same name, the internal command is
+executed.  Type the command with the du: included if the external
+transient command is the one desired.  Here is a complete alphabetized
+list of all the resident commands with their syntax:
+
+=============================================================================
+
+Command:  BELL
+
+Function: To ring terminal bell.
+
+Forms:    BELL
+
+Options:  None.
+
+Uses:     This command is designed to be placed in a submit file to
+          ring the bell to indicate significant checkpoints.
+
+=============================================================================
+
+Command:  BOOT
+
+Function: To execute BIOS cold boot routine.
+
+Forms:    BOOT
+
+Options:  REBOOT equate controls the inclusion/exclusion of this command.
+
+Uses:     Reboots the system without pushing the reset button.  The
+          cold boot entry point in the BIOS must be supported for this
+          command to work.
+
+=============================================================================
+
+Command:  DFU
+
+Function: To set the Default User Number for transient commands.
+
+Forms:    DFU <usrnum>
+
+Options:  DEFUSR equate defines the default user choice until this
+          command is entered.
+
+          NUMBASE equate defines the character that specifies a
+          hexadecimal number.  The distribution version is set to 'H'.
+
+Uses:     The default user area is searched after a transient command
+	  cannot be found in the current user area.  If the transient
+	  command still has not been found, the default user on the
+	  default drive is searched last.  The new default user number
+	  is in decimal, but hexadecimal numbers are entered by
+	  appending an 'H'.  The next warm boot will restore the
+	  original default user number.
+
+=============================================================================
+
+Command:  DIR
+
+Function: To display a directory listing of the files on a drive.
+
+Forms:    DIR <afn>       Display the DIR files
+          DIR <afn> S     Display the SYS files
+          DIR <afn> B     Display both DIR and SYS files
+          DIR <afn> A     Display both DIR and SYS files for all user areas
+
+Options:  TWOCOL equate controls the number of columns in the display.
+          Forty-column terminals are limited to two-column displays.
+
+          WIDE equate controls the spacing between the columns and
+          change the horizontal width of a directory display.
+
+          FENCE equate specifies the character separator between the
+          directory columns.
+
+          USRDLM equate specifies the character between the user number
+          and the filename.
+
+          USRFLG, SYSFLG, and SOFLG equates specify the command line
+          tail character that control the display of system and
+          non-system files.
+
+Uses:     Displays a directory listing of files in specific drive/user
+          area.
+
+=============================================================================
+
+Command:  ERA
+
+Function: To erase files.
+
+Forms:    ERA <afn>
+
+Options:  None.
+
+Uses:     Deletes files.  Names of erased files are displayed.
+
+=============================================================================
+
+Command:  ERAQ
+
+Function: To erase files with individual query.
+
+Forms:    ERAQ <afn>
+          <afn>? y          File erased
+          <afn>? <CR>       File not erased
+
+Options:  None.
+
+Uses:     Deletes a subset of a set of ambiguously specified files.
+          Any answer other than 'Y' (either case) will cause the file
+          to be skipped and not erased.
+
+=============================================================================
+
+Command:  GET
+
+Function: To load the specified file from disk to the specified address.
+
+Forms:    GET <hexadr> <ufn>
+
+Options:  None.
+
+Uses:     Loads a file into the TPA for patching purposes.  This command
+          searches for the specified file along the same search path as
+          the transient command loader.
+
+
+=============================================================================
+
+Command:  GO
+
+Function: To call the program in the TPA without loading from disk.
+
+Forms:    GO <command tail>
+
+Options:  None.
+
+Uses:     Most useful to rerun a program already loaded into the TPA.
+          Saves time and wear on disk drives.  The command tail is
+          entered exactly as it would appear if GO were replaced by the
+          program name.  Same as JUMP 100H, but more convenient,
+          especially when used with parameters for programs like STAT.
+
+=============================================================================
+
+Command:  JUMP
+
+Function: To call the program at a specified address.
+
+Forms:    JUMP <hexadr> <command tail>
+
+Options:  None.
+
+Uses:     Executes code not located at 100H.  For example, JUMP 0
+          warm boots.  The code must already reside at the specified
+          address.
+
+=============================================================================
+
+Command:  LIST
+
+Function: To print specified file on list device.
+-
+Forms:    LIST <ufn>      Print file
+          LIST <ufn> P    Print file without default paging
+
+Options:  NLINEP equate determines the number of lines per page.
+
+          FFKILL equate controls the suppression of form feeds before
+          printable text.
+
+          PGDFLG equate determines the command line tail character that
+          toggles the default form feed insertion every NLINEP lines.
+
+          NOSTAT equate controls the use of the BIOS list status call.
+
+Uses:     Prints files with/without pagination on LST: device.  A
+          listing is aborted by a console ^C.  Any submit file in
+          process is terminated and control is returned gracefully to
+          the console prompt.
+
+=============================================================================
+
+Command:  PAGE
+
+Function: To eject a page on list device via a form feed.
+
+Forms:    PAGE
+
+Options:  NOSTAT equate controls the use of the BIOS list status call.
+
+Uses:     Sends a form feed to the LST: device.  The page eject can
+	  be aborted by a console ^C if the system hangs because the
+	  printer is not ready.  If aborted, any submit file in process
+	  is terminated and control is returned gracefully to the
+	  console prompt.
+
+=============================================================================
+
+Command:  PEEK
+
+Function: To display hex values beginning at a specified address.
+
+Forms:    PEEK <hexadr> [<hexcnt>]
+
+Options:  None.
+
+Uses:     Displays hexadecimal values anywhere in the entire address
+          space.  The maximum value for <hexcnt> is 0FFH, but the
+          default <hexcnt> is 256.
+
+=============================================================================
+
+Command:  POKE
+
+Function: To poke a string of hex values into a set of consecutive
+          addresses.
+
+Forms:    POKE <hexadr> <hexval> [...<hexval>]
+
+Options:  None.
+
+Uses:     Modifies values anywhere in the entire address space.  Each
+          <hexval> represents one byte and is separated from the next
+          by a space.  The number of <hexval> are limited only by the
+          size of the command line buffer. The address is incremented
+          for each <hexval>.  Excellent for hand patching code.
+
+=============================================================================
+
+Command:  REN
+
+Function: To change the name of an existing file.
+
+Forms:    REN <newufn>=<oldufn>
+          REN <newufn>=<oldufn>     Existing <newufn>
+          Delete? y                 File deleted
+
+Options:  None.
+
+Uses:     Changes the names of files.  Any du: on <oldufn> is ignored;
+          the optional du: is on <newufn>.  If there already exists a
+          <newufn>, the console is queried for conformation.  Any
+          response except 'Y' (either case) aborts the command, kills
+          any submit file in process, and returns gracefully to the
+          command prompt.
+
+=============================================================================
+
+Command:  SAK
+
+Function: To pause until a key is struck.
+
+Forms:    SAK
+          ? <any key>
+
+Options:  None.
+
+Uses:     Pauses a submit file until a keystroke is entered.  Any
+	  character other than a ^C will resume execution.  A ^C kills
+	  the submit file, any commands remaining on the command the
+	  line are ignored, and control returns gracefully to the
+	  prompt.
+
+=============================================================================
+
+Command:  SAVE
+
+Function: To save the contents of TPA onto disk as a file.
+
+Forms:    SAVE <Number of Pages> <ufn>
+          SAVE <Number of Records> <ufn> R
+
+Options:  RECFLG equate determines the command tail character that
+          specifies records rather than pages.
+
+          NUMBASE equate defines the character that specifies a
+          hexadecimal number.  The distribution version is set to 'H'.
+
+Uses:     Saves the TPA to a file.  Records are 128 bytes long, pages
+	  are 256 bytes long.  Number of pages or records is in
+	  decimal, but a hexadecimal number is entered by appending an
+	  'H'.  Saved area begins at 100H.
+
+=============================================================================
+
+Command:  SCL
+
+Function: To force ZCPR to parse only a single command per line.
+
+Forms:    SCL
+
+Options:  MULTPL equate determines the inclusion/exclusion of this
+          command and whether or not multiple commands are allowed.
+
+          CMDCHR equate determines the character separating multiple
+          commands.
+
+Uses:     Some transient commands require the command separator in the
+          command tail.  This command turns off multiple command
+          parsing so the entire command tail is sent to the transient
+          program.  Multiple command format is reset at the next warm
+          boot. SCL toggles.
+
+=============================================================================
+
+Command:  TYPE
+
+Function: To display specified file on console.
+
+Forms:    TYPE <ufn>      Display file
+          TYPE <ufn> P    Display file without default paging
+
+Options:  NLINES equate determines the number of lines per screen.
+
+          FFKILL equate controls the suppression of form feeds before
+          printable text.
+
+          PGDFLG equate determines the command line tail character that
+          toggles the default form feed insertion every NLINEP lines.
+
+Uses:     Displays files with/without pagination on CON: device.  A
+          display is aborted by a console ^C.  If aborted, any submit
+          file in process terminates and control returns gracefully to
+          the console prompt.  When page breaks are enabled, any
+          console character except ^C will display the next page of
+          text.
+
+=============================================================================
+
+Command:  USER
+
+Function: To change current user number.
+
+Forms:    USER <usrnum>
+
+Options:  SUPRES equate controls the display of the user number in the
+          prompt when the user number is zero.
+
+          MAXUSR equate controls the maximum allowable user number.
+
+          NUMBASE equate defines the character that specifies a
+          hexadecimal number.  The distribution version is set to 'H'.
+
+Uses:     This command changes the current user number.  The new user
+          number is in decimal, but a hexadecimal number is entered by
+          appending an 'H'.  This command has been retained for
+          compatibility purposes only.  It is far easier to change
+          disk/user by typing du:.
+
+=============================================================================
+
+
+Error Messages
+==============
+
+If any error is encountered as a command line is being parsed, a
+message will be printed and, for serious errors, the remainder of the
+line is ignored.  Below is a complete list of all ZCPR error messages.
+Any error message encountered that is not on this list came from some
+program other than ZCPR.
+
+"?"
+
+   An error was detected in the command.  The an item on the command
+   line was not what was expected.  The command line is echoed up to
+   the position where the error was detected, as close as can be
+   determined, and the "?" printed.  Any commands remaining on the
+   command the line are ignored and any $$$.SUB file erased.
+
+"Full"
+
+   If ZCPR was attempting to load a transient program, one of two
+   things has gone wrong: either the program is so large that it won't
+   fit into the TPA or a read error was returned from the BDOS.  If
+   ZCPR was attempting to save a file, the BDOS write call returned
+   failure. Either the disk or the directory is full.  Any commands
+   remaining on the command line are ignored and any $$$.SUB file
+   erased.
+
+"No File"
+
+   No file could be found matching the filename specified in the
+   command.  This message is also be printed if the BDOS read command
+   returns failure.  If ZCPR was looking for a transient command, any
+   commands remaining on the command line are ignored and any $$$.SUB
+   file erased.
+
+"Name Error"
+
+   The specified filename has a user number larger than the allowable
+   maximum or an ambiguous filename was entered where only an
+   unambiguous filename is permitted.  Any commands remaining on the
+   command line are ignored and any $$$.SUB file erased.
+
+"Delete?"
+
+   Not really an error, but there already exists a file with the same
+   name as the requested new name in the REN command.  Any response
+   except 'Y' (either case) aborts the command, any commands remaining
+   on the command line are ignored, and any $$$.SUB file erased.
+
+"All?"
+
+   Not really an error, but a check to verify that all files on the
+   drive/user area are to be erased.  Any response except 'Y' (either
+   case) aborts the command and any commands remaining on the command
+   line are ignored.
+
+
+Installation Instructions
+=========================
+
+1) The first task is to determine the location of your BDOS because you
+   MUST set the P2DOS equate to this value.  If you do not know the
+   location of your BDOS, use ZCPRDEMO to find it.  If you do not
+   already have ZCPRDEMO.COM, assemble ZCPR with the TEST equate true
+   to make it.  A bootstrap loader will be included and you can run the
+   .com file.  This program assembles without errors using Microsoft's
+   M80/L80:
+
+   A>m80 =zcpr
+   A>l80 zcpr,zcprdemo/n/e
+
+   Other assemblers can be used, but ZCPR.MAC will probably require
+   editing to convert it to a form compatible.  The major decision in
+   converting is to determine how the .PHASE pseudo is to be handled.
+   Probably the best solution to the .PHASE is to generate a .hex
+   file and load it with an offset using DDT/SID/ZSID.  Consult the
+   "r" command in the DDT/SID/ZSID manaul.
+
+   Run ZCPRDEMO and peek at low memory:
+
+   A>zcprdemo
+   A<peek 0 10
+   0000 C3 03 F2 00 00 C3 06 E4 00 00 00 00 00 00 00 00
+   A<^C
+
+   Notice the prompt character has changed from a '>' to a '<'.  This
+   tells you the special debug version of ZCPR is running.  See the
+   debug section at the end for details.  Address 0 contains a jump 3
+   beyond the start of the BIOS and address 5 contains a jump 6 beyond
+   the start of the BDOS.
+
+   Be careful if you attempt to execute a transient program from
+   ZCPRDEMO.  Some transient programs, like NSWP, return rather than
+   warm boot when done. These programs don't know that ZCPRDEMO is at
+   address 8000H rather than just under the BDOS.  If they overwrite
+   ZCPRDEMO, then the return is to random code. Of course, this is not
+   a problem when ZCPR is installed just under the BDOS.
+
+2) You MUST edit the code to place your BDOS/P2DOS/Z80DOS/ZRDOS start
+   address in the P2DOS equate.  Set COMLD true (and TEST false if you
+   set it true in step 1 above) and make ZCPR.COM.  A bootstrap loader
+   will be included.
+
+   Assuming you successfully assemble it, just type "zcpr" to run it.
+   However, every time there is a warm boot, it will be  replaced by
+   the boot track CCP.  If you like what you see, place a copy on the
+   boot track to make it available all the time.
+
+3) Reassemble, this time with COMLD false to make ZCPRNBLD.COM (ZCPR
+   No Boot LoaDer).  
+
+4) Run SYSGEN to load a copy of the boot track into memory.
+
+   B>; Sample terminal session for integrating ZCPR
+   B>sysgen
+   SYSGEN VER 2.2
+   SOURCE DRIVE NAME (OR RETURN TO SKIP)a
+   SOURCE ON A, THEN TYPE RETURN  <cr>
+   FUNCTION COMPLETE
+   DESTINATION DRIVE NAME (OR RETURN TO REBOOT)  <cr>
+
+
+5) Run SAVE to save a track image to a file (eg: SAVE 32 BOOTFILE).
+   The number on the save command depends on the size of your boot
+   track loader; it can be as small as 31 and as large as 44.  If you
+   have extra disk space or are not sure, play it safe and use 44.
+
+   B>save 44 cpm56.com      <-- We now have a SYSGEN image of CP/M
+
+6) Find the location of the stock CCP by peeking at the boot file. It
+   is normally located at address 980H in the file. Using ZCPR:
+
+   B>zcpr                   <-- Reload zcpr.com version
+   B>get 100 cpm56.com
+
+   and search for the start of the console processor:
+
+   B>peek 980
+   0980 C3 xx xx C3 xx xx 7F 00 43 4F 50 59 52 49 47 48
+   0990 54 20 ...
+
+   If you don't find the start of the CCP at 980H, don't be
+   discouraged. It is there, but at a higher address.  Keep looking.
+
+7) When you find the location of the CCP, patch it with the new ZCPR
+   image.
+
+   B>get 980 zcprnbld.com
+
+8) Place the new file onto the boot track of a test disk, not your
+   original, using SYSGEN, and try it out.
+
+   B>sysgen
+   SYSGEN VER 2.2
+   SOURCE DRIVE NAME (OR RETURN TO SKIP) <cr>      <-- Use memory image
+   DESTINATION DRIVE NAME (OR RETURN TO REBOOT)b   <-- Load onto drive B
+   DESTINATION ON B, THEN TYPE RETURN <cr>
+   FUNCTION COMPLETE
+   DESTINATION DRIVE NAME (OR RETURN TO REBOOT) <cr>
+
+   You should now have a ZCPR system boot disk.  Notice you did all
+   your work on drive B so you wouldn't destroy the original.
+
+
+
+This may seem like a great number of steps, but each is only a single
+CP/M command line, total time is only 5 minutes or so after you get
+ZCPR to run as a .com file.
+
+
+Debugging ZCPR
+==============
+
+Special provisions have been make to ease the debugging of ZCPR.
+Setting the TEST equate true causes the assembler to build a version of
+ZCPR that executes in the TPA.  This allows the use of a debugger like
+DDT, ZSID, or Z8E to load and monitor execution.  To identify the debug
+version, the prompt character is changed from '>' to '<' when it runs.
+
+CPRLOC for the test version is 8000H.  A bootstrap loader is included
+at the beginning to move the image to this address.  Do not try to set
+a breakpoint until after the loader has moved ZCPR.  The easiest way to
+accomplish this is to single-step through the loader and then set your
+breakpoints.  Change the execution address to something lower if 8000H
+does not leave enough space for the debugger.
+
+A small amount of code is also added at the end of the debug version to
+compute the BIOS list status and cold boot entry points at run time.
+This permits the demo version to execute properly without setting the
+BDOS location equate.
+
+Patching SUBMIT.COM
+===================
+
+SUBMIT.COM is patched to run with ZCPR by the following procedure.
+This is recommended if the user does not have one of the newer public
+domain versions of submit.  This patch simply makes SUBMIT.COM always
+place the $$$.SUB file on drive A.  Illustrative terminal session
+follows:
+
+  A>get 100 submit.com;peek 5bb 2
+  05BB 00 24              <-- Patch is at 5BB Hex
+  A>poke 5bb 1            <-- Change 0 (default drive) to 1 (drive A)
+  A>peek 5b0 20           <-- Let's check just to make sure
+  05B0 00 00 00 00 00 00 30 30 31 20 24 01 24 24 24 20
+  05C0 20 20 20 20 53 55 42 00 00 00 1A 1A 1A 1A 1A 1A
+  A>save 5 newsubmt.com   <-- Save new SUBMIT.COM file
+
+Pretty simple, huh?
+ny error message encountered that is not on this list came from some
+prog

Doc/CPM/ZPM3.txt

@@ -0,0 +1,483 @@
+
+                    Z P M 3   by Simeon Cran
+                    ========================
+
+          A Z80 coded CP/M 3.0 compatible BDOS replacement.
+
+               The first public release: 27/3/92
+                    This document dated: 16/6/92
+
+          Distributed at: Z-Node 62 (Perth, Western Australia)
+                     V21,V22,V22bis 09 450 0200
+
+
+WELCOME TO ZPM3
+~~~~~~~~~~~~~~~
+Welcome to the best CP/M compatible operating system for Z80 
+based computers with banked memory. The best? Yes, we believe so. 
+CP/M 3.0 has had bad press, but the fact is that it is faster 
+than CP/M 2.2 ever was, and it offered more integrated 
+facilities. Perhaps it was all the Z80 replacement BDOSes for 
+CP/M 2.2 which stole the limelight from CP/M 3.0, or was it just 
+that few computers had the required banked memory?
+
+Whatever the reason for CP/M 3.0's lack of success in the 
+marketplace, there are still plenty of users who will stand by 
+its wonderful facilities and speed. For those users ZPM3 provides 
+the long awaited Z80 coded update.
+
+ZPM3 offers all the good things that CP/M 3.0 does, and then it 
+offers more. Because ZPM3 is written in Z80 code rather than the 
+8080 code of CP/M 3.0, it can do everything that CP/M 3.0 does, 
+but in much less space. With the extra space recovered, ZPM3 
+packs in a number of new facilities. Yet the whole package fits 
+in exactly the same space as CP/M 3.0 so you can directly replace 
+your old CP/M 3.0 BDOS with ZPM3 without a worry.
+
+ZPM3 is also fast. Faster, in fact, than CP/M 3.0. This is 
+possible because the rich Z80 instruction set allows many 
+algorithms to be implemented more efficiently. In addition, the 
+extra space available in ZPM3 has been put to use to further 
+optimise the code. Lots of small optimisations smooth the 
+execution flow, so ZPM3 becomes the fastest operating system on 
+most banked CP/M computers.
+
+
+THE FEATURES
+~~~~~~~~~~~~
+ZPM3, in addition to complete CP/M 3.0 compatibility, offers the 
+following features:
+
+
+Random Read Bug fixed.
+++++++++++++++++++++++
+Maybe you didn't know, but CP/M 3.0 has a bug. It affects random 
+reads under very specific circumstances, and can result in a 
+program thinking that you don't have some pieces of data in a 
+file when in fact you do. The bug would occur very, very rarely, 
+but it is real. ZPM3 finally squashes it.
+
+
+Protected SCB User code
++++++++++++++++++++++++
+The System Control Block of CP/M 3.0 was a revolution at the 
+time. ZCPR has a system environment and most other operating 
+systems have other similar structures, but the SCB of CP/M 3.0 
+was one of the very first.
+
+Unfortunately, Digital Research never properly documented it, and 
+some programmers found things out about it that weren't quite 
+true and started programming accordingly. As well, because it is 
+available in the TPA bank, runaway programs can overwrite it 
+causing problems.
+
+Mostly though, the SCB will survive, or at least any problems 
+will be so obvious that the user will realise that a crash has 
+occurred and will reboot. A real problem exists with the CP/M 3.0 
+code however when the user value is written over with a value 
+above 15. Many programs now directly write to this byte, and if 
+they put a value in that is above 15, all sorts of havoc can 
+happen with the disk system. Actually, CP/M 3.0 will handle user 
+areas above 15 with this method, and all seems ok until the 
+operating system mistakes one of these directory entries as an 
+XFCB. Simply put, user areas above 15 must not be used with CP/M 
+3.0.
+
+ZPM3 has code which prevents these problems, making the system 
+even more stable.
+
+
+Obsoleted Trap system.
+++++++++++++++++++++++
+One of the problems of the banked operating system was that it 
+was possible to redirect the BIOS to code below common memory, in 
+which case the banked BDOS could not access it. One solution is 
+to call all BIOS code from common memory, but this involves a 
+bank switch for every BIOS call, and this slows things down 
+considerably.
+
+CP/M 3.0 got around the problem by providing special code just 
+below the SCB. If you redirected the BIOS, you also had to change 
+this code which caused a bank switch when your new BIOS routine 
+was called. When you removed the redirection, you also had to 
+restore the special code.
+
+This system has major drawbacks. For a start, if you redirect the 
+BIOS, then another program redirects your redirection, then you 
+remove your first redirection (along with the special code), the 
+bank switch won't happen for the second redirection and the 
+system will crash.
+
+If a CP/M 2.2 program tried to do the redirection, it would know 
+nothing about CP/M 3.0 and would not adjust the special code, so 
+a crash would result in that case too.
+
+The special code was called the "Trap System" as it was meant to 
+trap redirection (as long as you set the trap). ZPM3 has 
+eliminated the need for the traps. They are still there, and 
+programs can still fiddle with them, but it doesn't matter how 
+they are set, they are ignored. There is simply no need for them 
+anymore. And this has been achieved without a performance 
+penalty. In fact, in the case of a program which sets the traps 
+but forgets to restore them, performance is now much better.
+
+
+Semi-Permanent Read Only status for drives.
++++++++++++++++++++++++++++++++++++++++++++
+In recent years, a trend in CP/M 2.2 is to make drives which have 
+been set read only to remain that way until explicitly changed by 
+function 37. ZPM3 now adopts this logic. Previously a control-C 
+would return a read only drive to read write. The advantage is 
+that a program can now make a drive read only for a session and 
+know that it will stay that way.
+
+
+ZCPR compatible function 152
+++++++++++++++++++++++++++++
+Function 152 is the CP/M 3.0 parser. It was a great innovation at 
+the time as parsing is one of the more tedious aspects of 
+programming for CP/M. Unfortunately, almost as soon as it 
+appeared, it was made obsolete by the fact that it didn't handle 
+references to user number (DU references). A line such as 
+A:FILE.TYP would be correctly parsed, but A3:FILE.TYP would not. 
+CP/M 3.0 programs would often parse the drive and user 
+separately, then give function 152 the line without the DU: 
+reference. All this extra work should not have been necessary if 
+CP/M 3.0 had included user number parsing.
+
+ZPM3 parses the user number, and goes even further by handling 
+named directories for ZCPR. This is possible as long as you set a 
+special word in the SCB which tells ZPM3 where to find the ZCPR 
+system environment descriptor. ZCCP, a companion CCP for ZPM3, 
+handles this automatically, but for Z3PLUS users, a special 
+utility is available which automatically sets this word.
+
+The result is that CP/M 3.0 programs will not balk at DU: 
+references and ZPM3 aware programs can use the full DU: and DIR: 
+facilities of function 152. It has also made the brilliant ZCCP 
+code possible.
+
+
+New Functions 54 and 55
++++++++++++++++++++++++
+Datestamps in CP/M 3.0 are wonderful, but difficult to 
+manipulate. Two new functions make them easier to handle and at 
+the same time give compatibility to Z80DOS aware programs.
+
+Function 54 (Get Stamp) returns a Z80DOS compatible datestamp. 
+Any program (such as many directory programs) which recognise the 
+Z80DOS standard can make use of function 54. There is only one 
+slight difference between Z80DOS datestamps and ZPM3's which you 
+should be aware of. Z80DOS will return a correct datestamp after 
+any successful open or search of any extent. ZPM3 can only return 
+a correct datestamp after a successful open or search of the 
+first extent of the file. This is because CP/M 3.0 datestamps are 
+only saved for the first extents of each file, in order to 
+provide the highest performance.
+
+Even more interesting is Function 55 (Use Stamp) which provides a 
+mechanism for changing datestamps on files. Trying to do this 
+with CP/M 3.0 was virtually impossible because it involved direct 
+sector writes. With Function 55 you can simply set the stamp and 
+then write.
+
+
+Wheel protected files
++++++++++++++++++++++
+If you are using a ZCPR system (ZCCP or Z3PLUS), ZPM3 has access 
+to the wheel byte and supports wheel protected files. Such files 
+act normally if the wheel is set (signifying a priveleged user), 
+but if the wheel is not set, the files can not be changed. This 
+is of most benefit to BBS systems. The implementation is 
+virtually the same as most current Z80 CP/M 2.2 compatible 
+BDOSes.
+
+
+Better error messages
++++++++++++++++++++++
+CP/M 3.0 introduced the best error messages that CP/M had ever 
+had. ZPM3 goes further. The main difference you will notice is 
+that the user number as well as the drive is shown in the error 
+message. This is invaluable in helping you identify which file 
+might have caused a problem.
+
+
+Function 10 history buffer and improved editing.
+++++++++++++++++++++++++++++++++++++++++++++++++
+Function 10 is used by the CCP to input command lines. Many other 
+programs use function 10 for input.
+
+CP/M 3.0 introduced a history buffer for function 10. You press 
+control-W and you were returned the last command. It is a great 
+facility, but because it only remembers one command it is rather 
+limited. There have been RSXes written which give a much larger 
+history buffer, but RSXes take up extra program memory so are 
+undesirable.
+
+ZPM3 gives a large (approximately 250 bytes) history buffer which 
+can store multiple commands. It also makes very intelligent use 
+of the buffer so that identical commands are not stored twice, 
+and commands of less than three characters are not stored. The 
+history buffer takes up no additional memory, and is always 
+available.
+
+For security, it is possible to clear the history buffer so that 
+other users can not see what commands you have used.
+
+The ZPM3 history buffer feature is so good, that for many users, 
+the ZPM3 upgrade is completely justified by it.
+
+As part of the history buffer system, ZPM3 also offers a facility 
+called Automatic Command Prompting. This can be disabled, or can 
+be made switchable from the keyboard. When it is on, ZPM3 tries 
+to fill in the rest of your command based on what commands you 
+used most recently. It is like magic, and can save you typing out 
+complicated commands many times. In effect, it looks through the 
+history buffer for you and finds the command it thinks you want. 
+As you keep typing, if it turns out that the command doesn't 
+match anymore, it will try to match another command, and if it 
+can't, it lets you make the command by yourself. This facility is 
+quite amazing to watch.
+
+And to integrate the history buffer and the automatic command 
+prompting, function 10 has the best command line editing you'll 
+find anywhere. Most of the control keys do something when you are 
+editing a function 10 line, and for the most part they mimic the 
+standard WordStar/NewWord/ZDE functions. You can jump to 
+different words in the command, delete individual words, delete 
+individual letters, insert letters, and a whole lot more.
+
+
+Here is a list of what the various control keys do for function 
+10:
+
+A    Move left one word
+B    Go to the beginning or end of the line
+C    Warm boot if at start of line, otherwise nothing
+D    Go right one character
+E    Go backwards one command in the history buffer
+F    Go right one word
+G    Delete current character
+H    Destructive backspace
+I
+J    Enter line
+K    Delete all to the right
+L
+M    Enter line
+N
+O
+P    Toggle printing
+Q    Toggle automatic command prompting (if enabled)
+R
+S    Go left one character
+T    Delete current word
+U    Add current line to history buffer
+V    Clear line and delete from history buffer
+W    Go forwards one command in the history buffer
+X    Delete all to the left
+Y    Clear the whole line
+Z
+
+
+CPMLDR.REL bug fixed.
++++++++++++++++++++++
+If you have ever tried to use the CPMLDR.REL code supplied with 
+CP/M 3.0 to load a CPM3.SYS file larger than 16k, you have 
+probably come across the CPMLDR.REL bug. The computer probably 
+crashed, and you were left wondering what you did wrong in your 
+bios.
+
+Well CPMLDR.REL has a bug. To solve this for you ZPM3 comes with 
+ZPM3LDR.REL which directly replaces CPMLDR.REL. It is also 
+somewhat better in that all the messages, and the fcb for loading 
+CPM3.SYS, are at the start of the file along with plenty of spare 
+room. As a result you can easily patch the signon and error 
+messages to say whatever you like and even change the FCB to load 
+a file called something other than CPM3.SYS.
+
+
+
+
+All About the Random Read Bug.
+==============================
+Never heard of it? Well it's there in CP/M 3.0. I spent a lot of 
+time trying to work out what it was and just why it was 
+happening, and if you are interested, here are the details.
+
+CP/M 3.0 uses the Record Count byte of an active FCB a little 
+differently from the way CP/M 2.2 does. It is mentioned in the 
+CP/M 3.0 manuals that the record count may contain numbers 
+greater than 128, but in such a case it implies that the record 
+count is really 128. CP/M 2.2 would not return record counts 
+greater than 128.
+
+The reason for the use of the record count in this way is to help 
+speed up some of the logic used to find records in a file. It 
+works very well for sequential access. When it comes to random 
+access, the system has some failings.
+
+The idea behind CP/M 3.0's unusual use of the record count is to 
+keep the record count of the last logical extent of the current 
+physical extent always in the Record Count byte. When accessing 
+extents before the last one, bit 7 of the byte is set. That way 
+it will always be at least 128 for logical extents before the 
+last (which CP/M 3.0 translates to mean equal to 128), and the 
+lower 7 bits are used as convenient storage for the record count 
+of the last logical extent. This is particularly convenient 
+because it means there is no need to go and read the directory 
+entry again when it comes time to read the last logical extent.
+
+I hope you have followed that! In sequential access, this scheme 
+is great. The problem occurs with random access. In this case it 
+is possible to access a logical extent which has no records in 
+it. This could be any logical extent past the last one. In such a 
+case the record count must be returned as 0 (which is correct). 
+If we then go back to a previous logical extent in the same 
+physical extent, CP/M 3.0 gets confused and assumes that there 
+must be 128 records in that extent because the one we just came 
+from had no records and we are now accessing an earlier extent. 
+You're probably well and truly lost by now!
+
+Anyhow, the assumption that CP/M 3.0 makes is quite wrong. The 
+record count ends up being set to 128, a read is allowed to go 
+ahead as if nothing was wrong, no error is returned, and the 
+record count remains incorrectly set until a different physical 
+extent is opened. The result could be chaos, but mostly it just 
+means that a program returns the wrong information.
+
+Remember, a logical extent is always 16k. A physical extent can 
+be a multiple of 16k and is all the data described by one 
+directory entry. If your system has physical extents which are 
+16k, you would never have the problem because a new physical 
+extent would be properly opened for every new logical extent that 
+was accessed.
+
+Typically though, a physical extent is 32k, so it holds 2 logical 
+extents. The problem won't arise until the file grows past the 
+32k mark in such a case. And when the file gets over 48k the 
+problem can't occur again until it gets over 64k... and so on. 
+Even then, it can only happen if reads are attempted to 
+particular extents in a particular order. So you shouldn't be too 
+surprised if the bug hasn't been too noticeable to you.
+
+ZPM3 squashes the bug once and for all by using the correct 
+logic. In the situation where the bug would normally occur, ZPM3 
+makes sure it gets the correct record count information, and the 
+reads return the correct record count every time.
+
+If you are interested in seeing a demonstration of the bug in 
+action (on CP/M 3.0) and comparing it with ZPM3, there is a file 
+floating around various bulletin boards which contains 
+demonstrations for the bug and an RSX to fix it. The RSX is a 
+less than perfect way of overcoming the bug, although it seems to 
+work. However, now that you have ZPM3, you don't need to worry.
+
+
+
+
+Other things you should know about ZPM3
+=======================================
+ZPM3 has worked on EVERY CP/M 3.0 system tried so far except one. 
+This is a Bondwell computer, and as yet it isn't clear why it 
+won't work. I will study the source code of its BIOS and come up 
+with a fix shortly.
+
+The MAKEDOS.COM utility is not perfect (as mentioned previously) 
+and it seems that nobody has managed to get it to work with the 
+Commodore C128 system. You must use the conventional method for 
+installing ZPM3 on such systems.
+
+If you have a computer that ZPM3 will not install on with MAKEDOS 
+and you do not have access to the files required to do a 
+conventional install, please contact me. I am interested in 
+making ZPM3 as universal as possible and will help you to install 
+it on your system.
+
+The ESCAPE key is ignored by function 10. There has been some 
+lively discussion about this but the decision is final: it stays 
+ignored. Remember what function 10 is for and you will understand 
+why I made it ignore the ESCAPE key. The argument against this 
+has been from people who control their terminals from the command 
+line. Apparently some people type in an escape sequence at the 
+command line (which CP/M 3.0 will not output correctly anyhow 
+(converting the escape character to ^[)) then press return to 
+have the CCP echo back the line including the escape character.
+
+Sorry folks, that is a KLUDGE in my books! Anybody using Z-System 
+would of course use an ALIAS and ECHO to do this properly, but 
+for those who will continue to complain that I have sacrificed 
+CP/M 3.0 compatibility I am now including ECHOTERM.COM to solve 
+your problems. Run it and whatever you type will be sent to the 
+terminal correctly after you press RETURN. Press RETURN twice to 
+exit the program.
+
+And a reminder that the ability to put control characters into 
+function 10 lines was always limited by the fact that some 
+control keys were used to edit the command line. CP/M 3.0 added 
+even more, and ZPM3 uses virtually all the control keys. The few 
+that aren't used are ignored, and this is in fact a FEATURE which 
+guarantees that unusable characters can't get into function 10 
+lines by accident.
+
+
+
+
+LEGALS and SUCH
+===============
+The ZPM3 package is supplied free of charge, on the condition 
+that you don't use it to make money. If you want to use it 
+commercially you must contact me to get the OK (and negotiate our 
+fee).
+
+If you find anyone (except myself) charging money for ZPM3, 
+please inform me!
+
+Nobody is making any guarantees about this software. None at all. 
+If it causes your house to burn down, or a divorce, or just a bad 
+day, this is unfortunate, regrettable, but there is nothing that 
+I can or will do about it. You have been warned.
+
+The ZPM3 package must only be distributed in the form that you 
+found it. Do not change or add anything. Don't even change it 
+into a different type of archive. Just leave it alone. However 
+you are free to distribute it to as many places and people that 
+you can. Just don't charge for it.
+
+
+
+If in using ZPM3 you find that it doesn't act as described, 
+please forward the details to me so that either the ZPM3 code or 
+the documentation can be changed. If you would like further 
+details, please forward your specific questions to me. SJC.
+
+
+
+
+As a service to all our ZPM3 fans, the latest version of the ZPM3 
+package can now be ordered. At this stage we can only supply IBM 
+formatted 3.5 inch 720k disks, however if you are keen enough 
+that shouldn't matter. ZPM3 remains free, however this service 
+will cost you $15 Australian (for the disk, copying, postage and 
+packing) to most places in the Western World (others by 
+arrangement).
+
+This is a good way to guarantee you have the latest version, and 
+to guarantee that your package has not been corrupted by some 
+unscrupulous person.
+
+When we fill your order, we will make sure to include the latest 
+demonstration copy of MYZ80 - the fastest and best Z80 emulator 
+for IBM AT (and better) compatibles. MYZ80 can run ZPM3 with 
+ease. It also handles ZCPR and CP/M 2.2. And yes, we do mean 
+FASTEST.
+
+Send your international money order to:
+
+          Software by Simeon
+          ZPM3 Package
+          2 Maytone Ave
+          Killara   NSW
+          Australia 2071
+
+Your order will be promptly filled.
+

Doc/ChangeLog.txt

@@ -1,4 +1,442 @@
-Version 2.6.2
+Version 3.6
+-----------
+- RDG: Added VDA driver for Xosera FPGA-based VDC
+- MGG: Added COBOL language disk image
+- WDC: Added config options to PCF driver
+- WBW: Enabled dynamic CPU speed update on LCD screen
+- WBW: Improve LPT driver boot messaging when not detected (per Robb Bates)
+- WBW: Correct DS1307 boot date/time display (per Tadeusz Pycio)
+- WBW: Add -DELAY option to TUNE app (per Robb Bates)
+- RDG: Add online documentation site
+- WBW: Added enhanced Hi-Tech C Compiler files from Ladislau Szilagyi
+- WBW: Added boundary check to ram/rom disk driver
+- WBW: Per Peter Onion, switch KERMIT default file xfer mode to binary
+- J?L: Source for ZSDOS2 and BPBIOS Utilities (from disassembly)
+- WBW: Support ROM-based font storage
+- MAP: New Slice Inventory Rom App "S" display bootable slices, during boot
+- MAP: Device Inventory moved from HBIOS to Rom App, saving >1k space in HBIOS
+- MAP: Added disk image for all Infocom text adventure Games
+- M?R: Fixed formatting issue with SLABEL where Slice # < 10
+- WBW: Improved image creation process to allow user defined aggregates
+- WBW: Implemented config driven slice name and system image specification
+- D?N: Added native USB driver support (keyboard, floppy, mass storage)
+- MGG: Added sample program source files for all language disk iamges
+
+Version 3.5.1
+-------------
+- WBW: Fix CPMLDR.SYS & ZPMLDR.SYS for SYSCOPY (reported by Guido Santer)
+- MAP: Enhanced SLR Tools Disk Image with Plus versions
+- WBW: Add missing BCLOAD file to MS BASIC Compiler Disk Image (reported by Marshall Gates)
+- WBW: Doc improvements (per Fraser and Rob Gowin)
+- WBW: Correct ZMP application crash
+- MAP: Contribution of the SLABEL.COM tool for displaying and changing slice labels.
+- MAP: Hardware documentation, Significant new content added with project links.
+
+Version 3.5
+-----------
+- M?F: Fix for hours display in HBRTC application
+- M?F: Fix for assembly error in DS1501RTC driver
+- WBW: Add VT-100 graphics char selection to Propeller firmware
+- WBW: Allow all lines of VGA display to be used on Propeller firmware
+- WBW: Allow front panel LED/Switch bits to be inverted in config
+- WBW: Add API to expose application banks available
+- WBW: Added console takeover at boot loader prompt
+- L?N: Fixed Propeller font vertical line character to align properly
+- L?S: EF9345 video display controller driver
+- WBW: Added Cowgol disk image based on the work of Ladislau Szilagyi
+- WBW: Added support for CP/NET on Duodyne Disk I/O
+- DDW: Added support for Duodyne Media board
+- WBW: Auto restore TMS video on user reset (CP/M warm boot)
+- L?B: Added support for NABU w/ RomWBW Option Board
+- MAP: Reorganization of Doc directory introducing subfolders
+- WBW: Upgraded BBCBASIC to v5.00
+- W?S: Updated FLASH utility to v1.3.9
+- WBW: Support RCBus PS/2 Keyboard (EP/Sally)
+- M?R: Update Timer app to display output in decimal
+- WBW: Preliminary support for S100 FPGA Z80 platform
+- WBW: Added simple serial (SSER) driver
+- WBW: Added preliminary support for S100 FPGA Z80 SD Cards
+- M?R: Consolidated ROM Applications document into the Applications document
+- M?R: Reviewed and substantially improved the Applications document
+- WBW: Added support for DS1305 RTC on S100 FPGA Z80
+- WBW: Added support for Les Bird's RCBus Graphics/Sound/Joystick module
+- WBW: Added support for Les Bird's Dual 16C550 UART module
+- WBW: Refactor UART driver for more flexible configuration
+- M?R: Added hour/minute/second display to timer app
+- WBW: Substantial customization of NZ-COM disk image
+- WBW: Refactor build post-processing (ZRC, ZZRCC, etc.)
+- MAP: Improved section Real Time Clock in User Guide document
+- WBW: Support for Hitachi HD44780-based LCD display
+- DRJ: Added support for Genesis STD Bus Z180 platform
+- MAP: Improved section Disk Management in User Guide document
+- WBW: Add CPU speed selection for HEATH platform to HBIOS
+- WBW: Add Warm/Cold reboot options to CPUSPD utility
+- D?N: Added support for eZ80 CPU
+- MAP: Contributed COPYSL utility that allows disk slices to be copied
+- MAP: Added new HBIOS function EXT_SLICE, extended disk slice info
+- MAP: ROMLDR now uses EXT_SLICE to get Slice Sector for boot
+- MAP: CBIOS now uses EXT_SLICE during drive selection
+- MAP: CPM3 Boot Loader, and BIOS (drive select) now use EXT_SLICE
+- M?R: Added REBOOT application
+- MAP: Significant improvement in Disk Catalog document
+- MAP: Added Disk Image for the Z3PLUS (Z-System for CP/M-Plus) os.
+- H?H: Fix XModem 12.3 WRERR to put CAN char in proper register to send.
+- MAP: Added support for dynamic HBIOS config via (RTC) NVRAM
+- MAP: Added boot application to allow config of NVRAM options
+- MAP: Configuration of autoboot disk/app added to NVRAM config
+- WBW: Autoboot is now handled in separate prompt during RomWBW startup
+- MAP: Added additional tools (Linker/Disasembler) to the Z80ASM Disk Image
+- PMS: Support interrupt-driven PS2 Keyboard Interface
+- D?M: Added NetBoot support for Duodyne
+- WBW: Add options to TUNE/HBIOS to force detection of MSX and RC AY/YM standard PSG ports
+- MAP: Added /B=OPTIONS for automated drive assignment to ASSIGN.COM
+- WBW: Added TE Editor (Ladislau Szilagyi)
+- WBW: Refrech Cowgol disk image (Ladislau Szilagyi)
+
+Version 3.4
+-----------
+NOTE: Changes require HBIOS/CBIOS/Apps sync, version bump to 3.4 to ensure integrity
+- WBW: Device type number moved from upper nibble to full byte
+- A?C: Support for EP ITX-Mini Z180 Platform
+- M?R: Significant improvement in User Guide document
+- J?P: Preliminary support for Monsputer (MON)
+- JLC: Standardize TMS driver memory map for compatibility
+- WBW: Improved IDE device detection
+- WBW: Fixed decompression when run on Z280
+- K?B: WDATE generic HBIOS date/time utility
+- WBW: Create new DSKY framework with simple driver style interface
+- JBL: Added ColecoVision config in TMS driver
+- WBW: Added support for interrupt mode 1 on Z180
+- WBW: Added S100 platform
+- WBW: Added Duodyne platform
+- WBW: Incorporated John Monahan's S100 Monitor in S100 platform build
+- WBW: Support ESP32 on Duodyne
+- M?C: Fixed port specification when using XM.COM send transfers
+- PMS: Support for Duodyne DMA
+- WBW: Added Serial ROM (SROM.COM) utility
+- WBW: Support S100 Propeller Console
+- SCC: Added support for SC700
+- WBW: Added Heath H8 platform
+- D?J: Enhanced build to run on Raspberry Pi 4
+- WBW: Complete overhaul of ROMless boot operation
+- WBW: Prevent access to slices outside of partition
+- T?P: Contributed the HTALK utility
+- WBW: CTS stall detection
+- W?S: Updated FLASH utility to v1.3.7
+- L?N: Updated UNARC to new OS universal version
+- B?C: Added support for Z1RCC
+- M?R: User Guide enhancements and corrections
+- D?H: Added support for specification of secondary console
+- WBW: Added platform for Monsputer
+- WBW: Added FAT.COM to standard ROM Disk (removed RMAC.COM & LINK.COM)
+
+Version 3.3
+-----------
+NOTE: v3.3 was never released
+- WBW: Support Front Panel switches
+- A?C: Preliminary support for Z80-Retro
+- A?C: Support for SD PIO
+- A?C: Support for Z80-Retro SD interface
+- WBW: Support per-drive floppy configuration
+- WBW: Support for Bill Shen's VGARC
+- WBW: Support for MG014 Parallel Port module + printer
+- WBW: Support for IMM Zip Drive on PPI interface (much inspiration from Alan Cox)
+- WBW: Support for PPA Zip Drive on PPI interface (much inspiration from Alan Cox)
+- WBW: Support for SyQuest SparQ Drive on PPI interface (much inspiration from Alan Cox)
+- WBW: Support for ATAPI Disk Drives (not CD-ROMs) on IDE and PPIDE interfaces
+- R?P: Added new disk images: Aztec C, MS BASIC Compiler, MS Fortran, Games, HiTech-C, Turbo Pascal, SLR Z80ASM
+- JBL: Added RCZ80 configuration for ColecoVision
+- WBW: Support for Z180 running interrupt mode 1
+- WBW: Preliminary support for S100 Computers Z180
+- WBW: Preliminary support for Dan Werner's ESP32 MBC Module
+- WBW: Early support for Duodyne base system (CPU/UART/ROM/RAM/RTC/SPK)
+- M?C: Fixed XM to allow specifying HBIOS port for send operations
+- WBW: Fix S100 Z180 LED operation (credit to Jay Cotton for finding this issue)
+- WBW: QPM system image is now combined with current CBIOS during build
+- WBW: Added framework for Heath platform
+- WBW: Support for USB Disks via CH375/CH376
+- D?J: Support for Raspberry Pi build process
+
+Version 3.2.1
+-------------
+- M?P: Fixed Zeta 2 FDD and CPUSPD config settings
+- WBW: Fixed SURVEY.COM (again)
+- DDW: Updates to DOS/65 binaries in disk images
+- PMS: Updates to VGMPLAY including support for YM2151
+- WBW: Fix for quark delay adjustment being trashed
+
+Version 3.2
+-----------
+- WBW: Version bump for release
+
+Version 3.1.1
+-------------
+- WBW: Version bumped due to pervasive changes
+- WBW: Preliminary hard disk partition support (backward compatible)
+- WBW: Change Propeller VGA signal timings to 60Hz refresh
+- WBW: Enhanced SYSTEM RESET function to allow a warm start back to boot loader
+- C?O: Add DUART driver
+- WBW: Early Z280 support (requires 512K RAM/ROM board)
+- HCS: ZRC memory manager support
+- S?K: Support for Tiny Z80 by Sergey
+- E?B: Support for v6 YM/AY sound card
+- C?M: Support for RCBus bus PropIO V2
+- W?S: Updated FLASH software to v1.3.4
+- PMS: Preliminary support for writing to FLASH ROMs
+- PMS: Creation of process to update ROM system area w/o updating ROM disk contents
+- PMS: Added "updater.asm" which allows uploading and updating ROM in one step
+- WBW: Support for Z280 w/ native memory and interrupt mode 3
+- WBW: Support for Z280 UART (interrupt driven only in interrupt mode 3)
+- WBW: Add support Z80-512K (watchdog and LED)
+- WBW: Add support for ZZ80MB address map
+- PLS: Add support for Z180 invalid opcode trap
+- WBW: Add support for ZZRCC
+- WBW: Allow selection of RAM/ROM disk individually in build
+- WBW: Support 256KB ROM size
+- WBW: CP/M 3 RTC support is now complete (reads and writes RTC date/time)
+- WBW: Add config to allow swapping logical order of MT011 SPI ports
+- WBW: COPY.COM updated from v1.72 -> v1.73 throughout distribution
+- D?M: CP/NET for CP/M 2.2 and CP/M 3 (requires MT011)
+- D?M: SD driver fixes for MT011
+- J?C: Added FIND application from Jay Cotton
+- PMS: Preliminary support for I2C-based DS1307 clock
+- WBW: FD driver auto hardware detect (thanks Alan Cox)
+- D?N: Added support for TMS V9958 VDU
+- D?N: Added support for MSX keyboard
+- D?N: Added support for RP5C01 RTC
+- L?N: Slightly enhanced ZCPRD&J w/ a couple bug fixes
+- L?N: UNZIPZ4 which handles most modern ZIP file compression algorithms
+- AJL: Preliminary support for MBC systems
+- WBW: Added preliminary support for DSKYng
+- WBW: Elevated MBC to a platform
+- WBW: Added support for MBC user LEDs
+- PMS: Early DMA support
+- W?S: Updated FLASH software to v1.3.5 (supports 128KB A29010B, 512KB A29040B)
+- DDW: Support for DSKYng capabitlities
+- WBW: Added Phil Summers' ROM Updater into ROM Loader
+- AJL: Added ramtest app (requires SBC and MBC for now)
+- L?N: Provided SCOPY, XSUB01, and EX applications
+- WBW: Added support for MBC FDC to FDU application
+- WBW: Added support for MBC FDC to HBIOS
+- WBW: Refactored make process
+- WBW: Added ROM verification to boot process
+- WBW: Added Z80 instruction test apps to user area 5 in CP/M & ZSDOS
+- WBW: Add support for LINC sound card
+- WBW: Add interrupt receive support to UART driver
+- PMS: Add XModem transfer within Debug Monitor
+- PMS & AJL: Add DMAMON test application
+- PMS: Add ZMP adaptation
+- LWN: Substantial BPBIOS cleanup
+- AJL: Add ZMD adaptation
+- D?T: Substantial update to TastyBasic incuding a .COM executable
+- PMS: Added VGM audio file player
+- WBW: ZPMLDR and ZPM3 fixes, credit to Lars Nelson for finding ZPM3 source!
+- DDW: Add support for MBC sound card
+- WBW: Add support for "romless" booting
+- L?N: Fixes for ZCPR-D&J (buffer overflow, default drive/user)
+- J?P: Add support for DS1501 RTC
+- LLS: Added a user defined mode for SD Card interfaces (not complete)
+- L?N: Updated ZDE to v1.8 including time stamp preservation fixes
+- D?M: Minor update to CP/NET client files, fix to CPNBOOT
+- WBW: Added p-System IV.0 Z80 implementation
+- WBW: Hacked SURVEY to work around bank switching crash
+
+Version 3.1
+-----------
+- WBW: Refactored ROM Loader
+- WBW: INTRTC periodic timer based clock
+- WBW: FDISK80 updated to allow reserving up to 256 slices
+- WBW: Added support dual 16C550 UART on RCBus platform
+- WBW: Made .com images smaller (contain only Z-System now)
+- WBW: Support automatic clock hardware detection and fallback
+- WBW: Support use of CTC for SIO baud rate divisors
+- WBW: Updated IDE and PPIDE drivers to improve old CF Card compatibility
+- WBW: Support TIMER mode in CTC driver
+- DEN: Added sound driver support
+- DEN: Added SN76489 sound chip driver
+- M?O: RomWBW Disk Catalog document
+- DEN: Updated TMS to optionally trigger SYSTIMER interrupt (TMSTIMENABLE)
+- J?M: Updated KERMIT applications with VT100 terminal support
+- A?C: Added support for EPFDC
+- PMS: Added AY driver with new sound API support
+- DEN: Allow immediate autoboot startup
+- DEN: Support for floppy device count parameter
+
+Version 3.0.1
+-------------
+- WBW: Increase XModem timeout waiting for host to start sending
+- WBW: Update TMS driver to dynamically increase Z180 I/O W/S inside driver
+- MJS: Update CLRDIR for CP/M 3 compatibility
+- WBW: Corrected cursor on/off esc sequence in pre-configured ZDE
+- WBW: Fix automatic CRT console switching under CP/M 3 and ZPM3
+- WBW: DSRTC driver now correctly returns an error if there is no RTC present
+
+Version 3.0.0
+-------------
+- WBW: v2.9.2 -> 3.0 version upgrade due to scope of changes
+
+Version 2.9.2
+-------------
+- PMS: Fixed DS1210-related issue resulting in "Invalid BIOS" errors
+- SCC: Support for SC126 motherboard
+- WBW: Enable Auto-CTS/DCD in SIO driver for pacing output data
+- WBW: Support missing pull-up resistors on SPI SD adapter boards (common)
+- WBW: Support two SIO modules w/ auto-detection
+- PMS: Support ECB USB-FIFO board
+- WBW: Fixed ASSIGN issue with incorrect DPB selection
+- WBW: Add RCBus Z180 AY sound support to TUNE app
+- WBW: Add RCBus AY sound support to AY driver
+- WBW: Add SC126 platform
+- WBW: Config files cleanup
+- WBW: Add interrupt support to ASCI driver
+- WBW: Refactored XModem overlay, merged USB-FIFO support
+- PMS: Added DS1210 low battery detection/message
+- PMS: Added note playing ability to SPK driver
+- WBW: Support disk I/O to any memory bank
+- WBW: Fix floppy I/O error on slow CPUs w/ ints active (credit Jorge Rodrigues)
+- WBW: Support for KIO chip (based on board by Tom Szolyga)
+- N?B: Made ZCAL Y2K compliant
+- WBW: Show disk activity on diagnostic LEDs
+- WBW: DSRTC now detects DS-1302 presence dynamically
+- WBW: SC126 platform renamed to SCZ180 w/ configs for SC126, SC130
+- WBW: Add status LED support
+- WBW: Add support for secondry SPI (SD Card) on SC126
+- PMS: Add sound support to NASCOM BASIC
+- WBW: Updated FAT to add MD and FORMAT commands
+- WBW: Add CP/M 3 (experimental)
+- M?T: Support Shift register SPI WIZNET for RCBus
+- PLS: Added seconds register in HBIOS
+- WBW: More flexible table-driven config in TUNE.COM
+- PMS: Added timer support for Zilog Peripherals ECB Board
+- PLS: Enhanced Intel Hex Load in dbgmon
+- WBW: Overhaul disk image creation
+- WBW: Added support for Dyno platform (based on work by Steve Garcia)
+- SLG: Added support for BQ4845 RTC (bqrtc.asm)
+- PMS: Added 80x30 video mode to VGA3 driver
+- PMS: Added 80x43 video mode
+- PMS: Added font compression option
+- PMS: Added a "safe mode" startup w/ minimal device support
+- WBW: Switch RC/SC Z180 platforms to 115,200 default baud rate
+- PMS: Enhanced PPIDE driver to handle multiple PPI interfaces
+- PMS: Added a ROM based game
+- WBW: Only assign drive letters to hard disk devices with media
+- WBW: Enhanced IDE driver to handle multiple IDE interfaces
+- D?R: Contributed SC126 How-To: Preparing a MicroSD Card to Transfer Files to/from a Linux System
+- PMS: Updated romldr to handle more than 9 drives
+- PMS: Added "user" rom module template
+- PMS: Added CP/M 3 manuals
+- WBW: Boot from any slice
+- C?M: Added Unix build process
+- PLS: FreeRTOS compatibility
+- WWB: Removed OSLDR application (can't handle new OSes)
+
+Version 2.9.1
+-------------
+- E?B: Added support for RCBus RTC
+- WBW: Converted PTXPLAY to TUNE (now plays PT2/PT3/MYM sounds files)
+- WBW: Updated Win32DiskImager to v1.0
+- WBW: Implemented character attributes on Propeller based consoles
+- MS:  Added support for BEL function in Propeller based consoles
+- WBW: Support additional escape sequences in Propeller console ANSI emulation
+- WBW: Map LPT: to second serial port, UL1: to third serial port
+- WBW: Update default IOBYTE so that LST:=LPT: by default
+- WBW: Fixed missing drive/head setup for writes in PPIDE
+- WBW: Fixed XModem HBIOS console driver for file send operations
+- WBW: Preliminary support for RC180 platform (Z180 module in RCBus)
+- WBW: Added NZCOM distribution files to third slice of hard disk image
+- WBW: Fixed getnum32 bug in MODE command (found by Phil Summers)
+- PMS: Added serial support for Zilog Peripherals Baord
+- WBW: Added preliminary support for interrupt management API
+- PMS: Improved boot messages in RAM-Floppy driver
+- PMS: Added charge setting display to RTC boot messages
+- WBW: Add SmallZ80 support to FDU
+- WBW: Refactored Debug Monitor w/ improved syntax parsing and help
+- PMS: Added Forth, Nascom BASIC, and Tasty BASIC to ROM
+- PMS: Refactored ROM Loader to support more ROM images, now table driven
+- WBW: Refactored DSKY code
+- S?K:  Initial support for Easy Z80
+- PMS: Enhance VDU driver to support alternative screen dimensions
+- WBW: DDT and DDTZ modified to use RST 30 instead of RST 38 to avoid conflicts with IM 1 interrupts
+- WBW: Added timer interrupt support for CTC under Zeta 2 and Easy Z80
+- WBW: Support LBA style access in floppy driver
+- WBW: Added beta version of FAT filesystem utility (copy, dir, del, ren)
+- SCC: Added support for native memory addressing on Z180-based RCBus
+- PMS: Dynamically discover and display processor type at boot
+- J?L: Added German keyboard support to PPK and KBD drivers
+
+Version 2.9.0
+-------------
+- WBW: Implemented multi-sector I/O in all disk drivers
+- WBW: Added support for RCBus SMB Floppy controller modules (SMC and WDC)
+- WBW: New function dispatching for character/disk/video drivers
+- WBW: Updated FDU app to support RCBus floppy controllers
+- WBW: Added TIMER app to display system timer value
+- WBW: Refactored interrupt management code
+- WBW: Added PTXPLAY application and sample tunes
+
+Version 2.8.6
+-------------
+- WBW: Added support for RCBus (SIO and ACIA drivers primarily)
+- WBW: Automatically detect and run PROFILE.SUB on boot drive if it exists
+- WBW: Fixed Dual SD Board detection
+- WBW: Added console support to XModem (for RCBus primarily)
+- E?B: Fixed IDE/PPIDE when used with non-CF drives
+- WBW: Patched SUBMIT.COM so that it always puts temp file on A: for immediate execution
+- WBW: Accommodate spin up time for true IDE hard disks (IDE or PPIDE)
+
+Version 2.8.5
+-------------
+- WBW: Cleaned up support in TMS driver for SCG board
+
+Version 2.8.4
+-------------
+- WBW: FD.COM renamed to FDU.COM and integrated with build
+- WBW: FDU.COM enhanced to select FDC hardare at startup to
+       eliminate multiple versions.
+
+Version 2.8.3
+-------------
+- WBW: Added MODE command
+- WBW: Removed obsolete 1200.COM, 9600.COM, and 38400.COM
+- WBW: New XM.COM that automatically adapts to primary port of platform
+- WBW: XM.COM now handles 38400 baud at 4MHz
+- WBW: Removed obsolete XM versions: XM5.COM, XM-A0.COM, XM-A1.COM
+
+Version 2.8.2
+-------------
+- WBW: Adjusted VGA3 register setup per John's recommendations
+
+Version 2.8.1
+-------------
+- WBW: Fix FDISK80
+- WBW: Upgrade to latest production UNA 2.1-45
+
+Version 2.8.0
+-------------
+- WBW: Add support for VGA3 board
+
+Version 2.7.1
+-------------
+- WBW: Replace ZX with XP compatible build (no functional changes)
+- WBW: Reset BDOS serial number on warm start
+- WBW: Turn off DRAM refresh on Z180 (fixes Z180 CPU speed detection)
+
+Version 2.7.0
+-------------
+- WBW: Memory page reorganization
+- WBW: Support for Zeta 2 (from Sergey Kiselev)
+- WBW: Support loading from image file (UNA FSFAT)
+- WBW: Dynamic CPU speed detection
+
+Version 2.6.5
+-------------
+- WBW: Yet more DS1302 clock driver delay mods
+
+Version 2.6.4
+-------------
+- WBW: Yet more DS1302 clock driver delay mods
+
+Version 2.6.3
 -------------
 - WBW: DS1302 clock driver modified to observe proper delays
 
@@ -94,7 +532,7 @@ Version 2.0
 - DWG: Entire new suite of Apps written in Aztec C
 - DWG:   BANKER.COM - displays bank identification and version information
 - DWG:   CPMNAME.COM - displays CBIOS header data and SYSCFG data, names and vaues
-- DWG:   CHARS.COM - displays ascii map as reference 
+- DWG:   CHARS.COM - displays ascii map as reference
 - DWG:   CLS.COM - clears screen
 - DWG:   LABEL.COM - displays and changes drive labels for drives with reserved tracks
 - DWG:   MAP.COM - like old map command, displays drives and logical unit labels and changes LU values
@@ -126,7 +564,7 @@ Version 1.5.1
 - WBW: Added ZSDOS clock drivers (see Support\Clock)
 - WBW: Overhaul of ZSystem ROM Disk (see Doc\ZSystem.txt)
 - WBW: Update PropIO ANSI emulation for compatiblity with ASSIGN
-- DWG: Added version tags to all applications, and IDENT program to 
+- DWG: Added version tags to all applications, and IDENT program to
        check version of utilities.
 - DWG: Added MULTIFMT program which prepares new media for use by
        initializing the metadata and clearing the directory sectors of
@@ -136,8 +574,8 @@ Version 1.5.1
 - DWG: ANALYSE and HELLO programs removed from ROM due space concerns
 - DWG: Additional macro librarties added supporting program identification
        (IDENTITY.LIB/ASM) and access to drive metadata (METADATA.LIB/ASM),
-       and realtime selection of logical units from within new application 
-       programs (LOGICALS.LIB/ASM). 
+       and realtime selection of logical units from within new application
+       programs (LOGICALS.LIB/ASM).
 - DWG: Added TERM_VT52 for VDU compatbility, all apps now compliant
 - DGG: Contributed Linux build (see Doc\BuildLinux.txt)
 
@@ -165,7 +603,7 @@ Version 1.4
 - DWG: Add various .SUB files used for application maintenance
 - DWG: Enhanced utility building .SUB files to only contain libs utilitized
 - DWG: Add BUILD.SUB to build all applications and DEVFILES.LBR
-- DWG: Add/update RMAC macro libraries used in Apps - 
+- DWG: Add/update RMAC macro libraries used in Apps -
 - DWG:	 BIOSHDR, STDLIB, STRCPY, STRLEN, CPMBIOS, CPMBDOS, TERMINAL, HARDWARE,
 - DWG:   CPMAPPL, GLOBALS, ATOI, LUBIND, APPLVERS, MEMORY(memcpy,memset), PORTAB
 - DWG: Add/Repair BIOS support for Boot Drive login during CP/M Coldstart
@@ -184,7 +622,7 @@ Version 1.4
 - DWG: Add LABEL utility to insert label into drive/slice metadata
 - DWG: Add 16 char label field to metadata
 - DWG: ASSIGN utility displays and manipulates DPH/DPB & logical unit parameters
-- DWG/WBW: Collaborated on design of Logical Unit DPH enhancemnt 
+- DWG/WBW: Collaborated on design of Logical Unit DPH enhancemnt
 - WBW: Proposed MAP utility functionality
 - WBW: Implement slice selection API for DSK devices
 - WBW: Record boot drive in config memory at load time
@@ -322,4 +760,4 @@ interrupts disabled the BIOS will now start OK even if some vagrant
 hardware is asserting an interrupt (DISKIO).  Seems like this is better
 anyway -- general idea is that we only enable interupts precisely
 when desired for very specific controled purposes since there is no
-concept of interrupt dispatching available.
+concept of interrupt dispatching available.

Doc/Contrib/PPI_Bus.txt

@@ -0,0 +1,39 @@
+
+PPI Signal	PPIDE		PPISD		DSKY		DSKYNG (PROTO)	DSKYNG (FINAL)
+----------	-----		-----		-----		-----		-----
+PA0		<>D0				>ID0		<>D0		<>D0
+PA1		<>D1                            >ID1		<>D1		<>D1
+PA2		<>D2                            >ID2		<>D2		<>D2
+PA3		<>D3                            >ID3		<>D3		<>D3
+PA4		<>D4                            >ID4 /SHUTDOWN	<>D4		<>D4
+PA5		<>D5                            >ID5 /DECODE	<>D5		<>D5
+PA6		<>D6                            >ID6 HEXA/CODEB	<>D6		<>D6
+PA7		<>D7                            >ID7 DAT_COMING	<>D7		<>D7
+
+PB0		<>D8				+<ROW5                          
+PB1             <>D9				+<ROW4                          
+PB2             <>D10				+<ROW3                          
+PB3             <>D11				+<ROW2                          
+PB4             <>D12                           +<ROW1                          
+PB5             <>D13                           +<ROW0                          
+PB6             <>D14				+                               
+PB7             <>D15		<MISO		+                               
+
+PC0		>DA0		>MOSI		>COL0		>A0		>A0
+PC1		>DA1		>CLK		>COL1           		>/WR                
+PC2		>DA2				>COL2           		>/RD                
+PC3		>CS0*				>COL3		>CS&*		>CS&*
+PC4		>CS1*		>/CS				>CS&*		>CS&*
+PC5		>DIOW*						>/WR
+PC6		>DIOR*				>/WR		>/RD
+PC7		>RESET*				>MODE		>RESET		>RESET
+
+* Inverted by adapter
++ Pullup
+& Both signals must be asserted
+
+Compatibility:
+
+- PPISD & DSKY
+- PPIDE & DSKYNG
+- PPISD & DSKYNG

Doc/Contrib/ZSystem.txt

@@ -1,4 +1,10 @@
-This file is a log of the work done to adapt the ZSDOS distribution to the N8VEM platforms under RomWBW.  I strongly recommend reviewing the zsdos.pdf file in the Doc directory.
+ZSDOS Adaptation Notes for RomWBW
+---------------------------------
+
+Wayne Warthen
+wwarthen@gmail.com
+
+This file is a log of the work done to adapt the ZSDOS distribution to the N8VEM platforms under RomWBW.  I strongly recommend reviewing the zsdos.pdf file in the Doc/CPM directory.
 
 The starting point was the general public release of ZSDOS that is generally available.  The first line of the README file is "ZSDOS-GP.  General Public Release of the ZSDOS 1.x Operating System."
 
@@ -14,7 +20,7 @@ Beyond the construction and integration of the actual DOS itself, the majority o
 
 The remainder of this document details the changes I made as I went along.  In all cases, my goal was to keep the result as close to the original distribution as possible.  I started by copying all of the files from the distribution (contained in zsdos2.zip) into Support\ZSDOS.  From there I tested, modified, updated, and customized as documented below.  Finally, I cherry picked files that made sense to include on the ZSystem ROM disks.
 
-1. CLOCKS.DAT has been updated to include the N8VEM clock drivers, N8VEMCLK AND N8CLK.  I have also added the SIMHCLOK clock driver.
+1. CLOCKS.DAT has been updated to include the RomWBW clock driver, WBWCLK.  I have also added the SIMHCLOK clock driver.
 
 2. STAMPS.DAT has been replaced with an updated version.  The update was called STAMPS11.DAT and was found on the Walnut Creek CP/M CDROM.  The original version has a bug that prevents RSX (resident system extension) mode to load properly.
 
@@ -26,6 +32,8 @@ The remainder of this document details the changes I made as I went along.  In a
 
 6. Updated FILEATTR to v1.6A.  Original FILEATTR.CFG was invalid.  FILEATTR.CFG replaced with FA16.CFG.  Added associated files FA16.DOC, FA16A.FOR, FA16CFG.TXT.
 
+7. ZCAL patched to be Y2K compliant.  Contributed by Nick Brok.
+
 
 Usage Notes
 -----------
@@ -44,4 +52,4 @@ Usage Notes
 
 6. After using PUTDS to initialize a directory for ZDS date stamping, I am finding that it is necessary to run RELOG before the stamping routines will actually start working.
 
-7. Generic CP/M PIP and ZSDOS path searching do not play well together if you use PIP to copy to or from a directory in the ZSDOS search path.  Best to use COPY from the ZSDOS distribution.
+7. Generic CP/M PIP and ZSDOS path searching do not play well together if you use PIP to copy to or from a directory in the ZSDOS search path.  Best to use COPY from the ZSDOS distribution.

Doc/FdTst.txt

@@ -1,429 +0,0 @@
-================================================================
-FDTST v3.1 for N8VEM DISKIO / DISKIO V3  / ZETA / DIDE / N8
-================================================================
-
-Updated JuLY 1, 2012
-by Wayne Warthen (wwarthen@gmail.com)
-
-Application to test the hardware functionality of the Floppy Disk
-Controller (FDC) on the ECB DISK I/O, DISK I/O V3, ZETA SBC, 
-Dual IDE w/ Floppy, or N8 board.
-
-The intent is to provide a testbed that allows direct testing
-of all possible media types and modes of access.  The application
-supports read, write, and format by sector, track, and disk as
-well as a random read/write test.
-
-The application supports access modes of polling, interrupt, 
-INT/WAIT, and DRQ/WAIT.  At present, it supports 3.5" media at DD (720KB) and
-HD (1.44MB) capacities.  It also now supports 5.25" media (720KB and 1.2MB)
-and 8" media (1.11MB) as well.   Additonal media will be added when I have
-time and access to required hardware.  Not all modes are supported
-on all platforms and some modes are experimental in all cases.
-
-In many ways this application is merely reinventing the wheel and
-performs functionality similer to existing applications, but I have
-not seen any other applications for DISK I/O that provide this range
-of functionality.
-
-While the application is now almost entirely new code, I would like to
-acknowledge that much was derived from the previous work of Andrew Lynch
-and Dan Werner.  I also want to credit Sergio Gimenez with testing the 5.25"
-drive support and Jim Harre with testing the 8" drive support.  Thanks!
-
-General Usage
--------------
-
-In general, usage is self explanatory.  The main menu allows you to set
-the unit, media, and mode to test.  These settings MUST match your
-situation.  Read, write, format, and verify functions are provided.  A sub-menu
-will allow you to choose sector, track, disk, or random tests.
-
-The verify function requires a little explanation.  It will take the contents
-of the buffer, save it, and compare it to the selected sectors.  So, you
-must ensure that the sectors to be verified already have been written
-with the same pattern as the buffer contains.  I typically init the buffer
-to a pattern, write the pattern to the entire disk, then verify the entire
-disk.
-
-Another submenu is provided for FDC commands.  This sub-menu allows you to
-send low-level commands directly to FDC.  You MUST know what you are doing
-to use this sub-menu.  For example, in order to read a sector using this
-sub-menu, you will need to perform specify, seek, sense int, and read 
-commands specifying correct values (nothing is value checked in this menu).
-
-Required Hardware/BIOS
-----------------------
-
-Of course, the starting point is one of the support hardware platforms.
-You need to start with either an N8VEM SBC, backplane, and ECB DISK I/O
-card or a Zeta SBC.  Additionally, a floppy drive connected via an
-appropriate cable:
-
-DISKIO - no twist in cable, drive unit 0/1 must be selected by jumper on drive
-ZETA - cable with twist, unit 0 after twist, unit 1 before twist
-DIDE/N8 - cable with twist, unit 0 before twist, unit 1 after twist
-
-
-It is preferable that the BIOS you use does not have DISK I/O support
-enabled since the application assumes it has complete control of the
-DISK I/O hardware.
-
-The DISK I/O should be jumpered as follows:
-
-J1: depends on use of interrupt modes (see interrupt modes below)
-J2: pins 1-2, & 3-4 jumpered
-J3: hardware dependent timing for DMA mode (see DMA modes below)
-J4: pins 2-3 jumpered
-J5: off
-J6: pins 2-3 jumpered
-J7: pins 2-3 jumpered
-J8: off
-J9: off
-J10: off
-J11: off
-J12: off
-
-Note that J1 can be left on even when not using interrupt modes.  As
-long as the BIOS is OK with it, that is fine.  Note also that J3 is
-only relevant for DMA modes, but also can be left in place when
-using other modes.
-
-The DISK I/O V3 should be jumpered at the default settings:
-
-JP2: 3-4
-JP3: 1-2 for int mode support, otherwise no jumper
-JP4: 1-2, 3-4
-JP5: 1-2
-JP6: 1-2
-JP7: 1-2, 3-4
-
-Zeta does not have any relevant jumper settings.
-
-DIDE should be jumpered as follows:
-
-K3 (DT/R or /RD): /RD
-P5 (bd ID): 1-2, 3-4 (for $20-$3F port range)
-
-There are no specific N8 jumper settings, but the default
-I/O range starting at $80 is assumed in the published code.
-
-
-Modes of Operation
-------------------
-
-You can select the following test modes.  Please refer to the chart
-that follows to determine which modes should work with combinations
-of Z80 CPU speed and media format.
-
-Polling: Traditional polled input/output.  Works well and very reliable
-including timeouts and good error recovery.  Also, the slowest performance
-which precludes it from being used with 1.44MB floppy on a 4MHz Z80.
-This is definitely the mode you want to get working before any others.
-It does not require J1 (interrupt enable) on DISK I/O and does not care about
-the setting of J3.
-
-Interrupt: Input/output is interrupt driven.  Works pretty well, but
-is not able to recover from some errors.  For example, if there is
-no disk in the drive, this mode will just hang until a disk is inserted.
-This mode REQUIRES that interrupts be enabled on the DISK I/O via
-jumper at J1.  On Zeta it requires the INT/NMI jumper be set for
-INT.  Mode not supported on DIDE or N8.  Some BIOS variants will not 
-handle interrupts during boot.
-
-Fast Interrupt: As above, but sacrifices additional reliability for
-faster operation.  This mode will allow a 1.44MB floppy to work
-with a 4MHz Z80 CPU.  However, if any errors occur (even a transient
-read error which is not unusual), this mode will hang.  As above
-you MUST have the appropriate jumpers for DISKIO and Zeta.  DIDE
-does not support this mode.
-
-INT/WAIT: Same as Fast Interrupt, but uses CPU wait instead of
-actual interrupt.  Subject to all the same issues as Fast
-Interrupt, but does not need J1 shorted.  J3 is irrelevant.
-This mode is available on only on DISKIO (and not DISKIO V3).
-
-DRQ/WAIT: Uses pseudo DMA to handle input/output.  Does not require that
-interrupts (J1) be enabled on the DISK I/O.  However, it is subject to
-all of the same reliability issues as "Fast Interrupt".  This
-mode is known to not work on N8VEM DISKIO!!!  It is included
-for testing only.  It is dependent on setting of J3.  This
-mode is NOT available on Zeta, DIDE, N8, or DISKIO V3.
-
-The chart below attempts to describe the combinations that
-work for me.  By far, the most reliable mode is Polling,
-but it requires 8MHz CPU for HD disks.
-
-DRQ/WAIT --------------------------------+
-INT/WAIT -----------------------------+  |
-Fast Interrupt --------------------+  |  |
-Interrupt ----------------------+  |  |  |
-Polling ---------------------+  |  |  |  |
-                             |  |  |  |  |
-CPU Speed --------------+    |  |  |  |  |
-                        |    |  |  |  |  |
-                        |    |  |  |  |  |
-
-3.5" DD (720K) ------  4MHz  Y  Y  Y  Y  X
-                       8MHz+ Y  Y  Y  Y  X
-
-3.5" HD (1.44M) -----  4MHz  N  N  Y  Y  X
-                       8MHz+ Y  Y  Y  Y  X
-					   
-5.25" DD (360K) -----  4MHz  Y  Y  Y  Y  X
-                       8MHz+ Y  Y  Y  Y  X
-
-5.25" HD (1.2M) -----  4MHz  N  N  Y  Y  X
-                       8MHz+ Y  Y  Y  Y  X
-					   
-8" DD (1.11M) -------  4MHz  N  N  Y  Y  X
-                       8MHz+ Y  Y  Y  Y  X
-					   
-Y = Yes, works
-N = No, does not work
-X = Experimental, probably won't work
-
-Tracing
--------
-
-Command/result activity to/from the FDC will be written out
-if the trace setting is changed from '00' to '01' in setup.
-Additionally, if a command failure is detected on any
-command, that specific comand and results are written
-regardless of the trace setting.
-
-The format of the line written is:
-<OPERATION>: <COMMAND BYTES> --> <RESULT BYTES> [<RESULT>]
-
-For example, this is the output of a normal read operation:
-READ: 46 01 00 00 01 02 09 1B FF --> 01 00 00 00 00 02 02 [OK]
-
-Please refer to the i8272 data sheet for information on the
-command and result bytes.
-
-Note that the sense interrupt command can return a non-OK
-result.  This is completely normal in some cases.  It is
-necessary to "poll" the drive for seek status using
-sense interrupt.  If there is nothing to report, then
-the result will be INVALID COMMAND.  Additionally,
-during a recalibrate operation, it may be necessary to
-issue the command twice because the command will only step
-the drive 77 times looking for track 0, but the head may be
-up to 80 tracks away.  In this case, the first recalibrate
-fails, but the second should succeed.  Here is what this
-would look like if trace is turned on:
-
-RECALIBRATE: 07 01 --> <EMPTY> [OK]
-SENSE INTERRUPT: 08 --> 80 [INVALID COMMAND]
-	...
-	...
-	...
-SENSE INTERRUPT: 08 --> 80 [INVALID COMMAND]
-SENSE INTERRUPT: 08 --> 71 00 [ABNORMAL TERMINATION]
-RECALIBRATE: 07 01 --> <EMPTY> [OK]
-SENSE INTERRUPT: 08 --> 21 00 [OK]
-
-Another example is when the FDC has just been reset.  In
-this case, you will see up to 4 disk change errors.  Again
-these are not a real problem and to be expected.
-
-When tracing is turned off, the application tries to be
-intelligent about error reporting.  The specific errors
-from sense interrupt documented above will be suppressed
-because they are not a real problem.  All other
-errors will be displayed.
-
-Error Handling
---------------
-
-There is no automated error retry logic.  This is very
-intentional since the point is to expose the controller
-and drive activity.  Any error detected will result in 
-a prompt to abort, retry, or continue.  Note that some
-number of errors is considered normal for this
-technology.  An occasional error would not necessarily
-be considered a problem.
-
-CPU Speed
----------
-
-I distribute the binary version of the application optimized for
-20MHz CPUs.  There is a configuration variable called CPUFREQ
-at the top of the source file.  Ideally, you should build
-with that set appropriately.  However, I have found that the
-default build setting of 20MHz seems to work for 4-20MHz CPUs.
-
-Interleave
-----------
-
-The format command now allows the specification of a sector
-interleave.  It is almost always the case that the optimal
-interleave will be 2 (meaning 2:1).
-
-360K Media
-----------
-
-The 360K media definition should work well for true 360K
-drives.  However, it will generally not work
-with 1.2M drives.  This is because these drives spin at 360RPM
-instead of the 300RPM speed of true 360K drives.  Additionally,
-1.2M drives are 80 tracks and 360K drives are 40 tracks and, so
-far, there is no mechanism in FDTST to "double step" as a way
-to use 40 track media in 80 track drives.
-
-With this said, it is possible to configure some 1.2M 5.25" drives
-to automatically spin down to 300RPM based on a density select
-signal (DENSEL).  This signal is asserted by FDTST for 360K
-media, so IF you have configured your drive to react to this
-signal correctly, you will be able to use the 360K media defintion.
-Most 1.2M 5.25" drives are NOT configured this way by default.
-TEAC drives are generally easy to modify and have been tested by
-the author and do work in this manner.  Note that this does not 
-address the issue of double stepping above; you will just be 
-using the first 40 of 80 tracks.
-
-Support
--------
-
-I am happy to answer questions as fast and well as I am able.
-Best contact is wwarthen@gmail.com or post something on the
-N8VEM Google Group https://groups.google.com/forum/#!forum/n8vem.
-
-Changes
--------
-
-WW 8/12/2011
-
-Removed call to pulse TC in the FDC initialization
-after determining that it periodically caused the FDC to write
-bad sectors.  I am mystified by this, but definitely found it
-to be true.  Will revisit at some point -- probably a timing
-issue between puslsing TC and whatever happens next.
-
-Non-DMA mode was being set incorrectly for FAST-DMA mode.
-It was set for non-DMA even though we were doing DMA.  It is
-interesting that it worked fine anyway.  Fixed it anyway.
-
-DIO_SETMEDIA was not clearing DCD_DSKRDY as it should.  Fixed.
-
-WW 8/26/2011: v1.1
-
-Added support for Zeta.  Note that INT/WAIT and DRQ/WAIT are
-not available on Zeta.  Note that Zeta provides the ability
-to perform a reset of the FDC independent of a full CPU
-reset.  This is VERY useful and the FDC is reset anytime
-a drive reset is required.
-
-Added INT/WAIT support.
-
-WW 8/28/2011: V1.2
-
-All changes in this version are Zeta specific.  Fixed FDC reset
-logic and motor status display for Zeta (code from Sergey).
-
-Modified Zeta disk change display to include it in the
-command output line.  This makes more sense because a command
-must be issued to select the desired drive first.  You can
-use the SENSE INT command id you want to check the disk
-change value at any time.  It will also be displayed with
-any other command output display.
-
-WW 9/1/2011: V1.3
-
-Added CPUFREQ configuration setting to tune
-delays based on cpu speed.  The build app
-is set for 8MHz which also seems to work well
-for 4MHz CPU's.  Faster CPU speeds will
-probably require tuning this setting.
-
-WW 9/5/2011: V1.4
-
-Changed the polling execution routines to utilize CPUFREQ
-variable to optimize timeout counter.  Most importantly,
-this should allow the use of faster CPUs (like 20MHz).
-
-WW 9/19/2011: V1.5
-
-Zeta changes only.  Added a call to FDC RESET after any
-command failure.  This solves an issue where the drive
-remains selected if a command error occurs.  Also
-added FDC RESET to FDC CONTROL menu.
-
-WW 10/7/2011: V2.0
-
-Added support for DIDE.  Only supports polling IO and it
-does not appear any other modes are possible given the
-hardware constraints.
-
-WW 10/13/2011: V2.1
-
-Modified to support N8.  N8 is essentially identical to
-Dual IDE. The only real change is the IO addresses.  In
-theory, I should be able to support true DMA on N8 and
-will work on that.
-
-WW 10/20/2011: v2.2
-
-I had some problems with the results being read were
-sometimes missing a byte.  Fixed this by taking a more
-strict approach to watching the MSR for the exact
-bits that are expected.
-
-WW 10/22/2011: V2.3
-
-After spending a few days trying to track down an
-intermittent data corruption issue with my Dual IDE
-board, I added a verify function.  This helped
-me isolate the problem very nicely (turned out to
-be interference from the bus monitor).
-
-WW 11/25/2011: V2.4
-
-Preliminary support for DISKIO V3.  Basically just
-assumed that it operates just like the Zeta.  Needs
-to be verified with real hardware as soon as I can.
-
-WW 1/9/2012: V2.5
-
-Modified program termination to use CP/M reset
-call so that a warm start is done and all
-drives are logged out.  This is important
-because media may have been formatted during
-the program execution.
-
-WW 2/6/2012: v2.6
-
-Added support for 5.25" drives as tested by
-Sergio.
-
-WW 4/5/2012: v2.7
-
-Added support for 8" drives as tested by
-Jim Harre.
-
-WW 4/6/2012: v2.7a
-
-Fixed issue with media selection menu to remove
-duplicate entries.
-
-WW 4/8/2012: v2.7b
-
-Corrected the handling of the density select
-signal.
-
-WW 5/22/2012: v2.8
-
-Added new media definitions (5.25", 320K)
-
-WW 6/1/2012: v2.9
-
-Added interleave capability on format
-
-WW 6/5/2012: v3.0
-
-Documentation cleanup
-
-WW 7/1/2012: v3.1
-
-Modified head load time (HLT) for 8" media based on
-YD-180 spec.  Now set to 50ms.

Doc/Flash4.txt

@@ -1,169 +0,0 @@
-
-           FLASH4 (c) 2014 William R Sowerbutts <will@sowerbutts.com>
-                          http://sowerbutts.com/8bit/
-
-= Warning =
-
-FLASH4 has been tested and confirmed working on:
- * SBCv2
- * N8-2312
- * Mark IV SBC
-
-However it remains somewhat experimental. If it works for you, please let me
-know. If it breaks please also let me know so I can fix it! Until it is more
-widely tested please ensure you have some other means to reprogram your flash
-ROM before exclusively trusting FLASH4.
-
-
-= Introduction =
-
-FLASH4 is a CP/M program which can read, write and verify Flash ROM contents to
-or from an image file stored on a CP/M filesystem. It is intended for in-system
-programming of Flash ROM chips on N8VEM Z80 and Z180 systems.
-
-FLASH4 aims to support a range of Flash ROM chips. Ideally I would like to
-support all Flash ROM chips that are in use in Z80/Z180 N8VEM machines. If
-FLASH4 does not support your chip please let me know and I will try to add
-support.
-
-When writing to the Flash ROM chip, FLASH4 will only reprogram the sectors
-whose contents have changed. This helps to reduce wear on the flash memory,
-makes the reprogram operation faster, and reduces the risk of leaving the
-system unbootable if power fails during a reprogramming operation. FLASH4
-always performs a full verify operation after writing to the chip to confirm
-that the correct data has been loaded.
-
-FLASH4 is reasonably fast. Reprogramming and verifying every sector on a 512KB
-SST 39F040 chip takes 21 seconds on my Mark IV SBC, versus 45 seconds to
-perform the same task using a USB MiniPro TL866 EEPROM programmer under Linux
-on my PC. If only a subset of sectors require reprogramming FLASH4 will be
-even faster.
-
-FLASH4 works with binary ROM image files, it does not support Intel Hex format
-files. Hex files can be easily converted to or from binaries using "hex2bin" or
-the "srec_cat" program from SRecord:
-
-  $ srec_cat image.hex -intel -fill 0xFF 0 0x80000 -output image.bin -binary
-  $ srec_cat image.bin -binary -output image.hex -intel
-
-FLASH4 can use three different methods to access the Flash ROM chip. The best
-available method is determined automatically at run time. Alternatively you may
-provide a command-line option to force the use of a specific method.
-
-The first two methods use bank switching to map sections of the ROM into the
-CPU address space. FLASH4 will detect the presence of RomWBW or UNA BIOS and
-use the bank switching methods they provide.
-
-If neither RomWBW nor UNA BIOS is detected and the system has a Z180 CPU,
-FLASH4 will use the Z180 DMA engine to access the Flash ROM chip. This does not
-require any bank switching but it is slower and will not work on all platforms.
-
-Z180 DMA access requires the flash ROM to be linearly mapped into the lower
-region of physical memory, as it is on the Mark IV SBC. The N8-2312 has
-additional memory mapping hardware, consequently Z180 DMA access on the N8-2312
-is NOT SUPPORTED and if forced will corrupt the contents of RAM; use bank
-switched access instead.
-
-Z180 DMA access requires the Z180 CPU I/O base control register configured to
-locate the internal I/O addresses at 0x40 (ie ICR bits IOA7, IOA6 = 0, 1).
-
-
-= Usage =
-
-The three basic operations are:
-
-  FLASH4 WRITE filename [options]
-
-This will rewrite the flash ROM contents from the named file. The file size
-must exactly match the size of the ROM chip. After the write operation, a
-verify operation will be performed automatically.
-
-  FLASH4 VERIFY filename [options]
-
-This will read out the flash ROM contents and report if it matches the contents
-of the named file. The file size must exactly match the size of the ROM chip.
-
-  FLASH4 READ filename [options]
-
-This will read out the entire flash ROM contents and write it to the named
-file.
-
-If your ROM chip is larger than the image you wish to write, use the "/PARTIAL"
-(or "/P") command line option. To avoid accidentally flashing the wrong file,
-the image file must be an exact multiple of 32KB in length. The portion of the
-ROM not occupied by the image file is left either unmodified or erased.
-
-One of the following optional command line arguments may be specified at the
-end of the command line to force FLASH4 to use a particular method to access
-the flash ROM chip:
-
-  /ROMWBW
-  /UNABIOS
-  /Z180DMA
-
-If no option is specified FLASH4 attempts to determine the best available
-method automatically.
-
-
-= Supported chips and features =
-
-FLASH4 will interrogate your flash ROM chip to identify it automatically.
-FLASH4 assumes that you have a single flash ROM device and it is located at the
-bottom of the physical memory map.
-
-FLASH4 does not support setting or resetting the protection bits on individual
-sectors within Flash ROM devices. If your Flash ROM chip has protected sectors
-you will need to unprotect them by other means before FLASH4 can erase and
-reprogram them.
-
-AT29C series chips employ an optional "software data protection" feature. This
-is supported by FLASH4 and is left activated after programming the chip to
-prevent accidental reprogramming of sectors.
-
-The following chips are supported:
-
-  AT29F010
-  AT29F040
-  M29F010
-  M29F040
-  MX29F040
-  SST 39F010
-  SST 39F020
-  SST 39F040
-  AT29C512
-  AT29C040
-  AT29C010
-  AT29C020
-
-The following chips are supported but have unequal sector sizes; FLASH4 will
-only erase and reprogram the entire chip at once rather than its normal
-sector-by-sector operation:
-
-  AT49F001NT
-  AT49F001N
-  AT49F002N
-  AT49F002NT
-  AT49F040
-
-If you use a flash ROM chip that is not listed above please email me
-(will@sowerbutts.com) and I will try to add support for it.
-
-
-= Compiling =
-
-The software is written in a mix of C and assembler. It builds using the SDCC
-toolchain and the SRecord tools. A Makefile is provided to build the executable
-in Linux and I imagine it can be easily modified to build in Windows.
-
-You may need to adjust the path to the SDCC libraries in the Makefile if your
-sdcc installation is not in /usr/local
-
-
-= License =
-
-FLASH4 is licensed under the The GNU General Public License version 3 (see
-included "LICENSE.txt" file). 
-
-FLASH4 is provided with NO WARRANTY. In no event will the author be liable for
-any damages. Use of this program is at your own risk. May cause rifts in space
-and time.

Doc/Language/HI-TECH Z80 C Compiler Messages.txt

@@ -0,0 +1,99 @@
+1	"dimension required"
+2	"functions can't return arrays"
+3	"functions can't return functions"
+4	"can't have array of functions"
+5	"argument redeclared: %s"
+6	"not an argument: %s"
+7	"undefined struct/union: %s"
+8	"can't have array of functions"
+9	"only functions may be void"
+10	"functions can't return arrays"
+11	"declarator too complex"
+12	"no identifier in declaration"
+13	"can't initialize arg"
+14	"argument redeclared: %s"
+15	"bad storage class"
+16	"can't mix proto and non-proto args"
+17	"type specifier reqd. for proto arg"
+18	"can't initialise auto aggregates"
+19	"integer expression required"
+20	"undefined enum tag: %s"
+21	"integer constant expected"
+22	"bad bitfield type"
+23	"members cannot be functions"
+24	"struct/union redefined: %s"
+25	"can't be unsigned"
+26	"can't be short"
+27	"can't be long"
+28	"can't be register"
+29	"inconsistent type"
+30	"bad storage class"
+31	"storage class illegal"
+32	"inconsistent storage class"
+33	"illegal initialisation"
+34	"only register storage class allowed"
+35	"too much indirection"
+36	"argument list conflicts with prototype"
+37	"identifier redefined: %s"
+38	"not a label identifier: %s"
+39	"'case' not in switch"
+40	"'default' not in switch"
+41	"default case redefined"
+42	"inappropriate break/continue"
+43	"illegal type for switch expression"
+44	"inappropriate 'else'"
+45	"illegal initialisation"
+46	"initialisation syntax"
+47	"illegal initialisation"
+48	"%s expected"
+49	"close error (disk space?)"
+50	"digit out of range"
+51	"hex digit expected"
+52	"exponent expected"
+53	"'.' expected after '..'"
+54	"char const too long"
+55	"illegal character (0%o)"
+56	"illegal conversion"
+57	"logical type required"
+58	"type conflict"
+59	"simple type required for %.3s"
+60	"integral type required"
+61	"illegal use of void expression"
+62	"void function cannot return value"
+63	"pointer required"
+64	"only lvalues may be assigned to or modified"
+65	"can't take this address"
+66	"can't take address of register variable"
+67	"undefined struct/union: %s"
+68	"struct/union member expected"
+69	"struct/union required"
+70	"illegal type for index expression"
+71	"not a variable identifier: %s"
+72	"undefined identifier: %s"
+73	"expression syntax"
+74	"illegal type for array dimension"
+75	"constant expression required"
+76	"too few arguments"
+77	"too many arguments"
+78	"function does not take arguments"
+79	"float param coerced to double"
+80	"non-void function returns no value"
+81	"Unreachable code"
+82	"implicit return at end of non-void function"
+83	"Can't create xref file %s"
+84	"implicit conversion of float to integer"
+85	"illegal conversion between pointer types"
+86	"illegal conversion of pointer to integer"
+87	"illegal conversion of integer to pointer"
+88	"%s() declared implicit int"
+89	"operands of %.3s not same type"
+90	"operands of %.3s not same pointer type"
+91	"function or function pointer required"
+92	"Can't create xref file %s"
+93	"close error (disk space?)"
+94	"Can't reopen %s"
+95	"can't open %s"
+96	"illegal '#' directive"
+97	"EOF in #asm"
+98	"Too many cases in switch"
+99	"unexpected EOF"