Hi,
Right now there's a very nice momentum to improve the interoperability of Apple II cross development tools. The primary aspect is to have a common way to express ProDOS 8 meta data on the path from the development tool (running on a foreign file system) to the Apple II disk image management tool that writes ProDOS 8 meta data into the disk image.
cc65 and AppleCommander team up here since many years in a great way. cc65 generates a 4-byte DOS 3.3 header for BIN executable and AppleCommander has the -cc65
option to consume the 4-byte header.
However, from a conceptual POV the 4-byte DOS 3.3 header is far from optimal, especially as it doesn't contain the ProDOS 8 File Type. Fortunately Apple created already back in 1990 the AppleSingle/AppleDouble file format that can be used well as replacement for the 4-byte header.
I want drop the support for the 4-byte DOS 3.3 header in cc65 completely and switch to generation of an AppleSingle file. Of course the success of this plan heavily depends on AppleCommander to support AppleSingle files! Therefore I need to ask you to add support for AppleSingle asap.
I see several options for AppleCommander:
AppleSingle can only be supported for put
operations - like it is currently with the -p
variant -cc65
- or it can be supported for both put
and get
operations.
As AppleSingle isn't specific to cc65 and is in fact supposed to be soon supported by Merlin32 too. So from my POV its use shouldn't have a name like -cc65
that relates to cc65.
From my perspective -cc65
can be dropped from AppleCommander. However, I can imagine very well you're interested to keep to for backward compatibility reasons.
Now for the technical details:
AppleSingle is described in http://kaiser-edv.de/documents/AppleSingle_AppleDouble.pdf. Additionally there's an RFC in https://tools.ietf.org/html/rfc1740.
AppleSingle is a container for several optional "Entries" of different types. Each entry type has a specific "Entry ID". The files created by cc65 always contain exactly two entries with the Entry IDs 1 (Data Fork) and 11 (ProDOS File Info).
The actual location of entries in the file is described by a file header. This in general rather complex layout becomes pretty simple when the Entry ID 11 (the ProDOS File Info) is placed first and the Entry ID 1 (Data Fork) is placed last because the Entry ID 11 has a fixed, small size.
So from the AppleCommander perspective I see two viable approaches to handle AppleSingle files:
-
The "correct" approach: Follow the AppleSingle spec to indentify (or even generate) all relevant Entry IDs.
-
The "quick" approach: Presume that AppleSingle files have the layout that cc65 creates and treat them as 1:1 replacement of the 4-byte DOS 3.3 header.
For the second approach there's no need to look at any AppleSingle spec. Rather all that needs to be known is:
-
There's a header with a size of $3A bytes. After that header the rest of the file is the actual file data (just like with the old header of 4 bytes).
-
At the file offset $24/$25 there's the length of actual file data (just like with the old header at offset $02/$03). However, that value is big endian !!! If you ignored that value so far you can continue to do so.
-
At the file offset $35 there's the ProDOS File Type. It can be either $06 for a BIN file or $FF for a SYS file.
-
At the file offset $38/$39 there's the Auxiliary Type for BIN files (just like with the old header at offset $00/$01). However, that value is big endian !!!
-
At the file offset $33 there's the ProDOS Access Byte. It's set to %11000011 meaning to enable Access, Destroy, Rename, Write and Read. For me personally it's purely nice-to-have that this value is actually used. You can as well ignore it from my POV.
Again, I'd really appreciate if you could add support for AppleSingle quickly as this would help to keep up the momentum we currently have in harmonizing the files created / consumed by different Apple II tools. In order to ease that I attached an AppleSingle file created with cc65. It's a BIN file with Auxtype $803. It's an executable printing "Hello, World": https://github.com/AppleCommander/AppleCommander/files/1737098/hello.zip
Thanks in advance, Oliver