bet@ecsvax.UUCP (06/12/84)
I recently posted a note asking if there is something intrinsic to the Apple
disk recording scheme which make it slow, or whether it is simply coincidental
that Apple DOS and the Macintosh's system software share brain-damage that
slows down the disk access.
Ross Alford (alford@ecsvax) responded describing a program he had written
in TURBO-PASCAL for the Apple under CPM that read a ~40K file in ~10 seconds.
It then took ~20 seconds of computing. He mailed me that program, and I ran
it under TURBO-PASCAL on PC-DOS 2.10 (with the disk parameter table patch).
It took ~20 seconds to read a ~50K file, and another 10 seconds to compute.
It looks like
a) Apple drives are not intrinsically slow
b) insofar as Apple disk access is slow it is the fault of
the Apple operating system
c) The IBM-PC is half as fast (assuming that TURBO-PASCAL
makes a good benchmark comparison, and that DOS 2.10
isn't inflicting too much overhead on disk I/O)
d) In one (possibly typical) application the IBM-PC
seems to compute approximately twice as fast.
Bennett Todd
...{decvax,ihnp4,akgua}!mcnc!ecsvax!betbinder@dosadi.DEC (The Stainless Steel Rat) (06/14/84)
I don't know how the Mac does it, but the Apple ][ DOS places data on
the disk sequentially backward, thus:
Imagine a 16-sector file, ie one track, to be saved on a freshly
initialised disk. This file will be stored in this order on the disk:
File sector Disk track/sector File sector Disk track/sector
----------- ----------------- ----------- -----------------
1 18/15 9 18/ 7
2 18/14 10 18/ 6
3 18/13 11 18/ 5
4 18/12 12 18/ 4
5 18/11 13 18/ 3
6 18/10 14 18/ 2
7 18/ 9 15 18/ 1
8 18/ 8 16 18/ 0
...and so on for longer files. What this means in terms of read/write
time is that a simple-minded DOS can have lots of time to read a sector
into a buffer area and then move it to the proper area in memory, and
then do housekeeping before the next sector comes along, almost a full
revolution later. Thus, it takes DOS 3.3 18 revolutions to read that
16-sector file. SLOOOOOOOWWW!!!
There are several third-party DOSes available for the Apple ][ machines;
three that I know of are Diversi-DOS, from DSR, Inc.; ProntoDOS, from
Beagle Brothers; and David DOS, from David Data. All of these are
smarter in that they don't need the massive amount of time between
sectors. They use a little intelligence to read sectors out of order,
and all of them can load a 16-sector Applesoft or binary programme in
only TWO revolutions. Text file handling is a little slower but still
vastly faster than DOS 3.3. All of these DOSes also include extra
functions, some of them rather nice; David DOS has new commands for
direct load and save of text files, Diversi-DOS has a TLIST command that
lists Applesoft directly from the disk, and so on.
Cheers,
Dick Binder (The Stainless Steel Rat)
UUCP: { decvax, allegra, ucbvax }!decwrl!rhea!dosadi!binder
ARPA: binder%dosadi.DEC@decwrl.ARPA
Posted Thursday 14th June 1984, 08:59 Eastern time by DOSADI::BINDERmd@ncsu.UUCP ( ) (06/26/84)
Apple DOS also uses a little bit of intelligence in accessing the sectors on a disk. Using a sector interleaving scheme in software is what allows both Apple and third party Dos to alter the sector interleaving pattern. I admit that Apple's might not be the best but this is what it is. physical sector logical sector 0 0 1 7 2 14 3 6 4 13 etc. Apple DOS is slow for several reasons, but SAVE, and BSAVE times can be improved by removing the VERIFY routine that is executed after each SAVE or BSAVE. Replace those JSRs with NOPs. This is one method that those third party DOSes use to improve their speed. Mike Davis