There was a thread here about detecting the sector ordering of Apple II
5.25" .dsk images (unfortunately under Michael Mahon's FASTCIRC post).

I maintain that .dsk images should always be DOS 3.3 sector order, .do
images are always DOS3.3 sector order, and .po images are always ProDOS
order. All images > 140KB are ProDOS order, as well as any unknown extension
(so harddrive images and 3.5" 800KB images are always ProDOS order).

The ease of creation of ProDOS images with tools like Cadius now means
people are creating many new images on modern computers. If they name
their image files .dsk (which seems like the "right thing to do"), then
they've created new .dsk images in ProDOS order.

A description of sector order is at the end of this message, feel free to
skip it if you know this stuff, or don't care about the details.

As for detection, Applewin uses a simple easy-to-understand algorithm to
determine the sector order of .dsk images:

A .dsk defaults to DOS 3.3 sector order. However, if a DOS 3.3 catalog
track appears to exist on track $11 by looking at the first 2 bytes of
each sector, when assuming the disk is in ProDOS order, then it treats the
..dsk image as ProDOS order. Or, if a ProDOS volume directory appears to be
on blocks 2,3,4,5 on track $00 by looking at the first 4 bytes of each
block when treated as ProDOS order, then the .dsk is treated as ProDOS order.

I like this simple check, since it's looking for well-formed disk images
with normal catalog tracks. This makes sense if a main source of the
images in ProDOS order is modern tools creating these images. If an image
doesn't look like a normal DOS 3.3 disk or ProDOS (say, no OS at all, like
a game would do), then .dsk is always DOS 3.3 sector order.

But this detection seems to have a problem: if a user mounts a prodos1.dsk
created by Cadius in ProDOS order, it will work fine as long as the user
keeps using it as a normal disk. But what if the user then, under
emulation, plays a game which wants to format a save disk to save
progress on, and picks this prodos1.dsk? The resulting image probably
no longer has a valid catalog. Applewin will read and write the
prodos1.dsk image in ProDOS order since that's what it knows to do for
as long as the user runs the game in one session. But when stopped and
restarted later, the .dsk detection routine will now say the prodos1.dsk
image is DOS 3.3 order (since it cannot tell), and the saved game is
lost.

So my proposal: Emulators should support detecting .dsk images as ProDOS,
but should use a very simple check like Applewin's. And if a .dsk image
is determined to be ProDOS order, then the emulator should immediately
re-write the .dsk image file as DOS 3.3 order. If the image is write-
protected or not writeable, then do nothing. This solves the misdetection
problem of using .dsk images in ProDOS order--.dsk is always DOS 3.3 sector
order to the emulator

Kent

----

As background, Apple II 5.25" disks generally contain 16 sectors of 256-bytes
each on 35 tracks. On the physical disk, these sectors have a physical
sector number, counting from 0-15 in order on the disk. DOS 3.3 knew it
could not read adjacent sectors that fast, so it has a table of logical
sectors to physical sectors, to try to give it more time to process
adjacent logical sectors. All DOS 3.3 operations are on logical sectors.

Physical sector: 0 1 2 3 4 5 6 7 8 9 a b c d e f
Logical sector: 0 7 e 6 d 5 c 4 b 3 a 2 9 1 8 f

This arrangement is great for booting DOS 3.3, where it reads logical sector
'f', then 'e', 'd', etc. Once 'f' is found, 'e' is 3 sectors later, and
'd' is 2 sectors after that. That is about as fast as the DOS 3.3 RWTS can
read. It turns out, DOS 3.3's File Manager is so slow that between
reading sectors during LOAD or BLOAD, about half a track passes by while it
twiddles its thumbs between each sector. This is why there are enhanced
DOS's which are more efficient.

ProDOS has a logical 512-byte block. So it needs to map it's blocks to
sectors. Here's that mapping for 5.25" disks.

ProDOS block: 0 1 2 3 4 5 6 7
DOS 3.3 physical sector: 0,2 4,6 8,a c,e 1,3 5,7 9,b d,f
DOS 3.3 logical sector: 0,e d,c b,a 9,8 7,6 5,4 3,2 1,f

