I haven't had much chance to work on it for the past day or two and I won't again for a couple of days yet, but reimplementing cppo is finally coming along:
tjcarter@rem:~/Source/iKarith/cppo-ng$ ./cppo-ng -cat disks/dos_33.dsk
Disk extension suggests disk is in DOS order, 143360 bytes
Testing for DOS 3.3...
testing DOS order
VTOC track 17 0 looks good
DOS order 1 , winner DOS order
testing ProDOS order
VTOC track 17 0 looks good
ProDOS order 3 , winner ProDOS order
Disk volume 254
*A 006 HELLO
*I 018 ANIMALS
*T 003 APPLE PROMS
*I 006 APPLESOFT
*I 026 APPLEVISION
*I 017 BIORHYTHM
*B 010 BOOT13
*A 006 BRIAN'S THEME
*B 003 CHAIN
*I 009 COLOR DEMO
*A 009 COLOR DEMOSOFT
*I 009 COPY
*B 003 COPY.OBJ0
*A 009 COPA
*A 010 EXEC DEMO
*B 020 FID
*B 050 FPBASIC
*B 050 INTBASIC
*A 028 LITTLE BRICK OUT
*A 003 MAKE TEXT
*B 009 MASTER CREATE
*B 027 MUFFIN
*A 051 PHONE LIST
*A 010 RANDOM
*A 013 RENUMBER
*A 039 RENUMBER INSTRUCTIONS
*A 003 RETRIVE TEXT
140k disk
it's not ProDOS
it's DOS 3.3
order needs fixing (PO)
fixing order
HELLO
ANIMALS
APPLE PROMS
APPLESOFT
APPLEVISION
BIORHYTHM
BOOT13
BRIAN'S THEME
CHAIN
COLOR DEMO
COLOR DEMOSOFT
COPY
COPY.OBJ0
COPA
EXEC DEMO
FID
FPBASIC
INTBASIC
LITTLE BRICK OUT
MAKE TEXT
MASTER CREATE
MUFFIN
PHONE LIST
RANDOM
RENUMBER
RENUMBER INSTRUCTIONS
RETRIVE TEXT
This code doesn't "work" yet, but you can see that it's coming along. When cppo is told to load a pathname, it runs my code before it returns the disk image loaded into memory for the legacy cppo code--that's why you're seeing a DOS 3.3 catalog and order detection before order detection and a bare catalog.
Now, I didn't know DOS 3.3. I new something about ProDOS disk structures when I started this part of the code, but nothing about DOS 3.3 at all. The other problem was one of architecture. I've more or less settled on architecture now, I think, and I've been spending some time with Beneath Apple DOS (see iKarith/beneath-apple-dos for the first part of what I've done with that) for some help with DOS. Basically the two major disk tools I have access to (CiderPress and AppleCommander) implement it a bit differently, but fundamentally both effectively treat disk images like onions, which is probably the right way to do it. (AppleCommander is less flexible about this and CiderPress's way is totally how I'd have done it back when C was the promary language I did anything with--abstract the C file pointer API and have each layer implement it in terms of its own stuff plus the API of the next layer.
Actually I think i'm going to keep doing it that way just with a bit more tailored API more tailored to our needs.
Anyway the first issue is that of sector interleave. ProDOS order images happen to be in block order. DOS images are always accessed in sector order. Since these are the only two things we support in cppo, it was possible to "cheat" at sector transformations a bit. If you're reading blocks for ProDOS, the offset of blockno is blockno * PRODOS_BLOCK_SIZE, easy. And if the image is in DOS order, the offset of the track and sector t, s is (t * SECTORS_PER_TRACK + s) * SECTOR_SIZE. Looking at it this way, you can effectively swap a disk from one order to the other using this pseudocode:
for track on the disk:
for s1, s2 in zip(range(1, 8), range(14, 7, -1)):
swap disk(track, s1) and disk(track, s2)
That's basically what cppo does. Well, not exactly that because that's an in-place swap using a clever Python idiom to count up and down at the same time. Others exist. We don't even pretend we support them, so ultimately you need an arbitrary lookup table of sector transformations. I've done that, and the new DOS 3.3 code does that. But first you need to know what ordering to use. I predict this based on the extension ... and then promptly ignore my prediction for now. More on that in a moment.
So on to detecting the filesystem. AppleCommander, CiderPress, and a neat little thing called a2disk (which is actually written in Python) all use different methods to detect/read a DOS 3.3 disk. We'll ignore a2disk for the moment because it only supports DOS 3.3 and in DOS order. The DOS 3.x VTOC doesn't move for DOS or ProDOS order, so we can just read that as a quick test of DOS-3.3-ness. But then we need to figure out the sector order for real. To do that, CiderPress and AppleCommander attempt to walk the DOS catalog to see if they can determine the order. That's gonna break if we have fewer than 7 files in the catalog, I can tell you that right now. If there's some signature on track 0 (outside of sectors 0 and 15 of course) that survives "common" patches to the RWTS, I don't know what it would be, but I'd love for someone to tell me. :)
I mentioned a2disk before and said I'd come back to it. That's a pretty simple (but well-written) bit of Python that can read a DOS order DOS 3.3 disk. It extracts the VTOC sector and keeps it in memory as a bytes object and uses @property methods to give you friendly access to its fields, most of which are single bytes. Very nice implementation, and I'm doing similar for the VTOC. I had code to display the allocation map written about Wednesday or so, but that's a mess and I'd do it differently now that I've got those architecture questions answered.
I'm not doing the same for the catalog. I could I guess, but ... for the catalog, a list of directory entries makes a lot more sense. There's a convenience method to spit out the CATALOG output you see above, but my intention is that one should be able to iterate over directory entries in the catalog and simple access the fields as desired. I have in mind for the cppo runner to output the same format what IvanExpert wrote, but also to be able to output more information--to the screen or in JSON format for embedding. Of course code written in Python will be able to just import the blocksfree module and access things directly.
Once I have all of the DOS 3.3 functions implemented completely I'll modify legacy.py to use that instead of its current code for DOS 3.3 disks. The same for ProDOS will conclude refactoring cppo as such. Anything else should rightly be done after I write a new runner script whose command line doesn't have to be compatible with cppo's for existing scripts like the a2server netboot script, for example. That's future though.