10

I am trying to read files of an AppleDOS 3.3 disk. The documentation I've found, both from Inside AppleDOS and also from Archiveteams' website (which I believe was taken from Inside AppleDOS): http://fileformats.archiveteam.org/wiki/Apple_DOS_file_system describes it in a lot of detail. The VTOC is the root block for the filesystem; it lives at 0x11000 in the image; it contains a pointer to the first directory block and also contains the bitmap.

However, my disk is a bit exotic. It's not a standard 35-track Apple disk; instead it's one of the rarer 80-track DSDD disks used by third-party disk expansions and clone systems. It's still the AppleDOS file format, except with 160 logical tracks (80 on one side and another 80 on the other.)

Except... the VTOC only has room for 50 tracks of bitmap, and this disk has 160. So, for the file system to work, the bitmap for the other 90 110 tracks must be somewhere.

Does anyone know where? As this is from a clone system, it's obviously not described in Apple's documentation!

(It's not in the logical sector immediately following the VTOC --- on my disk image, that's part of the directory. And yes, I have remembered about the AppleDOS sector translation!)

Improve this question
9
  • ...uh... possibly? (Fixed.)
    – David Given
    Commented Mar 28, 2023 at 20:25
  • 2
    The VTOC holds 50 tracks * 32 sectors, so if they used 16-sector tracks they could map up to 100 of them with minor tweaks. If they used a separate VTOC for the back side of the disk, presumably on track 80+17, that would cover it, but that sounds harder. Disassembling the modified DOS might be necessary. I don't think I've ever seen a disk image like this; if you have an image file you can share I'd love to see it.
    – fadden
    Commented Mar 29, 2023 at 4:37
  • 1
    Are you sure it was 80 tracks per side? I'd heard of people stretching the 35 out to about 40 using a specially modified DOS in the boot region (the first few tracks) but 80 seems a hard ask. If it was 40 per side, with each side having its own VTOC, that would be doable. In any case, the fact that INIT would simply write in-memory DOS to the drive means that you could easily replace the boot part. As fadden states, you may need to look at that. If it's a disk image rather than physical disk, how big is it?
    – paxdiablo
    Commented Mar 29, 2023 at 8:29
  • 1
    And, finally, what are the hex contents of the VTOC sector in your image? There's a lot of stuff there you could play with to allow more storage, over and above the track count.
    – paxdiablo
    Commented Mar 29, 2023 at 8:49
  • 1
    Can you share the dump? Might be easier to figure that out by actually looking at the contents.
    – dirkt
    Commented Mar 29, 2023 at 16:12

1 Answer 1

Reset to default
6

Summary of comments, plus analysis of "appleii640.img.gz" from the github issue page...

This is an 80-track, 16-sector disk. The interpretation of the sector in-use map in the DOS VTOC was modified to use two bytes per track instead of 4, which allows up to 100 16-sector tracks.

Modifying DOS 3.3 to work with this should be pretty straightforward software-wise. Many Apple II drives should be able to read these disks, stepping by "half-track" instead of full track. Writing to them could be problematic because many Apple II drive heads write in a large enough area that adjacent half tracks will be altered.

The decoded image file includes both sides of the disk, but the DOS image only spans one side. The second half of the disk image, which holds the back side of the disk, is nothing but 0xe5.

Improve this answer
2
  • Was that something that DOS 3.3 could dynamically detect? As in something on the disk indicated 2 or 4 bytes that DOS picked up and adjusted for. My curiosity is because I don't recall having to boot a special version of DOS 3.3 to access my older 400K Sider volumes. That being said, I rarely used them since most of the drive was formatted for ProDOS; IIRC the stock Sider software required you to have at least 4 partitions: ProDOS (<=16MB), DOS 3.3 (4 vols), Pascal, and CP/M. You could create more than that, but you needed at least some Pascal representation even if you didn't use it.
    – bjb
    Commented Mar 30, 2023 at 12:22
  • Standard DOS doesn't define bytes per track. The VTOC declares the number of tracks and the tracks per sector, so you can specify 50 32-sector tracks to get a 400KB volume. AmDOS/UniDOS/OzDOS use that to put two 400KB volumes on an 800KB disk. To support 80-track disks you'd need to modify DOS to parse the VTOC differently when the number of tracks exceeds 50. I wonder if the designers anticipated 80-track disks, and that's why they used 4 bytes per track.
    – fadden
    Commented Mar 30, 2023 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .