NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/cpm/1569

Text File | 1993-01-11 | 9.7 KB | 198 lines

Path: sparky!uunet!news.tek.com!wrgate!fury.wr.tek.com!donk
From: [e-mail] (Donald C. Kirkpatrick)
Newsgroups: comp.os.cpm
Subject: Re: diseased Kaypro/Wordstar
Message-ID: <[e-mail]>
Date: 11 Jan 93 21:30:56 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Tektronix, Inc.
Lines: 186

In article <[e-mail]> [e-mail] (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     [e-mail]

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.


-------------------------begin extraction-------------------------------

[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!


-------------------------end of extraction------------------------------


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 ([e-mail])
        UUCP:    ...!uunet!tektronix!Donald.C.Kirkpatrick