ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/CPM/BDOS/Z80DS231.LBR/Z80DOS23.DZC/Z80DOS23.DOC

Text File | 2000-06-30 | 8KB | 158 lines

 Z80DOS 2.31                                                Nov 15, 1988
 11/14/88
 Eugene Nolan
 C/O DHN* RCPM 215-623-4040 (Sysop Bob Dean)

PURPOSE:

     Z80DOS version 2.3 attempts to speed the most  basic  operation  of
 the  internals  by  decreasing  the  time  it takes to look up the next
 extent of a file already open. The file may  be  open  for  reading  or
 writing in either sequential or random (or mixed modes).


METHOD:

     It  does  this  by making use of File Control Block (FCB) entry 13,
 the 's1' 'unused' byte in the FCB. Z3X use this byte to pass  the  user
 number  of  a  file  referenced  in the command line tail to the loaded
 transient, but after that the transient cannot expect it  to  still  be
 there after the file is referenced.

     In  FCB+13,  Z80DOS23  will store the sector of the directory where
 the file was found. This scheme will work will all disk definitions  up
 to  1024  directory  entries.  Note that this sector is relative to the
 base track offset for a given logical (physical) drive.

     If the file was referenced by a call to 'MAKE FILE' or a new extent
 was opened while reading or writing, the FCB+13 will here again contain
 the directory sector of the relevant entry in the directory.


BDOS TUTORIAL:

     Access to the directory entries of a file using CPM 2.2  compatible
 BDOS's,  at least 2.2 itself and the variants of P2DOS that are around,
 will all search the directory starting at the beginning every  time  an
 application  has  read/written  more  than 16k from a file, even if you
 have 16k allocation per block and can contain 16 entries per  directory
 entry!

     Now  let's  say  you  have  4k  allocation blocks, and 8 allocation
 references per directory entry ( a fairly standard hard disk system  ),
 and  there  are  1024  available entries of which 256 are used (we have
 just done a SAP). Now we want to copy a 63k  file  to  this  drive.  We
 start  by checking to see if the file exists, this will require reading
 every directory entry for the 256 files. Now the file did not exist, so
 we  'MAKE'  the  file,  again we must scan the directory looking for an
 unused slot in the directory, 257 directory entries scanned this time.

     Now we have a slot and we start writing, after we have written 16k,
 the  CPM2.2  compatible BDOS must then open the next extent, so it will
 close the current one by searching all 257 directory  entries  for  the
 FCB  it  already  has opened, write out the updated entry, and allocate
 the next free block. 16k more and we then search 257 entries, write the
 updated  entry  and  accept  more input till we again have 16k's worth,
 again scan 257, write updated directory and accept the  last  15k.  The
 application then closes the file, which requires 257 more scans and the
 write of the updated directory.

     So all in all we 'looked' for this file thru  over  1541  directory
 entries!  Now don't forget that we copied that file from somewhere, and
 the above process was repeated every time the application read 16k from
 the source file!

     Now  of course if we had fewer than 256 used entries to start with,
 then there would be a correspondingly less searching required.

     Z80DOS2.3 attempts to address the above searching by decreasing the
 number   of  searches  required  once  a  file  is  open  and  we  have
 read/written more than 16k. The above scenario would of been  completed
 with just a max of 529 directory entry scans. 257 for the original look
 to see if file exists, 257 to find a free slot, and then up  to  4  for
 each of the 16k hunks and the final close.


INCOMPATABLITIES:

  There are some side effects of the above scheme. It assumes that the
 root, and subsequent entries for the file, all fall in ascending order
 in the directory. This is assured by Z80DOS if files were made under
 it's control, as it will always 'make' the next directory higher in the
 directory.

  But this scheme of having a non-zero FCB+13 and subsequent directory
 entries occur higher in the directory is NOT strictly CPM2.2 compatible.
 That is not to say that a CPM 2.2 compatible BDOS cannot use the files
 created this way, it surely can, but it does say that some files created
 by the 2.2 BDOS may not be accessible by the Z80DOS2.3 BDOS. This can
 occur if you have ever had one file open for writing, and with the file
 open, have deleted a file that occurred lower in the directory than the
 current FCB, and the FCB entry overflows which requires opening a new
 one. The 2.2 BDOS will use the extent lower in the directory for the
 next entry, which Z80DOS2.3 cannot 'find' because it occurred before the
 files root directory entry.

  The execellent program DU can be used to find files that may cause a
 problem. Use it's 'F' command to show the directory entries for the file
 in question, if the last byte of the first line of each entry shows a
 value of 80, and the very last entry has a value not equal 80, then no
 problem, but if an entry with a value not equal 80 occurs BEFORE an
 entry with the byte equal 80, then this file will not be accessible in
 it entirety. To make it compatible, merely copy it to another drive, delete
 the original, and copy it back again. Or you can copy it to a different
 name on the same drive, delete the original, and rename the copy.


TESTING:

  Z80DOS2.3 has been in use on my own system (64180/ZCPR33) and I have had no
 problems whatsoever. It is also in use on DHN* RCPM (SYSOP: Bob Dean), and has
 run smoothly the utilities required in the managment of a remote access system,
 which in this case is HBBS/BYE510/NZCOM/FOR/KMD and a myraid of others that
 are in regular use both manually ( by the SYSOP and callers alike ) and
 invoked for automatic BBS maintainence.


DIFFERENCES:

  There are also other modifications made on the inside to combine like
 functions, rearrangement of code to provide 'minimal' paths for the most
 used functions, deletion of redundant code left over by modifications to the
 original P2DOS, and decrease of the size of the ascii error messages to
 make enough room for the new internal routines to implement the fast lookup
 code.

ADDITIONS:

     There has been an addition of returning an identifier saying Z80DOS
 is present. This has been implemented by returning a 38 hex code in the
 D register upon the GET VERSION BDOS call (12).

 ZRL CAPABLE:

     The  code  as  distributed  has the necessary lines marked that are
 required for assembling to a .REL (read .ZRL) format for use with NZCOM
 and  JETLDR.  See the individual files for the required changes (search
 for ZRL ).


IN CONCLUSION:

     All in all, on some test runs, I have noticed up to a 25%  increase
 in through-put. Even copying 100k+ files to a floppy with only 23 files
 on it have seen 5% increases. And this is on  a  10mhz  64180  homebrew
 SCSI ( both winchester AND floppy on SCSI ) based system ( 1 wait state
 for all mem/io accesses) running a CDC WREN II (50  ms  avg  )  with  0
 interleave ( 512 byte sectors/ 1k deblocking).

     As  an  example,  using  VDE266  to  call  up the Z80DDISK file for
 editing (48k) took 4. seconds with the original Z80DOS2.0A,  under  the
 new  scheme  3.6  secs,  a  savings of 10% time. This included the path
 search of ramdisk to drive A of the first partition on the  winchester,
 load of VDE from there, read the file (also from drive A) till the file
 was being displayed on the terminal (19.2k baud, DTR handshaking).

                                - end -