Statistics on disk images with ProDOS file system:

2,639 total disk images with ProDOS file system

2,197 in DOS sector order (83.25%), and 442 (16.75%) in ProDOS sector order


Disk image filename extensions:

2,161 .dsk in DOS order
144 .dsk in ProDOS order

0 .po in DOS order
257 .po in ProDOS order

34 .do in DOS order
0 .do in ProDOS order

43 files have no file extension, or have some other file extension


NOTE: 2MG, DC42, SDK, and all other disk image wrappers are NOT COUNTED in these statistics.

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

Hi David,

2,161 .dsk in DOS order
144 .dsk in ProDOS order

So only 6.5% of the .DSK files are in ProDOS order.

257 .po in ProDOS order

So the vast majority of ProDOS order images are .PO files.

Looking at those numbers, it seems to me that Kents desire to get rid of
.DSK files in ProDOS order (with all the trouble they cause) is totally reasonable.

Regards,
Oliver

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

On 11/8/22 7:26 PM, D Finnigan wrote:

Statistics on disk images with ProDOS file system:

2,639 total disk images with ProDOS file system

2,197 in DOS sector order (83.25%), and 442 (16.75%) in ProDOS sector order

Disk image filename extensions:

2,161 .dsk in DOS order
144 .dsk in ProDOS order

That's in keeping with my experience too - "just about everything" 140k
with a .dsk extension is in DOS order, regardless of the filesystem inside.

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

David Schmidt wrote:

On 11/8/22 7:26 PM, D Finnigan wrote:

Statistics on disk images with ProDOS file system:

2,639 total disk images with ProDOS file system

2,197 in DOS sector order (83.25%), and 442 (16.75%) in ProDOS sector
order


Disk image filename extensions:

2,161 .dsk in DOS order
144 .dsk in ProDOS order

That's in keeping with my experience too - "just about everything" 140k
with a .dsk extension is in DOS order, regardless of the filesystem
inside.

And the other observation is that when it comes to disk images with ProDOS
file system, the .do and .po extensions are reliable indicators of sector order.

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

Oliver Schmidt wrote:

Hi David,

2,161 .dsk in DOS order
144 .dsk in ProDOS order

So only 6.5% of the .DSK files are in ProDOS order.

257 .po in ProDOS order

So the vast majority of ProDOS order images are .PO files.

Looking at those numbers, it seems to me that Kents desire to get rid of
.DSK files in ProDOS order (with all the trouble they cause) is totally reasonable.

Agreed. And one might even go so far as to write a script to change the file extension of ProDOS-ordered .dsk files to .po.

Next point of investigation for me is to see a list of these 144 .dsk images that are in ProDOS order. What application made these images? Are
ProDOS-sector ordered .dsk images still being made by some application
today?

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

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

Next point of investigation for me is to see a list of these 144 .dsk images that are in ProDOS order. What application made these images? Are ProDOS-sector ordered .dsk images still being made by some application today?

Probably the most popular application would have been Dsk2File5.8. It has been around the longest and can handle both Dos order and Prodos order disks as well as create the disk image that can be stored on a hard drive, and from there transferred to a
modern computer for upload.

I think Disk.Maker.8 would have got some usage when it came out. And the earlier version of Copy2Plus could make disk images as well, but unsure if it created Prodos disks in Dos order.

I believe one of the questions is still lingering unanswered is, what algorithm did you use to differentiate a Dos order disk from a Prodos order one?

Some emulators use the .po extension to indicate it is an 800kb Prodos disk and doesn't work if a 144 kb disk is used with .po instead. And .dsk was still used to indicate an 800kb AMDos disk as well.

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

I am Rob wrote:

I believe one of the questions is still lingering unanswered is, what algorithm did you use to differentiate a Dos order disk from a Prodos
order
one?

I look for the catalog sectors.

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

Hi David,

And one might even go so far as to write a script to change the file extension of ProDOS-ordered .dsk files to .po.

That was - of course - my first thought. But as I'm not the one to perform
such a change, I didn't feel entitled to bring up the topic.

Regards,
Oliver

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

On Wednesday, November 9, 2022 at 11:54:59 AM UTC-8, [email protected] wrote:

I think Disk.Maker.8 would have got some usage when it came out. And the earlier version of Copy2Plus could make disk images as well, but unsure if it created Prodos disks in Dos order.

IIRC, there's a version that could create disk images in *physical* sector order, but didn't become popular. I'm not sure what version did that; I found copies of 7.4, 8.2, and 9.0 but didn't see the feature in the menus.

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

On Wednesday, November 9, 2022 at 3:50:41 PM UTC-8, fadden wrote:

I think Disk.Maker.8 would have got some usage when it came out. And the earlier version of Copy2Plus could make disk images as well, but unsure if it created Prodos disks in Dos order.

IIRC, there's a version that could create disk images in *physical* sector order, but didn't become popular. I'm not sure what version did that; I found copies of 7.4, 8.2, and 9.0 but didn't see the feature in the menus.

Found it. With Copy ][+ 7.x, use Copy > Disk, and try to copy a 5.25" disk onto a larger ProDOS volume. It will ask for a filename. The result is a physical-ordered image with type $F7 and auxtype $0118 (==280, indicating the number of blocks).

Attempting to do this with Copy ][+ v6.0 yields the error "both drives must be the same size", while v8.4 reports "device size mismatch". So this was a very short-lived feature.

The procedure works for 800K disks as well, creating an unadorned ProDOS block-order image.

I'm guessing that the feature's obscurity and lack of compression led to its demise. Further, I discovered that if you run out of space on the target volume, it marks the blocks as in-use but doesn't create the necessary index entries, so you have to
run Mr. Fixit on the volume afterward.

The preferred extension appears to be ".img".

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