Apple Orchard 1980 Fall v1n2 reduced

FALL 1980
THE APPLE ORCHARD
PAGE 51
stage of INIT, why bother with the
data block at all Instead, RWTS
simply fills enough disk space with
$FF's to allow room for a data block.
Then RWTS proceeds on to the
next sector. Since the fake data
block just written has no beginning
marks, the DOS won't be able to
find data in the sector. Therefore an\
initialized sector can't be read (1/0
ERROR) until properly written to.
As far as DOS is concerned, there's
absolutely nothing there.
Once a sector gets formatted,
RWTS goes on to format the next
sector. As you might expect by
now, sectors aren't put on the disk
in a straightforward linear fashion
(0, 1, 2, 3 ... ). Instead they are interleaved
(0, 10, 7, 4, 1, 11, 8, 5, 2, 12, 9,
6, 3) to give the computer thinking
time between sectors, DOS uses
this time to handle data encoding
and decoding, as well as to find out
what sector to process or command
to interpret next. Thus sector 2 is
actually four sectors behind sector
1. Reading an entire track actually
takes four revolutions of the
diskette rather than one (.13 sec vs.
.03 sec).
Once each sector has been formatted
on a track, RWTS's formatter
performs a quick check to
insure that the next sector coming
past the read head is really sector
zero. If sector zero wasn't there,
then RWTS must have gotten its
timing wrong, so it adjusts the
number of timing bytes between
sectors and starts over. When sector
zero can be found on cue, the
timing is correct. Then RWTS
moves on to the nex-.t track.
After formatting all tracks, INIT
returns to command level DOS.
There, the DOS copies itself out
onto the diskette, writes out a
catalog, a Volume Table Of Contents,
or "VTOC", and executes a
"SAVE" command for the Hello
program. The entire initialization
takes two to three minutes or more,
depending on the length of your
Hello program.
There are several places in the
format routine to cut corners and
get away with it. The first place that
springs to mind is the routine which
calibrates the read/write head to
track 0. Adventurous souls can try
POKEing new numbers into 48801
($BEA1) to see what happens; just
keep the number above 35. I've
seen too many instances where the
drive's head only hit the stop once
or twice to muck about here. On
most systems the maximum time
savings would only be about five
seconds, anyway.
Another, safer number to change
is the number of timing bytes which
begin each sector. When first formatting
track 0, RWTS puts 60 bytes
between each sector. This is clearly
too much to fit onto one track
causing the last sectors to overwrite
sector 0. An error handling routine
decrements the number of timing
bytes by one and tries again. If the
number of timing bytes falls below
16, the error handler will quit with
an error message. Normally the
routine finds a number of timing
bytes that works and sticks with that
number for the rest of initialization.
A well-adjusted drive will have
about 40 timing bytes between
each sector, so you can speed
things up by starting the countdown
with a lower number. Try
POKE 48817,48 ($BEB1 :30). Fortyeight
bytes will work with any disk
drive within 30 speed units of zero
as measured on Apple's Disk Speed
Adjust program. This change will
shave about ten seconds from the
beginning of INIT.
Both changes so far have just
nibbled at the speed problem. Now
get ready for the Big Fix. Since the
timing bytes between sectors
together with the sectors themselves
fill up each track, there's no
need to erase the whole track
beforehand. Rather, one need only
erase enough to cover the gap
between the end of the last sector
(sector 3, remember) and the start
of sector O's timing marks. POKE
48821,4 does the trick ($BEB5:04).
My own trials showed that any
number less than four yields flakey
disks that can't be trusted. This
change, together with the preceeding
one, cuts initialization
time from two minutes to 45
seconds.
Another change to the DOS can
speed up disk access, although it
doesn't help speed INIT. The
change must be effected prior to
initializing a diskette for the new
diskette to work faster, so I'll
include it with the rest of this
discussion on INIT.
Remember our old friend, sector
interlacing Well, it turns out that
RWTS doesn't need all of that extra
time to think after all. If you POKE
48998,7 ($BF66:7) before initializing
a diskette you will change the interleaving
sequence from every
fourth sector to every other sector.
This effectively doubles machine
level access to the disk. You won't
believe how fast a disk created this
way will boot, for example. Unfortunately
much of the DOS itself is a
very slow program, so you can't
double the speed of everything.
This interleaving change will help
machine language access via RWTS
tremendously. Access time through
command-level DOS will only be
improved 10%, however. Curiously,
the alternate interleaving scheme
seems to be the scheme originally
intended by Apple. The formula
given in the original Wozpak documentation
support this interleaving
scheme. However, the
actual scheme used is the slower
one described above.
All is not lost if you still would
like to read programs and data off
the disk at a reasonable speed.
Mark Pump (ABBS Illinois Microcomputers,
Inc.) has discovered
that by POKEing 48998,2 ($BF66:02),
file read time can be speeded up by
almost 30%. Boot time wil be
slightly increased from normal,
however. This interleaves the sectors
such that any two consecutively
numbered sectors are 180
degrees apart on the disk. Evidently
this interleaving synchronizes
just right with the delays in command-level
DOS. Any slave diskette
created by a DOS containing
the above changes will retain those
changes for initializing its offspring.
Everyone kn·ows that Language
System disks pack data with higher
density. There are many misconceptions
about what changes were
made. Since I'm discussing disk
formatting, I might as well clear
some up. Many people think the
Language System achieves higher
density by going from 256 byte to
512 byte sectors. The 512 byte
blocks used in Pascal actually are
two 256 byte sectors grouped
together by the Pascal operating
system. On disk the sectors still
represent 256 bytes. Unlike DOS
3.2.1, however, each track has 16
sectors instead of 13. Therefore the
data in each sector must be denser.
(continued on page 52)