Maybe I did *something* right... so it's just a matter of MOAR EFFORT, right?

OOOH:

Less-Promising:

This covers basically every file.

...(except LA.COM? Hmmmm... as in the Logic Analyzer application? Hmmmm....)

Ah, no... would seem I've messed *something* up...

used cpmcp to copy all the files to a directory on my main computer... and... this is a text-file:

which seems to contain, at the beginning, an assembly listing, followed by an empty sector, followed by possibly machine-code from an executable, followed by a help file.

Oy.

..........

"I wonder if..."

If I understand correctly there are several different interleaving-methods...

The obvious one is on-disk, wherein the sectors are out of order (so the disk-controller can read e.g. sector1, then process it, then by the time it's done processing it, the disk will've spun around a few sectors... so instead of putting them sequentially, they skip a few so sector2 will be close to the head when the processing of sector1 is complete).

But, also, there allegedly exists *software* interleaving... which I suppose could exist at the ROM-level, the OS-level, or any number of other places. Hmmm... In which case, I guess, if the software was accessing what it would consider sequential sectors, it might remap the requests to *different* sectors... so it might want sectors 1 and 2, but then remap those to sectors 1 and 6, so it's actually requesting, from the drive, sectors labelled on-disk as 1 and 6, regardless of the physical order of the sectors on the disk.

Thing is, since that's software-level, it should have no effect on whether my image, burnt to the floppy, is in or out of order as far as the numbering of the sectors on the disk. So it may help to know the software-interleave for using tools on my linux machine, but that has nothing to do with why the disk I wrote didn't work in the actual machine.

--------

And... what's up with this file called emo.lap with the first character in its name being 0x03? I've verified that the sector containing that file-entry was read without CRC-error *numerous* times.