Date : Mon, 11 Jan 1993 21:30:56 GMT
From : news.tek.com!wrgate!fury.wr.tek.com!donk@uunet.uu.net (Donald C. Kirkpatrick)
Subject: Re: diseased Kaypro/Wordstar
In article <1if6sfINNeou@CS.UTK.EDU> jfarmer@cs.utk.edu (JOHN FARMER) writes:
>
>I have a Kaypro 4'84, and I'm using Wordstar 4.0, and I have a problem
>somewhere. I keep looking part of 'large-files'. What's happening is that
>parts of files are disappearing only to be replaced with other (duplicate)
>parts of the same file.
>
>The first times it happened, I was working on a large file on a full disk,
>and I just assumed that when I had tried to save, and there wasn't room, that
>Wordstar got lost when it stopped to tell me there wasn't any room and I had
>to delete stuff to continue. The latest time it happened, I was working on
>a much smaller file on a virtually empty disk. (and to make it worse,
>I was dutifully saving every so often, so there was no backup file to
>get the data from. I lost about 2-3 hours of work.)
>
>My husband thinks it's a disk drive problem. I'm not so sure. I don't
>seem to have the problem with pip, for instance. Any suggestions? Ideas?
>I do re-build Wordstar ever so often. I use it all the time, and the disk
>"goes bad" every so often.
>
>All help appreciated.
>
>Thanks
>Susan B. Farmer farmer@cs.utk.edu
While it is not yet known for sure, the problem described above appears
to me as if Susan has found the infamous BDOS Function 37 bug. She is
now checking to see if that was indeed her problem. To save others her
grief, I thought I'd post the information I sent to her. Everyone who
has not yet installed a BDOS replacement must at least become aware of
this bug and decide for themselves whether or not to patch their BDOS.
The following text is from the file NULU151.INF contained in the
library NULU152A.LBR. I have deleted much that is not relevant and you
will find my comments in square brackets with my initials.
[Extracted from: NULU152.INF, a file included with NULU152A.LBR, a
library utility program - DCK]
<much stuff deleted -DCK>
The other problem - that of overcoming the BDOS error is more
complicated. The simplest way would be to fix the BDOS and I have
included a patch to the Digital Research BDOS for those who wish to make
the change. There are dangers inherent with fixing the BDOS however, and
I would strongly recommend leaving things the way they are. My argument
for leaving things is as follows:
The CP/M 2.2 BDOS is a stable product and can be guaranteed to perform
in exactly the same way for every user. Knowing its limitations, it is
possible to overcome the problems caused by the bug(s). If all users of
NULU were to patch their BDOSes, they may one day come across a program
which works BECAUSE of the bug and hence would not work on their
systems. Similarly, any software developed on a 'fixed' BDOS cannot be
guaranteed to work on an unfixed BDOS. However, I include the patch and
leave it up the users to decide. Freedom of choice is everyones right.
The BDOS bug although related to function 37 is not, in fact, in that
function but in the Select Disk function (function 14). Problems will
only be caused under the following circumstances:
1. The default drive has been reset, AND
2. Data has been written to the default drive since the disk reset, AND
3. Some sort of disk activity is requested on a different drive.
The BDOS keeps a 16 bit variable (the login vector) which shows the
login state for each of drives A-P. In the vector, each bit represents
one drive and is set if the drive is logged in. As records are written
to disk, the allocation vector in the BIOS is used to maintain a record
of those disk blocks allocated to the file. The allocation vector is
updated as blocks are written to disk but is initially set up from the
disk directory when the drive is first logged in. BDOS function 37
simply resets the appropriate bit(s) in the login vector which should
cause the drive to be relogged on the next access.
Unfortunately, Digital Research maintain an internal variable for
holding the last drive accessed and check it before logging in a disk.
If the requested drive is the same as the last, then the BDOS assumes
that it is already logged in and it doesn't check the login vector at
all. If we have reset the default drive, the internal variable will
still say that is is logged in, even though the login vector bit will
have been reset. Disk writes may still be made to this drive and the
allocation vector will still be updated.
If we were now to temporarily switch drives to do a read, for example.
The internal variable will reflect this and NEXT time we access the
default drive, the BDOS's check will now say "Ah, a different drive -
check the login vector". When this happens, of course, it will find the
bit for this drive is reset and will re-read the disk directory to
update the allocation vector.
The disk directory is only updated when either an extent boundary is
passed (every 16k) or when the file is closed. Consequently, unless we
are lucky, the disk directory will not show the last few disk writes we
have made and those bits will be reset in the allocation vector. This
means that as far as the BDOS is concerned, those blocks are free for
use and it will use them again - even if it means allocating the same
block(s) twice to the same file.
In context of NULU, assume that a library, resident on drive A, is open
and that we are currently logged into drive B (ie: drive B is the
default drive). Assume that we wish to extract a 100k member file to
drive B. NULU creates a buffer when the library is opened and a 2k
buffer for the file to be extracted. The buffer for the library will be
a large percentage of the remaining TPA size but suffice to say that it
will be smaller than our member file. We then fill the library buffer
with the first part of the member file and reset drive B in case the
disk has been changed - condition 1 is then satisfied. We now start
writing out the member file (condition 2) until the library buffer is
exhausted. We then need to read more of the library from drive A -
condition 3.
<more stuff deleted - mostly NULU specific code - DCK>
On another subject altogether, the additions of code to save and resore
the S2 byte are to do with files larger than 512k. It may be of interest
to note that Digital Research 'forgot' to document that the S2 byte is
an overflow extent byte. Anyone who has tried to edit a text file under
Wordstar will probably have found that it goes bananas when the file
size exceeds 512k. Wordstar is not alone in this, there are several
other commercial and PD programs that suffer badly when dealing with
files greater than 512k.
Digital Research say that CP/M 2.2 can handle files of up to 8Mb and
CP/M Plus can handle files up to 32Mb. They also say that the extent
byte (under 2.2 and Plus) can vary between 0 and 31 in use - under CP/M
1.4 this was 0 to 15. Now 32 times 16k is nowhere near 8Mb let alone
32Mb, in fact it comes to that magic figure of 512k - this is where the
S2 byte comes in. The S2 byte counts the multiples of 512k used in a
file and may range from 0 to 15 under CP/M 2.2 (bits 0-3) and 0 to 63
under CP/M Plus (bits 0-6). Bit 7 of the S2 byte is used by the BDOS as
an internal 'archive' bit. When a file is opened, an examination of the
S2 byte will show a value of 80H. If any write is performed to the file
in question, this bit will be cleared. When the close file function is
called, if the bit is set then no action is required. If it is clear,
the disk directory is updated.
<more NULU specific code deleted - DCK>
The DRI BDOS fix
Zero out the following locations in the DRI BDOS, note that the BDOS
starts 6 bytes before the address at location 0006H and that ZSID/DDT
etc. will not give the true address. Use something like Z3LOC or STATUS
to determine your BDOS address. The bytes at those locations and what
they do are given so that you can patch away with confidence.
Location to patch Byte at that location (Hex)
(xx = depends upon BDOS address)
BDOS + 0C45H 3A LDA xxD6H ; Get wanted drive
BDOS + 0C46H D6
BDOS + 0C47H xx
BDOS + 0C48H 21 LXI H,xx42H ; Get last drive
BDOS + 0C49H 42
BDOS + 0C4AH xx
BDOS + 0C4BH BE CMP M ; Same drive?
BDOS + 0C4CH C8 RZ ; Return if it is
[Note: only the RZ code at 0c4ch need be set to zero - DCK]
This patch prevents the BDOS from using its internal saved record of the
last drive accessed and forces it to check the login vector bits to
determine whether or not to relog a drive.
The patch above works but on your own head be it!
As a final note, anyone who is running one of the BDOS replacements, P2DOS,
NovaDOS, ZRDOS, ZSDOS, and so on, should find that this bug has been fixed.
I all my 14 years of CP/M, I have never encountered a program that required
the bug present to work properly. (Insert weasel words here) Thats not to
say such a program doesn't exist, just that I have not found it yet.
--
-Don Kirkpatrick (Donald.C.Kirkpatrick@tek.com)
UUCP: ...!uunet!tektronix!Donald.C.Kirkpatrick
End of INFO-CPM Digest V93 Issue #7
***********************************