In DOS3.3 sector order, the .do image has DOS 3.3 logical sectors 0...f
in ascending order. This is what users would think is the natural order
for sectors since any sector editor would make the disk appear to be in
this order.

In ProDOS block order, a .po image has ProDOS blocks in ascending order 0...7,
which works out to DOS 3.3 logical sectors: 0,e,d,c,b,a,9,8,7,6,5,4,3,2,1,f.

Note the physical sector order does not matter at all for .dsk, .do, or
..po images.

In general, almost all "classic" .dsk images (created more than 20 years ago)
are in DOS 3.3 logical sector order since that's what tools of the time
generally did. But now there are various ways to quickly make ProDOS images
on modern computers--and if users name their files .dsk, then they are
creating .dsk's in ProDOS order.

On Wednesday, November 23, 2022 at 2:12:26 PM UTC-8, Kent Dickey wrote:
> [...]And if a .dsk image
> is determined to be ProDOS order, then the emulator should immediately
> re-write the .dsk image file as DOS 3.3 order. If the image is write-
> protected or not writeable, then do nothing.

That should probably be preceded by a dialog box with 3 options: (1) rewrite the disk; (2) rename the image file to have the correct extension; (3) leave the disk image alone and come what may. Rearranging the image order without asking permission seems... rude.

Or maybe just offer #2 and #3, since #1 seems like more work for a less-desirable outcome.

