bridger%rcc@RAND.ORG (Bridger Mitchell) (09/28/89)
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