Let's not confuse things here. Today, most disks use either a servo track
on an unused surface or they use embedded servo written right in with the
data they're storing. That certainly helps with speed control as well as
with positioning. They now use voice-coil actuators rather than steppers,
and therefore can make quite subtle adjustments in head-stack position
depending on what is read. Back in the early days, that wasn't so. In that
sense, it's fair to say that Apple was somewhat forward in their thinking.
Normally they only thought inward, hence, they did this because it saved
them money.
FM, MFM, RLL including GCR, are simply modulation schemes. They
characterize how the data is actually written on the track, but really
aren't involved in decoding the position when a track is being found. The
data format, however, customarily has extensive information allowing the
system to verify the current position of the head on the medium. A typical
sort of format layout would have a sync field, followed by an address mark
(a framing-sync character sort-of like the unique word used in HDLC and
other protocols) to tell the controller what's next, then a position
indicator data field to tell the system the current head and sector
information, then a CRC, followed by another sync field containing a write
splice (write turn-on gap) followed by a data address mark followed by the
data and its CRC and yet another sync field containing yet another write
splice(write turn-off gap). There are variations on this theme, but that's
basically what's there. The basic format is written in the "low-level"
format process while the data fields are written in the "high-level" format.
On old drives, the drive's internals don't care about the data. They just
transfer it. Newer drives, since they have to fiddle with the data in order
to set the data rate, manipulate the heads, buffer the data, correct the
errors, etc. care very much about and involve themselves greatly with the
media content. Hence, they rely less on hardware specifically in place to
yield position information.
Floppy drives, AFAIK, don't bother with this, though the ZIP and LS-120
drives may very well do so. They have a track-zero detector, and, normally,
that's what's used by the system to find track-00. Apple didn't even use
one of those because they could move the heads until it seemed reasonable
for one reason or another to assume track zero had been reached, perhaps by
reading where they were and then making an adjustment, or perhaps by moving
the head in one direction or the other until it had to be at the limit.
Then they could step inward until data was encountered, and could be
interpreted. Someone else will have to elucidate on that, however, because
although I know a fair amount about what they might have done, I don't
actually know what they did. How about it Eric? How dit they manage a
recal?
One interesting thing about the Apple GCR modulation format is that it
essentially was a "double-density" technique. It was cleverly implemented
in a way which saved on hardware, capitalized on software's ability to
exploit the time window normally spent waiting for a transfer, and,
especially, didn't wed them to one or another FDC chip maker. Those IC's
cost plenty back then. This was at a time when Radio Shack still stayed
with single-density, and Apple exceeded their capacity easily. Radio Shack
was the only major competitor Apple had. This was a real coup!
Dick
-----Original Message-----
From: Cameron Kaiser <ckaiser_at_oa.ptloma.edu>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Thursday, April 08, 1999 6:32 PM
Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 5
>::> How does this work? Do you mean that the disk drive has no internal
means
>::> of judging whether or not it's on the right track and that this is
>::> determined by the contents of the disk?
>::
>::Basically, yes. The track and sector are stored in the sector header of
>::each sector, among other data.
>
>In fact, most floppy disk systems work that way. Commodore GCR does that.
>So does MFM, doesn't it?
>
>--
>-------------------------- personal page:
http://calvin.ptloma.edu/~spectre/ --
>Cameron Kaiser Database Programmer/Administrative
Computing
>Point Loma Nazarene University Fax: +1 619 849
2581
>ckaiser_at_ptloma.edu Phone: +1 619 849
2539
>-- FORTUNE: You will feel gypped by this
fortune. -----------------------------
Received on Thu Apr 08 1999 - 20:43:24 BST