Article View: net.arch
Article #3115Re: an idea for higher capacity disks
From: Jim Greenlee
Date: Fri, 07 Nov 1986 05:49
Date: Fri, 07 Nov 1986 05:49
40 lines
2800 bytes
2800 bytes
In article <22218@rochester.ARPA> ken@rochester.UUCP (Comfy chair) writes:
>Wait a minute. If we are talking about constant angular velocity (CAV)
>disks, then the surface moves faster under the head on the outer
>tracks. Then to fit more sectors in you'd have to write the bits
>faster, so you would still have to change the clock rate.
It depends on the encoding scheme used. For single-density (FM-encoded)
diskettes, the clock pulses are interleaved with the data pulses so all
you have to do is sync on those and presto-bingo - no changes in clock
rate are required.
For double-density (MFM-encoded) diskettes, the clock pulses are derived
from an external oscillator which is usually hooked into the drive motor
somehow to generate a consistent clock pulse (this is typically done by
means of a phase-locked loop).
Most of the variable-rate drives with which I am familiar take a slightly
different tack by varying the speed of the drive motor to increase the
bit density on the outer tracks. The Victor 9000 was the first micro that
I am aware of which used this technique - they hooked up an Intel 8048 to
a bare drive motor and used it as the drive controller. It was smart enough
to compensate for differences between drive rotational speed (the 'C' in
CAV isn't always so from drive to drive) so you could move diskettes from
machine to machine without worrying about having the data get garbaged.
Variable-speed drives are obviously impractical for large hard disks because
of the inertial forces built up by the spinning platters. I would think
a variable clock rate would work for a disk with fixed media if the rotational
speed could be tightly controlled or compensated for. Removable media are
a different story, however, because the tiniest difference in rotational
speed would make disks unreadable by any drive besides the one that wrote it.
I would expect the hardware for such a system to be extremely complicated
and cost-prohibitive.
Jim Greenlee
--
The Shadow
Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jkg
Technical Details
Message-ID:
<2575@gitpyr.gatech.EDU>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!seismo!gatech!gitpyr!jkgReferences:
<1256@hoptoad.uucp> <273@csustan.UUCP> <22218@rochester.ARPA>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!seismo!gatech!gitpyr!jkg From: jkg@gitpyr.gatech.EDU (Jim Greenlee) Newsgroups: net.arch,net.periphs Subject: Re: an idea for higher capacity disks Message-ID: <2575@gitpyr.gatech.EDU> Date: Fri, 7-Nov-86 00:49:09 EST Article-I.D.: gitpyr.2575 Posted: Fri Nov 7 00:49:09 1986 Date-Received: Sat, 8-Nov-86 04:55:47 EST References: <1256@hoptoad.uucp> <273@csustan.UUCP> <22218@rochester.ARPA> Reply-To: jkg@gitpyr.UUCP (Jim Greenlee) Organization: Georgia Institute of Technology Lines: 40