If you've ever wanted to create HGR graphics containing circles of
various sizes, you’ve probably been disappointed with the slow drawing
speed. The straightforward method using sines and cosines can take
several seconds per circle.

I’ve just added a short (374 bytes) subroutine, FASTCIRC, to my website
that draws circles in from 22 to 75 milliseconds, depending on radius.
It’s self-relocating, so you can BLOAD it anywhere convenient.

To use FASTCIRC, the center (Xlo, Xhi, Y) and the radius are POKEd into
locations 6, 7, 8, and 9 and FASTCIRC is CALLed at its load address.

My website has more complete documentation and a FASTCIRC.DSK image
containing FASTCIRC, its Merlin source, and several demo programs to
illustrate its use.

Time to have fun with circles!
--

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://michaeljmahon.com

"The wastebasket is our most important design
tool--and it's seriously underused."

On Friday, October 21, 2022 at 12:01:49 AM UTC-7, Michael J. Mahon wrote:
> If you've ever wanted to create HGR graphics containing circles of
> various sizes, you’ve probably been disappointed with the slow drawing
> speed.

It's nice to know I'm not the only one. :-)

The self-relocation routine has that fun "living on the edge" feel to it. Very nice.

> Time to have fun with circles!
> -michael
> Home page: http://michaeljmahon.com

Hi Michael, can I just say a big "thank you" for keeping your website http so folks like me (on a IIgs) can read your post and then go check out the website without switching to modern hardware? It adds so much atmosphere and fun to be able to do that. I even downloaded the .dsk via the IIgs, however I haven't yet figured out how to access .dsk, .po, etc... once downloaded without switching to moden hardware and making an image with CiderPress. But that's besides the point. Great website and it works on "vintage" (haha) hardware!

Matt

fadden <thefadden@gmail.com> wrote:
> On Friday, October 21, 2022 at 12:01:49 AM UTC-7, Michael J. Mahon wrote:
>> If you've ever wanted to create HGR graphics containing circles of
>> various sizes, you’ve probably been disappointed with the slow drawing
>> speed.
>
> It's nice to know I'm not the only one. :-)
>
> The self-relocation routine has that fun "living on the edge" feel to it. Very nice.
>

Thanks! I’m pretty happy with my “key byte(s)” relocation scheme. I use
it on most programs of few pages, since in a short chunk of code it’s
extremely unlikely that all 256 byte values appear (and impossible in less
than one page of code!).

I actually use a short Applesoft program to histogram the byte values in
the target program and print a list of all the unused values. It’s typical
that there are several runs of consecutive “missing” values, so it’s not
difficult to choose unique values to be used as “keys” to flag addresses
requiring relocation. Setting the assembly ORG then completes the job. ;-)

I haven’t seen this approach used by others, but I’d be surprised if it
hasn’t been.

Of course, if code can be written so that it’s location-independent, that’s
great, but if you need internal subroutines or data, relocation is
necessary.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Hi Matt,

> [...] however I haven't yet figured out how to access .dsk, .po, etc...
> once downloaded without switching to moden hardware and making an image with CiderPress.

There are (at least) these options:

- http://www.sheppyware.net/apple-ii-software/diskmaker.html

- https://archive.org/details/diskmaker8

-
https://mirrors.apple2.org.za/ground.icaen.uiowa.edu/apple8/Utils/dsk2file.info

Or bypass the image file step altogether with
https://github.com/cc65/ip65/wiki/Wget65

Regards,
Oliver

Oliver Schmidt <ol.sc@web.de> wrote:
> Hi Matt,
>
>> [...] however I haven't yet figured out how to access .dsk, .po, etc...
>> once downloaded without switching to moden hardware and making an image with CiderPress.
>
> There are (at least) these options:

Have you tried MountIt ?
https://www.brutaldeluxe.fr/products/apple2gs/mountit.html

"Oliver Schmidt" wrote:

> Hi Matt,

> There are (at least) these options:
> - http://www.sheppyware.net/apple-ii-software/diskmaker.html
> - https://archive.org/details/diskmaker8
> https://mirrors.apple2.org.za/ground.icaen.uiowa.edu/apple8/Utils/dsk2fil
> e.info
>
> Or bypass the image file step altogether with
> https://github.com/cc65/ip65/wiki/Wget65

