You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is only about disk image files, which contain only the user data of 5.25" floppy disks and are of 140kB size.
Any files that represent more user data (and are therefore larger) are not affected because they have always to be mounted as SmartPort devices.
Any files that represent beside user data also metadata (like WOZ files) are not affected because they have always to be mounted as Disk II floppies (in a well defined way).
The files in question have two levels of content attribute:
The low level attribute 'sector order'
The high level attribute 'file system'
The sector order is either DOS or ProDOS.
The file system is either DOS, ProDOS or anything else.
There are three usual name extensions for the files in question:
.DO denoting a DOS sector order
.PO denoting a ProDOS sector order
. DSK not denoting any sector order
There are programs that completely ignore the name extension and fully rely on their automatic detection. And there are programs using the name extension only as a hint on which automatic detection to try first.
Anyhow, my personal suggestion is to strictly imply DOS sector order for .DO files and ProDOS sector order for .PO files - and to try any auto detection only for .DSK files.
The sector order question is relevant for both mounting as SmartPort device and Disk II floppy!
Right now, the code base calls serialise_track() always with the last parameter set to false. But the serialise_track() documentation says @param is_prodos @c true if the DSK image is in Pro-DOS order; @c false if it is in DOS 3.3 order. :-(
In other words: It is very well possible that the user wants to mount a ProDOS sector order file as Disk II floppy or mount a DOS sector order file as SmartPort device. That implies of course that there is in general no strict relationship between name extension and mounting option.
But how to autodetect the sector order? Unfortunately this is only possible by looking at the file system and making more or less smart assumptions.
My personal suggestion is to limit the autodection to the ProDOS file system. Every disk with a ProDOS file system has a root directory almost always at a certain place on the disk. That root directory shows some usual patterns. The idea is to look for those patterns both presuming a ProDOS sector order and a DOS sector order.
So to summarize:
.DO file -> Assume DOS sector order.
.PO file -> Assume ProDOS sector order.
.DSK file -> Check for ProDOS file system. If found, use detected sector order. Otherwise fall back to DOS sector order.
And what to do with the known (or guessed) sector order?
For Disk II mounting, just set the correct parameter for serialise_track().
For SmartPort mounting, ...
ProDOS sector order means "do nothing special".
DOS sector order means remap the 16 sectors (with 256 bytes) of each track to the 8 blocks (with 512 bytes) for the CBus.
This issue is only about disk image files, which contain only the user data of 5.25" floppy disks and are of 140kB size.
The files in question have two levels of content attribute:
The sector order is either DOS or ProDOS.
The file system is either DOS, ProDOS or anything else.
There are three usual name extensions for the files in question:
There are programs that completely ignore the name extension and fully rely on their automatic detection. And there are programs using the name extension only as a hint on which automatic detection to try first.
Anyhow, my personal suggestion is to strictly imply DOS sector order for .DO files and ProDOS sector order for .PO files - and to try any auto detection only for .DSK files.
The sector order question is relevant for both mounting as SmartPort device and Disk II floppy!
Right now, the code base calls
serialise_track()
always with the last parameter set tofalse
. But theserialise_track()
documentation says@param is_prodos @c true if the DSK image is in Pro-DOS order; @c false if it is in DOS 3.3 order.
:-(In other words: It is very well possible that the user wants to mount a ProDOS sector order file as Disk II floppy or mount a DOS sector order file as SmartPort device. That implies of course that there is in general no strict relationship between name extension and mounting option.
But how to autodetect the sector order? Unfortunately this is only possible by looking at the file system and making more or less smart assumptions.
My personal suggestion is to limit the autodection to the ProDOS file system. Every disk with a ProDOS file system has a root directory almost always at a certain place on the disk. That root directory shows some usual patterns. The idea is to look for those patterns both presuming a ProDOS sector order and a DOS sector order.
So to summarize:
And what to do with the known (or guessed) sector order?
For Disk II mounting, just set the correct parameter for
serialise_track()
.For SmartPort mounting, ...
That remapping is described i.e. on https://retrocomputing.stackexchange.com/questions/15056/converting-apple-ii-prodos-blocks-to-dos-tracks-and-sectors. Please note that the 512 bytes you need for the CBus aren't 512 contiguous bytes in the file.
The text was updated successfully, but these errors were encountered: