[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MFM or GCR...
- Subject: Re: MFM or GCR...
- From: Linards Ticmanis <ticmanis@coli.uni-sb.de>
- Date: Sun, 04 May 2003 12:26:54 +0200
- Followup-to: comp.sys.apple2
- In-reply-to: <nU1ta.44212$3h5.823633@news2.east.cox.net>
- Newsgroups: comp.sys.apple2, comp.sys.atari.8bit, comp.sys.cbm, comp.sys.ibm.pc.hardware.systems
- Organization: University of Saarland, Computing Center, Germany.
- References: <nU1ta.44212$3h5.823633@news2.east.cox.net>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
- Xref: archiver1.google.com comp.sys.apple2:30157 comp.sys.atari.8bit:20929 comp.sys.cbm:55968 comp.sys.ibm.pc.hardware.systems:8839
Hon Tseng wrote:
> Apple 8bit and Commodore 1541 use GCR. Atari 8bit and IBM use MFM. Which is
> better and realible? Why?
Both systems have 2 purposes:
1.) Limit the number of consecutive 0 bits since those can't be synced
on. They're stored as "nothing happens" basically while 1 bits are
stored as "something happens." You can determine the exact moment
something does happen but you cannot determine the exact moment when
nothing does happen. And so the circuit wouldn't be able to compensate
for small variations in rotation speed which always occur in mechanical
drives if you had many 0 bits following directly after each other.
2.) and provide a way to discern between data and metadata. E.g. the
"this is the start of this track" mark musn't be confusable with some
piece of normal data. So if you need to store a bit of data that just
happens to be identical to the mark, it has to be changed in some
unambigous way.
GCR is easier to implement in Software. It takes bit patterns and
replaces them with other (longer) bit patterns that don't contain many
consecutive 0s. On reading it converts them back.
Apple stored 3 bits for 2 in the beginning (13 sector disks) and later 4
bits for 3 (16 sector disks). Commodore stored 5 bits for 4.
MFM is easier to implement in Hardware. Basically it inserts extra
"halfway" bits into areas with consecutive 0s. Since they're halfway in
between the normal bit positions they can be discerned and thrown out on
reading back the data.
Apple used the computer's main processor to decode, Commodore put a
general-purpose CPU into the drive, IBM and most CP/M computers put a
custom chip into the drive. Atati I don't know.
Both method are pretty reliable if not pushed to the max, which no
system really does since users are know to value data security over disk
size. (What's the point of storing an extra 80KB on the disk if I can't
retrieve the data?)
I've successfully read disks almost 20 years old of both the GCR and MFM
variety.
fup2 c.s.apple2 to reduce crossposting.
--
Linards Ticmanis
The Master said, "The business of laying on the colors follows the
preparation of the plain ground."