On Sat, 30 Jul 2016, Fred Cisin wrote: There used to be a `fdformat' utility available providing fancy stuff for DOS users like sector physical and logical shifting, interleaving, unusual geometries, etc. You could use physical shifting (track lead and inter-sector gap rearrangement) to avoid bad spots in some cases altogether, and logical shifting (out of order sector ID assignment) to improve data transfer performance -- typically ~twice compared to results obtained with the regular `format' utility shipped with DOS. Some other features were available I don't remember offhand anymore; basically you had much control over the NEC ?PD765 FDC chip itself with this tool's command line options. Back in 1990s the software package used to be carried by the usual FTP sites with DOS software, so I guess it still has to be available online somewhere. I highly recommend it if you're still into the floppy business and don't use Linux. The plain `format' command supplied with DOS gives you little control really and produces poor performance floppies. HTH, Maciej

On Sat, 30 Jul 2016, Fred Cisin wrote: From my experience with floppy formats and reasonably fast computers (i.e. where CPU processing latency doesn't really matter) the best results are obtained with no interleaving, no sector staggering on head switching, and single-sector staggering on cylinder incrementing. I.e. taking the the 1.44MB 3.5" format (18 sectors, 2 sides, 80 cylinders) as an example you start track #0, #1, #2, etc. on both sides with logical sector #1, #18, #17, etc. Logical sector numbers then increment modulo 18, plus 1 (as sector IDs start counting from 1), i.e.: s[n+1] = (s[n] % 18) + 1. This is because with a fast host CPU it takes negligible time to issue commands to the FDC as results from preceding commands become available and therefore the FDC will receive a subsequent sector or track read (or write) command soon enough for data requested not to have passed under the head in rotary movement yet. And head selection is instantaneous, made along a read (or write) request. A seek command requesting the next cylinder however requires the step motor to physically move the head assembly and it takes enough time to complete for medium to have already rotated past the next physical sector. So if that happened to be the logical sector requested with the next read (or write) command as well, then almost a full rotation would be required to even start executing the data transfer. So to avoid that missed sector you need to stagger sectors back by one on cylinder increments, so that the physical sector lost due to the head movement is actually one you may need last and the subsequent one is the logically next one. Empirical data showed that a 1.44MB 3.5" floppy formatted as I described above took IIRC ~35s to read (or write) it whole whereas one formatted with the regular DOS utility required noticeably more. Given the figures I quoted above we have 2+1/18 vs 3 revolutions per two-sided cylinder read (or written) for the staggered vs unstaggered sector layout, giving ~51s required for a whole floppy formatted with physical and logical sector IDs identity mapped. This makes the staggered format only ~1.5 times rather than twice as good, contrary to what I quoted from my faded memory in my original statement. Still this was not to be underrated at the time of regular floppy use. Maciej

On Sat, 30 Jul 2016, Fred Cisin wrote: Sure, there'll always be outliers, no argument about that. I described what has been solely my personal experience (which I hope nobody is going to question), which just happens to coincide with a common use case (cf. the elevator algorithm used by some OSes for block device accesses), and I gave a reference to a tool which lets one adjust their floppy disk format to suit their needs and which some may find useful. I'm leaving it up to individual people then to make use of this tool or not, and if the former, then how. I'm surely not going to interfere with that in any way. FWIW, Maciej