This is the program and technique in question:


Also described here:


And here is the unintelligible explanation from the website:

"2MGUI utilized bit banging and tricked the floppy controller into writing a full track of data as a single sector before resetting the floppy controller in order to avoid overwriting the next track, enabling the absolute maximum capacity possible at the physical level. A similar technique was also used by Vincent Joguin's Disk2FDI for Amiga floppies."

Ok, it gets direct access to the floppy controller (instead of using DOS interrupts), with you so far.

And then: "writing a full track of data as a single sector"

Uh, what?

A floppy disk looks like this:

enter image description here

A track consists of multiple sectors, how do you write a full track into a sector?

I can imagine that there would be used some better, more modern encoding scheme than initially used for 1.44 MB floppy disks to achieve higher density. However, if the floppy disk supports writing a full track worth of data into each sector, then why didn't they simply do this originally? Is the data more prone to corruption? Is it that simple -- you can just tell the floppy disk controller to stuff higher density data into a sector than usual, but at the cost of higher error rates?

I don't think it is this simple. Clearly there is a lot more to it than this simple explanation of just stuffing a track into a sector.

  • 1
    You obviously can't write a full track into a single sector. Maybe you misunderstood something, to me it sounds like the floppy controller is manipulated and tricked to write a whole track in one go, which is unusual for PC floppy controllers as it works in sectors, but for Amiga, it can only write a full track in one go, and does not normally support writing single sectors. It does say, "writes full track as a sector" because a sector write is what the controller should be commanded to do normally.
    – Justme
    Commented Jul 25, 2023 at 22:27
  • 1
    @Justme I don't think I misunderstood, I just quoted the website, "tricked the floppy controller into writing a full track of data as a single sector". In fact, I pointed out myself that this makes no sense. How does it help writing one track in "one go" in terms of data density? Commented Jul 25, 2023 at 22:31
  • 2
    As far as I know, 2M uses the ability of standard PC floppy controllers to write sectors in different sizes. Instead of eighteen 512-byte sectors, it writes one 8192-byte sector, followed by (If I remember correctly - big IF) one 2048-byte sector and one 1024-byte sector. Since there are fewer gaps, there is more usable data on the track.
    – TeaRex
    Commented Jul 25, 2023 at 22:34
  • 2
    You did ask how does one write a full track into a sector, so I assumed that's how you interpreted it. Anyway, writing a full track, with all sectors in one go, means that you can write them as tightly packed as you can and you don't need to leave gaps between sectors to allow for normal floppy writing to work. The gaps are needed to scan (read) when a sector is under the read/write head, to turn on the erase head and write head to write to sector's area, and after writing, some time to turn off erase and write head. Which is why gaps of suitable size between sectors is needed.
    – Justme
    Commented Jul 25, 2023 at 22:38
  • 1
    And actually, it is a tradeoff. If you want to have suitable sized chunks (sectors) that are easily individually addressable for reading and writing, but don't need to stuff data extremely tightly, you use sectoring. If you are like Amiga which for even reading or writing a single sector, it must read the whole track, find the sector in software, and prepare a new full track in software to write it to disk. Basically the downside is that your track can be just one single really big sector so you need few kilobytes of storage to change one single byte, and early computers didn't have space.
    – Justme
    Commented Jul 25, 2023 at 22:48

2 Answers 2


A typical floppy disk track will contain, depending upon the exact medium, between 8 and 24 repetitions of the pattern "sector header, sector data; sector header, sector data", etc. Each sector header contains a flux transition sequence that is only allowed to appear at the start of a sector header, followed by information about the sector. Each sector's data starts with a flux transition sequence that is only allowed to appear at the start of a sector's data, followed by the data itself.

In order to read a sector, the drive controller will look for a sector header marker, then read the information about the sector to see if it's the one of interest. If not, it will revert to looking for the next a header marker. Once the desired sector is found, it will watch, briefly, for the "Start of data" marker and once it is seen, read a sector's worth of data. If the start of data marker wasn't seen very soon after the sector header, the drive should revert to looking for another sector header.

