Timeline for How can I programmatically determine whether an Apple II .dsk disk image is a DOS .do image or a ProDOS .po image?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 22, 2022 at 17:47 | comment | added | supercat | @NickWestgate: I've also been curious how hard it would have been to design a DOS that would, when a language card was present, use the otherwise-unused 4K of RAM in that card to grab an entire track when a request was made to read any sector on it, thus allowing any subsequent read requests to be served from that cache, and which supported a "write to the next observed sector X for which READYSECTORTABLE,X is zero" operation, and indicate which sector was written, rendering issues of read and write interleave irrelevant for most purposes. | |
| Nov 22, 2022 at 17:15 | comment | added | supercat | @NickWestgate: Perhaps it's because cross assemblers are more convenient than assembling on a period machine, but raw nybble reading doesn't seem all that hard. I've written a demo that reads double-hires pictures stored on three disk tracks each, decoding groups of seven nybbles to screen six bytes while they are being read off disk. BTW, I wonder why it seems like everything always used DISK ID 254 rather than if nothing else picking a random ID when writing a disk image? | |
| Nov 22, 2022 at 7:48 | comment | added | Nick Westgate | @supercat: Writing raw nibble-reading code to get the physical sectors is non-trivial, so almost nobody did that. And it served no purpose for DSK creators because moving physical sectors around didn't affect the image contents. The only thing that affects image contents is the logical to physical mapping - which was introduced in DOS 3.3 for interleaving, but in practice makes disks incompatible when changed. | |
| Nov 22, 2022 at 7:38 | comment | added | Nick Westgate | @supercat: The first DSK creators were written in DOS, so DO became the default for DSK. ProDOS was less popular, but utilities written for that used PO, which was the start of the confusion. (I wrote such a utility myself in the 90's using ProDOS but its DSK output was DO.) During the 90's some emulator authors collaborated to create the 2(I)MG format, but it was too late. There's a (hijacked thread) discussion in CSA2, which brought me back here. ; - ) | |
| Nov 21, 2022 at 18:04 | comment | added | supercat | @NickWestgate: I would also think it would have been fairly simple but useful to have all three sector numbers be sequential, but handle interleaving via the choice of what order to allocate sectors. Such an approach would have likely made it possible to offer a choice of whether to use an interleave optimized for read speed or write speed. When producing backups that will likely never be read, use the optimal interleave for write speed. Once a file is stable and will be used a lot, use the optimal interleave for read speed. | |
| Nov 21, 2022 at 18:02 | comment | added | supercat | @NickWestgate: There are three orders in which one might at least somewhat sensibly choose to write out a disk dump format: using physical order of sectors, using labeled sector numbers, or using any other mapping the OS introduces. I find it a bit weird that disk dump formats choose the last approach for both DOS and ProDOS, rather than perhaps starting with DOS order but then migrating to OS-agnostic labeled-sector-number order once it became clear DOS wasn't the only game in down. | |
| Nov 21, 2022 at 9:01 | comment | added | Nick Westgate | @supercat: What I mean is that each sector has a physical sector number (written in the sector prologue) but ProDOS and DOS (3.3, not 3.2, but also Pascal, C/PM etc - see here) deal in logical sector numbers and convert to the physical sector number via lookup tables. So it's using different lookup tables that scrambles disks if they're read/written with the wrong combination. | |
| Aug 30, 2022 at 16:01 | comment | added | supercat | @NickWestgate: I would expect neither DOS 3.3 nor ProDOS to care about physical sector order except when formatting a disk. Accessing a disk whose segments aren't in the ideal order would be very slow, but both DOS 3.3 nor ProDOS will perfectly happily ignore sectors they're not interested in until the one they're interested in arrives under the drive head. | |
| Jun 4, 2020 at 1:37 | comment | added | hippietrail | I started to implement some code checking validity of various fields in the DOS VTOC and the ProDOS Volume Directory Key Block and found that of the images I downloaded from various sites, almost all the ProDOS images were in DOS order, which really surprised me. I have no DOS images in ProDOS order and in fact it's not easy to find ProDOS images. For my needs so far it seems that checking for DOS in DOS logical order, and ProDOS in both DOS logical order and ProDOS logical order seems to work. Mapping DOS to and from ProDOS is the same both ways so I'm calling it "flipped" in my code. | |
| Jun 4, 2020 at 0:14 | comment | added | Nick Westgate | @hippietrail: Both DOS 3.3 and ProDOS each have their own logical to physical sector mapping, and the imaging app mightn't care about it - it just asks (Pro)DOS to read each sector/block. Disks with different mappings will cause problems, the most common being when you image DO to PO or PO to DO. The AppleWin emulator has code to detect those cases by looking for the DOS 3.3 Catalog track/sector link or ProDOS Volume Directory pointer bytes at the expected locations. | |
| Jun 3, 2020 at 12:58 | comment | added | Tommy | @dirkt they’re definitely in physical order; e.g. for my dsk2woz file format converter I just put responsibility on the user: give it a file extension with a ‘p’ in it if you want the sector to be interpreted in ProDOS order (see the bottom of the README). | |
| Jun 3, 2020 at 10:37 | comment | added | dirkt | @Tommy I was under the impression that .dsk files are sector dumps in order of sector number, no matter what physical interleaving is used. If it would be dumps in physical order, then that's a problem, because without the address field in the dump, you wouldn't be able to generate the correct address header when emulating. Maybe I am wrong, but if I am, I'd really like to know how to solve this problem. It's also easy to check: Look at track 11 in a DOS image, and see if they are in sector-number order, as opposed to physical order. I'll do that when I have some time. | |
| Jun 3, 2020 at 8:10 | comment | added | cjs |
@dirkt The .dsk image formats do not have the sector address field, just the data field for each sector. Thus the emulator must synthesize the sector address field for the RTWS, generating volume, track and sector numbers for each data block based on the sector numbers it assigned to each sequential block of data in the .dsk file. Thus, it must know the interleave used in the .dsk file.
|
|
| Jun 3, 2020 at 4:43 | comment | added | hippietrail | @dirkt: Are you certain they are the physical sectors? I thought it was the physical sectors for DOS 3.3 and the logical blocks for ProDOS, but when I started to dig in, it did not seem to be clear and I'm now down another rabbit hole. A disk-consuming tool running on some other OS will have to do whatever the RWTS does. | |
| Jun 3, 2020 at 4:28 | comment | added | Tommy | @dirkt that it were that simple; DSK files are sector dumps in physical order, without addresses. DOS 3.3 and ProDOS use different interleaves. So without making a judgment call on whether a disk image is DOS 3.3 or ProDOS, an emulator can't actually determine the addresses to associate with sectors. | |
| Jun 3, 2020 at 4:16 | comment | added | dirkt | Emulators and .dsk-consuming tools deal with that by not caring (because e.g. the RWTS routine called in an emulator will return the correct data, no matter if its called from DOS or ProDOS in the emulation), assuming one or the other and failing when it doesn't match reality, or allowing the user to select it. | |
| Jun 3, 2020 at 3:59 | comment | added | hippietrail | Yes my proximate goal is to list the files on the disk, later I'll move on to extracting files from the disk. I'm only reading and only care about the most common formats as used sites with lots of .dsk files of old software. I don't care about games using the disk their own. But I did want to allow for techniques and tricks found by writers of emulators and .dsk-consuming tools, who must've had to deal with this over the past twenty years. Perhaps based on the sectors vs blocks approaches. | |
| Jun 3, 2020 at 3:45 | history | answered | dirkt | CC BY-SA 4.0 |