Date : Fri, 06 Apr 1984 00:16:00 MST (Fri)
From : Keith Petersen <W8SDZ@Simtel20.ARPA>
Subject: SD-81 now available
Thanks to our Info-Cpm readers a bug in SD-80 was uncovered and Sigi
Kluger has just released SD-81, which I just uploaded to SIMTEL20.
Here's a list of the files:
Filename Type Bytes Sectors CRC
Directory MICRO:<CPM.DIRUTL>
SD-79A.DOC.1 ASCII 9525 75 = 4BH D733H
SD-79A.DQC.1 COM 6144 48 = 30H 2D4BH
SD-81.AQM.1 COM 53248 416 = 1A0H F3D9H
SD-81.ASM.1 ASCII 78722 616 = 268H B1B8H
SD-81.NOT.1 ASCII 2689 22 = 16H 3ECCH
SD-81H.COM.1 COM 3584 28 = 1CH 49AEH
SD-81H.HEX.1 ASCII 8745 69 = 45H DD3FH
SD-81V.COM.1 COM 3968 31 = 1FH F321H
SD-81V.HEX.1 ASCII 9680 76 = 4CH 7563H
SD8081.DIF.1 ASCII 3401 27 = 1BH 15A1H
The last one, SD8081.DIF, is an SSED2 editor script for those who got
SD-80.ASM so they don't have to download the whole .ASM file again.
Here's a note from Sigi about the update:
04/04/84 S. Kluger El Paso RCPM
First off... sorry for the mess-up in SD-80. Sometimes it helps if you
know what you're doing!
Anyway, the bug is now fixed and that with an extra bonus... Seems like
the way SD has been working right now, it would get mighty confused with
extremely large files. To backtrack a bit, filesize is stored in the
directory as follows:
ENTRY+12 EX (extent number 0..31)
ENTRY+14 S2 (extent overflow 0..31)
ENTRY+15 RC (record count in last extent)
This means that the largest extent number is 1FH. In order to allow files
larger than 512k, the S2 byte is used. S2 is incremented every time EX
is incremented to 20H. EX is then zeroed. The highest number in S2 is 0F.
EX and S2, therefore, form a 9-bit number. The least significant bits
0..4 being EX, the most significant bits 5..8 being S2. That 9-bit number
is the total number of extents possible. Multiplied by 16k, we get 8192k,
the maximum file (and disk) size under CP/M 2.2.
(If I have bored you so far, please realize that many people out there
don't know this)
In SD, the file size was stored as a 2-byte value, one byte being the
total number of extents, the other being the number of sectors in the
last extent. From the previous explanation it should be easy to see that
you can't fit a 9-bit value into a byte. SD up to version 8.1 therefore
truncated all files over 4MB to 4096k. In SD-81, the file size is stored
as a normal (as opposed to byte-reversed) 16-bit integer in sector units
(8192k = 65536 sectors).
Not feeling a desire to perform a major rewrite, I did not change the fact
that SD loads and sorts ALL directory entries and then scans the list
for the highest numbered extent and displays it. The main reason for
changing it would be to save space and to possibly speed the program
up insignificantly. Should anyone ever tackle this, please make SD report
correct file sizes for random files with holes. (One way of doing it would
be to scan the directory and add up the RC fields of all like file names).
There still is a bug in the vertical display routine. It is my opinion that
vertical display best be left to XDIR, but again, if someone desires to
fix it up to look neat, be my guest. The vertical display currently loses
track sometimes and displays a blank line rather than file names. This
occurs with a very crowded directory (I noticed it with ~260 entries).
Also, the directory should be alphabetized by screenful.
If you find any serious problems with SD-81 which are obviously related
to my fixes, please be sure to let me know immediately. Do not mail any
explosives no matter how bad the bugs, please...