Amiga floppy disks and GCR vs MFM

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












6















According to https://en.wikipedia.org/wiki/Group_coded_recording the Commodore 1541 disk drive used a particularly efficient GCR encoding scheme to cram 170K onto the same 5.25" disks that in an Apple drive only stored 140K.



However, for the Amiga 3.5" disks, they reverted to MFM, a lower density encoding. Why abandon something that worked so well?



According to 'Amiga Disk Encoding Schemes MFM? GCR? Please explain!' by Betty Clay,



"[GCR] would appear to let a disk hold far more information than could be stored under most other methods. However, since GCR permits the use of as many as eight on-bits in a row, the drive cannot interpret them at full speed. It is necessary to write or read at only half the normal speed, in order to insure accuracy. When the writing speed is slowed to four microseconds per bit instead of the normal two, the density of the data is only half as much, cutting drastically into the storage advantage."



That would indeed seem to eliminate the advantage of GCR. but then why did that disadvantage not apply to its use for 5.25" disks? Is it a limitation of the rate at which the electronics can process the bits, or of the physics of the interaction of the drive head with the magnetic fields?










share|improve this question

















  • 4





    The Amiga was designed by a different company and bought by Commodore. So it isn't like Commodore was abandoning what was done in the 1541. Amiga Inc. just wasn't basing their work on Commodore's computers.

    – vacawama
    Jan 24 at 14:22















6















According to https://en.wikipedia.org/wiki/Group_coded_recording the Commodore 1541 disk drive used a particularly efficient GCR encoding scheme to cram 170K onto the same 5.25" disks that in an Apple drive only stored 140K.



However, for the Amiga 3.5" disks, they reverted to MFM, a lower density encoding. Why abandon something that worked so well?



According to 'Amiga Disk Encoding Schemes MFM? GCR? Please explain!' by Betty Clay,



"[GCR] would appear to let a disk hold far more information than could be stored under most other methods. However, since GCR permits the use of as many as eight on-bits in a row, the drive cannot interpret them at full speed. It is necessary to write or read at only half the normal speed, in order to insure accuracy. When the writing speed is slowed to four microseconds per bit instead of the normal two, the density of the data is only half as much, cutting drastically into the storage advantage."



That would indeed seem to eliminate the advantage of GCR. but then why did that disadvantage not apply to its use for 5.25" disks? Is it a limitation of the rate at which the electronics can process the bits, or of the physics of the interaction of the drive head with the magnetic fields?










share|improve this question

















  • 4





    The Amiga was designed by a different company and bought by Commodore. So it isn't like Commodore was abandoning what was done in the 1541. Amiga Inc. just wasn't basing their work on Commodore's computers.

    – vacawama
    Jan 24 at 14:22













6












6








6








According to https://en.wikipedia.org/wiki/Group_coded_recording the Commodore 1541 disk drive used a particularly efficient GCR encoding scheme to cram 170K onto the same 5.25" disks that in an Apple drive only stored 140K.



However, for the Amiga 3.5" disks, they reverted to MFM, a lower density encoding. Why abandon something that worked so well?



According to 'Amiga Disk Encoding Schemes MFM? GCR? Please explain!' by Betty Clay,



"[GCR] would appear to let a disk hold far more information than could be stored under most other methods. However, since GCR permits the use of as many as eight on-bits in a row, the drive cannot interpret them at full speed. It is necessary to write or read at only half the normal speed, in order to insure accuracy. When the writing speed is slowed to four microseconds per bit instead of the normal two, the density of the data is only half as much, cutting drastically into the storage advantage."



That would indeed seem to eliminate the advantage of GCR. but then why did that disadvantage not apply to its use for 5.25" disks? Is it a limitation of the rate at which the electronics can process the bits, or of the physics of the interaction of the drive head with the magnetic fields?










share|improve this question














According to https://en.wikipedia.org/wiki/Group_coded_recording the Commodore 1541 disk drive used a particularly efficient GCR encoding scheme to cram 170K onto the same 5.25" disks that in an Apple drive only stored 140K.



However, for the Amiga 3.5" disks, they reverted to MFM, a lower density encoding. Why abandon something that worked so well?



