Support for AppleSingle about applecommander HOT 19 CLOSED

I like! As we're talking about the cc65 suite of tools, am I right in assuming that the command-line ac tool is the primary target for AppleCommander? I ask because one of the fundamental problems with AppleCommander is the assumption of a physical disk (aka, some form of disk geometry). I'll have to review how we shoehorned Shrinkit files into the GUI tooling (pretty certain it dynamically allocates a disk on the fly), so maybe we can fake it in for that aspect.

from applecommander.

I remembered seeing an AppleSingle ProDOS File Type tech note at some point. Just in case it's useful: http://www.apple2online.com/web_documents/ft_e0.0001_applesingle.pdf

from applecommander.

One note regarding file name... I don't see the "Real Name" entry. I assume this is because cc65 is a compiler/assembler, so it really doesn't have one. I suspect that means AppleCommander should (a) try to use entry ID 3 if present or (b) just use the filename of the AppleSingle file. Sound like a valid approach? Thanks!

from applecommander.

I like!

:-)

am I right in assuming that the command-line ac tool is the primary target for AppleCommander?

Absoulutely! This "issue" is only about the command-line ac tool.

AppleSingle ProDOS File Type tech note

That is AppleSingle version 1. We're discussing AppleSingle version 2.

I don't see the "Real Name" entry.

Correct. In general an AppleSingle file is "supposed to" have entries with the IDs 3 and 8. But after some discussion we agreed to not include those in the AppleSingle files we want to use for transporting meta data from cross dev tools to disk image tools. And after all the RFC says Each entry is optional and may or may not appear in the file. so we're conceptually on the safe side.

I assume this is because cc65 is a compiler/assembler, so it really doesn't have one.

Yep.

I suspect that means AppleCommander should (a) try to use entry ID 3 if present or (b) just use the filename of the AppleSingle file. Sound like a valid approach?

Absolutely! That's from my perspective not only a valid approach but the optimal approach.

from applecommander.

Working through this now, a couple of notes (comment if necessary!):

• Assuming ProDOS only. I expect to error if the disk image is DOS 3.3 and the AppleSingle file specifies ProDOS. (Especially in the cc65 case! We can translate the meta-data but the binary is likely to assume one OS over the other.) If a DOS 3.3 example shows up, then we can add support for it.
• Ignoring dates.
• I expect the access bits to be ignored and $C3 to be assumed.

I don't think any of this is an issue, but thought I should make a note of it.

from applecommander.

Ha! Went to look for the DOS 3.3 entry. It's MS-DOS. So apply a filter to that comment above. ;-)

from applecommander.

Working through this now

:-)

the binary is likely to assume one OS over the other.