Thank you, man, Will do. I hope comp.sys.apple2 sticks around for another 30 years. I learn so much here. Hahaha any hope for a favoites page in the 8-bit Contiki browser?

** Proudly posted from an Apple IIgs **

Hi Matt,
> Thank you, man, Will do.

You're welcome :-)

> I hope comp.sys.apple2 sticks around for another 30 years. I learn so much here.

Me too!

> Hahaha any hope for a favoites page in the 8-bit Contiki browser?

Not much memory left for any feature whatsoever. Maybe a prefilled start
URL (aka home page) set to http://frogfind.com

Regards,
Oliver

In article <SPecnXQkNMtF3s_-nZ2dnZfqn_udnZ2d@giganews.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:
>If you've ever wanted to create HGR graphics containing circles of
>various sizes, you’ve probably been disappointed with the slow drawing
>speed. The straightforward method using sines and cosines can take
>several seconds per circle.
>
>I’ve just added a short (374 bytes) subroutine, FASTCIRC, to my website
>that draws circles in from 22 to 75 milliseconds, depending on radius.
>It’s self-relocating, so you can BLOAD it anywhere convenient.
>
>To use FASTCIRC, the center (Xlo, Xhi, Y) and the radius are POKEd into
>locations 6, 7, 8, and 9 and FASTCIRC is CALLed at its load address.
>
>My website has more complete documentation and a FASTCIRC.DSK image
>containing FASTCIRC, its Merlin source, and several demo programs to
>illustrate its use.
>
>Time to have fun with circles!
>--
>
>-michael

Very cool little program, it draws fast circles.

The FASTCIRC.dsk image is actually in ProDOS order. Could you rename
the image to FASTCIRC.po?

Kent

Kent Dickey <kegs@provalid.com> wrote:
> In article <SPecnXQkNMtF3s_-nZ2dnZfqn_udnZ2d@giganews.com>,
> Michael J. Mahon <mjmahon@aol.com> wrote:
>> If you've ever wanted to create HGR graphics containing circles of
>> various sizes, you’ve probably been disappointed with the slow drawing
>> speed. The straightforward method using sines and cosines can take
>> several seconds per circle.
>>
>> I’ve just added a short (374 bytes) subroutine, FASTCIRC, to my website
>> that draws circles in from 22 to 75 milliseconds, depending on radius.
>> It’s self-relocating, so you can BLOAD it anywhere convenient.
>>
>> To use FASTCIRC, the center (Xlo, Xhi, Y) and the radius are POKEd into
>> locations 6, 7, 8, and 9 and FASTCIRC is CALLed at its load address.
>>
>> My website has more complete documentation and a FASTCIRC.DSK image
>> containing FASTCIRC, its Merlin source, and several demo programs to
>> illustrate its use.
>>
>> Time to have fun with circles!
>> --
>>
>> -michael
>
> Very cool little program, it draws fast circles.
>
> The FASTCIRC.dsk image is actually in ProDOS order. Could you rename
> the image to FASTCIRC.po?
>
> Kent
>

Hi, Kent!

I’m glad you like it—it was fun to write!

Interesting that you should ask about the disk image. There are so many
disk images “out there”, many made before .po existed, that almost all
emulators disregard the image name and just examine the first sectors to
determine how to treat it. As a result, I’ve adopted the convention of
naming all 5.25” images .dsk!

I’m fact, I think all the disk images on my site are ProDOS images, but all
are named .dsk—and (so far) you’re the only one to mention it! ;-)

I’m willing to rename it, but then it would be the “inconsistent” one, or I
could change them all (which would be a pain since I refer to them by name
in several places in the text). I figure that if I name one image .po
people will assume that I consider the suffix meaningful, and all the other
images are *not* ProDOS! ;-)

Frankly, I don’t think the Apple II world will ever get the naming of all
the images consistent with their content. (And we haven’t even gotten to
disks that are neither DOS nor ProDOS.) I don’t think the rampant
inconsistency is a source of much confusion, either. Certainly you weren’t
confused. ;-)

Put another way, any of us who deal with disk images or write programs that
deal with them, have already adapted to “misnamed” images and learned to
cope with them, automatically or manually. That’s a useful skill in the
Apple II world. And, frankly, having a single suffix about which no
assumptions should be made is more consistent than trying to retroactively
impose a new standard which will never apply universally.

I originally tried posting .sdk ShrinkIt images, which are universal for
recreating physical disks, but received several inquiries about what they
were and why didn’t they work with emulators! So I switched several years
ago to simply posting disk (.dsk) images. Maybe .woz images will finally
become universal.

“The great thing about standards is that there are so many to choose from.”
And our “standard” solution is to create yet another “to rule them all”.

If my reasoning is faulty, please straighten me out. ;-)

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Hi,

> Interesting that you should ask about the disk image. [...]

If there is any "standard" at all, then it's this:

..do: DOS3.3 order
..po: ProDOS8 order
..dsk: Go figure

Regards,
Oliver

Oliver Schmidt <ol.sc@web.de> wrote:
> Hi,
>
>> Interesting that you should ask about the disk image. [...]
>
> If there is any "standard" at all, then it's this:
>
> .do: DOS3.3 order
> .po: ProDOS8 order
> .dsk: Go figure
>
> Regards,
> Oliver
>

Fair enough, though the Apple II world seems to have lots of other image
types, many of which aim(ed) to be more “universal”.

But I stand corrected, and will review my site and adopt the “standard” as
I have the time.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Hi Michael,

>> If there is any "standard" at all, then it's this:
>>
>> .do: DOS3.3 order
>> .po: ProDOS8 order
>> .dsk: Go figure

> But I stand corrected, and will review my site and adopt the “standard” as
> I have the time.

There seems to be a misunderstanding. I do NOT see an issue with .dsk files
having ProDOS ordering!

..do and .po both imply a statement regarding their ordering but .dsk does
NOT imply any ordering - and therefore a .dsk can per definition never have
a wrong ordering.

At least that is my POV which I wanted to express with my last posting.

Regards,
Oliver

In article <tjgdh7$4qa7$1@solani.org>, Oliver Schmidt <ol.sc@web.de> wrote:
>Hi Michael,
>
>>> If there is any "standard" at all, then it's this:
>>>
>>> .do: DOS3.3 order
>>> .po: ProDOS8 order
>>> .dsk: Go figure
>
>> But I stand corrected, and will review my site and adopt the “standard” as
>> I have the time.
>
>There seems to be a misunderstanding. I do NOT see an issue with .dsk files
>having ProDOS ordering!
>
>.do and .po both imply a statement regarding their ordering but .dsk does
>NOT imply any ordering - and therefore a .dsk can per definition never have
>a wrong ordering.
>
>At least that is my POV which I wanted to express with my last posting.
>
>Regards,
>Oliver

The two main problems with .dsk being "Go figure" is:

1) It makes emulators harder to write. An Apple II emulator is pretty easy
to get started with, and my guess is there are at least 20 freely
available. But: needing to auto-detect .dsk can be quite complex to do well,
and it's one of many features that emulators seem to need that raises the bar
to get new emulators.

2) It's actually not possible to detect PO or DO for an arbitrary .dsk
image. Let me see your code you're using to auto-detect, and I can
create an image which it will fail on. And many games have no OS, so there's
no great way to detect PO or DO of these images.

I think AppleWin's detection algorithm for .dsk is:

- Detect .DO order first. See if the link pointers on Track $11 look
like a DOS 3.3 catalog track for all sectors 0-14, looking at byte
+$02 in each sector. If it is, it's .DO. Then look to see if
blocks 2,3,4,5 on track $00 look like they have the ProDOS links
in the first 4 bytes of each block look valid for DOS 3.3 order.
If so, it's .DO. Otherwise, it's MAYBE .DO, which will be the
choice if nothing else matches.

- Detect .PO order next. Checks DOS 3.3 catalog track first, but only checks
some of the sectors (I'm not sure why, probably a trick of sector
numbers). If it looks valid, it's .PO. Then check blocks
2,3,4,5 for the ProDOS links in the first 4 bytes. If it
matches, it's PO order.

- Anything not detected defaults to .DO order

Note, this can be confused by a file on a ProDOS image in ProDOS order
that is on track $11 (blocks 136-151) and matches the DOS 3.3 pattern it's
looking for. It would be better if AppleWin checked ProDOS directory patterns
first when considering ProDOS order, to help avoid this confusion. And I'm
not picking on AppleWin, it just is the easiest source for me to look at.

Kent

Kent Dickey wrote:
>
> 2) It's actually not possible to detect PO or DO for an arbitrary .dsk
> image. Let me see your code you're using to auto-detect, and I can
> create an image which it will fail on.

But that's not the criteria is it? We don't need to write code that can
detect any arbitrary image which you create solely for the purpose of
failing said code.

The set of all Apple II disks in existence is finite.

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

D Finnigan wrote:
> Kent Dickey wrote:
>>
>> 2) It's actually not possible to detect PO or DO for an arbitrary .dsk
>> image. Let me see your code you're using to auto-detect, and I can
>> create an image which it will fail on.
>
> But that's not the criteria is it? We don't need to write code that can
> detect any arbitrary image which you create solely for the purpose of
> failing said code.
>
> The set of all Apple II disks in existence is finite.
>

When I wrote and tested my Apple II disk format detection code for the Mac
GUI Vault web site, I tested it against however many thousand disk images I
had in the Apple II collection.

A finite set.

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

On Friday, October 28, 2022 at 12:21:40 PM UTC-7, D Finnigan wrote:
> But that's not the criteria is it? We don't need to write code that can
> detect any arbitrary image which you create solely for the purpose of
> failing said code.
>
> The set of all Apple II disks in existence is finite.

Even if your auto-detection succeeds on 100% of all known DOS and ProDOS (and Pascal and CP/M) disks, you will be unable to auto-detect the layout of disks with a customized operating system, of which there are many. I believe most ".dsk" images are DOS order, which means the odds of success are > 50% on a blind guess... but why guess at all, when giving the image the correct filename extension removes the ambiguity?

On Friday, October 28, 2022 at 10:42:32 AM UTC-7, Kent Dickey wrote:

> I think AppleWin's detection algorithm for .dsk is:
> - Detect .DO order first.
> - Detect .PO order next.
> - Anything not detected defaults to .DO order

Yes, that's correct. CDiskImageHelper::Detect() runs through the supported disk types (initialized in the CDiskImageHelper::CDiskImageHelper() ctor) calling each Disk Type's Detect() function.
i.e.
CDoImage::Detect()
CPoImage::Detect()
etc.

> Note, this can be confused by a file on a ProDOS image in ProDOS order
> that is on track $11 (blocks 136-151) and matches the DOS 3.3 pattern it's
> looking for. It would be better if AppleWin checked ProDOS directory patterns
> first when considering ProDOS order, to help avoid this confusion. And I'm
> not picking on AppleWin, it just is the easiest source for me to look at.

Tom (or 4am or maybe qkumba) would know better then me but I don't believe defaulting to ProDOS sector order is a good idea for the (historical) reasons Andy mentioned.

Ideally, someone would do an in-depth analysis of the thousands of images and verify this assumption. In the 80's the number of DOS formatted disks dwarfed the ProDOS format. My gut feeling is that ProDOS didn't really take off in popularity until well into the 2000's when emulators made it trivial to switch. I would also say qkumba converting games to ProDOS also had an impact. And probably John Brooks excellent work that allowed newer version of ProDOS to run on 6502s.

Given the fact that it is not possible to write a 100% fool proof system there will always be edge cases that fail. Whoever is making the initial disk image "should" be properly tagging the disk format. But alas not everyone takes the same pride so we have some (many?) disks that aren't properly tagged and as such need to guess.

Regardless, please open an AppleWin issue so the rest of the team can mull this over and see if it is time to auto-detect a ProDOS volume directory first. Thanks.

Michael

In article <dog_cow-1666985012@macgui.com>,
D Finnigan <dog_cow@macgui.com> wrote:
>D Finnigan wrote:
>> Kent Dickey wrote:
>>>
>>> 2) It's actually not possible to detect PO or DO for an arbitrary .dsk
>>> image. Let me see your code you're using to auto-detect, and I can
>>> create an image which it will fail on.
>>
>> But that's not the criteria is it? We don't need to write code that can
>> detect any arbitrary image which you create solely for the purpose of
>> failing said code.
>>
>> The set of all Apple II disks in existence is finite.
>>
>
>When I wrote and tested my Apple II disk format detection code for the Mac
>GUI Vault web site, I tested it against however many thousand disk images I
>had in the Apple II collection.
>
>A finite set.
>
>--
>]DF$
>The New Apple II User's Guide:
>https://macgui.com/newa2guide/

Can you share some of this information? Do you know roughly what is the
percentage of .dsk images that are in ProDOS order? I do know the biggest
irony is DOS 3.3 Master.dsk on Asimov was in ProDOS order.

I think what you're saying is, if someone wants to throw together an Apple II
emulator (say, written in whatever new language is hot this year), before
releasing it they need to:

- Write .dsk auto-detect code. As far as I know, my description of AppleWin's
algorithm is the first public documentation of .dsk sector order
detection. Otherwise, they would need to do a bunch of research to
decide what to do. Note: other disk formats other than DOS 3.3 and
ProDOS are not covered, such as Pascal.

- Download every Apple II .dsk image available on the web.
How should I go about doing this? I am unable to see how to download
all Apple II files from macgui.com, can you provide some help?

- Test their auto-detect code and make sure they don't make any mistakes.

This seems like a pretty high bar, and I'm not sure any existing emulator
meets this requirement.

Kent

On Saturday, October 29, 2022 at 10:17:38 AM UTC-7, Michael 'AppleWin Debugger Dev' wrote:
> My gut feeling is that ProDOS didn't really take off in popularity until well into the 2000's when emulators made it trivial to switch.

Early emulators assumed all non-nibble disk images were in DOS order, because that's what the disk transfer utilities available back then used.

I suspect that what propelled ProDOS-ordered images was the use of ShrinkIt to compress disks, and utilities like NuLib that would unpack them into a ProDOS-ordered file. When using that approach, you'd need to use a second utility to reorder the sectors to DOS order so the image would be accepted by the emulator. Support for both DOS and ProDOS ordering in emulators came later, and I don't think any emulators used auto-detection until CiderPress started doing it (2003).

The ".2img" format was designed to resolve the ambiguity once and for all, but it never really took off.

