mirror of
https://github.com/wwarthen/RomWBW.git
synced 2026-02-06 14:11:48 -06:00
* added hack to handle tunes * quiet clean * added chmod for execution * suppress warnings * Multi-boot fixes * the windows build somehow thinks that these filesystems are cpm3. * credit and primitive instructions * Update sd.asm Cosmetic fix. * make compile shut up about conditionals * Add bin2asm for linus and update build to process font files under linix * fixed quoted double quote bug, added tests * added tests * added bin2asm for font file source creation * Revert linux bin2asm font stuff * added rule for font source generation * build fonts * added directory mapping cache. if the same directory is being hit as last run, we don't need to rebuild the map. will likely break if you are running more than one at a time, in that the cache will be ineffective. also, if the directory contents change, this will also break. * removed strip. breaks osx * added directory tag so . isn't matched all over the place * added real cache validation * fixed build * this file is copied from optdsk.lib or optcmd.lib * install to ../HBIOS * prerequisite verbosity * diff soft failure and casefn speedup * added lzsa * added lzsa * removed strip. breaks on osx * added clobber * added code to handle multiple platform rom builds with rom size override * added align and 0x55 hex syntax * default to hd64180 * added N8 capability * added SBC_std.rom to default build * added support for binary diff * diff fixes * clean, identical build. font source generator emitted .align. this does not match the windows build * Upgrade NZCOM to latest * Misc. Cleanup * fixed expression parser bug : ~(1|2) returned 0xfe * added diff build option * Update Makefile Makefile enhancement to better handle ncurses library from Bob Dunlop. * Update sd.asm Back out hack for uz80as now that Curt fixed it. * Misc. Cleanup * UNA Catchup UNA support was lacking some of the more recent behavior changes. This corrects most of it. * Add github action for building RomWBW * Bump Pre-release Version * Update build.yml Added "make clean" which will remove temporary files without removing final binary outputs. * Update Makefile Build all ROM variants by default in Linux/Mac build. * Update Makefile * Update Makefile * Update Makefile * Update Makefile * Update Makefile * Update Makefile * Update Makefile * Update Makefile * Update Makefile * Update for GitHub Build Case issue in TASM includes showing up in GitHub build. This should correct that. * Added an gitignore files to exclude generated files * Removed Tunes/clean.cmd and Tunes/ReadMe.txt - as make clean removes them * Build.sh: marked as executable chmod +x Build.sh * Fix to HBIOS/build.sh When adding files to rom disk, if files were missing, it would error out. It appears the intent is to skip non-existing files. Updated to log out correctly for missing files - and continue operation. * Update Microsoft NASCOM BASIC.docx Nascom manual, text version by Jan S (full name unknown) * Fix issue with Apps/Tune not making If dest directory does not exist, fails to make Apps * Create ReadMe.txt * Update Makefile * Update Build.sh * Make .gitignores for Tools/unix more specific * cpmtools Update Updated cpmtools applications (Windows only). Removed hack in diskdefs that is no longer required. * HBIOS Proxy Temp Stack Enhancement Reuse the bounce buffer area as the temporary stack space required briefly in HBX_INVOKE when transitioning banks. Increases size of temporary stack space to 64 bytes. * Update ReadMe.txt * HBIOS - clean up TMPSTK * Update hbios.asm Minor cosmetic changes. * Build Process Updates Minor udpates to build process to improve consistency between Windows and Mac/Linux builds. * Update hbios.asm Add improved interrupt protection to HBIOS PEEK, POKE, and BNKCPY functions. * hbios - wrap hbx_bnkcpy * hbios - adjust hbx_peek hbx_poke guards * Update hbios.asm Adjusted used of DI/EI for PEEK and POKE to regain a bit of INTSTK space. Added code so that HB_INVBNK can be used as a flag indicating if HBIOS is active, $FF is inactive, anything else means active. * Add HBIOS MuTex * Initial Nascom basic ecb-vdu graphics set and reset for 80x25b screen with 256 character mod * Finalize Pre-release 34 Final support for FreeRTOS * Update nascom.asm Optimization, cleanup, tabs and white spaces * IDE & PPIDE Cleanup * Clean up Make version include files common. * Update Makefile * Update Makefile * Build Test * Build Test * Build Fixes * Update nascom.asm Cleanup * Update nascom.asm Optimization * hbios - temp stack tweak * Update hbios.asm Comments on HBX_BUF usage. * Update nascom.asm Optimization * Update nascom.asm Setup ECB-VDU build option, remove debug code * Update nascom.asm Set default build. update initialization * Update nascom.asm Make CLS clear vdu screen * Update nascom.asm Fixup top screen line not showing * Add SC131 Support Also cleaned up some ReadMe files. * HBIOS SCZ180 - remove mutex special files * HBIOS SCZ180 - adjust mutex comment * Misc. Cleanup Includes some minor improvements to contents in some disk images. * Delete FAT.COM Changing case of FAT.COM extension to lowercase. * Create FAT.com Completing change of case in extension of FAT.com. * Update Makefile Remove ROM variants that just have the HBIOS MUTEX enabled. Users can easily enable this in a custom build. * Cleanup Removed hack from Images Makefile. Fixed use of DEFSERCFG in various places. * GitHub CI Updates Adds automation of build and release assets upon release. * Prerelease 36 General cleanup * Build Script Cleanups * Config File Cleanups * Update RomWBW Architecture General refresh for v2.9.2 * Update vdu.asm Removed a hack in VDU driver that has existed for 8 years. :-) * Fix CONSOLE Constant Rename CIODEV_CONSOLE constant to CIO_CONSOLE because it is a unit code, not a device type code. Retabify TastyBasic. * Minor Bug Fixes - Disk assignment edge case - CP/M 3 accidental fall thru - Cosmetic updates * Update util.z80 * Documentation Cleanup * Documentation Update * Documentation Update * Documentation Updates * Documentation Updates * Create Common.inc * Documentation Updates * Documentation Updates * doc - a few random fixes * Documentation Cleanup * Fix IM 0 Build Error in ACIA * Documentation Updates * Documentation Cleanup * Remove OSLDR The OSLDR application was badly broken and almost impossible to fix with new expanded OS support. * Bug Fixes - Init RAM disk at boot under CP/M 3 - Fix ACR activation in TUNE * FD Motor Timeout - Made FDC motor timeout smaller and more consistent across different speed CPUs - Added "boot" messaging to RTC * Cleanup * Cleanup - Fix SuperZAP to work under NZCOM and ZPM3 - Finalize standard config files * Minor Changes - Slight change to ZAP configuration - Added ZSDOS.ZRL to NZCOM image * ZDE Upgrade - Upgraded ZDE 1.6 -> 1.6a * Config File Tuning * Pre-release for Testing * cfg - mutex consistent config language * Bump to Version 3.0 * Update SD Card How-To Thanks David! * update ReadMe.md Remove some odd `\`. * Update ReadMe.txt * Update ReadMe.md * Update Generated Doc Files * Improve XModem Startup - Extended startup timeout for XM.COM so that it doesn't timeout so quickly while host is selecing a file to send. - Updated SD Card How-To from David Reese. * XModem Timing Refinements * TMS Driver Z180 Improvements - TMS driver udpated to insert Z180 I/O waitstates internally so other code can run at full speed. - Updated How-To documents from David. - Fixed TUNE app to properly restore Z180 I/O waitstates after manipulating them. * CLRDIR and ZDE updates - CLRDIR has been updated by Max Scane for CP/M 3 compatibility. - A minor issue in the preconfigured ZDE VT100 terminal escape sequences was corrected. * Fix Auto CRT Console Switch on CP/M 3 * Handle lack of RTC better DSRTC driver now correctly returns an error if there is no RTC present. * Minor RTC Updates * Finalize v3.0.1 Cleanup release for v3.0 * New ROMLDR and INTRTC driver - Refactored romldr.asm - Added new periodic timer based RTC driver * CP/M 3 Date Hack - Hack to allow INTRTC to increment time without destroying the date * Update romldr.asm Work around minor Linux build inconsistency * Update Apps for New Version * Revert "Update Apps for New Version" This reverts commitad80432252. * Revert "Update romldr.asm" This reverts commit4a9825cd57. * Revert "CP/M 3 Date Hack" This reverts commit153b494e61. * Revert "New ROMLDR and INTRTC driver" This reverts commitd9bed4563e. * Start v3.1 Development * Update FDISK80.COM Updated FDISK80 to allow reserving up to 256 slices. * Update sd.asm For Z180 CSIO, ensure that xmit is finished, before asserting CS for next transaction. * Add RC2014 UART, Improve SD protocol fix - RC2014 and related platforms will autodetect a UART at 0xA0 and 0xA8 - Ensure that CS fully brackets all SD I/O * ROMLDR Improvements .com files can now be started from CP/M and size of .com files has been reduced so they always fit. * Update commit.yml Run commit build in all branches * Update commit.yml Run commit build for master and dev branches * Improved clock driver auto-detect/fallback * SIO driver now CTC aware The SIO driver can now use a CTC (if available) to provide much more flexible baud rate programming. * CTC driver fine tuning * Update xmdm125.asm Fixed a small issue in core XM125 code that caused a file write error message to not be displayed when it should be. * CF Card compatibility improvement Older CF Cards did not reset IDE registers to defaults values when reset. Implemented a work around. * Update ACIA detection ACIA should no longer be detected if there is also a UART module in the system. * Handle CTC anomaly Small update to accommodate CTC behavior that occurs when the CTC trigger is more than half the CTC clock. * Update acia.asm Updated ACIA detection to use primary ACIA port instead of phantom port. * Update acia.asm Fix bug in ACIA detection. Thanks Alan! * MacOS Build Improvement Build script updated to improve compatibility with MacOS. Credit to Fredrik Axtelius for this. * HBIOS Makefile - use env vars for target Allow build ROM targets to be restricted to just one platform thru use of ENV vars: ROM_PLATFORM - if defined to a known platform, only this platform is build - defaults to std config ROM_CONFIG - sets the desired platform config - defaults to std if the above ENVs are not defined, builds all ROMs * Added some more gitignores * Whitespace changes (crlf) * HBIOS: Force the assembly to fail for vdu drivers if function table count is not correct * Whitespace: trailing whitespaces * makefile: updated some make scripts to use when calling subdir makefiles * linux build: update to Build.sh fix for some platforms The initialization of the Rom dat file used the pipe (|) operator to build an initial empty file. But the pipe operator | may sometimes return a non-zero exit code for some linux platforms, if the the streams are closed before dd has fully processed the stream. This issue occured on a travis linux ubuntu image. Solution was to change to redirection. * Bump version * Enhance CTC periodic timer Add ability to use TIMER mode in CTC driver to generate priodic interrupts. * HBIOS: Added support for sound drivers New sound driver support with initial support for the SN76489 chip New build configuration entry: * SN76489ENABLE Ports are currently locked in with: * SN76489_PORT_LEFT .EQU $FC ; PORTS FOR ACCESSING THE SN76489 CHIP (LEFT) * SN76489_PORT_RIGHT .EQU $F8 ; PORTS FOR ACCESSING THE SN76489 CHIP (LEFT) * Miscellaneous Cleanup No functional changes. Co-authored-by: curt mayer <curt@zen-room.org> Co-authored-by: Wayne Warthen <wwarthen@gmail.com> Co-authored-by: ed <linux@maidavale.org> Co-authored-by: Dean Netherton <dnetherton@dius.com.au> Co-authored-by: ed <ed@maidavale.org> Co-authored-by: Phillip Stevens <phillip.stevens@gmail.com> Co-authored-by: Dean Netherton <dean.netherton@gmail.com>
483 lines
21 KiB
Plaintext
483 lines
21 KiB
Plaintext
|
||
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.
|
||
|