No. As long as the user/programmer keeps clear from certain features, the same binary works on both ProDOS and DOS3.3 (see http://cc65.github.io/doc/apple2.html#ss8.1). So the linker doesn't make a difference between ProDOS and DOS3.3 binaries. So placing an AppleSingle file onto a DOS3.3 image is a viable use case from cc65 perspective. E.g. the "Hello, World" I supplied works on DOS3.3 nicely.

Ignoring dates.

I guess so far you used the date of the file in the "host" file system (NTFS, ext3, ...) for the date of the file in the ProDOS file system. I'd just stick to that. The AppleSingle files created with cc65 will never have a date entry.

I expect the access bits to be ignored and $C3 to be assumed.

Using the access bits form the AppleSingle file as-is for ProDOS would seem more straight-forward from the user's perspective, but if it's simple/better to ignore it it's perfectly fine for me as the AppleSingle files created with cc65 will never ever have something diffrent than $C3.

from applecommander.

I'm not spotting a "translation" in the current code base and I don't see an Apple DOS 3.3 header in the AppleSingle. Can I assume that the DOS and ProDOS file sets up the AppleSingle header? I'll go ahead and jimmy something together to do some translation (probably TXT=>T, BAS=>A, and B for everything else).

For dates, that's more challenging. I'm following the rest of the command-line interface, so the actual binary input is piped into ac. (Meaning that I don't have those dates available...) There is, however, an AppleSingle entry ID 8 with the file creation and modification date. If cc65 were to populate that entry, ac could just use the dates. Otherwise it's just the time the ac command is executed.

I'll peak at the access bits. I didn't see anything obvious in the current ac code, so ... no promises!

from applecommander.

I'm not spotting a "translation" in the current code base and I don't see an Apple DOS 3.3 header in the AppleSingle. Can I assume that the DOS and ProDOS file sets up the AppleSingle header? I'll go ahead and jimmy something together to do some translation (probably TXT=>T, BAS=>A, and B for everything else).

I'm afraid we have some misunderstanding here. Maybe the problem is that I have no overview over the AppleCommander functionality. I can only talk about the functionality relevant from the cc65-point-of-view. And from that POV the current situation is:

• A binary file can be put both onto DOS 3.3 and ProDOS disks. If the file has no header then using -p B[IN] and providing the start address. If the file has a four-byte header then using -cc65. Either with or without header the same file works both for DOS 3.3 and ProDOS.
• A ProDOS system can be put onto ProDOS disks using -p SYS. It has no header.

The desired situation from the cc65-POV is:

• A binary file can be put both onto DOS 3.3 and ProDOS disks. If the file has no header then using -p B[IN] and providing the start address. If the file is an AppleSingle file then using -p or some new option without file type specification. Either AppleSingle file or not the same file works both for DOS 3.3 and ProDOS.

• A ProDOS system can be put onto ProDOS disks. If the file has no header then using -p SYS. If the file is an AppleSingle file then using -p or some new option without file type specification.

That means that from the cc65-POV it's desirable that AppleCommander can put an AppleSingle file with an entry of ID 11 and file type $0006 onto a DOS 3.3 disk by extracting the start address form the aux type and building a DOS 3.3 four byte header from it.

from applecommander.

For dates, that's more challenging.

Hm, I must admit that I can't follow you why...

Otherwise it's just the time the ac command is executed.

If that's is how AppleCommander works today then just keep to that. I don't see any reason to change something about that at all.

I didn't see anything obvious in the current ac code, so ... no promises!

If it remotely looks like becoming complicated then just keep to how AppleCommander works today

from applecommander.

Actually, no. -p is to put a file exactly as it is. No interpretation. From stdin (so piped or redirected). <filename> here is the name it will be in the disk image, not the source of the data.

-p  <imagename> <filename> <type> [[$|0x]<addr>] put stdin
    in filename on image, using file type and address [0x2000].

I'm currently modeling the -as (-applesingle?) after the old -cc65 tag. Which I should deprecate and maybe rename -dos or something. Current help text:

-cc65 <imagename> <filename> <type> put stdin with cc65 header
      in filename on image, using file type and address from header.
-as <imagename> [<filename>] put stdin with AppleSingle format
      in filename on image, using file type, address, and (optionally) name
      from the AppleSingle file.

<filename> is optional in the AppleSingle case because it may be within the AppleSingle file itself. If there is no name entry, <filename> becomes required.

Generally, I don't want to totally change the way ac is working (via stdin), so I'm following the existing pattern.

from applecommander.

Some sample runs...

1. Create specific disk type.
2. Import form AppleSingle sample file.
3. List files.

Placing HELLO into a DOS 3.3 disk:

$ java -jar build/libs/AppleCommander-ac-1.4.0-BETA.jar -dos140 dos.dsk
$ cat src/test/resources/hello.applesingle.bin | java -jar build/libs/AppleCommander-ac-1.4.0-BETA.jar -as dos.dsk HELLO
$ java -jar build/libs/AppleCommander-ac-1.4.0-BETA.jar -l dos.dsk 
dos.dsk DISK VOLUME #254
  B 013 HELLO 
DOS 3.3 format; 131,840 bytes free; 11,520 bytes used.

Placing HELLO onto a ProDOS disk:

$ java -jar build/libs/AppleCommander-ac-1.4.0-BETA.jar -pro140 prodos.po WORK
$ cat src/test/resources/hello.applesingle.bin | java -jar build/libs/AppleCommander-ac-1.4.0-BETA.jar -as prodos.po HELLO
$ java -jar build/libs/AppleCommander-ac-1.4.0-BETA.jar -l prodos.po 
prodos.po /WORK/
  HELLO BIN 007 03/02/2018 03/02/2018 2,912 A=$0803 
ProDOS format; 136,192 bytes free; 7,168 bytes used.

from applecommander.

Actually, no. -p is to put a file exactly as it is. No interpretation. From stdin (so piped or redirected).

Even re-reading what I wrote I don't see where I wrote anything contradicting this. Anyhow, I fully understand (and agree).

Generally, I don't want to totally change the way ac is working (via stdin), so I'm following the existing pattern.

I, again, fully agree. Sorry if I wrote something that appears to contradict this.

from applecommander.

I'm currently modeling the -as (-applesingle?) after the old -cc65 tag. Which I should deprecate and maybe rename -dos or something. Current help text: [...]

That seems just great :-))

Some sample runs... [...]

Cool! Can you provide that AppleCommander-ac-1.4.0-BETA.jar to me? The AppleSingle file I posted here was created with some proof-of-concept cc65 code. With your BETA I'd be able to test a real cc65 AppleSingle implementation - and provide you with feedback...

from applecommander.

Just pushed the 1.4 BETA!!

from applecommander.

Just pushed the 1.4 BETA!!

Thanks! I checked it out and -as works exactly as expected :-)

So from my perspective 1.4 is ready for release. However, I noticed that I needed to update to Java SE 8 in order to run AppleCommander-ac-1.4.0-BETA.jar but I guess that's expected / intended.

from applecommander.

I just released cc65 2.17 which now generates AppleSingle files: https://github.com/cc65/cc65/releases/tag/V2.17

Here's the announcement - of course referring AppleCommnader:
https://sourceforge.net/p/cc65/mailman/message/36247481/

from applecommander.

Closing ticket out, as 1.4.0 was just released. See https://github.com/AppleCommander/AppleCommander/releases/tag/v1-4-0

from applecommander.

Thanks a lot for your support :-))

from applecommander.