<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Fri, 28 Oct 2005 10:37:37 +0100
From   : jgh@... (Jonathan Graham Harston)
Subject: Re: 3.5" Floppy For A Master

Pete Turnbull <pete@...> wrote:
> Jonathan Graham Harston wrote:
> > Acorn managed to get hold of some single-sided 3.5" drives for
> > early disk interfaces for the Electron.
> 
> I think you're confusing single-sided with single-density?  There are
 
No, I'm not.
 
To the disk and drive single density and double density are the
same. They are only different at the controller.
 
A SS/DD disk can store 50,000 bits on each track. These bits can
be parcelled up in whatever manner the disk controller in the
computer wants.
 
A controller running in single density mode uses FM (Frequency
Modulation) encoding. This uses every second bit as a clock bit,
leaving 25,000 bits to hold data.
 
disk data stream: c d c d c d c d c d c d  ...
 
25,000 bits can be arranged into 3125 bytes. Again, these bytes
can be parcelled up into whatever the controller wants. Normally,
these are parcelled up into a number of sectors with a certain
overhead for each sector for the sector identity marks and CRCs. A
sector needs about 80 raw track bytes of overhead, which
translates into about 40 data bytes. The track needs about another
160 bytes track header and footer (80 data bytes).
 
With these overheads you can fit ten sectors of 256 bytes on each
track on a SS/DD disk using single density/FM encoding:
 
(sectorcontents + sectoroverhead)*numberofsectors + trackoverhead
(     256       +     50        )*      10        +     60
                           =306 * 10 + 60
                           =3060 + 60
                           =3120 - which fits into 3125 bytes
 
Giving 2*80*10*256 bytes = 400K per disk.
 
A controller running in double density mode uses MFM (Modified
Frequency Modulation) encoding. This uses the transitions of data
bits themselves to generate artifical clock bits. Instead of
inserting a clock bit before every data bit one is only inserted
between consecutive zeros. When a "1" bits is found there has
already been a flux reversal in the middle of the bit, so a clock
bit is not needed. Now, all 50,000 bits can be used to hold data.
 
50,000 bits can be arranged into 6250 bytes. Again, these bytes
can be parcelled up into whatever the controller wants. Normally,
these are parcelled up into a number of sectors with a certain
overhead for each sector for the sector identity marks and CRCs.
As with FM each sector needs about 80 raw track bytes of overhead.
and the track needs about 160 bytes for the header and footer. As
we are using MFM, this is the full 80 bytes and 160 bytes.
 
With these overheads you can fit sixteen sectors of 256 bytes on
each track on a SS/DD disk using double density/MFM encoding:
 
(sectorcontents + sectoroverhead)*numberofsectors + trackoverhead
(     256       +     100       )*      16        +     120
                           =356 * 16 + 120
                           =5696 + 120
                           =5816 - which fits into 6250 bytes
 
Giving 2*80*16*256 bytes = 640K per disk.
 
RISC OS ADFS can use 1024-byte sectors. You can fit five sectors
of 1024 bytes on each track giving 2*80*5*1024 bytes = 800K per
disk.
 
A high density disk can store 100,000 bits per track due to the
magnetic surface having *smaller* grain sizes and consequently a
*higher* magnetic coercivity.
 
Higher? Yes, higher. Because as the magnetic granularity is lower,
the magnetic medium needs a higher coercivity in order to keep its
magnetic state.
 
It is incrediby rare to find any system using FM encoding on HD
disks. Using MFM encoding on a HD disk there are 12500 bytes
available. RISC OS ADFS fits in ten sectors of 1024 bytes, giving
1600K per disk.
 
> lots of single/double density 3.5" drives with no HD capability in the
> world.  Machines from Acorn including Electron, Filestore, Master
 
In the majority of cases you would find a DD/HD drive connected to
a computer that could not do HD.
 
-- 
J.G.Harston - jgh@...                - mdfs.net/User/JGH
HADFS System Resources - http://mdfs.net/Software/HADFS
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>