Apple 2 DS/DD disks

[ibm5110]

I'm having troubles converting flux images of Basis 108 disks (an Apple 2 clone) into correct Apple 2 IMG files. The particularity is that it uses 80 track double-sided drives, with filesystem tracks 0..79 on side 0, and tracks 80..159 on side 1. I can't create a working textpb file that handles this situation. Here's the textpb configuration:

encoder {
  apple2 {
  }
}
decoder {
  apple2 {
  }
}
comment: "Apple II 80 track DS"
image_writer {
  filename: "apple2x.img"
  type: IMG
}
flux_source {
  type: DRIVE
}
image_reader {
  filename: "apple2x.img"
  type: IMG
}
drive {
  drive: 0
}
tpi: 96
layout {
  layoutdata {
    sector_size: 256
    physical {
      start_sector: 0
      count: 16
    }
  }
  tracks: 80
  sides: 2
}

And this is what fluxengine generates (which is wrong):

 0.0: 495 ms in 138045 bytes
      96 raw records, 48 raw sectors; 3.27us clock (306kHz)
      sectors: 0.0.0 0.0.1 0.0.2 0.0.3 0.0.4 0.0.5 0.0.6 0.0.7 0.0.8 0.0.9 0.0.10 0.0.11 0.0.12 0.0.13 0.0.14 0.0.15
      4096 bytes decoded
 0.1: 495 ms in 141238 bytes
      no more data; giving up
      96 raw records, 48 raw sectors; 3.27us clock (306kHz)
      sectors: 0.1.0? 0.1.1? 0.1.2? 0.1.3? 0.1.4? 0.1.5? 0.1.6? 0.1.7? 0.1.8? 0.1.9? 0.1.10? 0.1.11? 0.1.12? 0.1.13? 0.1.14? 0.1.15? 80.1.0 80.1.1 80.1.2 80.1.3 80.1.4 80.1.5 80.1.6 80.1.7 80.1.8 80.1.9 80.1.10 80.1.11 80.1.12 80.1.13 80.1.14 80.1.15
      4096 bytes decoded
 1.0: 495 ms in 141276 bytes
      96 raw records, 48 raw sectors; 3.27us clock (306kHz)
      sectors: 1.0.0 1.0.1 1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.9 1.0.10 1.0.11 1.0.12 1.0.13 1.0.14 1.0.15
      4096 bytes decoded
 1.1: 495 ms in 141464 bytes
      no more data; giving up
      96 raw records, 48 raw sectors; 3.27us clock (306kHz)
      sectors: 1.1.0? 1.1.1? 1.1.2? 1.1.3? 1.1.4? 1.1.5? 1.1.6? 1.1.7? 1.1.8? 1.1.9? 1.1.10? 1.1.11? 1.1.12? 1.1.13? 1.1.14? 1.1.15? 81.1.0 81.1.1 81.1.2 81.1.3 81.1.4 81.1.5 81.1.6 81.1.7 81.1.8 81.1.9 81.1.10 81.1.11 81.1.12 81.1.13 81.1.14 81.1.15
      4096 bytes decoded
[...]
     Tracks -> 1         2         3         4         5         6         7         8         9         10        11        12        13        14        15
H.SS 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 1 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 2 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 3 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 4 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 5 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 6 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 7 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 8 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 9 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.12 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.13 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.14 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.15 ................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1. 0 ????????????????????????????????????????????????????????????????????????????????...........B....................................................................
1. 1 ????????????????????????????????????????????????????????????????????????????????................................................................................
1. 2 ????????????????????????????????????????????????????????????????????????????????................................................................................
1. 3 ????????????????????????????????????????????????????????????????????????????????...........B....................................................................
1. 4 ????????????????????????????????????????????????????????????????????????????????................................................................................
1. 5 ????????????????????????????????????????????????????????????????????????????????................................................................................
1. 6 ????????????????????????????????????????????????????????????????????????????????..........B.....................................................................
1. 7 ????????????????????????????????????????????????????????????????????????????????................................................................................
1. 8 ????????????????????????????????????????????????????????????????????????????????................................................................................
1. 9 ????????????????????????????????????????????????????????????????????????????????................................................................................
1.10 ????????????????????????????????????????????????????????????????????????????????................................................................................
1.11 ????????????????????????????????????????????????????????????????????????????????................................................................................
1.12 ????????????????????????????????????????????????????????????????????????????????................................................................................
1.13 ????????????????????????????????????????????????????????????????????????????????................................................................................
1.14 ????????????????????????????????????????????????????????????????????????????????................................................................................
1.15 ????????????????????????????????????????????????????????????????????????????????................................................................................
Good sectors: 3837/5120 (74%)
Missing sectors: 1280/5120 (25%)
Bad sectors: 3/5120 (0%)
      IMG: wrote 80 tracks, 2 sides, 640 kB total to /tmp/x.img

