Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[apple-ii] Improved floppy disk image support #616

Open
oliverschmidt opened this issue Jun 15, 2023 · 2 comments
Open

[apple-ii] Improved floppy disk image support #616

oliverschmidt opened this issue Jun 15, 2023 · 2 comments

Comments

@oliverschmidt
Copy link
Contributor

oliverschmidt commented Jun 15, 2023

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.

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.

@tschak909
Copy link
Collaborator

I'll put this on the short list.

@miraixyz
Copy link

I have been asking for this as well. Hope we can get it soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants