I come up with 6298 raw bytes (or "nibbles") per track at
300 RPM with tolerance for speed variation of 1.5%.
Below I discuss:
- drive speed,
- how many bits can fit on a track,
- what "nibbles" really are,
- compare my theoretical capacity calculations for various rotational
speeds with Nick Westgate's experimental results (spoiler: they're
within 0.2%), and
- calculate the actual maximum data storage of an Apple II diskette.
The Disk II system uses a Shugart SA400 drive which rotates
at a fixed rate of 300 RPM, so it is constant angular velocity.
(Actually, it's the SA400 drive mechanism with a custom analog
electronics board; the drive without Shugart's electronics is
sometimes called the SA390. But that makes no difference for this
Bits per Track
Beneath Apple DOS on page 3-7 briefly mentions 50,000 bits but
doesn't provide any details oh this number was calculated.
That number comes from either a simple calculation based on the
IBM-standard FM and MFM data rates for floppy drives or just directly
from the Shugart specification for the SA400 drive.
- The IBM 3740 single-density format data bit rate is 125 kHz. Since
this uses FM encoding that's 125,000 pairs per second of clock bit
followed by data bit, which works out to 8 μs per pair or 4 μs per
bit of clock or data.
- The IBM System 34 double-density format uses MFM which irregularly
intersperses clock bits with data bits. So in this case they specify
the "data + clock" rate as 250 kHz, which works out to the same
result: 4 μs per bit of clock or data. (Simply using fewer clock
bits is why "double-density" stores more data.)
- Page 4 of the SA400 Service Manual gives the number of
bits per track as 25,000. This would clearly have been just the data
bits that could be stored with FM encoding, since they mention later
on that page a soft-sector format of 18 sectors × 128 bytes, which
would be 36,864 bits on the diskette after FM encoding. (Plus
overhead of well over 2000 bits, from the diagram on the following
page.) That manual appears to be too early to have mentioned MFM
Before going further we need to discuss these so-called "nibbles."
The Disk II controller always reads an 8-bit chunk of data every 32
cycles; I call this a "raw byte." For various reasons, there are only
66 different 8-bit sequences that the disk controller can read while
maintaining synchronization (or fewer for the older controller PROMs
and DOS ≤3.2), which is why we need to encode our data.
(If you want more detail, this answer goes a bit deeper into
the reasons for this. The truly gory details are in Chapter 9 of Jim
Sather's Understanding the Apple II; see page 9-27 for a
list of the raw byte values that can be used while maintaining sync.)
Because Woz originally used an FM encoding to store 4 bits of data in
every raw byte written to the diskette, he originally called these
post-encoding raw bytes, "nibbles." Before the first Apple II DOS
release the encoding system for data bytes was changed to store 5 bits
of data in every raw byte (and eventually 6 bits, with DOS 3.3 and a
controller PROM change), but the name appears to have stuck. However,
to avoid confusion with the other standard terminology of a
"nibble" as a 4-bit chunk of data, I will henceforth refer
to the 8-bit chunks stored on the diskette and read by the controller
as "raw bytes."
Bits and Raw Bytes per Track
Beneath Apple DOS (fourth printing) Figure 3.3 states it takes 4 μs
(microseconds) to read 2 consecutive bits off the disk.
No, it's 4 μs for a single bit. The figure in the fourth printing
is incorrect; this was fixed in the fifth printing. More
details are given in this answer.
This is no doubt where the 6,250 raw byte (or so-called nibble)
figure came from: 200 ms for a track rotation at 300 RPM divided
by 4 μs gives 50,000 bits per track, and that divided by eight
bits gives 6,250.
But even that's not quite correct: it's really 4 clock cycles per
bit. Since the Apple II clock is 1.023 MHz, that's 3.91 μs per bit,
which gives us a track capacity at 300 RPM of 51,150 bits, or 6393 raw
bytes. We can do the calculations for other rotational speeds as well,
which I have done in the following table. I've chosen the same speed
values as Nick Westgate did in his answer; you'll note how
close my calculated values are to his experimentally determined values
raw exp column.
1 rotation RPM bits raw bytes raw exp difference
188 ms 319 48081 6010 6015 +0.08%
200 ms 300 51150 6393 6400 +0.11%
210 ms 286 53708 6713 6715 +0.03%
220 ms 273 56265 7033 7045 +0.17%
230 ms 261 58823 7352 7360 +0.11%
240 ms 250 61381 7672 7680 +0.10%
250 ms 240 63938 7992 8004 +0.15%
260 ms 231 66496 8312 8309 -0.04%
Maximum "Safe" Raw Bytes per Track
I've not seen any documents that discuss the acceptable speed ranges
for Disk II drives, but I can try a rough calculation. The read output
signal for a
1 bit from the drive is a 1 μs pulse that must be
detected within 4 μs of the previous bit (see page 9-29 of
Understanding the Apple II for details, and correct me if I'm
The drive will fully resync at the starting
1 bit of a raw byte (see
the discussion of byte framing in, again, this answer), so
that that means that the drive can't slow more than about half a
microsecond over the course of 8 bits, or about 1.5%.
Using this figure, we get a minimum drive speed of 197 ms per
rotation: 50383 bits or 6298 raw bytes per track.
Maximum data storage per track.
Since we've done all this, it's interesting and easy enough to
calculate the maximum number of (encoded) data bytes we can store on a
track. If we decide to go with a full-track format (one huge sector
per track) we need just 50 bits for synchronization (details again in
this question and answer) and the rest can be data.
At 50383 bits per track we have 50333 remaining after the sync bits,
all of which we can use to store GCR 6+2 encoded data:
÷ 8 = 6,291 raw bytes
× 6 = 37,749 encoded bits
÷ 8 = 4,718 encoded bytes
Multiply by 35 tracks and this would give us a total capacity of
161.25 KB/disk. Round down just a bit for safety and it seems that
160 KB is the maximum you could ever pack on to an Apple II floppy.