To write a sector, the drive controller will look for a sector header as above, but once it has seen the right sector it will write out the sector data marker and a sector worth of data, blindly overwriting whatever passes under the head. In order to avoid overwriting the start of the next sector, the controller must be certain that it finishes writing a sector before the data for the next sector spins under the head. To accommodate the possibility that data might be written with a drive that's spinning faster than the drive used to write it originally, disks are formatted with some unused space between sectors.

The 512-byte sectors used on PC-DOS disks represent a trade-off between buffering requirements and inter-sector waste space. Using larger sectors would reduce the amount of space wasted between sectors, but because updating even a single byte in a file requires reading an entire sector, editing the data in RAM, and writing the entire sector back, using larger sectors would make it necessary to read or write more data at once.

  • Excellent. So the tradeoff is only saving RAM? Wow. Makes sense for when the floppy disk standard was introduced, I suppose. Thanks. Commented Jul 25, 2023 at 22:45
  • 4
    It saves also speed. You read a single 512 byte sector, modify it, and write a 512 byte sector back. Instead of transferring 9 kilobytes back and forth if only 1 byte is changed.
    – Justme
    Commented Jul 25, 2023 at 22:51
  • 5
    @AlphaCentauri: The other issue I should have made clear is that writing any amount less than a sector requires using a read-modify-write sequence, but writing one or more complete sectors does not. If one wants to be able to have a track contain parts of more than one file, having parts of multiple files in one sector would mean rewriting any of them would require a read-modify-write.
    – supercat
    Commented Jul 25, 2023 at 22:51
  • @supercat Sounds a bit similar to modern flash memory. Commented Jul 29, 2023 at 0:36
  • @AlphaCentauri: Modern flash memory can handle appends, and requires erasing a rather large chunk of memory in order to allow reuse of any of it.
    – supercat
    Commented Jul 29, 2023 at 2:14

The description of that format does not hint what exactly is used, but there are essentially four ways of stuffing more data into a track, all based on reducing the format overhead of regular sector formatting.

  1. Increased Number of Sectors

    All formats leave a lengthy gap at the end of a track to avoid overwriting the first sector. If a tat gap is large enough, one could instead write an additional sector.

  2. Increased Sector Size

    There is not only a gap between the last and the first sector of a track but also one between each sector as well as between sector header and sector data. Having less sectors not only means less gaps between then and between header and sector, but also less headers. That can be done in various ways:

    1. A) Symmetric Increased Sector Size

      All sectors are increased by the same factor, hoping that with enough reduction in sector number space for one more is provided.

    2. B) Filling Up With Variable Size

      Increased sector size may not always produce size allowing even distribution of a track, which would result in a gap too small for another sector. This method adds sectors of smaller size until that gap is filled as much as possible.

    3. C) Writing a Single Sector Per Track

      That's essentially putting #2 to the max. A sector equals a track. Having only one sector means also only a single gap between header and sector and a single gap at the end of the track. All overhead is reduced to the absolute minimum possible.

  3. Writing a Track With Only Minimal Gap Size

    Here Sectors are written as usual but the gap between header and data as well as between sectors are reduced to the absolute minimum needed for synchronisation. This can only be done when the whole track is written as one using a special command.

A lot can be done, isn't it? But all of these have their issues. And all of them are about timing - or better timing differences between writing and reading when using different drives. We tend to forget that a floppy recording is not only about encoding data into a time variant signal, but that this signal can be read back at a different timing.

Or in simple words, the drive writing a disk may have had a different rotational speed than the drive a disk is later read and rewritten.

And believe me, there was a lot of variation, especially early on. An SA-400, the grand daddy of all 5.25 drives, was considered in spec when rotation was +/-10%. This means no format should use more than 90% of a track, otherwise the recording may not be compatible with other drives. Since the speed variation does as well influence the space one had to provide for each sector - at least not if a faster drive should be able to rewrite a sector on a disk formatted by a slower drive.

