Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!jarthur!nntp-server.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Dos 3.3 Question
Message-ID: <1990Apr9.065205.27689@laguna.ccsf.caltech.edu>
Date: 9 Apr 90 06:52:05 GMT
References: <9004082354.AA20755@apple.com>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 34

jefft@gnh-applesauce.cts.com (Jeff Tarr Jr.) writes:

>Okay, I was dissassembling the SEEKABS routine in the DOS 3.3 code that seeks
>the read/write head and it appears that DOS 3.3 has the capability of seeking
>and writing to half tracks as well as full tracks. I was wondering what the
>reason for this was, and does this fact slow down disk access? To read a full
>track, SEEKABS must be called in a loop twice, essentially seeking a double
>half track to yield a full track, which seems to be wasteful, unless The Woz
>originally had plans of formatting or using half tracks and then abandoned it.
>I wanted to know if anyone knew why this was done in this way.

If you write a track on the disk, the magnetic field isn't razor thin. It's
wide enough to effectively write on the adjacent quarter tracks, and partially
(i.e. gobs of unpredictable errors) on the adjacent half tracks as well.

It might slow things down if a single routine can optimize the stepping time
for long seeks... I think the settling time and track read time are far more
significant, so the speed impact of rewriting SEEKABS would be minimal.
(I could be wrong.)

But it is for that reason that data is never stored closer than 3/4 of a track
apart, and since 1/4 tracks are a pain to work with (you have to do gross
things with the stepper magnets) DOS only uses full tracks to store data.
Spiral tracking copy protection schemes use quarter tracks but spiral it
such that data is never closer than 3/4 track at any point on the disk
(assuming they are reading real data and not checking for the presence of
intentional errors).

I suspect that Woz wrote it this way to keep the code simpler or (more
likely) smaller. 13 sector DOS didn't have as many unused spots as 16
sector DOS does.

Todd Whitesel
toddpw @ tybalt.caltech.edu