ZPM3 Fixes

- Fixes to ZPMLDR to make it functional with RomWBW.
- Incorporate fixes from the Jon Saxton disassembly in ZPM3 itself.
- Credit to Lars Nelson for finding the ZPM3 source (disassembly).

Source/Doc/GettingStarted.md

@@ -850,12 +850,14 @@ ZPM3 is an interesting combination of the features of both CP/M 3 and
 ZCPR 3. Essentially, it has the features of and compatibility with
 both.
 
-Like CP/M 3, to make ZPM3 boot disk, you put CPMLDR.SYS on the system
+Like CP/M 3, to make ZPM3 boot disk, you put ZPMLDR.SYS on the system
 tracks of the disk.
 
 ### Notes
 
-- `ZPMLDR` is included with ZPM3, but it is not working correctly.
+- `ZPMLDR` is equivalent to CPMLDR.  Both are included.  Previously,
+ZPMLDR had issues that prevented it from properly booting RomWBW ZPM3.
+However, those issues have been resolved.
 
 - The ZPM operating system is contained in the file called CPM3.SYS
 which is confusing, but this is as intended by the ZPM3 distribution.

Source/Images/Build.cmd

@@ -21,7 +21,7 @@ call BuildDisk.cmd cpm22 wbw_hd512 ..\cpm22\cpm_wbw.sys || exit /b
 call BuildDisk.cmd zsdos wbw_hd512 ..\zsdos\zsys_wbw.sys || exit /b
 call BuildDisk.cmd nzcom wbw_hd512 ..\zsdos\zsys_wbw.sys || exit /b
 call BuildDisk.cmd cpm3 wbw_hd512 ..\cpm3\cpmldr.sys || exit /b
-call BuildDisk.cmd zpm3 wbw_hd512 ..\cpm3\cpmldr.sys || exit /b
+call BuildDisk.cmd zpm3 wbw_hd512 ..\zpm3\zpmldr.sys || exit /b
 call BuildDisk.cmd ws4 wbw_hd512 || exit /b
 
 if exist ..\BPBIOS\bpbio-ww.rel call BuildDisk.cmd bp wbw_hd512 || exit /b
@@ -37,7 +37,7 @@ call BuildDisk.cmd cpm22 wbw_hd1024 ..\cpm22\cpm_wbw.sys || exit /b
 call BuildDisk.cmd zsdos wbw_hd1024 ..\zsdos\zsys_wbw.sys || exit /b
 call BuildDisk.cmd nzcom wbw_hd1024 ..\zsdos\zsys_wbw.sys || exit /b
 call BuildDisk.cmd cpm3 wbw_hd1024 ..\cpm3\cpmldr.sys || exit /b
-call BuildDisk.cmd zpm3 wbw_hd1024 ..\cpm3\cpmldr.sys || exit /b
+call BuildDisk.cmd zpm3 wbw_hd1024 ..\zpm3\zpmldr.sys || exit /b
 call BuildDisk.cmd ws4 wbw_hd1024 || exit /b
 
 if exist ..\BPBIOS\bpbio-ww.rel call BuildDisk.cmd bp wbw_hd1024 || exit /b

Source/Images/Makefile

@@ -1,7 +1,7 @@
 #
 # this makefile subsumes all the work done in Build.cmd, BuildDisk.cmd, BuildDisk.ps1
 #
-SYSTEMS = ../CPM22/cpm_wbw.sys ../ZSDOS/zsys_wbw.sys ../CPM3/cpmldr.sys
+SYSTEMS = ../CPM22/cpm_wbw.sys ../ZSDOS/zsys_wbw.sys ../CPM3/cpmldr.sys ../ZPM3/zpmldr.sys
 
 FDIMGS = fd144_cpm22.img fd144_zsdos.img fd144_ws4.img
 HD512IMGS = hd512_cpm22.img hd512_zsdos.img hd512_nzcom.img \
@@ -71,7 +71,8 @@ blankhd1024:
 	case $@ in \
 		(*cpm22*) sys=../CPM22/cpm_wbw.sys;; \
 		(*zsdos* | *nzcom*) sys=../ZSDOS/zsys_wbw.sys;; \
-		(*cpm3* | *zpm3*) sys=../CPM3/cpmldr.sys;; \
+		(*cpm3*) sys=../CPM3/cpmldr.sys;; \
+		(*zpm3*) sys=../ZPM3/zpmldr.sys;; \
 	esac ; \
 	if echo $@ | grep -q ^fd144_ ; then \
 		fmt=wbw_fd144 ; type=fd144_ ; proto=blank144 ; \

Source/Images/d_zpm3/u0/ROMWBW.TXT

@@ -6,9 +6,10 @@ boot directly into ZPM3 by choosing the ZPM3 disk from the RomWBW
 loader prompt.  The ZPM3 disk must be bootable in this case.
 
 You may notice that there is a ZPMLDR application on the hard disk
