Apple IIc (not IIC+) details

From: Eric Smith <eric_at_brouhaha.com>
Date: Tue Aug 8 14:38:36 2000

"Richard Erlacher" <richard_at_idcomm.com> wrote:
> What? How does it generate FM? Is there a straightforward way to create FM
> with the standard controller? FM is VERY easy to deal with, while GCR
> requires one switch data rates, etc, all of which can be done, but it's an
> unnecessary pain. How does it generate FM? is that a function it does
> automatically or does it bit-bang it into a buffer and then ship it out ...
> or what??? I was NOT aware the Apple-][ controller could put out FM. That
> would have made it able to read/write TRS-80 diskettes, wouldn't it? Well .
> . . maybe . . .

It can do FM, but not IBM 3740 and equivalent formats. Woz's patent on
the controller in fact *only* describes FM; apparently he switched to
GCR later. In fact, the address fields on the disk are FM-encoded even
though the data sectors are GCR.

In the following discussion, not the careful distinction between channel
bits (the actual bits on the diskette), and user bits. FM and GCR are
channel codes, which specify the transformation from user bits to
channel bits during write operations, and back to user bits during read
operations. In the Apple disk controller, these transformations are
performed by software (typically the RWTS routines). However, the
hardware still imposes restrictions on what channel codes may be used.
In Apple terminology, eight channel bits are called a nibble, but since
that term is more commonly used to refer to four data bits (half a
byte), I'll instead use the term "octet". Note that while an octet is
eight channel bits, it does not inherently correspond to any specific
number of user data bits. Some octets on the disk do not correspond to
user data at all, but instead are used for address fields, data marks,
checksums, etc.

The basic idea of read channel of the Apple disk controller is that the
PROM state machine does clock recovery by acting as a digital PLL. The
original (13-sector) PROM could not reliably count more than one missing
pulse (i.e., a zero channel bit). The 16-sector PROM can reliably count
two missing pulses.

The only way the processor can tell that an octet has been read into the
shift register is that the MSB of the shift register is set. This means
that there are only 128 usable octet values. However, when combined
with the additional restriction of no more than one or two consecutive
zero channel bits (for 13 and 16 sector PROMs, respectively), this
leaves only 34 or 81 usable octet values.

For FM, then, you simply use data patterns for which the odd-numbered
bits of the octet (considering bit 0 to be the LSB) are all set. These
are effectively clock bits. The even numbered channel bits are used for
user data bits. This encoding takes advantage of only 16 of the usable
channel code octets, so it clearly is nowhere near optimal coding
efficiency. It results in an expansion of each user data byte into two
octets. This format is used for the address fields on the disk, but if
it were to be used for the data fields as well, it would only be
possible to fit ten 256-byte sectors per track.

Apple's 13 and 16 sector formats take advantage of the larger range of
possible channel code octets. 13-sector format uses 32 octet values for
representing 5 bits of user data, and the remaining 2 octets values for
address and data marks. 16-sector format uses 64 octet values for data,
2 for address and data marks, and leaves 15 unused.

The disk write process requires the software to gather groups of five or
six user data bits from a data buffer, look up the corresponding octet
in a table, and write that to the shift register. The read process
involves getting an octet from the shift register, looking up the
equivalent user data bits in a second table, and packing them into the
data buffer. The processes of converting user data bits to and from the
corresponding octet values are commonly referred to as "nibblizing" and
"denibblizing".

In the traditional RWTS routines, the nibblizing and denibblizing were
done as separate steps before and after the actual writing and reading.
This is one reason why a minimum of 2:1 sector interleave is required.

Starting with the Apple III, more clever code was developed that could
handle nibblizing and denibblizing for 16-sector format on-the-fly.

There is one other important part of how the Apple disk controller
works, which is the "self-sync" pattern written as a preamble before
sectors. The self-sync consists of sets of nine (13-sector format) or
ten (16-sector format) channel bits, of which the first eight bits are
ones, and the remaining bit(s) are zero. The self-sync pattern is
necessary because if the controller attempted to start a read at an
arbitrary point on the track, it wouldn't be able to determine where an
octet starts. However, when starting in a preamble, it is guaranteed
that no matter where reading starts, after five complete self-sync
patterns (16-bit format) the reading will be properly synchronized.

Of course, there's no way to guarantee that the read process starts in
a preamble. However, if it starts somewhere else, it will not find a
valid address mark until after a preamble, so synchronization will be
achieved.

The self-sync marks are generated by writing an all-ones (0xff) octet
to the shift register every 36 or 40 microseconds, rather than the normal
32 microseconds.

In terms of what you can do to "abuse" the floppy controller into talking
to devices other than floppy drives, you still have the limitation of
no more than 81 usable octet values. If you use a microcontroller and
shift register as your interface, you can easily support the Apple GCR
formats. But if you prefer, there's no reason why you can't simply stick
to FM. That will get you an effective user data transfer rate of
125 Kbits/second.

> The stepper phase signals are of interest because they can sink some
> current,

No, they can't. They're TTL signals. The drive has ULN2803A drivers.

> Now, is the rest of the memory map pretty much the same as on the ][+, that
> is, can one rely on finding the small 256-byte blocks associated with each
> "slot"? That's way more than I'd need for a channel.

No, the "slot" memory is taken up by the IIc ROM.
Received on Tue Aug 08 2000 - 14:38:36 BST