According to 'Amiga Disk Encoding Schemes MFM? GCR? Please explain!' by Betty Clay,



"[GCR] would appear to let a disk hold far more information than could be stored under most other methods. However, since GCR permits the use of as many as eight on-bits in a row, the drive cannot interpret them at full speed. It is necessary to write or read at only half the normal speed, in order to insure accuracy. When the writing speed is slowed to four microseconds per bit instead of the normal two, the density of the data is only half as much, cutting drastically into the storage advantage."



That would indeed seem to eliminate the advantage of GCR. but then why did that disadvantage not apply to its use for 5.25" disks? Is it a limitation of the rate at which the electronics can process the bits, or of the physics of the interaction of the drive head with the magnetic fields?







hardware amiga floppy-disk commodore






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 24 at 3:26









rwallacerwallace

9,031445131




9,031445131







  • 4





    The Amiga was designed by a different company and bought by Commodore. So it isn't like Commodore was abandoning what was done in the 1541. Amiga Inc. just wasn't basing their work on Commodore's computers.

    – vacawama
    Jan 24 at 14:22












  • 4





    The Amiga was designed by a different company and bought by Commodore. So it isn't like Commodore was abandoning what was done in the 1541. Amiga Inc. just wasn't basing their work on Commodore's computers.

    – vacawama
    Jan 24 at 14:22







4




4





The Amiga was designed by a different company and bought by Commodore. So it isn't like Commodore was abandoning what was done in the 1541. Amiga Inc. just wasn't basing their work on Commodore's computers.

– vacawama
Jan 24 at 14:22





The Amiga was designed by a different company and bought by Commodore. So it isn't like Commodore was abandoning what was done in the 1541. Amiga Inc. just wasn't basing their work on Commodore's computers.

– vacawama
Jan 24 at 14:22










4 Answers
4






active

oldest

votes


















12














On a floppy disk, each 'bit' is a flux reversal — a magnetic event. If those bits are too close together, they'll leak into one another and data will be lost.



Disk controllers use a regular clock and either write a transition or write nothing at each clock tick.



There's also a lower limit on how far apart transitions can be. Disk rotation speed varies according to the whims of the motor, aerodynamic drag, etc, and drives contain automatic gain controls — if they think they aren't seeing data but should be, they turn up their own volume.



So bits need to be regular enough that the controller doesn't have to make too many guesses about rotation speed, and the drive doesn't turn up its gain so far that it's reading noise.



As a result, the bit patterns that drives actually write are a translation of the bytes to be stored into some other encoding, that guarantees bits aren't too far apart, and aren't too close together.



FM and the GCR schemes solve for too far apart differently, but use the same solution for ensuring bits can't be too close together: their data clock is picked so that each tick is far enough apart that two will never be too close. The GCR schemes then do a better job of making sure that they're not too far apart than does FM: FM encoding uses two output bits per input bit, but e.g. Apple's second GCR encoding uses only eight output bits for six inputs.



MFM is a later development than GCR and provides a different solution to the too-close-together problem: it guarantees that there are no sequences that lead to two bits being output consecutively. So, you can double the data clock without fear of magnetic collision. Like FM it also produces two output bits per input, but those two fit into the same physical space as one FM bit. Hence: double density.



MFM is an equally valid improvement for 5.25" drives as it is for any other, and is better than both company's GCRs; the reason that Apple and Commodore each came up with GCR schemes is that they were coming up with something better than FM, not rejecting MFM — both companies released drives before MFM controllers were available.






share|improve this answer


















  • 5





    MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

    – supercat
    Jan 24 at 6:27


















2














No answer yet told about the four different writing speeds the Commodore 8-Bit floppies used. That way, it could store



 Track Sectors/track Sum Sectors Storage in Bytes/track
----- ------------- ----------- ----------------------
1-17 21 357 7820
18-24 19 133 7170
25-30 18 108 6300
31-40(*) 17 85 6020
---
683 (for a 35 track image)


while one-speed FM/MFM floppies have to use the smaller number of bytes per track on the outer tracks, too.



