Apple IIc (not IIC+) details

"Richard Erlacher" <richard(a)idcomm.com> wrote: 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. No, they can't. They're TTL signals. The drive has ULN2803A drivers. No, the "slot" memory is taken up by the IIc ROM.