mirror of https://github.com/wwarthen/RomWBW.git
Browse Source
- 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).pull/283/head
Wayne Warthen
4 years ago
23 changed files with 248 additions and 19 deletions
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -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 |
|||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -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. |
|||
|
|||
Binary file not shown.
Binary file not shown.
Loading…
Reference in new issue