The only other system I know which did that was an Olivetti PC with FM floppies. Totally incompatible to anything. Other than the Commodore 8-Bit floppies, it changed the physical drive speed instead of the writing speed.






share|improve this answer






























    1














    I think that the reason was simple: amiga used standard (well, nearly standard) double-density disk drives. This is untrue for 1541, that used non-standard disk drive (consisting of only mechanical parts) and quite sophisticated controller circuity, that includes analog parts (read and write amplifiers, disk motor driver).



    The standard drive was optimized for standard bitrate -- so no even emulation of CLV by switching bit frequency is possible -- as 1541 did.



    The MFM/GCR difference is actually less important part since again disk drive is not aware of the specific encoding. If you wish, you can use GCR encoding with amiga as well -- because amiga FDC does not do any MFM encoding or decoding. That is done by either CPU or blitter.






    share|improve this answer






























      1














      Aside from the technical aspects: when early floppy systems came out, disks were expensive and higher capacity was a selling point. By the time that 3½" disks were popular, the media was cheaper and it wasn't worth the effort of having complex controllers to save a few bytes.






      share|improve this answer






















        Your Answer








        StackExchange.ready(function()
        var channelOptions =
        tags: "".split(" "),
        id: "648"
        ;
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function()
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled)
        StackExchange.using("snippets", function()
        createEditor();
        );

        else
        createEditor();

        );

        function createEditor()
        StackExchange.prepareEditor(
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader:
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        ,
        noCode: true, onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        );



        );













        draft saved

        draft discarded


















        StackExchange.ready(
        function ()
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8928%2famiga-floppy-disks-and-gcr-vs-mfm%23new-answer', 'question_page');

        );

        Post as a guest















        Required, but never shown

























        4 Answers
        4






        active

        oldest

        votes








        4 Answers
        4






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        12














        On a floppy disk, each 'bit' is a flux reversal — a magnetic event. If those bits are too close together, they'll leak into one another and data will be lost.



        Disk controllers use a regular clock and either write a transition or write nothing at each clock tick.



        There's also a lower limit on how far apart transitions can be. Disk rotation speed varies according to the whims of the motor, aerodynamic drag, etc, and drives contain automatic gain controls — if they think they aren't seeing data but should be, they turn up their own volume.



        So bits need to be regular enough that the controller doesn't have to make too many guesses about rotation speed, and the drive doesn't turn up its gain so far that it's reading noise.



        As a result, the bit patterns that drives actually write are a translation of the bytes to be stored into some other encoding, that guarantees bits aren't too far apart, and aren't too close together.



        FM and the GCR schemes solve for too far apart differently, but use the same solution for ensuring bits can't be too close together: their data clock is picked so that each tick is far enough apart that two will never be too close. The GCR schemes then do a better job of making sure that they're not too far apart than does FM: FM encoding uses two output bits per input bit, but e.g. Apple's second GCR encoding uses only eight output bits for six inputs.



        MFM is a later development than GCR and provides a different solution to the too-close-together problem: it guarantees that there are no sequences that lead to two bits being output consecutively. So, you can double the data clock without fear of magnetic collision. Like FM it also produces two output bits per input, but those two fit into the same physical space as one FM bit. Hence: double density.



        MFM is an equally valid improvement for 5.25" drives as it is for any other, and is better than both company's GCRs; the reason that Apple and Commodore each came up with GCR schemes is that they were coming up with something better than FM, not rejecting MFM — both companies released drives before MFM controllers were available.






        share|improve this answer


















        • 5





          MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

          – supercat
          Jan 24 at 6:27















        12














        On a floppy disk, each 'bit' is a flux reversal — a magnetic event. If those bits are too close together, they'll leak into one another and data will be lost.



        Disk controllers use a regular clock and either write a transition or write nothing at each clock tick.



        There's also a lower limit on how far apart transitions can be. Disk rotation speed varies according to the whims of the motor, aerodynamic drag, etc, and drives contain automatic gain controls — if they think they aren't seeing data but should be, they turn up their own volume.



        So bits need to be regular enough that the controller doesn't have to make too many guesses about rotation speed, and the drive doesn't turn up its gain so far that it's reading noise.



        As a result, the bit patterns that drives actually write are a translation of the bytes to be stored into some other encoding, that guarantees bits aren't too far apart, and aren't too close together.



        FM and the GCR schemes solve for too far apart differently, but use the same solution for ensuring bits can't be too close together: their data clock is picked so that each tick is far enough apart that two will never be too close. The GCR schemes then do a better job of making sure that they're not too far apart than does FM: FM encoding uses two output bits per input bit, but e.g. Apple's second GCR encoding uses only eight output bits for six inputs.



        MFM is a later development than GCR and provides a different solution to the too-close-together problem: it guarantees that there are no sequences that lead to two bits being output consecutively. So, you can double the data clock without fear of magnetic collision. Like FM it also produces two output bits per input, but those two fit into the same physical space as one FM bit. Hence: double density.



        MFM is an equally valid improvement for 5.25" drives as it is for any other, and is better than both company's GCRs; the reason that Apple and Commodore each came up with GCR schemes is that they were coming up with something better than FM, not rejecting MFM — both companies released drives before MFM controllers were available.






        share|improve this answer


















        • 5





          MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

          – supercat
          Jan 24 at 6:27













        12












        12








        12







        On a floppy disk, each 'bit' is a flux reversal — a magnetic event. If those bits are too close together, they'll leak into one another and data will be lost.



        Disk controllers use a regular clock and either write a transition or write nothing at each clock tick.



        There's also a lower limit on how far apart transitions can be. Disk rotation speed varies according to the whims of the motor, aerodynamic drag, etc, and drives contain automatic gain controls — if they think they aren't seeing data but should be, they turn up their own volume.



        So bits need to be regular enough that the controller doesn't have to make too many guesses about rotation speed, and the drive doesn't turn up its gain so far that it's reading noise.



        As a result, the bit patterns that drives actually write are a translation of the bytes to be stored into some other encoding, that guarantees bits aren't too far apart, and aren't too close together.



        FM and the GCR schemes solve for too far apart differently, but use the same solution for ensuring bits can't be too close together: their data clock is picked so that each tick is far enough apart that two will never be too close. The GCR schemes then do a better job of making sure that they're not too far apart than does FM: FM encoding uses two output bits per input bit, but e.g. Apple's second GCR encoding uses only eight output bits for six inputs.



        MFM is a later development than GCR and provides a different solution to the too-close-together problem: it guarantees that there are no sequences that lead to two bits being output consecutively. So, you can double the data clock without fear of magnetic collision. Like FM it also produces two output bits per input, but those two fit into the same physical space as one FM bit. Hence: double density.



        MFM is an equally valid improvement for 5.25" drives as it is for any other, and is better than both company's GCRs; the reason that Apple and Commodore each came up with GCR schemes is that they were coming up with something better than FM, not rejecting MFM — both companies released drives before MFM controllers were available.






        share|improve this answer













        On a floppy disk, each 'bit' is a flux reversal — a magnetic event. If those bits are too close together, they'll leak into one another and data will be lost.



        Disk controllers use a regular clock and either write a transition or write nothing at each clock tick.



        There's also a lower limit on how far apart transitions can be. Disk rotation speed varies according to the whims of the motor, aerodynamic drag, etc, and drives contain automatic gain controls — if they think they aren't seeing data but should be, they turn up their own volume.



        So bits need to be regular enough that the controller doesn't have to make too many guesses about rotation speed, and the drive doesn't turn up its gain so far that it's reading noise.



        As a result, the bit patterns that drives actually write are a translation of the bytes to be stored into some other encoding, that guarantees bits aren't too far apart, and aren't too close together.



        FM and the GCR schemes solve for too far apart differently, but use the same solution for ensuring bits can't be too close together: their data clock is picked so that each tick is far enough apart that two will never be too close. The GCR schemes then do a better job of making sure that they're not too far apart than does FM: FM encoding uses two output bits per input bit, but e.g. Apple's second GCR encoding uses only eight output bits for six inputs.



        MFM is a later development than GCR and provides a different solution to the too-close-together problem: it guarantees that there are no sequences that lead to two bits being output consecutively. So, you can double the data clock without fear of magnetic collision. Like FM it also produces two output bits per input, but those two fit into the same physical space as one FM bit. Hence: double density.



        MFM is an equally valid improvement for 5.25" drives as it is for any other, and is better than both company's GCRs; the reason that Apple and Commodore each came up with GCR schemes is that they were coming up with something better than FM, not rejecting MFM — both companies released drives before MFM controllers were available.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 24 at 4:31









        TommyTommy

        14.7k14073




        14.7k14073







        • 5





          MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

          – supercat
          Jan 24 at 6:27












        • 5





          MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

          – supercat
          Jan 24 at 6:27







        5




        5





        MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

        – supercat
        Jan 24 at 6:27





        MFM requires a higher bit rate and an ability to more accurately measure flux-transition widths. The design of the Disk-II controller is very much tied to the fact that the worst-case time for a branch-until-ready loop on the 6502 is slightly less than two bit times, and would require extra buffering if that were not the case.

        – supercat
        Jan 24 at 6:27











        2














        No answer yet told about the four different writing speeds the Commodore 8-Bit floppies used. That way, it could store



         Track Sectors/track Sum Sectors Storage in Bytes/track
        ----- ------------- ----------- ----------------------
        1-17 21 357 7820
        18-24 19 133 7170
        25-30 18 108 6300
        31-40(*) 17 85 6020
        ---
        683 (for a 35 track image)


        while one-speed FM/MFM floppies have to use the smaller number of bytes per track on the outer tracks, too.



        The only other system I know which did that was an Olivetti PC with FM floppies. Totally incompatible to anything. Other than the Commodore 8-Bit floppies, it changed the physical drive speed instead of the writing speed.






        share|improve this answer



























          2














          No answer yet told about the four different writing speeds the Commodore 8-Bit floppies used. That way, it could store



           Track Sectors/track Sum Sectors Storage in Bytes/track
          ----- ------------- ----------- ----------------------
          1-17 21 357 7820
          18-24 19 133 7170
          25-30 18 108 6300
          31-40(*) 17 85 6020
          ---
          683 (for a 35 track image)


          while one-speed FM/MFM floppies have to use the smaller number of bytes per track on the outer tracks, too.



          The only other system I know which did that was an Olivetti PC with FM floppies. Totally incompatible to anything. Other than the Commodore 8-Bit floppies, it changed the physical drive speed instead of the writing speed.






          share|improve this answer

























            2












            2








            2







            No answer yet told about the four different writing speeds the Commodore 8-Bit floppies used. That way, it could store



             Track Sectors/track Sum Sectors Storage in Bytes/track
            ----- ------------- ----------- ----------------------
            1-17 21 357 7820
            18-24 19 133 7170
            25-30 18 108 6300
            31-40(*) 17 85 6020
            ---
            683 (for a 35 track image)


            while one-speed FM/MFM floppies have to use the smaller number of bytes per track on the outer tracks, too.



            The only other system I know which did that was an Olivetti PC with FM floppies. Totally incompatible to anything. Other than the Commodore 8-Bit floppies, it changed the physical drive speed instead of the writing speed.






            share|improve this answer













            No answer yet told about the four different writing speeds the Commodore 8-Bit floppies used. That way, it could store



             Track Sectors/track Sum Sectors Storage in Bytes/track
            ----- ------------- ----------- ----------------------
            1-17 21 357 7820
            18-24 19 133 7170
            25-30 18 108 6300
            31-40(*) 17 85 6020
            ---
            683 (for a 35 track image)


            while one-speed FM/MFM floppies have to use the smaller number of bytes per track on the outer tracks, too.



            The only other system I know which did that was an Olivetti PC with FM floppies. Totally incompatible to anything. Other than the Commodore 8-Bit floppies, it changed the physical drive speed instead of the writing speed.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 24 at 16:36









            JankaJanka

            1,47938




            1,47938





















                1














                I think that the reason was simple: amiga used standard (well, nearly standard) double-density disk drives. This is untrue for 1541, that used non-standard disk drive (consisting of only mechanical parts) and quite sophisticated controller circuity, that includes analog parts (read and write amplifiers, disk motor driver).



                The standard drive was optimized for standard bitrate -- so no even emulation of CLV by switching bit frequency is possible -- as 1541 did.



                The MFM/GCR difference is actually less important part since again disk drive is not aware of the specific encoding. If you wish, you can use GCR encoding with amiga as well -- because amiga FDC does not do any MFM encoding or decoding. That is done by either CPU or blitter.






                share|improve this answer



























                  1














                  I think that the reason was simple: amiga used standard (well, nearly standard) double-density disk drives. This is untrue for 1541, that used non-standard disk drive (consisting of only mechanical parts) and quite sophisticated controller circuity, that includes analog parts (read and write amplifiers, disk motor driver).



                  The standard drive was optimized for standard bitrate -- so no even emulation of CLV by switching bit frequency is possible -- as 1541 did.



                  The MFM/GCR difference is actually less important part since again disk drive is not aware of the specific encoding. If you wish, you can use GCR encoding with amiga as well -- because amiga FDC does not do any MFM encoding or decoding. That is done by either CPU or blitter.






                  share|improve this answer

























                    1












                    1








                    1







                    I think that the reason was simple: amiga used standard (well, nearly standard) double-density disk drives. This is untrue for 1541, that used non-standard disk drive (consisting of only mechanical parts) and quite sophisticated controller circuity, that includes analog parts (read and write amplifiers, disk motor driver).



                    The standard drive was optimized for standard bitrate -- so no even emulation of CLV by switching bit frequency is possible -- as 1541 did.



                    The MFM/GCR difference is actually less important part since again disk drive is not aware of the specific encoding. If you wish, you can use GCR encoding with amiga as well -- because amiga FDC does not do any MFM encoding or decoding. That is done by either CPU or blitter.






                    share|improve this answer













                    I think that the reason was simple: amiga used standard (well, nearly standard) double-density disk drives. This is untrue for 1541, that used non-standard disk drive (consisting of only mechanical parts) and quite sophisticated controller circuity, that includes analog parts (read and write amplifiers, disk motor driver).



                    The standard drive was optimized for standard bitrate -- so no even emulation of CLV by switching bit frequency is possible -- as 1541 did.



                    The MFM/GCR difference is actually less important part since again disk drive is not aware of the specific encoding. If you wish, you can use GCR encoding with amiga as well -- because amiga FDC does not do any MFM encoding or decoding. That is done by either CPU or blitter.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Jan 24 at 13:23









                    lvdlvd

                    2,658618




                    2,658618





















                        1














                        Aside from the technical aspects: when early floppy systems came out, disks were expensive and higher capacity was a selling point. By the time that 3½" disks were popular, the media was cheaper and it wasn't worth the effort of having complex controllers to save a few bytes.






                        share|improve this answer



























                          1














                          Aside from the technical aspects: when early floppy systems came out, disks were expensive and higher capacity was a selling point. By the time that 3½" disks were popular, the media was cheaper and it wasn't worth the effort of having complex controllers to save a few bytes.






                          share|improve this answer

























                            1












                            1








                            1







                            Aside from the technical aspects: when early floppy systems came out, disks were expensive and higher capacity was a selling point. By the time that 3½" disks were popular, the media was cheaper and it wasn't worth the effort of having complex controllers to save a few bytes.






                            share|improve this answer













                            Aside from the technical aspects: when early floppy systems came out, disks were expensive and higher capacity was a selling point. By the time that 3½" disks were popular, the media was cheaper and it wasn't worth the effort of having complex controllers to save a few bytes.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Jan 24 at 13:53









                            scrussscruss

                            6,80711247




                            6,80711247



























                                draft saved

                                draft discarded
















































                                Thanks for contributing an answer to Retrocomputing Stack Exchange!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid


                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.

                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function ()
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8928%2famiga-floppy-disks-and-gcr-vs-mfm%23new-answer', 'question_page');

                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown






                                Popular posts from this blog

                                How to check contact read email or not when send email to Individual?

                                Bahrain

                                Postfix configuration issue with fips on centos 7; mailgun relay