home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.96 / text3965.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  6.8 KB  |  134 lines
  1.     id m0u3zLa-0007rNa; Mon, 1 Apr 96 23:13 MST
  2. Sender: owner-executor
  3. Received: from ardi.com by ftp.ardi.com
  4.     (Smail3.1.29.1 #3) id m0u3zL2-0007rKn; Mon, 1 Apr 96 23:13 MST
  5. Path: sloth.swcp.com!tesuque.cs.sandia.gov!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!noao!ennfs.eas.asu.edu!cs.utexas.edu!uwm.edu!lll-winken.llnl.gov!nntp.coast.net!fu-berlin.de!zrz.TU-Berlin.DE!news.dfn.de!uni-muenster.de!news
  6. From: gutschk@uni-muenster.de (Markus Gutschke)
  7. Newsgroups: comp.emulators.mac.executor
  8. Subject: Re: mac 800k disks
  9. Date: 01 Apr 1996 08:46:46 GMT
  10. Organization: Markus Gutschke, Schlage 5a, 48268 Greven-Gimbte, Germany
  11. Lines: 110
  12. Message-ID: <GUTSCHK.96Apr1104646corpus@uni-muenster.de>
  13. References: <Doy90x.8wE@cix.compulink.co.uk> <DozB2p.DLx@statcan.ca>
  14. NNTP-Posting-Host: pppe091.uni-muenster.de
  15. Mime-Version: 1.0 (generated by tm-edit 7.41)
  16. Content-Type: text/plain; charset=US-ASCII
  17. In-reply-to: royfran@statcan.ca's message of Thu, 28 Mar 1996 13:06:24 GMT
  18. To: executor@ardi.com
  19. X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
  20. Sender: owner-executor@ardi.com
  21. Precedence: bulk
  22.  
  23. -----BEGIN PGP SIGNED MESSAGE-----
  24.  
  25. In article <DozB2p.DLx@statcan.ca> royfran@statcan.ca (Francois Roy) writes:
  26. > Rob Heath (rheath@cix.compulink.co.uk) wrote:
  27. > : is there any program out there that will read 800k mac floppy disks?
  28. > 
  29. > As far as I know, there isn't.  From what I've heard, the 800k floppys
  30. > are written with a different speed of rotation depending on whether you
  31. > are writing on the outer or the inner tracks.  The drives on PCs all
  32. > operate at a constant rotational speed.
  33.  
  34. It is a common trick (used by harddrive manufacturers) to increase the
  35. data density on the outer tracks, but I do not know whether the Mac
  36. actually makes use of this for its 800k floppy disks.
  37.  
  38. But the main problem with trying to use 800k floppy disks on a PC is
  39. different from that (I try to explain just the basic concepts; if you
  40. do not like the simplifications that I make, either get hold of good
  41. documentation on these topics or ask me and I will try to look it up):
  42.  
  43. The data on each track of a the floppy disk is basically a cyclical
  44. stream of "one" and "zero" bits. There is no way, that the hardware
  45. could tell where the data starts and where it ends. Thus this
  46. information needs to be somehow encoded into the data stream; a very
  47. simplistic approach could work like this:
  48.  
  49.  1) expand every byte ( = 8 bits) of data to be 9 bits long
  50.  2) for regular user-supplied data, that is to be stored on the disk,
  51.     set the 9th bit to "one"
  52.  3) for synchronisation information, set the 9th bit to "zero"
  53.  4) mark the beginning of each data block, that contains just
  54.     synchronisation data, but nine consecutive "zero" bits.
  55.  
  56. This way we would waste a little more than 11% of disk capacity, but
  57. we could now tell where to start looking for data. Unfortunately, this
  58. will fail if the user data contains long blocks of 0xFF bytes (all
  59. bits set). Small deviations in rotational velocity would cause us to
  60. get out of phase and we would then read bogus data.
  61.  
  62. Therefore, encoding mechanisms have been designed which guarantee,
  63. that there will be no more than a certain amount of consecutive bits
  64. with the same value. This enables us to obtain clock information and
  65. re-synchronize on the data stream while reading the data. Besides, it
  66. offers a new improved technique for marking the beginning of
  67. synchronisation information. Now, there are sequences of bits, that
  68. are definitly "illegal" with regard to our encoding scheme; these
  69. sequences are used to mark "out-of-band" data.
  70.  
  71. As computer technology improved, different encoding schemes were used;
  72. some of the more important schemes where named FM, GCR, MFM, and
  73. RLL. In early days, the computer's CPU would actively do the
  74. encoding/decoding. Thus it did not really matter, if a new encoding
  75. scheme was developed; as long as the CPU was sufficiently fast, all
  76. you had to do was upgrading your software. This was the case for the
  77. Commodore C64 and for the Apple II. Later, some dedicated hardware was
  78. designed that assisted the CPU while still retaining flexibility and
  79. allowing for different encoding schemes. As far as I can tell this is
  80. the case with the Commodore Amiga and the Apple MacIntosh. At about
  81. the same time, MFM encoding became very popular and developed into the
  82. dominating encoding scheme. Thus chip designers, developed a "floppy
  83. disk controller" that would do *all* of the encoding/decoding. This is
  84. what is done in current PC's.
  85.  
  86. The PC has always used MFM encoding (even though RLL encoding would
  87. bring a 50% improvement in data capacity), but the data density has
  88. increased considerably from single sided, 40 tracks, 9 sectors (this
  89. gives 180kB) to double sided, 80 tracks, 18 sectors (this gives 1.44
  90. MB). I believe there have been some other formats that stored even
  91. less data and there also is a format that stores 2.88 MB (while using
  92. 36 sectors), but I think these have never been really popular.
  93.  
  94. The Apple MacIntosh used to have its own proprietary format. I do not
  95. know much about the encoding scheme other than one reference that I
  96. found; it states something about "6-out-of-2" coding. Back in the
  97. days, when "double density" disks (720kB) where popular, the Apple
  98. MacIntosh had the advantage of storing about 10% more data (800kB) on
  99. the same medium. But when "high density" disks (1.44MB) became
  100. commonly available, Apple had to decide whether they wanted to come up
  101. with an improved proprietary format or if they would go with the
  102. "industry standard". Fortunately, they decided for the latter. This
  103. has the disadvantage of storing less data than is physically possible
  104. (I believe, advanced encoding schemes can store at least up to 1.8MB
  105. user data on a regular "high density" disk), but finally there is just
  106. one standardized format, which allows for easy exchange of media.
  107.  
  108. Computers such as the Commodore Amiga or the Apple MacIntosh still
  109. have the ability of handling arbitrary encoding schemes, if the CPU is
  110. programmed to recognize this format, but the PC never had this
  111. ability. There are tricks that can be used in order to force the
  112. "floppy controller" into accessing the raw data stream, but this is
  113. usually very unreliable and you will never read the same data
  114. twice. Thus, with sophisticated software it might just be possible to
  115. make the PC read 800kB floppy disks, but I would not trust it to
  116. reliably write these disks.
  117.  
  118. I hope, I cleared up some of the confusion,
  119.  
  120.  
  121. Markus
  122.  
  123. -----BEGIN PGP SIGNATURE-----
  124. Version: 2.6.2
  125. Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
  126.  
  127. iQCVAgUBMV+X7xqJqDLErwMxAQFzPgP/YifZAIPZJl5pA7tatIW8rB/rfEx4VhMz
  128. 6D7u+oQPpTUswmqmbgyFe9Y6JsfKNvzryqt+WCb1Sqeh06bXi57GcB5sLAM8PfRk
  129. 6Cu6HtVzgAXKEraCOOGNjod/ApO8vLAal02nAWivwjMCjq8KiWdMgCjp2EtJj710
  130. vf9terdgnTM=
  131. =V7ai
  132. -----END PGP SIGNATURE-----
  133.  
  134.