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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
fadden <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)