Re: [cc65] Newbie question, using cc65 for Apple II assembly

From: Mark Lemmert <>
Date: 2015-11-15 17:14:43

Thank you for your reply! My follow-up answers/questions are below in green

On Sun, Nov 15, 2015 at 7:29 AM, Oliver Schmidt <> wrote:

> Hi Mark,
> [...] have been using Liza as my compiler.
> Rather Lisa -


>> [...] compile hello.c in the example on this intro page (
>>, convert it to a disk image using
>> Apple Commander, and brun the program successfully using AppleWin.
> :-)
>> However, I tried to use the hello program as a template and any assembly
>> code I try to write myself does not work. Does anybody have any suggestions?
> My first suggestion would be to go a totally different route. The idea to
> use machine generate assembly code as starting point for own assembly code
> is a bad idea(tm).
> If you want to use the cc65 toolchain for assembly code then ignore the C
> compiler.

I thought maybe a .S file created for the Apple2 platform from a .C file
would contains headers that ca65 needed in order to assemble for the
Apple2. I am doing trial and error guessing at this point due to my
inexperience. Your advice narrowed things down quite a bit for me, thanks!

Unfortunately, I tried .S files completely stripped down, literally just
two lines "lda #$20", "brk" and go the same result. More on the same result
below.  Do you have a sample Apple II assembly source code file you'd be
willing to share?

These are the ca65 and AppleCommander I was using.

ca65 hello.s
ld65 -o hello -t apple2 hello.o apple2.lib

java -jar ac.jar -cc65 cc65.dsk test B < hello

Thanks for your help, I really appreciate it!

>> I used the command cc65 -O -t apple2 hello.c to get a copy of the
>> assembly source for the example program (hello.s), included below for quick
>> reference.
>> I tried modifying hello.s by deleting the assembly code between
>> .segment CODE and .endproc, and adding my own code. I literally just added
>> one line, lda #$20, keeping the format with columns, etc. as in the
>> example. I also tried removing the .import statements, and various other
>> modifications to the text above int_near_main but nothing worked.
> "nothing worked" isn't an exactly precise problem description, is it?

No, LOL. Sorry. When I wrote the OP my brain was fried after a long day of
working on the problem. What I meant was that nothing I tried produced
an verifiable result, by observing the machine instructions $A9, $20 in the
starting memory location used to BLOAD the file in AppleWin.

>> After making the changes to hello.s I used the ld65 tool to create the
>> file for apple commander, just as in the example.
>> My method for evaluating the results was, in AppleWin bload test, A$6000,
>> enter the apple monitor (call -151), enter 6000L, and observe whether the
>> machine instruction equivalent to my assembly code was there.
> Ageneral thought about debugging: You had something working and now you
> have something non-working. Then you have to do the changes you made
> one-by-one and see when it starts breaking. From that you know which change
> is the culprit. I bet that in your case adding the lda#$20 isn't the change
> that breaks your thing.
> From what you write above I'd that you linker the program to the default
> address which is $803. Then you tried to run it from address $6000. This
> can't work. 6502 assembly is in general not position-independent.

Understood. I was generally trying to follow that debugging principle but
clearly erred by changing the memory location.

This morning I tried the entire process exactly the same with the
hello.c example on the cc65 website, with the only change being to add "lda
#$20" as the first line of assembly code (I loaded the code at the default
memory address $803), and it did not work as described next.

Here is what I did in AppleWIN:


this is exactly what I did with the hello.c example that worked. For my
simple hello.s, I'd expect it to give me a beep, the * monitor prompt, and
display the registers, which #$20 being the accumulator. Instead it hangs
(no screen output, system unresponsive to keyboard).

I've also tried putting a "brk" after the "lda #$20" and get the same
result described here.

Given the results of the BRUN test, I proceeded to examine the contents of
memory via the following commands:

bload test
call -151

Since $803 is the default memory address the code is loaded into, I would
expect to see:

803- $A9
804- $20

instead, I see completely different hex numbers. in the 20 lines that 803L
prints to the screen, there is no $A9, $20 anywhere.

Any ideas?

Thanks for your help, I really appreciate it!

> Regards,
> Oliver

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun Nov 15 17:14:58 2015

This archive was generated by hypermail 2.1.8 : 2015-11-15 17:15:00 CET