How to get code to correctly run on an Apple ii

Question

I've written a small piece of code (add.asm, shown below) in 6502 assembly but are having some problems to get it to run correctly on an apple ii emulator. Using the config file below, and ca65 and ld65, I can get a binary to compile.

Then, using ciderpress, I can put this onto a disk image. However, this is where my problems start. When I edit the file's attributes, making it a binary, Ciderpress changes something called "aux Type (hex)" to D818. I'm unsure why this is (changing this to 6000, where I have said the ram starts in my ld65 config file does not fix the issues I am about to describe).

In Ciderpress, I can view the file add which I have just added to the disk image. It says it starts at location "D818". However, it does not include every line up to "STA ADR1", which is over halfway through the program. When I run this on an appleii emulator the behaviour of the program confirms that only the second half of the code seems to exist.

Can anyone please help me understand what is going on?

add.asm:

CLC      ; CLEAR CARRY BIT
CLD      ; CLEAR DECIMAL BIT

ADR1 = $6100 
ADR2 = $6101
ADR3 = $6102

LDA #01
STA ADR1
LDA #02
STA ADR2

LDA ADR1 ; LOAD CONTENTS OF ADR1 INTO ACCUMULATOR
ADC ADR2 ; ADD CONTENTS OF ADR2 INTO ACCUMULATOR 
STA ADR3 ; TRANSFER CONTENT OF ACC TO ADR3

RTS

apple.cfg:

MEMORY {
RAM: start = $6000, size = $8E00, file = %O;
}
SEGMENTS {
CODE: load = RAM, type = ro;
DATA: load = RAM, type = rw;
}

Answer 1

Your problem is less to do with Apple II knowledge and more to do with passing info between tools. If you were building for C64 then you would use the PRG format to set the load address. See my answer here.

And CiderPress is wonderful, but there are limitations, and sometimes you have to get to know it in order to achieve what you want. There are other options; for instance AppleCommander supports the AppleSingle format which was added to cc65. CiderPress supports it too, but I don't have experience with it yet.

(I sometimes prefer working with Merlin 32 and Cadius.)

In any case, CiderPress is guessing the type and start address of your binary. DOS "B" type files have a 2-byte load address header, hence the address D818 is from:

6000-   18          CLC
6001-   D8          CLD

These lines are assembler directives, not code, and so don't appear in the output binary.

ADR1 = $6100
ADR2 = $6101
ADR3 = $6102

One easy way to achieve what you want is to specify the file type (BIN) and address (6000) using:

File Attribute Preservation

The definitive guide to the file attribute preservation mechanism employed by CiderPress can be found in the "library" section of the www.nulib.com web site. This is a brief introduction to the topic.

There are four attributes that must be restored when adding Apple II files: file type, aux type, pathname, and file part (i.e. data fork, resource fork, disk image, or comment).

File Type and Aux Type

ProDOS files use an 8-bit file type and a 16-bit aux type. These can be encoded in a six-character hexadecimal string that looks like "#062000". The '#' is used to indicate the start of an attribute preservation string.

E.g.

.\bin\cl65.exe -o add#066000.bin -t apple2 -C apple.cfg add.asm

Now your output file is named:

add#066000.bin

CiderPress will add this file correctly to the DSK image and the contents can be executed.