The IMG file has all the correct data from side 0, but side 1 data is all blank instead of having the data from tracks 80..159. I need to tell fluxengine a track offset for side 1 or something like that. How do I do that?

[davidgiven]

Oh, good grief --- why would they even do that?

I believe this will need custom logic in the apple2 decoder/encoder. I'll take a look.

[davidgiven]

Can you upload a flux file I can use for testing? There's some non-trivial stuff to deal with, in part because this is the first double-sided Apple disk I've ever seen.

[ibm5110]

Oh, good grief --- why would they even do that?

I guess the idea is that the file system/OS (I'm not an Apple 2 expert) doesn't know about a second head, so they just increased the number of tracks.

[ibm5110]

Can you upload a flux file I can use for testing? There's some non-trivial stuff to deal with, in part because this is the first double-sided Apple disk I've ever seen.

007.scp.gz

This is a DOS 3.3 disk with a couple of simple games.

[davidgiven]

The basis branch should now contain some experimental code for reading these. Binaries will be here once it builds, at least for Windows and OSX:

https://github.com/davidgiven/fluxengine/actions/runs/4537446990

However, I'm not sure it's right. Looking at the image, neither appledos nor prodos nor no sector skew at all seemed to make sense (there's an adventure game in Basic near the top of the disk which helps here). PTAL?

When you say DOS 3.3, you mean appledos, right? I don't have a filesystem plugin for that yet, although I do have one for prodos.

[ibm5110]

The basis branch should now contain some experimental code for reading these. Binaries will be here once it builds, at least for Windows and OSX:

https://github.com/davidgiven/fluxengine/actions/runs/4537446990

Ok, I managed to build this (I had to remove basis108 from the build.mk and create/modify _apple2.textpb and apple2.textpb)

However, I'm not sure it's right. Looking at the image, neither appledos nor prodos nor no sector skew at all seemed to make sense (there's an adventure game in Basic near the top of the disk which helps here). PTAL?

Looks good now! At least the image is identical to that what my decoder produced four years ago.

When you say DOS 3.3, you mean appledos, right? I don't have a filesystem plugin for that yet, although I do have one for prodos.

Yes, it's AppleDOS. But I suspect that the side 1 data should be appened to the track 0 data and not interspersed inbetween. After all, they are marked as tracks 80..159, i.e. change tracks before heads. This can be configured with order: HCSin the config.

I have found the following regarding Apple 2 CP/M:

C:  This disk format is 16 sectors/track, 80 tracks double sided, where
    the tracks and sides are mapped within the modified CP/M RWTS so they
    appear as 160 tracks to the CP/M Z-80 BIOS (which knew nothing about
    double-sided disks).  This format yields 628K of data per diskette,
    excluding the system tracks.

There were several after-market floppy drives with Shugart interface for the Apple 2 that offered 80 cylinders/2 sides. So I think that AppleDOS (and certainly also ProDOS) was modified to map a track range from 0..159 to the corresponding cylinder/head.

[davidgiven]

Oops, I forgot to check in the important files! Yes, it 640kB format does order the tracks with one side and then the other. Please see https://github.com/davidgiven/fluxengine/actions/runs/4545419260 for the updated build.

As the DS 640kB format seems not to be specific to the Basis 108, I've renamed it to appleii640 and the normal format to appleii140 (to match the naming scheme used by the other formats).

[davidgiven]

Also, something very weird is going on.

I've implemented a basic AppleDOS filesystem plugin, allowing files to be read from the disk. This is usually a good way to check that the image makes sense.

If I use the AppleDOS sector translation, I get one set of files.

$ ./fluxengine ls appleii640 -f 007.scp --appledos
      OPTION: compensating for AppleDOS soft sector skew
SCP tracks 0-80, heads 0-1
SCP sample resolution: 25 ns
17.0: 495 ms in 136135 bytes
  DOS-CONVERTER                          768 
  "HELLO                 03.12.83"      2048 
  CONV-COPY                             2560 
  COPY.OBJ0                              768 
  ACCESS                                 768 
  "DISK A12/39.2"                        512 
  HELLO2                                1024 
  "HDCPY-TEST1           28.07.84"       512 
  EPSONCOPY                              768 
  "HARDCOPY4             28.07.84"      1280 
  "ANGELIKA              28.07.84"       512 
  "mandelbaum            28.07.84"       512 
  "sechstund             28.07.84"      1280 
(13 files, 13312 bytes)

The files then don't read, which makes me think this is incorrect.

 ./fluxengine getfile appleii640 -f 007.scp --appledos -p "EPSONCOPY"
      OPTION: compensating for AppleDOS soft sector skew
SCP tracks 0-80, heads 0-1
SCP sample resolution: 25 ns
17.0: 495 ms in 136135 bytes
77.0: 495 ms in 138642 bytes
 8.1: 496 ms in 134523 bytes
49.1: 496 ms in 134521 bytes
57.1: 496 ms in 134528 bytes
Error: invalid filesystem: sector 4000 is out of bounds

If I don't use AppleDOS sector translation, then I get more files.

$ ./fluxengine ls appleii640 -f 007.scp --plain-appledos
      OPTION: 
SCP tracks 0-80, heads 0-1
SCP sample resolution: 25 ns
17.0: 495 ms in 136135 bytes
  DOS-CONVERTER                          768 
  "HELLO                 03.12.83"      2048 
  CONV-COPY                             2560 
  COPY.OBJ0                              768 
  ACCESS                                 768 
  "DISK A12/39.2"                        512 
  HELLO2                                1024 
  "ALIEN INVASION"                       512 
  GO-BANG                               4864 
  "Moskitoplage         1"               512 
  "GOLD RUSH"                          29440 
  "GAMMA GOBLINS"                      32512 
  "TESTFILE              29.05.84"       512 
  "BILDRUCK              28.07.84"       768 
  WIZ2.SHAPES                           3840 
  WIZ3.SHAPES                           2304 
  WIZ                                    512 
  WORD4                                  512 
  WORDS                                 1280 
  WORD2                                 1280 
  WORD3                                 1280 
  LOMEM:                                 512 
  INVADERS                               512 
  "TENNIS FUER 2"                       3328 
  ZOMBIE                                4352 
  "LUNAR LANDER"                         512 
  "BLUNAR LANDER"                       7936 
  "BALIEN INVASION"                     3072 
  LOGO                                  8448 
  "---ZOMBIE ISLAND---"                    0 
  ZOMBIE-ISLAND                         4352 
  "PIRATE'S ADVENTURE"                 20736 
  WELTRAUMGEDR[NGE                      1536 
  MICROCHESS.BOARD                      8448 
  MICROCHESS.CODE                       8192 
  "SARGON II.LOGO"                       512 
  "SARGON II.CODE"                     14848 
  BACKGAMMON                           11776 
  A2-FS1                               40704 
  FLY                                    512 
  INV.B.PDL                            24576 
  "CREATURE VENTURE"                     512 
  WIZDIM                                4096 
  WIZARD1                              15616 
  WIZARD2                              15872 
  WIZARD3                              12544 
  WIZ.SAVE                               512 
  WIZ.SHAPES                            4864 
(48 files, 307456 bytes)

These files can all be read, but the results are usually garbage --- clearly broken Basic data, for example.

$ ./fluxengine getfile appleii640 -f 007.scp --plain-appledos -p "WIZARD1"
      OPTION: using AppleDOS filesystem but with no sector skew
SCP tracks 0-80, heads 0-1
SCP sample resolution: 25 ns
17.0: 495 ms in 136135 bytes
30.0: 495 ms in 140594 bytes
 1.0: 495 ms in 142161 bytes
 2.0: 495 ms in 135969 bytes
 3.0: 495 ms in 140474 bytes

00000000   54 22 00 18  0E 48 00 B0  34 38 36 3A  AD 56 D0 33  T"...H..486:.V.3
00000010   CE 56 D0 32  C4 AB 37 39  00 40 0E 49  00 AD 56 D0  .V.2..79.@.I..V.
00000020   35 CD 4E D0  33 32 CD 4F  5A D0 30 C4  95 39 39 C5  5.N.32.OZ.0..99.
00000030   31 37 30 2C  31 34 30 3A  4F 5A D0 31  3A AB 37 32  170,140:OZ.1:.72
00000040   00 4F 0E 4A  00 AD 4F 5A  D1 CF 30 C4  AB 37 39 00  .O.J..OZ..0..79.
00000050   55 0E 4B 00  91 00 BE 0E  4C 00 81 49  D0 31 C1 35  U.K.....L..I.1.5

So, I'm thinking that this disk is using a third, different translation scheme. But if that were the case, it would seem odd that the directory lists at all.

Do you know what the translation scheme is for this disk? Or, know what files are supposed to be on the disk (and in what order)? I should be able to reconstruct the sector translation table from that, with luck.

(I've pushed this stuff to the basis branch if you want to play with it.)

[davidgiven]

Also, I've just got write support working. At least, I was capable of writing your disk image to a 5.25" floppy and then read it back again. I'd be interested to know if it works on real hardware.

[davidgiven]

Also also, turns out that this disk is, in fact, single sided! The VTOC says there are only 80 tracks and the other side of the disk is completely blank (all 0xe5 bytes). The AppleDOS file system can't represent more than 90 tracks anyway.

For reference, here's the decoded image (with no sector translation):

appleii640.img.gz

[fadden]

I posted a note over on https://retrocomputing.stackexchange.com/a/26730/56

The standard definition of the DOS VTOC allows up to 50 32-sector tracks. This disk changed the way the in-use bitmap is defined to allow 100 16-sector tracks, but only used the first 80.

I split the disk image in half and ran it through a disk checker. There may be some minor issues with the contents, so be careful with it. :-) FWIW, I found 61 files (same as your 48+13).

The 0xe5 pattern is what CP/M formats blank disks to.

File: testdata/appleii320.img
  Filesystem notes:
   I Sector count wrong in catalog entry: read 0, calculated 1: ---ZOMBIE ISLAND---
   I Sector count wrong in catalog entry: read 2, calculated 42: SARGON II.LOGO
   I Sector count wrong in catalog entry: read 159, calculated 67: A2-FS1
   W EPSONCOPY overlaps with GAMMA GOBLINS
   W GAMMA GOBLINS overlaps with EPSONCOPY
   W I/A/B stored length (8192 + 4) exceeds actual file length (1024): sechstund             28.07.84
   E Found 3 used blocks that are marked free
   W Found 3 blocks in use by more than one file
Disk image (Unadorned, order=physical) - 320KB DOS 3.3 Vol 254, 0% free
  Warning: filesystem flagged as dubious
Type Auxtyp Modified          Length  Storage *Name
---- ------ --------------- -------- -------- ----------------------------------
 A   $0801  [No Date]            275      768  DOS-CONVERTER
 A   $0801  [No Date]           1739     2048  HELLO                 03.12.83
 A   $0801  [No Date]           2142     2560  CONV-COPY
 B   $02C0  [No Date]            267      768  COPY.OBJ0
 A   $0801  [No Date]            312      768  ACCESS
 A   $0801  [No Date]             27      512  DISK A12/39.2
 A   $0801  [No Date]            650     1024  HELLO2
 A   $0801  [No Date]            124      512  CREATURE VENTURE
 A   $0801  [No Date]           3714     4096  WIZDIM
 A   $0801  [No Date]          15147    15616  WIZARD1
 A   $0801  [No Date]          15431    15872  WIZARD2
 A   $0801  [No Date]          12244    12544  WIZARD3
 T   $0000  [No Date]            129      512  WIZ.SAVE
 B   $4000  [No Date]           4471     4864  WIZ.SHAPES
 B   $4000  [No Date]           3524     3840  WIZ2.SHAPES
 B   $4000  [No Date]           1974     2304  WIZ3.SHAPES
 T   $0000  [No Date]             88      512  WIZ
 A   $0801  [No Date]            223      512  WORD4
 B   $4000  [No Date]            869     1280  WORDS
 B   $4000  [No Date]            786     1280  WORD2
 B   $4000  [No Date]            909     1280  WORD3
 B   $4000  [No Date]           5116     5632  BROOMS
 B   $4000  [No Date]           4236     4608  BROOM2
 B   $4000  [No Date]           4074     4352  BROOM3
 B   $4000  [No Date]           1858     2304  BKIT
 B   $4000  [No Date]            819     1280  RA.SHAPES
 B   $4000  [No Date]            138      512  SCANNER
 B   $0808  [No Date]            456      768  CHAIN
 B   $2000  [No Date]           8184     8448  LOGO
 T   $0000  [No Date]              0      256  ---ZOMBIE ISLAND---
 A   $0801  [No Date]           4049     4352  ZOMBIE-ISLAND
 B   $0800  [No Date]          20336    20736  PIRATE'S ADVENTURE
 A   $0801  [No Date]           1083     1536  WELTRAUMGEDR[NGE
 B   $2000  [No Date]           8187     8448  MICROCHESS.BOARD
 B   $01FD  [No Date]           7683     8192  MICROCHESS.CODE
 B   $4000  [No Date]          10368    10752  SARGON II.LOGO
 B   $07FD  [No Date]          14339    14848  SARGON II.CODE
 B   $0800  [No Date]          11264    11776  BACKGAMMON
 B   $4003  [No Date]          16640    17152  A2-FS1
 A   $0801  [No Date]             48      512  FLY
 B   $1200  [No Date]          24064    24576  INV.B.PDL
 B   $0330  [No Date]            160      512  LOMEM:
 A   $0801  [No Date]            187      512  INVADERS
 A   $0801  [No Date]           2970     3328  TENNIS FUER 2
 A   $0801  [No Date]           4049     4352  ZOMBIE
 A   $0801  [No Date]             40      512  LUNAR LANDER
 B   $0800  [No Date]           7427     7936  BLUNAR LANDER
 B   $0800  [No Date]           2561     3072  BALIEN INVASION
 A   $0801  [No Date]             32      512  ALIEN INVASION
 A   $0801  [No Date]           4587     4864  GO-BANG
 A   $0801  [No Date]            211      512  Moskitoplage         1
 B   $07FD  [No Date]          28931    29440 *GOLD RUSH
 B   $07FD  [No Date]          31747    32512 ?GAMMA GOBLINS
 T   $0000  [No Date]              9      512  TESTFILE              29.05.84
 B   $9000  [No Date]            320      768  BILDRUCK              28.07.84
 A   $0801  [No Date]            105      512  HDCPY-TEST1           28.07.84
 B   $9000  [No Date]            320      768 ?EPSONCOPY
 A   $0801  [No Date]            930     1280  HARDCOPY4             28.07.84
 A   $0801  [No Date]            184      512  ANGELIKA              28.07.84
 A   $0801  [No Date]            162      512  mandelbaum            28.07.84
 B   $4000  [No Date]           8192     1280  sechstund             28.07.84

[fadden]

FWIW, https://github.com/davidgiven/fluxengine/blame/master/src/formats/apple2.textpb may be incorrect, which would explain the catalog output discrepancy.

My ProDOS skew table matches yours:

    internal static readonly uint[] sProdos2Phys = new uint[16] {
        0, 2, 4, 6, 8, 10, 12, 14, 1, 3, 5, 7, 9, 11, 13, 15
    };

My DOS does not:

    internal static readonly uint[] sDos2Phys = new uint[16] {
        0, 13, 11, 9, 7, 5, 3, 1, 14, 12, 10, 8, 6, 4, 2, 15
    };

[ibm5110]

Also also, turns out that this disk is, in fact, single sided! The VTOC says there are only 80 tracks and the other side of the disk is completely blank (all 0xe5 bytes). The AppleDOS file system can't represent more than 90 tracks anyway.

Oh my, I should have better checked the example ;-) Anyways, here's another image with data on both sides. 013.scp.gz

[davidgiven]

Yup, the AppleDOS translation table was wrong --- that should now be fixed. fluxengine ls can now see all the files and reading a random Basic file shows sensible-looking data. Thanks! Should be fixed now.

013.scp looks like it has different data on the second side. None of those sectors read correctly, but there do seem to be sector records on it. I'll have to investigate in more detail later.

I wonder: was 007.scp a CP/M disk (formatted with tracks 0..159) that was then reformatted as a single-sided AppleDOS disk? If so, 013 might be a native AppleDOS double-sided disk, however they work.

[davidgiven]

...yes. 013 contains tracks 0..79 on both sides of the disk. Both sides contain a VTOC and directory (one at 0x11000 and the other at 0x51000), giving two distinct volumes. I would therefore guess that it either shows up as two AppleDOS drives, or else the DOS has been hacked to combine the two volumes into one virtual drive. I've attached the image here (with AppleDOS sector translation).

@ibm5110 Do you have a double-sided CP/M disk to compare with?

013.img.gz

[fadden]

FWIW, I've never heard of the Apple II using double-sided disks as a single entity. 80-track disks are technically possible to read -- the stepper motor can position the drive head correctly -- but Apple II 5.25" drives with a second read head were rare. AFAIK none of the operating systems expected it to be there. Using it would require a special driver, and would probably require ProDOS because of the DOS disk format limitations.

Using the second side of a disk was done by flipping it over. Punching a second write-protect notch on the other side of the disk was common practice (using scissors, a hole punch, or a purpose-built device).

With that in mind, having DOS on one side and blank CP/M sectors on the other is entirely reasonable, as is having independent DOS volumes on each side.

[ibm5110]

@ibm5110 Do you have a double-sided CP/M disk to compare with?

Yes, here you are :-) And also a scan of the disk label (I always do this when archiving floppies).

004.scp.gz

[davidgiven]

Oh, joy. Yet another different soft sector translation. /s

If you have the machine running, could you boot that disk, do a DIR, and send me the photo of the result. That will show me the order of the files in the directory, which I can use to reconstruct the translation table.

[fadden]

Try this:

    internal static readonly uint[] sCpm2Phys = new uint[16] {
        0, 3, 6, 9, 12, 15, 2, 5, 8, 11, 14, 1, 4, 7, 10, 13
    };

That should be the full set. UCSD Pascal uses the same order as ProDOS.

[davidgiven]

Yes, that's the right mapping, although the three boot tracks seem to use ProDOS translation instead(!).

I now have correct support for reading 160-track CP/M disks (with the --cpm option). I already have CP/M filesystem support, and figuring out the right options was easy, so files can be read now. Currently only the command line supports the additional options, so you can't do this through the GUI --- that's my next thing to fix.

I've also put in support for accessing the files on side 1 of an AppleDOS disk by doing --appledos --side1.

I do wonder what this thing does to ProDOS disks...

[fadden]

the three boot tracks seem to use ProDOS translation instead(!).

Looking at the boot sector on a different Apple II CP/M disk:

000: 01 a5 27 c9 09 d0 13 8a 4a 4a 4a 4a 09 c0 85 3f  .%'I.P..JJJJ.@.?
010: a9 5c 85 3e a9 00 85 00 e6 27 e6 00 a4 00 c0 0b  )\.>)...f'f.$.@.
020: d0 03 4c 00 10 b9 2d 08 85 3d 6c 3e 00 00 02 04  P.L..9-..=l>....
030: 06 08 0a 0c 0e 01 03 05 07 09 0b 0d 0f a0 c3 cf  ............. CO
040: d0 d9 d2 c9 c7 c8 d4 a0 a8 c3 a9 a0 b1 b9 b8 b0  PYRIGHT (C) 1980
050: a0 cd c9 c3 d2 cf d3 cf c6 d4 a0 ad a0 ce cb a0   MICROSOFT - NK 
[...]

The values starting at +2d appear to be the ProDOS/Pascal skew table. I just learned something new. :-)

[davidgiven]

I've updated the GUI so now you can specify format options, through handy radio buttons and check boxes. This allows you to use the file browser with AppleDOS disks.

This should now all be live in the current released version, so I'm going to call this done? Please reopen the bug if anything turns out to be broken, or it needs new functionality.

Thanks for the assistance --- it's really good to get the AppleDOS filesystem working, at least read only, and this poked me into finally implementing the GUI half of the format options stuff.