-image.  This application is equivalent to CPMLDR, but it has some
-issues with the number of drives that RomWBW supports.  So, as
-indicated above, use CPMLDR to launch ZPM3.
+image.  This application is equivalent to CPMLDR.  It originally
+had some issues that prevented it from booting RomWBW properly,
+but those issues are now resolved (I think).  Either ZPMLDR or CPMLDR
+can be used to launch ZPM3.
 
 I have not found a way to make ZPM3 start up with any drive other
 than A: as the system drive.  So, during the load process, the boot

Source/ZPM3/Build.cmd

@@ -29,8 +29,10 @@ echo.
 echo *** ZPM Loader ***
 echo.
 zx LINK -ZPMLDRD[L100]=ZPM3LDR,BIOSLDRD,UTIL || exit /b
+:: zx SLRNK -ZPM3LDR,BIOSLDRD,UTIL,ZPMLDRD/N/E
 move /Y zpmldrd.com zpmldr.bin || exit /b
 zx LINK -ZPMLDRC[L100]=ZPM3LDR,BIOSLDRC,UTIL || exit /b
+:: zx SLRNK -ZPM3LDR,BIOSLDRC,UTIL,ZPMLDRC/N/E
 move /Y zpmldrc.com zpmldr.com || exit /b
 rem pause
 

Source/ZPM3/Notes.txt

@@ -0,0 +1,30 @@
+RESBDOS3.SPR and BNKBDOS3.SPR have been replaced
+with versions from the Jon Saxton disassembly with
+fixes distribution.  The file called zpm3fix.txt
+have been included and details the fixes.
+
+ZPMLDR has also been updated with the version from
+the Jon Saxton disassembly.  However, it has additionally
+been updated to correct an issue that was preventing
+RomWBW from booting under ZPMLDR.
+
+ZPMLDR has a slightly modified version of the rdSeq
+procedure (compared to CPMLDR).  It appears that this
+causes deblocking to be bypassed on the initial disk
+read of CPM3.SYS.  As a result, the entire disk sector
+(512 bytes) is read starting at 0x0080.  This winds up
+overlaying 0x180 bytes of the start of ZPMLDR.COM causing
+it to fail catastrophically.
+
+According to the documentation at the top of zpm3ldr.z80,
+zpmldr is normally loaded from system tracks to address
+0x0400.  In that scenario, the read of the entire sector
+would not overlay the start of the application.  So, I
+suspect this is why this (bug?) is not relevant to many
+implementations.
+
+The ZPM3LDR.REL file used here has been modified to
+sync the rdSeq procedure back to the DIR CPMLDR version.
+This seems to allow ZPMLDR to work with RomWBW now.
+
+--WBW  4:22 PM 12/8/2021

Source/ZPM3/zpm3fix.txt

