Date : Wed, 27 Sep 1989 12:48:44 PDT
From : Bridger Mitchell <bridger%rcc@rand.org>
Subject: Alspa Computer ACI-1/2 BIOS bug, NZCOM, ZSDOS
In INFO-CPM Digest, Tue, 26 Sep 89, Volume 89 : Issue 178 Bill Swan
reports:
>The symptom, in general, is that an application running from one drive
>fails to find all the files on another drive specified by a wildcard. I
>have seen this with the above UUCP, with SHAR.COM, and a CP/M make. For
>some reason I have not seen this with Alspa's D.COM.
>
>The problem is caused by the BIOS density (disk format) routines use of
>the 128-byte scratch directory buffer (DIRBF) as a scratch buffer for
>reading track 0, sector 1, to determine the disk format encoded therein
>at byte 7FH.
>
>This causes the directory buffer to be clobbered between search-first and
>search-next BDOS calls, and any matching but unfound file entries in the
>buffer at that time will not be found.
>
The BIOS drive-select specification for CP/M 2.2 was not fully
documented in early Digital Research publications and may have
contributed to the bug you have found.
In general, the BIOS should determine density/sides/format of a disk
only when the BIOS select-disk routine is called with a "new mount"
parameter (E register bit 0 value of 0). I believe the correct "fix"
is the following: The relevant parameters should then be stored in a
data structure for that logical drive and those values used until the
drive is again selected with a new mount indication. From your
description is sounds as if the BIOS is going through the code to
physically determine the format *each time* the drive is selected and
is not the current drive.
The BDOS keeps track of whether a drive has been logged in. On the
first use of a drive that is not yet logged in, it sets E bit 0 to 0.
Thereafter, E bit 0 is 1, until the drive is "logged out", by a
function 13 or 37.
In your example, suppose you have just warmbooted, so that A: is the
current drive, and assume the application is searching B: *with an
explicit drive indicator in the fcb*. The BDOS will select drive B:
as a new mount as part of the search-first function, read the first
directory sector to the directory buffer, and then re-select A: before
returning to the application. Each search-next function will select
B: with an old mount parameter, return the sector containing the next
directory entry (reading the disk if necessary) to the directory
buffer, and then reselect A:.
If instead of an explicit drive value in the fcb, the application
first uses a BDOS drive select function to log in B:, the BDOS will
leave drive B: selected on each search first/next call. Since the
selected drive is not changing between search calls, the Alspa BIOS
won't be attempting to determine format and presumably "Alspa's D.COM"
will return the correct directory sectors.
Bill also remarks:
>(Note: I have done a *lot* of work on the BIOS - it is at rev 3.7 now, up
>from the last ACI v3.0, and accomodates P2DOS and ZCPR3 among other things.)
NZCOM -- the most recent version 3.4 of the ZCPR system, installs
automatically and requires no additions or modifications to a standard
BIOS. It has many, many advantages over earlier versions, including
allowing the user to switch dynamically to a "tiny" version that
requires only 0.25 K.
ZSDOS is a replacement for the Digital Research BDOS that is distantly
descended from P2DOS. It integrates DateStamping, public filetypes,
internal search path, fast fixed-disk relogging, and a host of other
excellent features.
NZCOM and ZSDOS run on standard Z80 CP/M 2.2 systems of all types,
require no assembly or BIOS modifications, and come with menu-driven
installation and configuration tools. They should be fully compatible
with a corrected version of the Alspa BIOS.
-- bridger