It really depends on the speed of the system (CPU and disks) and what processing is beng done on the data (and how).

Not having interleave when you need it can obviously slow down operations. eg: reading all sectors from a 18 sector track.. if your proessing is so slow that you "miss" each next sector, then you have to wait for it to come round again... In this case, 18 revolutions instead of 1.
1 2 3 4 5 6 7 8 9 0 11 12 13 14 15 16 17 18

But... having interleave when you don't need it can also cause system slowdown, eg: Reading sequentually with and interleave of 3:
1 7 13 2 8 14 3 9 15 4 10 16 5 11 17 6 12 18 you will need 3 revolutions instead of 1.

Given that the possible penalty for not having interleave is so much worse than the penalty for "too much" interleave, traditionally makers would err on the "to much" side.

With "modern"(ie: 286+) systems and DMA data transfer to/from FDC, 1:1 interleave is almost always best. There is so much "time" in the gaps between sectors (and even more at the end of each track) that most systems can process the data and queue up the next access. Many more recent disks format use 1:1.

---

Double stepping is almost exclusively used to make 360k(40 track) disks usable in 1.2m(80 track) drives. Yes 80 track heads are thinner and lay down thinner tracks. For this reason I don't recommend writing 360k disks at all on a 1.2m drive. If you have to (ie: You want to send a disc to someone who only has a 360k drive) - bulk erase the disc first! That will get rid of any vestages of any existing tracks.

In practice, the track laid down by the thinner head overwrites most of any that were made with a fatter head that the domains seen by the head are much stronger and the edges with the old data just result in more "noise"... but the good track signal is still within the range of the detection electronics and the laster/thinner track reads normally and everything still works as it should - ON WELL ALLIGNED DRIVES! - If the reading drive is a bit misaligned, the noise from the edges can be effectively more pronounced and cause problems.

This can actually help when trying to recover a damaged 360k disk content - by reading in a 1.2m drive and intentionally misaligning slightly to read more of the track from an edge.

---

Tracks don't line up quite well enough for adjacent tracks to help (not to mention that various ID bits will differ), formatting 80 tracks before 40 would just create more noise... Best way to "recover" an disk thats been written at 80 tracks to 40 tracks is to bulk erase it!

Format under OS will guarantee that low-level format is exactly what the OS expects. Obviously you want to do a "full" format and not some kind of quick or recovery format.

I asked about these interleave details, because I see, that NFORMAT is using interleave 2 for 83 track, 21 sectors 3.5" diskettes (bigger non-standard format). Probably the 18+ sector count is the main reason for this. I'll keep in mind, that interleave different from 1 is only good for diskettes used in 8086/88 systems or for diskettes formatted with bigger non-standard formats.

DaveDDS wrote on Yesterday, 13:54:

Tracks don't line up quite well enough for adjacent tracks to help (not to mention that various ID bits will differ), formatting 80 tracks before 40 would just create more noise... Best way to "recover" an disk thats been written at 80 tracks to 40 tracks is to bulk erase it!

Actually I was asking not for recovering, but for preparing a blank 40 track diskette previously formatted and used on 40 track only drive with a newer 80 track capable drive. But, yeah, it seems like bulk erasing before formatting is the safest way.

aVd wrote on Yesterday, 14:31:

I asked about these interleave details, because I see, that NFORMAT is using interleave 2 for 83 track, 21 sectors 3.5" diskettes (bigger non-standard format). Probably the 18+ sector count is the main reason for this. I'll keep in mind, that interleave different from 1 is only good for diskettes used in 8086/88 systems or for diskettes formatted with bigger non-standard formats.

Probably has more to do with reduced gaps between sectors and end of track.

Also remember than if the system is doing significant (ie: time consuming) processing as it reads each sector, Interleave can still help.
It really does depend on how the data is being used (and "modern" systems will usually cache sectors allowing them to take advantage of low-interleave even if the application does "take it's time") - none of this is simple always-obvious answers 😀

Like I said, better to err on the "too much" side.

DaveDDS wrote on Yesterday, 22:37:

Probably has more to do with reduced gaps between sectors and end of track.

Yep. More sectors per track means narrower gaps between the sectors.

DaveDDS wrote on Yesterday, 22:37:

Also remember than if the system is doing significant (ie: time consuming) processing as it reads each sector, Interleave can still help.
It really does depend on how the data is being used (and "modern" systems will usually cache sectors allowing them to take advantage of low-interleave even if the application does "take it's time") - none of this is simple always-obvious answers 😀