Kent Dickey wrote:
> There was a thread here about detecting the sector ordering of Apple II
> 5.25" .dsk images (unfortunately under Michael Mahon's FASTCIRC post).
>
> I maintain that .dsk images should always be DOS 3.3 sector order, .do
> images are always DOS3.3 sector order, and .po images are always ProDOS
> order. All images > 140KB are ProDOS order, as well as any unknown
> extension
> (so harddrive images and 3.5" 800KB images are always ProDOS order).
>
> The ease of creation of ProDOS images with tools like Cadius now means
> people are creating many new images on modern computers. If they name
> their image files .dsk (which seems like the "right thing to do"), then
> they've created new .dsk images in ProDOS order.
>
> A description of sector order is at the end of this message, feel free to
> skip it if you know this stuff, or don't care about the details.
>
> As for detection, Applewin uses a simple easy-to-understand algorithm to
> determine the sector order of .dsk images:
>
> A .dsk defaults to DOS 3.3 sector order. However, if a DOS 3.3 catalog
> track appears to exist on track $11 by looking at the first 2 bytes of
> each sector, when assuming the disk is in ProDOS order, then it treats the
> .dsk image as ProDOS order. Or, if a ProDOS volume directory appears to
> be
> on blocks 2,3,4,5 on track $00 by looking at the first 4 bytes of each
> block when treated as ProDOS order, then the .dsk is treated as ProDOS
> order.
>
> I like this simple check, since it's looking for well-formed disk images
> with normal catalog tracks. This makes sense if a main source of the
> images in ProDOS order is modern tools creating these images. If an image
> doesn't look like a normal DOS 3.3 disk or ProDOS (say, no OS at all, like
> a game would do), then .dsk is always DOS 3.3 sector order.
>
> But this detection seems to have a problem: if a user mounts a prodos1.dsk
> created by Cadius in ProDOS order, it will work fine as long as the user
> keeps using it as a normal disk. But what if the user then, under
> emulation, plays a game which wants to format a save disk to save
> progress on, and picks this prodos1.dsk? The resulting image probably
> no longer has a valid catalog. Applewin will read and write the
> prodos1.dsk image in ProDOS order since that's what it knows to do for
> as long as the user runs the game in one session. But when stopped and
> restarted later, the .dsk detection routine will now say the prodos1.dsk
> image is DOS 3.3 order (since it cannot tell), and the saved game is
> lost.
>
> So my proposal: Emulators should support detecting .dsk images as ProDOS,
> but should use a very simple check like Applewin's. And if a .dsk image
> is determined to be ProDOS order, then the emulator should immediately
> re-write the .dsk image file as DOS 3.3 order. If the image is write-
> protected or not writeable, then do nothing. This solves the misdetection
> problem of using .dsk images in ProDOS order--.dsk is always DOS 3.3
> sector
> order to the emulator
>
> Kent
>
> ----
>
> As background, Apple II 5.25" disks generally contain 16 sectors of
> 256-bytes
> each on 35 tracks. On the physical disk, these sectors have a physical
> sector number, counting from 0-15 in order on the disk. DOS 3.3 knew it
> could not read adjacent sectors that fast, so it has a table of logical
> sectors to physical sectors, to try to give it more time to process
> adjacent logical sectors. All DOS 3.3 operations are on logical sectors.
>
> Physical sector: 0 1 2 3 4 5 6 7 8 9 a b c d e f
> Logical sector: 0 7 e 6 d 5 c 4 b 3 a 2 9 1 8 f
>
> This arrangement is great for booting DOS 3.3, where it reads logical
> sector
> 'f', then 'e', 'd', etc. Once 'f' is found, 'e' is 3 sectors later, and
> 'd' is 2 sectors after that. That is about as fast as the DOS 3.3 RWTS
> can
> read. It turns out, DOS 3.3's File Manager is so slow that between
> reading sectors during LOAD or BLOAD, about half a track passes by while
> it
> twiddles its thumbs between each sector. This is why there are enhanced
> DOS's which are more efficient.
>
> ProDOS has a logical 512-byte block. So it needs to map it's blocks to
> sectors. Here's that mapping for 5.25" disks.
>
> ProDOS block: 0 1 2 3 4 5 6 7
> DOS 3.3 physical sector: 0,2 4,6 8,a c,e 1,3 5,7 9,b d,f
> DOS 3.3 logical sector: 0,e d,c b,a 9,8 7,6 5,4 3,2 1,f
>
> In DOS3.3 sector order, the .do image has DOS 3.3 logical sectors 0...f
> in ascending order. This is what users would think is the natural order
> for sectors since any sector editor would make the disk appear to be in
> this order.
>
> In ProDOS block order, a .po image has ProDOS blocks in ascending order
> 0...7,
> which works out to DOS 3.3 logical sectors:
> 0,e,d,c,b,a,9,8,7,6,5,4,3,2,1,f.
>
> Note the physical sector order does not matter at all for .dsk, .do, or
> .po images.
>
> In general, almost all "classic" .dsk images (created more than 20 years
> ago)
> are in DOS 3.3 logical sector order since that's what tools of the time
> generally did. But now there are various ways to quickly make ProDOS
> images
> on modern computers--and if users name their files .dsk, then they are
> creating .dsk's in ProDOS order.
>

Very cool little explanation of sector ordering.

The physical disk is actually circular. Could you write a fast program to
draw an image of the disk using HGR graphics?

mmphosis

In article <3ec07805-8fec-4a40-8d0b-33418b755134n@googlegroups.com>,
fadden <thefadden@gmail.com> wrote:
>On Wednesday, November 23, 2022 at 2:12:26 PM UTC-8, Kent Dickey wrote:
>> [...]And if a .dsk image
>> is determined to be ProDOS order, then the emulator should immediately
>> re-write the .dsk image file as DOS 3.3 order. If the image is write-
>> protected or not writeable, then do nothing.
>
>That should probably be preceded by a dialog box with 3 options: (1)
>rewrite the disk; (2) rename the image file to have the correct
>extension; (3) leave the disk image alone and come what may.
>Rearranging the image order without asking permission seems... rude.
>
>Or maybe just offer #2 and #3, since #1 seems like more work for a
>less-desirable outcome.

OK, I'll move to option 4):

When a .dsk image is mounted and is detect to be ProDOS-ordered, the
internal image will be swapped to be DOS-ordered, but not written back to
the host yet. When ANY write to the image occurs and would update the
host copy, the entire image will be written to the host in DOS-order.

If you never write to the disk image in any way, the host copy is untouched.
If you write to it in any way, the host copy becomes DOS-ordered.

Kent