As a result, basic formats usually stayed below 80 % of a track.

(Following all calculation will be done using the basic 5.25 inch, 40 track, MFM drive to keep it simple - application to later 1.44 follows the very same rules, just more tracks and sectors)

#1 is what IBM already did with the PC going from 320 to 360 KiB per disk by writing 9 sectors instead of 8. The original 320 KiB format was developed with a really high security margins, so it may work with the worst drives imaginable (+/- 10%). By the time the IBM-PC was created (1981) Speed variation was down to +/- 4.5%. Together with the previous margin this was enough to squeeze in another sector without increasing risk of overwrite.

Of course, this only works once as a general improvement. Then again, if one had a drive toward the fast side and no need for data exchange another (10th) sector could sometimes be fitted. This was quite common on machines like the Atari ST. Still fully DOS compatible, as DOS takes the number of sectors per track from a disks boot sector, but not always readable on all machines.

#2A is another easy bet, benefiting from reduced sector overhead. In fact it also played a role why IBM's 360 KiB format worked out fine. Standard MFM format is designed for 16 sectors of 256 bytes user data. By using 512 byte sectors IBM already halved the sector overhead.

One can increase that further. By using 1024 byte sectors instead of 512 byte on an IBM 5.25 drive would allow 5 sectors per track, holding 5 KiB instead of 4.5 KiB per track or 400 KiB per Disk. Using three 2048 byte sectors instead would yield 6 KiB but is too close to maximum track capacity to work reliable across all machines and for data exchange.

Increasing sector size would as well work fine with all DOS and all compatible OS as sector size is recorded on disk and blocking/deblocking is part of the DOS spec. Well in theory. Any practical use would be a test how well drivers implement this.

#2B sounds like a great way to solve this by closing in to maximum capacity. In case of an MFM drive a combination of one 4096 , one 1024 and a 512 Byte sector would add up to 5.5 Kib per track or 440 KiB 40 track 5.25 Disk.

But there's a caveat - DOS does not support variable sector size. THere is only a single variable for sector size and only that is used by DOS to calculate sector numbers for access. So any format using this would need very specific drivers, showing DOS a same size organization and do all conversion on it's own. Not exactly portable.

#2C would mean creating one sector with a size close to track capacity. With a brutto track capacity of about 6250 byte and some security margin this ends at a sector size of ~5.8 KiB. Cool. Except it's even worse than #2B, as DOS does not support odd sector sizes.


#3 now tackles the GAPs directly. A 512 byte sector including headers and gaps takes 658 byes on disk. Of those 106 are gap bytes. Another 330 are within the track header/trailer, giving a total of 1284 gap bytes. Even with keeping a fully compatible 512 byte sector size, one could put 11 sectors for the same 5.5 KiB per track (440 KiB per Disk) as in #2B. All readable by standard read command from every standard drive out there. This works as we haven't touches any sync bytes or headers.

(For a 1.44 MB Disk this is means an increase to 1.76 MB)

The only, but critical issue will be writing. When using a standard write command, the controller will seek as with reading but then write including all gaps, which will always overwrite the header of a following sector, thus destroying the disk. Writing a sector can only happen reading all sectors of that track, repackaging them in the condensed format, inserting the one to be written and then write the track at once. Not anything one can expect from DOS or any standard floppy driver.

Oh and there's another caveat: The write track command can not write data bytes containing the value of F5 or F6 - so this would need another hack to be discovered :)))

Long story short,t such a disk would be great to distribute software or do data backup, but not as a regular rewriteable exchange medium.

Pick your solution.

  • 2
    I just superformatted to unlock the last two tracks. DOS sure didn't like it. Windows 95 was fine.
    – Joshua
    Commented Jul 26, 2023 at 17:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .