If you've ever wanted to create HGR graphics containing circles of
various sizes, you’ve probably been disappointed with the slow drawing speed.
Time to have fun with circles!
-michael
Home page: http://michaeljmahon.com
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.
[...] 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.
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:
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?
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
In article <[email protected]>,
Michael J. Mahon <[email protected]> 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
Interesting that you should ask about the disk image. [...]
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
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.
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
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.
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.
I think AppleWin's detection algorithm for .dsk is:
- Detect .DO order first.
- Detect .PO order next.
- 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.
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/
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.
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 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 popularityuntil 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.)
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
Can you describe CiderPress's algorithm for determining sector order of
a .dsk file?
What is your suggested algorithm for auto-detecting the sector order of
.dsk images?
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".
Can you share some of this information? Do you know roughly what is the percentage of .dsk images that are 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.
What is your suggested algorithm for auto-detecting the sector order of
.dsk images?
With values in hex...
If I may, block 88 can be changed to getting the value of T1/SB/01. It contains the track of the VTOC. Using it allows to handle VTOC that are not on T11.
Antoine
If I may, block 88 can be changed to getting the value of T1/SB/01. It contains the track of the VTOC. Using it allows to handle VTOC that are not on T11.
AntoineIs this part of DOS and is it the same for all versions of DOS? Including DOS3.2 and Third Party DOS's?
If I may, block 88 can be changed to getting the value of T1/SB/01. It contains the track of the VTOC. Using it allows to handle VTOC that are not on T11.
DOS: track 17 sector 0 holds the VTOC. Everything else is potentially variable.AntoineIs this part of DOS and is it the same for all versions of DOS? Including DOS3.2 and Third Party DOS's?
ProDOS: block 2 holds the start of the volume directory. Everything else is potentially variable.
Most disks follow the standard pattern: track 17 is a full catalog track, ProDOS has 4 volume directory blocks followed by the bitmap. Detecting "most disks" isn't the interesting part of the problem though. :-)
I was taking Antoine's comment of T1/SB/01 as the location of the VTOC within DOS. Unless that was a typing error and was supposed to be T11/SB/01, in which case it has a different meaning.
Kent Dickey wrote:
Can you share some of this information? Do you know roughly what is the
percentage of .dsk images that are in ProDOS order?
Not off hand, but I can get that if you are really curious.
SELECT COUNT(*) FROM files WHERE file_format = 11;
+----------+
| 2700 |
+----------+
SELECT COUNT(*) FROM files WHERE file_format = 11
-> AND file_url LIKE '%.dsk.%';
+----------+
| 2341 |
+----------+
The result seems even (much) more clear than I expected: .DSK files with ProDOS order are simply the de facto standard. Period.
D Finnigan wrote:
Kent Dickey wrote:
Can you share some of this information? Do you know roughly what is the >>> percentage of .dsk images that are in ProDOS order?
Not off hand, but I can get that if you are really curious.
Counting ProDOS format disks:
mysql> SELECT COUNT(*) FROM files WHERE file_format = 11;
+----------+
| COUNT(*) |
+----------+
| 2700 |
+----------+
1 row in set (0.10 sec)
Counting ProDOS format disks with file extension .dsk:
SELECT COUNT(*) FROM files WHERE file_format = 11
-> AND file_url LIKE '%.dsk.%';
+----------+
| COUNT(*) |
+----------+
| 2341 |
+----------+
1 row in set (0.10 sec)
Using the output from Andy's file list
can only show which disks have a ProDOS filesystem on it, not which have sectors in ProDOS order.
D Finnigan wrote:
Kent Dickey wrote:
Can you share some of this information? Do you know roughly what is the >>> percentage of .dsk images that are in ProDOS order?
Not off hand, but I can get that if you are really curious.
Counting ProDOS format disks:
mysql> SELECT COUNT(*) FROM files WHERE file_format = 11;
+----------+
| COUNT(*) |
+----------+
| 2700 |
+----------+
1 row in set (0.10 sec)
Counting ProDOS format disks with file extension .dsk:
SELECT COUNT(*) FROM files WHERE file_format = 11
-> AND file_url LIKE '%.dsk.%';
+----------+
| COUNT(*) |
+----------+
| 2341 |
+----------+
1 row in set (0.10 sec)
CP/M, RDOS, Gutenberg, and is probably checking for HFS even though I doubt anybody put that on a 5.25" floppy.Can you describe CiderPress's algorithm for determining sector order of"Complicated".
a .dsk file?
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,
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.
Just realized you were testing for file systems and not sector ordering.
There should only be 2 sector orderings, is there not? Sequential like Prodos does it, and DOS ordering? Or does formatting with interleave change the sector orders as well?
Is a pascal disk on a floppy using sector order, whereas a Pascal volume on a hard drive uses Prodos order blocks?
Same with CP/M, does it use both, depending on which disk it is on, floppy or hard drive?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 140:42:18 |
| Calls: | 12,087 |
| Files: | 14,998 |
| Messages: | 6,517,425 |