@@ -0,0 +1,187 @@
+PATCHES TO SIMEON CRAN'S ZPM3
+=============================
+
+ZPM3 is a CP/M 3 workalike written by Simeon Cran.  It is readily available in
+binary form; just look for archives like zpm3n10.arc and similar.
+
+This patch contains updated BNKBDOS3.SPR and RESBDOS3.SPR files although it
+is only the banked portion which has been modified.
+
+Three changes have been implemented.
+
+1. BDOS function 152 (Parse file name) password bug
+===================================================
+
+The first change was to fix a bug identified by Tilmann Reh in the file name
+parser invoked by BDOS function 152.  Unlike the parser in standard CP/M 3,
+Simeon's version can deal with a user number.  The FCB which is filled in by
+the parser has the following structure where the field names are those shown
+in the CP/M 3 Programmer's Reference Manual:
+
+
+  Offset   Field   Length
+  ------   -----   ------
+     0       DR       1     Drive code (0 = current, 1 = A, ... 16 = P
+     1      NAME      8     File name
+     9      TYPE      3     File type (extension)
+    12       PM       1     Password mode
+    13       S1       1     Reserved
+    14       S2       1     Reserved
+    15       RC       1     Reserved (Result code)
+    16    PASSWORD    8     Password (encrypted)
+    24    RESERVED    8     Used by CP/M 3
+
+Now the RC field gets set to FFh if an error occurs during the parse but S1
+and S2 are not used at all by CP/M 3.  Simeon's parser uses those fields to
+store the user number (S1) and a copy of the DR field (S2) thus rendering the
+parser far more useful in that it can now handle names like
+
+	K12:TESSER.CAT
+
+and deliver a sensible result to a user program.
+
+None of this is useful to other CP/M 3 implementations and so most programs do
+their own parsing but the basic idea is commendable.  However Tilmann noticed
+that if a password is attached to a file then Simeon's parser puts it in the
+wrong place, overwriting the four fields PM through RC.
+
+It is probably not a critical issue; after all, how many CP/M 3 users bother
+to password-protect files?  Nevertheless it is clearly wrong and is fixed in
+this version of BNKBDOS3.SPR.
+
+2. BDOS function 152 (Parse file name) user/drive prefix
+========================================================
+
+A limitation of Simeon's parser is that it cannot handle the UD: (user, drive)
+prefix, only the DU: form.  That was annoying to me since I am just as likely
+to type 7g:tesser.cat as g7:tesser.cat.  My second patch was to fix ZPM3 to
+handle both the UD: and DU: prefix forms.
+
+I also put the drive number in the S2 field even when no drive was specified
+in the input string.  Assuming that the current drive is E and the current
+user number is 8 then the following results are obtained with the inputs
+shown:
+
+	Input string		DR    S1    S2
+	------------		--    --    --
+	FILE.EXT		 0     8     5
+	E:FILE.EXT		 5     8     5     
+	12:FILE.EXT		 0    12     5
+	G:FILE.EXT		 7     8     7
+	G12:FILE.EXT		 7    12     7
+	12G:FILE.EXT		 7    12     7
+
+The interesting cases shown above are the first and third.  Setting DR to zero
+is consistent with the way standard CP/M works and the setting of S2 is just
+extra information which may be of use to the calling program but which can
+be ignored.  Unfortunately it is not possible to do the same thing with the
+user number because standard CP/M does not have a field for that.
+
+3. BDOS function 152 (Parse file name) Clear target FCB
+=======================================================
+
+On 2013-09-05 a contributor to comp.os.cpm known only as "Ed" pointed out that
+there is yet another bug in BDOS 152 in that it does not clear the record
+number fields in the last four bytes of the FCB populated by the function.
+A program which uses the FCB for a read or write operation without first
+explicitly setting the fields will have the I/O operation start at some
+unexpected position in the file.
+
+This problem has also been fixed.
+
+4. Command line editing keys
+============================
+
+A couple of years ago I added code to yaze-ag (a Z80 emulator) to make it
+possible to use the cursor and function keys on a modern PC keyboard to do
+sensible things in CP/M.  The keyboard translations are specified in external
+text files and can be loaded dynamically from within CP/M.
+
+By far the most useful translate table maps the arrow keys to WordStar
+controls.  For example, pressing the up arrow key generates a ^E, pressing
+PgUp generates ^R and so on.  This works really well in most cases but there
+is one piece of software which gives problems, namely CP/M itself.
+
+Yaze-ag uses Simeon Cran's ZPM3 as a replacement for the CP/M 3 BDOS.  It was
+a good choice because ZPM3 offers more features than standard CP/M 3 and in
+particular, it provides a rich command history facility with decent recall and
+edit capabilities.
+
+As originally implemented, ZPM3 viewed the history as an upward-growing
+stack, i.e. with new lines being added at the top.  For example assume
+that lines comprising the single words "one", "two", "three", "four" and
+"five" are entered in sequence.  The history looks like this:
+
+	->			(current line, blank)
+		five		(newest)
+		four
+		three
+		two
+		one		(oldest)
+
+According to this view, the NEXT line in the history is the last one
+entered.  After ^W ^W ^W ^W (NEXT, NEXT, NEXT, NEXT) the view is like this:
+
+		two		(line ready for editing)
+		five		(newest)
+		four
+		three
+	->	two
+		one		(oldest)
+
+After ^E ^E (PREVIOUS, PREVIOUS) the view is:
+
+		four		(line ready for editing)
+		five		(newest)
+	->	four
+		three
+		two
+		one		(oldest)
+
+This is all very consistent.  The problem is that it is utterly counter-
+intuitive and the complete reverse of any recall and edit scheme in any
+other operating system.  For example, linux and Windows both view shell
+command history as a stack, but one which grows downwards.  The most
+recently entered command is the one conceptually ABOVE the current line.
+This view of the command history also corresponds to the way that we
+compose text, where new lines are added below the most recently added
+lines.
+
+Using the same five-line example as above, the initial view would be:
+
+		one		(oldest)
+		two
+		three
+		four
+		five		(newest)
+	->			(current line, blank)
+
+After UP, UP, UP, UP the view is:
+
+		one		(oldest)
+	->	two
+		three
+		four
+		five		(newest)
+		two		(line ready for editing)
+
+then DOWN, DOWN yields:
+
+		one		(oldest)
+		two
+		three
+	->	four
+		five		(newest)
+		four		(line ready for editing)
+
+Tilman Reh recognised this as a bug when he disassembled this ZPM3.
+It was fixed by cross-renaming the two routines NextLine and PreviousLine
+and for WordStar compatability the NextLine routine was moved to ^W.
+That meant the previous occupant of the ^W position, DeleteToLeft had to
+be moved also.  For no particularly good reason I chose to use the just-
+vacated ^X slot.
+
+Although I cannot imagine why one would want to do so, the original ZPM3
+behaviour can be recovered by setting the assembly-time switch "HistoryBug"
+to some odd number, e.g. 0FFFFh.
+

Source/ver.inc

@@ -2,4 +2,4 @@
 #DEFINE	RMN	1
 #DEFINE	RUP	1
 #DEFINE	RTP	0
-#DEFINE BIOSVER	"3.1.1-pre.142"
+#DEFINE BIOSVER	"3.1.1-pre.143"

Source/ver.lib

@@ -3,5 +3,5 @@ rmn	equ	1
 rup	equ	1
 rtp	equ	0
 biosver	macro
-	db	"3.1.1-pre.142"
+	db	"3.1.1-pre.143"
 	endm