cc65 AppleSingle magic number issue

    Hi there,


    not sure if any of you ran into this issue recently, but I am a bit clueless on this one...


    The standard binary file format generated by the linker for the Apple ][ target is an AppleSingle file. The default load address is $803.

    AppleCommander 1.4.0 or later includes the option `-as` that allows to put AppleSingle files onto disk images containing ProDOS 8.

    ( `-cc65` is deprecated and translates to `-dos` )


    I have AC v1.7.0 and cc65 v2.19 installed.


    When I try to put the binary to a disk image with `-as` I get the following error message:

    Error: Not an AppleSingle file - magic number does not match. Expected 0x00051600 but read 0x3b0a3b20.

    java.io.IOException: Not an AppleSingle file - magic number does not match. Expected 0x00051600 but read 0x3b0a3b20.



    Any idea what just happened?

    Thanks

    > Any idea what just happened?


    I'm working with those tools all the time. They for sure generally work that way. Maybe you want to post the actual command lines that you use.

    Zitat von ol.sc

    > Any idea what just happened?


    I'm working with those tools all the time. They fore sure generally work that way. Maybe you want to post the actual command lines that you use.

    I used these tools in this order before, and they did work.

    ( I have prepared a `hello.dsk` disk image that holds prodos )


    I can reproduce this issue even on the simplest hello world application on multiple machines:


    cc65 -t apple2 hello.c -o hello.apple2

    ac.sh -p hello.dsk hello.system sys < /usr/share/cc65/target/apple2/util/loader.system

    ac.sh -as hello.dsk hello bin < hello.apple2

    I see from both your comment and the pasted code that you are indeed a knowledgable user of these tools.


    So the only idea I'm left with is that you additionally have an old version of cc65 installed and that you unintentionally use that pre 2.17 (?) version of cc65 here.

    Zitat von ol.sc

    I see from both your comment and the pasted code that you are indeed a knowledgable user of these tools.


    So the only idea I'm left with is that you additionally have an old version of cc65 installed and that you unintentionally use that pre 2.17 (?) version of cc65 here.

    That would make sense, but it is not the case. I usually compile cc65 from source, there is always one instance of its binaries on my computer and that is currently cc65 V2.19 - Git 4f87c7cc6. ( Also I tried it on a fresh virtual machine and installed cc65 from debian repos, just to double check and got me the same result. )

    I am wondering if the problem is on AC side. I've raised the issue on their project page.

    ooh. if you are on other versions than me, could you please share your version numbers? also if it is not a too big ask, could you please try to replicate the issue?


    Thanks.

    And we're for sure talking about the same use case - what I actually just did successfully:


    cc65\bin\cl65 -t apple2enh -Ois -m test.map test.c


    copy Tools\template.dsk test.dsk

    1 file(s) copied.


    java -jar Tools\ac.jar -as test.dsk test <test


    java -jar Tools\ac.jar -p test.dsk test.system sys <cc65\target\apple2enh\util\loader.system

    hm... If i omit the `bin` argument , like in your case it works :fp:

    To be honest I don't think so. None of my many years old scripts (used up until today with that 1.4.0 beta) had it. The AppleSingle header contains all necessary meta data - that's the whole point about it. Therefore there's no point in providing any meta data to AC when using AppleSingle.