One of my tests for CiderPress is to run MDC (Multi-Disk Catalog) on a partial mirror of asimov. (I occasionally update a copy here: https://faddensoftware.com/ .) One could instrument MDC to report the number of ambiguous / mis-labeled / unrecognizable images there are, were one sufficiently interested in doing that, but I'm not sure this discussion is really hampered by a lack of data. (FWIW, a simple grep reveals there are 10,411 disk image files with recognizable filesystems named "*.dsk" in my data set, though some of them are larger than 140KB and hence unambiguously ProDOS-ordered.)

On Sat, 29 Oct 2022, fadden wrote:

> On Friday, October 28, 2022 at 12:21:40 PM UTC-7, D Finnigan wrote:
>> But that's not the criteria is it? We don't need to write code that can
>> detect any arbitrary image which you create solely for the purpose of
>> failing said code.
>>
>> The set of all Apple II disks in existence is finite.
>
> Even if your auto-detection succeeds on 100% of all known DOS and ProDOS
> (and Pascal and CP/M) disks, you will be unable to auto-detect the
> layout of disks with a customized operating system, of which there are
> many. I believe most ".dsk" images are DOS order, which means the odds
> of success are > 50% on a blind guess... but why guess at all, when
> giving the image the correct filename extension removes the ambiguity?
>

I consider .DSK to mean DOS order, and if a ProDOS order file is given the
..DSK extension I consider it a mistake.

But having the option to override on open is nice.

-uso.

Hi Kent,

It seems to me that your topic is by now rather far away from where we
(or at least I) started.

But let me first try to avoid potential misunderstandings:

1. Is it great that .DSK images are often DOS3.3 and often ProODS
ordered? No.

Personal note: If I could decide from scratch, I'd have .DSK images
simply being always in the pyhsical sector order. My first
pre-internet emulator worked that way.

2. Is it great that the most popular Apple II disk image type has to
go without any meta data at all. No.

Personal note: If I could decide from scratch, I'd have all disk
images come with extensible meta data.

Okay, now to what used to be the topic at hand:

1. Is the issues with .DSK images noticably reduced by Michael
renaming his .DSK file to .PO? No.

2. Is Michael's .DSK file hard to auto-detect? No.

Just my two cents,
Oliver

In article <tjlob2$6u0v$1@solani.org>, Oliver Schmidt <ol.sc@web.de> wrote:
>Hi Kent,
>
>It seems to me that your topic is by now rather far away from where we
>(or at least I) started.
>
>But let me first try to avoid potential misunderstandings:
>
>1. Is it great that .DSK images are often DOS3.3 and often ProODS
>ordered? No.
>
>Personal note: If I could decide from scratch, I'd have .DSK images
>simply being always in the pyhsical sector order. My first
>pre-internet emulator worked that way.
>
>2. Is it great that the most popular Apple II disk image type has to
>go without any meta data at all. No.
>
>Personal note: If I could decide from scratch, I'd have all disk
>images come with extensible meta data.
>
>Okay, now to what used to be the topic at hand:
>
>1. Is the issues with .DSK images noticably reduced by Michael
>renaming his .DSK file to .PO? No.

Actually, my thesis is most of these .DSK images in ProDOS sector order are
relatively recent creations (within the last 20 years), and are not historical.
And so asking people who are creating these images now to use .PO for ProDOS
order would achieve my goal.

>2. Is Michael's .DSK file hard to auto-detect? No.
>
>Just my two cents,
>Oliver

What is your suggested algorithm for auto-detecting the sector order of
..dsk images?

Kent

In article <5cdb9ecc-d234-4fe0-8d26-ff8de4c4fa5bn@googlegroups.com>,
fadden <thefadden@gmail.com> wrote:
>On Saturday, October 29, 2022 at 10:17:38 AM UTC-7, Michael 'AppleWin
>Debugger Dev' wrote:
>> My gut feeling is that ProDOS didn't really take off in popularity
>until well into the 2000's when emulators made it trivial to switch.
>
>Early emulators assumed all non-nibble disk images were in DOS order,
>because that's what the disk transfer utilities available back then
>used.
>
>I suspect that what propelled ProDOS-ordered images was the use of
>ShrinkIt to compress disks, and utilities like NuLib that would unpack
>them into a ProDOS-ordered file. When using that approach, you'd need
>to use a second utility to reorder the sectors to DOS order so the image
>would be accepted by the emulator. Support for both DOS and ProDOS
>ordering in emulators came later, and I don't think any emulators used
>auto-detection until CiderPress started doing it (2003).
>
>The ".2img" format was designed to resolve the ambiguity once and for
>all, but it never really took off.
>
>One of my tests for CiderPress is to run MDC (Multi-Disk Catalog) on a
>partial mirror of asimov. (I occasionally update a copy here:
>https://faddensoftware.com/ .) One could instrument MDC to report the
>number of ambiguous / mis-labeled / unrecognizable images there are,
>were one sufficiently interested in doing that, but I'm not sure this
>discussion is really hampered by a lack of data. (FWIW, a simple grep
>reveals there are 10,411 disk image files with recognizable filesystems
>named "*.dsk" in my data set, though some of them are larger than 140KB
>and hence unambiguously ProDOS-ordered.)

Can you describe CiderPress's algorithm for determining sector order of
a .dsk file?

Kent

On Sunday, October 30, 2022 at 11:07:53 AM UTC-7, Kent Dickey wrote:
> Can you describe CiderPress's algorithm for determining sector order of
> a .dsk file?

"Complicated".

It tries DOS, ProDOS/Pascal, CP/M, and physical sector orders. (CP/M ordering is not really a thing, since nobody is creating disk images with CP/M software... but we might as well collect the whole set.) It tests the filesystem for DOS, ProDOS, Pascal, CP/M, RDOS, Gutenberg, and is probably checking for HFS even though I doubt anybody put that on a 5.25" floppy.

The tests for DOS / ProDOS filesystems have to take into account non-5.25" situations, like UNIDOS disks and DOS Master floppies, so there's a bunch of auto-detect code that doesn't really apply to 5.25" disks.

The tricky part is finding the right thresholds for the filesystem check. If you find 15 catalog sectors in the right order on track 17, you're done. If you find 2, you've got the wrong order. If you find 4... could be the wrong order plus some lucky bytes, could be a DOS disk with a custom short catalog track. So you try each order, and come up with a "yes definitely", "no definitely", or "maybe go with this one if you can't find anything better".

The filename extension is used as a hint, but enough files were named the wrong way that CiderPress doesn't pay much attention to it. It does allow the code to try the most likely order first, so if we get a "yes definitely" from a filesystem we can just stop looking. Also, if we can't identify the filesystem, we can open the sector editor with order indicated by the extension.

It Would Be Nice if CiderPress complained about incorrect or ambiguous filename extensions to encourage people to correct them.

cf. https://retrocomputing.stackexchange.com/q/15054/56