So, it seems like there's no universal formula for floppy disk sector arrangement which can guarantee the fastest reading on both "modern" (huh, even Linux abandoned the floppy drives support years ago 🙁 ) and very old machines. Probably for the standard formats a sector interleave value of 2 is a good compromise if the diskette is used in both 8086/88 and more "modern" systems. Back in time I read for some 3rd party tools, that arranges sectors and gaps in a custom patterns, so the relatively slowly moving heads will access them as fast as it is possible. Unfortunately I cant recall at least one name of such a DOS tool.

DaveDDS wrote on Yesterday, 22:37:

Like I said, better to err on the "too much" side.

Тhat is an ambiguity and could be interpreted as "too much" compatibility at expense of speed, or "too much" speed optimizations at expense of compatibility 😉

Thank you very much for clarifying the details regarding the questions I had, Dave! I think, I can finally use all the features of your awesome DOS ImageDIsk with the proper settings for the standard DOS diskette formats.

hi dave because i hope you understand it much better than me could you look at fascinating Plain DOS 2 Core Demo. and say if itsnot a virus or so `? it should be a dos multicore demo. many thanks!!!

fascinating Plain DOS 2 Core Demo.

MarkDastedt wrote on Today, 08:42:

hi dave because i hope you understand it much better than me could you look at fascinating Plain DOS 2 Core Demo. and say if itsnot a virus or so `? it should be a dos multicore demo. many thanks!!!

Looks interesting, not sure what compiler and assembler it's written using, and given that I don't have any multi-core bare DOS systems, don't want to put time into figuring any of that out. I don't think DosBox supports multi-core at all...

I recall my first experience with multi-core ... wwaaaaaayy back in the day before multi-core CPUs were all common, we built up a system using a mainboard that supported two physical CPUs (we called it the "Whopper" - War Games reference)

IIRC we got an edition of Unix running on it which properly supported multi-threads/cores.

I "played" with hardware multi-threads in DOS a bit - I did get a program working which showed off hom much this system could do ... but nothing really useful under DOS - DOS just didn't track resources used by multiple threads, you could launch a program which enabled the second CPU pointed at it's own memory and with both "threads" being careful not to "stomp" on each other you could indeed count running loops etc. to show there were two running and how much faster it could be than one.

But ... you better make sure the second CPU didn't try to invoke any system resources and was halted before terminating, otherwise it would keep running as DOS reloaded something else into it's memory space.

And there had been some ability to address multiple threads within DOS as TSRs could load and perform background activity based on various interrupts... but there was never any support for true multi-threads running simultaneously.

Fun times!

PS: I didn't see anything that stands out to me as malware, but I've not dug deeply into what exactly the source code is intended to do either...
It's very uncommon to see malware distributed as source code, and I suspect if a "bad guy" did that, he probably wouldn't put in obvious source comments describing how he was damaging your system environment - just guessing tho ... I have no personal experience with producing such a thing!

aVd wrote on Today, 08:39:

So, it seems like there's no universal formula for floppy disk sector arrangement which can guarantee the fastest reading ...

Exactly - interleave is a compromise which should be "tuned" to a given system (incl software running) to get faster possible performance, or course since it can't change "on the fly" nobody does that and the best you can do is get "as close during most/common operations" as you can.

on both "modern" (huh, even Linux abandoned the floppy drives support years ago 🙁 )

