Re: cc65 / ca65: how to interface C and assembly?

["Michael J. Mahon" <mjmahon@aol.com>]

Linards Ticmanis wrote:
> Thanks to all who answered for the help!
>
> U. v. Bassewitz wrote:
>
> > The builtin inline assembler is not a full featured assembler, therefore
> > control commands (like .align) aren't accepted. A second reason is that
> > the inline assembler code is processed by the the optimizer, and handling
> > control commands in this stage would be too complex.
>
>
> Being processed by the optimizer pretty much rules out using inline 
> assembly I fear, since the Apple disk controller wants to receive a byte 
> exactly every 32 cycles; one more or less and it won't work. So any kind 
> of optimization or reorganization would destroy the functionality.

I hope that the optimizer knows enough to leave assembly code
unchanged.  I presumed (oops) that UVB meant only that it "passed
through" the optimizer, not that the optimizer attempted to do
anything with it...  ;-(

> So I guess I'll use a separate assembly file and .align my code that 
> way. There's no need to call any functions from the write code, it's 
> just a simple loop that dumps memory locations' contents to the write 
> register. And now that I know how parameter passing works, it should be 
> easy enough.

A good fallback position.

> One more thing, on the Apple many hardware funktions are activated by 
> accessing certain addresses. It's only the access that matters, the data 
> read or written is irrelevant. But when I use peekpoke.h and say 
> something like "PEEK(0xC030);" without using the result for anything, it 
> gets optimized away. I've settled on "*((char *)0xC030) = __AX__;", 
> which gives a "pure" store, storing whatever is currently in A; but this 
> is problematic for some addresses, since the 6502 accesses an address 
> twice during a write. Some of these "softswitches" are toggle switches, 
> so you need to read them, which produces only one access; writing them 
> toggles them back and forth instead.
>
> Is there any way to get a "pure" load, i.e. make the compiler emit just 
> an LDA (or a BIT, or whatever) but to ignore the result? I mean without 
> resorting to inline assembly. I tried to do it with "volatile" but that 
> doesn't seem to have any effect.

It is not true that all stores cause a read access.  I don't know
how this myth continues to propagate.  (Perhaps it's because of
the "double access" note about the Applesoft POKE function, which
occurs because that store is *always* indexed.)

Only indexed and indirect indexed stores cause a read access prior
to the write access (because of a data path conflict in the chip
which requires another cycle).

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."