home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / apple / appledrv.dqc / APPLEDRV.DOC
Encoding:
Text File  |  1985-02-10  |  3.5 KB  |  67 lines
  1. Date: Sunday, 3 June 1984
  2. From: decvax!cwruecmp!cmf
  3. To:   net.micro
  4. Re:   Apple drives may have more storage?
  5.  
  6. There seems to be some confusion (this may be an understatement) about
  7. exactly what an Apple disk drive is and what it will do.  This may be a
  8. bit technical, but here goes...
  9.  
  10. The mechanics (i.e. head, motors, chassis, etc.) of the Apple drives
  11. are equivalent to those of a Shugart SA400.  Shugarts were used for a
  12. while, but reliability problems started cropping up, and they switched
  13. to ALPS drives.  In any case, these are your standard, run-of-the-mill,
  14. 48 TPI floppy drives.  Only 35 out of the 40 available tracks are used,
  15. probably because 35 track drives are cheaper, being older.  The
  16. recording method used is FM.  However, they pack 4K on a track, which
  17. is the same density as most MFM disks.  In fact, if the Apple drive
  18. used 40 tracks and both sides (like some of the Rana and other drives),
  19. it would have 320K per disk, just like an IBM PC.  Now, you may ask,
  20. how does the Apple get MFM data density with FM data rates and
  21. encoding?  The answer is a very clever recording method called MGCR
  22. (stands for Modified Group Code Recording).  Thanks to some wizardry
  23. (no lesser adjective is appropriate) on the part of Steve Wozniak, this
  24. is done with a handful of cheap chips (look closely at the Apple
  25. controller sometime).
  26.  
  27. The basic idea involved in FM is to have a stream of clock bits with a
  28. stream of data bits interleaved.  MFM takes this and fudges with the
  29. clock bits (sorry for the lack of technical accuracy, folks), sometimes
  30. dropping them altogether in order to fit in the data.  On the average,
  31. there are more flux changes per unit length, and thus a higher bit
  32. density.  MGCR takes the data bit stream and breaks it up into 6-bit
  33. groups.  It maps these groups to 8-bit groups (hence the name "group
  34. code recording") which represent flux changes on the disk.  No clock
  35. bits are used.  Instead, each 8-bit group conforms to a simple set of
  36. restrictions regarding number of consecutive 0 bits and others
  37. (including the high bit being high (no pun intended)).  These
  38. restrictions allow the nifto Woz state machine on the controller to
  39. keep track of everything and stay synced up.  This technique is used
  40. for high-density tape drives and on the MAC.  In short, it gives you
  41. double-density with single-density physical bit density (flux changes
  42. per unit length), and hence, greater reliabilty.
  43.  
  44. It's too bad everyone else uses flakey old MFM.  Oh, well.
  45.  
  46. On the issue of 96 TPI drives, etc.:
  47.  
  48. The stepper for the head on Apple-compatible drives is controlled
  49. directly by the 6502.  The existing code in DOS will step at 96 TPI
  50. even with a 48 TPI mechanism.  Several copy-protection schemes rely on
  51. this so-called "half-tracking" ability.  In fact, with appropriate
  52. incantations, you can step the head at 192 TPI.  There's only one small
  53. catch:  a 48 TPI head is twice as wide as the one on a 96 TPI mechanism.
  54. Therefore, a standard Apple drive will not quite handle 96 TPI.  A 96
  55. TPI mechanism will.  This is the trick by which the Rana and other 96
  56. TPI drives will boot and run 48 TPI (standard) disks without
  57. complaining.  They look like normal drives, but can handle the higher
  58. track density.  One wonders why Apple doesn't bring out 80 track,
  59. double sided drives.  Again, Oh well.
  60.  
  61.                 --Clayton Elwell
  62.                 ...!cbosgd!osu-dbs!elwell
  63.                 despite the address on the header of
  64.                 this message.
  65.  
  66. P.S. Flames are welcome, but do not send to cwruecmp!cmf...
  67.