I've not tried on the various Linux system, but I do know that at least with Winblows - even though floppy hardware isn't there any more, it does still recognize usb floppy drives (I've not tried with Win11 though) - and even it it didn't, Virtual machines can provide direct low level access to USB and other hardware and are often used to boot older OS editions!

This doesn't really matter - by "Modern" I am referring to anything newer than DOS - pretty much any multi-threaded OS will perform caching as it shares hardware between the threads.

And... Don't forget hard drives! - Interleave is more important there as the disk spins (and sectors "come up") much faster!

To truly escape the effects-of/need-for interleave ... you need to go to something like an SSD - any sector you want can be addressed immediately, no waiting for it to "come round"!

Probably for the standard formats a sector interleave value of 2 is a good compromise if the diskette is used in both 8086/88 and more "modern" systems.

Yep - that seems like a good choice. This was all more important with now-ancient machines back when they were in common use (PDP11, Nova etc.)
Processors and disks were noticeably slower - These were the kinds of media ImageDisk was originally designed to replicate.

Back in time I read for some 3rd party tools, that arranges sectors and gaps in a custom patterns, so the relatively slowly moving heads will access them as fast as it is possible. Unfortunately I cant recall at least one name of such a DOS tool.

Sounds like a good marketing point ... but not possible in practice. It really does depend on how much processing is done by the application accessing the disk - which the maker of a "3rd party tool" can't know for each customer... and the particular application being used can change on an ongoing basis. It really is a compromise you try to optimize for "typical" use cases.

DaveDDS wrote on Yesterday, 22:37:

Like I said, better to err on the "too much" side.

Тhat is an ambiguity and could be interpreted as "too much" compatibility at expense of speed, or "too much" speed optimizations at expense of compatibility 😉

"too much" interleave (which may cause an unneeded revolution or two) is generally better than not enough (which will generally cause extra revolutions matching the number of sectors on track.

Thank you very much for clarifying the details regarding the questions I had, Dave! I think, I can finally use all the features of your awesome DOS ImageDIsk with the proper settings for the standard DOS diskette formats.

Glad to help - Perhaps I should add a document to the distribution which explains all these details. It really can be hard to judge what to document about a system where you personally have a lot of experience (and hopefully knowledge) - then again, most people using IMD these days are involved in archival operations, already know probably more than I do, and I really dislike "cluttering" my distributions with unneeded "Stuff"...

For hard drives low level formatting back in time I used those built-in HDD LLF BIOS options in old motherboards and I think those rely entirely on HDD's parameters set by the factory. In most recent years (at least 15 years back in time) I used some windows software tools from Maxtor (and similar HDD makers), but I'm not sure, if they perform a true low level format on modern mechanical hard drives. And this is another huge topic, which I will pass 😀 I know, that there are some very old commercial software tools, which can be used to manually set bad sector tables and other HDD parameters, but personally never had one or used one. I don't know it it is possible to get such a tool by "legal way" nowadays, since they are long time ago considered as abandonware. I have no idea, if there is some free DOS tool for HDD low level diagnostics, formatting and setting.

DaveDDS wrote on Today, 10:53:

"too much" interleave (which may cause an unneeded revolution or two) is generally better than not enough (which will generally cause extra revolutions matching the number of sectors on track.

In other words - "better safe, than sorry". We agreed on interleave of 2 for older systems compatibility in standard DOS diskette formats, and this fits in "better (a little more) safe, than sorry" 😁

DaveDDS wrote on Today, 10:53:

Glad to help - Perhaps I should add a document to the distribution which explains all these details. It really can be hard to judge what to document about a system where you personally have a lot of experience (and hopefully knowledge) - then again, most people using IMD these days are involved in archival operations, already know probably more than I do, and I really dislike "cluttering" my distributions with unneeded "Stuff"...

Actually this is a pretty good idea. You can add some brief explanations in IMD's documentation about those more "obscure" settings like sectors interleave. And this is not an "unneeded stuff", but more like kind of an additional details for the newer IMD users (like me) about what is possible to be achieved by using the tool and why it may be of use in some particular cases.

aVd wrote on Today, 11:44:

Actually this is a pretty good idea. You can add some brief explanations in IMD's documentation about those more "obscure" settings like sectors interleave. ...

There is in fact a pretty good description in IMD.TXT of what Interleave is, why it exists and how it works. I don't know that I could improve on this much...

Other "obscure" things are also mentioned - if you have suggestions on specific things you'd like to see added, or how to improve the descriptions - I'm "all ears"

Keep in mind the non-system specific nature of ImageDisk ... I don't want to offer "setup suggestions" which would make it work better with one system/format over another!

You are right. But this does not explain why in the settings menu we can set interleave value of 99 (I know it's a math, but I will not count 99:1 shifting for 8, 9, 15. 18, 21, 26 or 36 sectors 😁 ). Apologies for my stupid suggestion about skipping the reading of "unpopulated" space on the floppy disk, which may potentially contain some bad sectors. Until yesterday I didn't knew, that IMD works while not relying on any OS properties/functions.

aVd wrote on Today, 13:10:

You are right. But this does not explain why in the settings menu we can set interleave value of 99

Look under IMD F1-Help -> "General Notes" -> "256 Tracks/Sectors?"