[Coco] CCASM 5.0, procedures, nested procedures, MMU support

[Roger Taylor]

Hello gang,

If you're a CCASM fan, read this whole letter...

A user of CCASM pointed out to me that parameter passing was 
semi-broken in CCASM.  This prompted me to investigate and I found 
out that parameters were being passed in what appears to be standard 
Extended addressing but were being pushed as Direct values of those 
symbols or values.

After a while of updating and testing, CCASM now can pass parameters 
to a procedure as so:

call theroutine,#100
-calls "theroutine" procedure passing in 100 as the parameter

call theroutine,100
-calls procedure passing in contents of address 100 as the parameter
-how big is the contents, a byte or word?  that's defined in the 
procedure definition

theroutine	proc	theparam:byte
or
theroutine	proc	theparam:word

Ok...

What if we want to pass symbols/variables in?

data	rmb	1

lda	#1
sta	data
call theroutine,data
-calls procedure passing in byte stored at data

call theroutine,#data
-calls procedure passing in ADDRESS of data

...which won't work unless the procedure defines a word parameter

CCASM will build the program and it will run, but the LSB of the out 
of range value will be passed to the procedure
CCASM will report an error which will cause the Rainbow IDE to abort 
the project (or not) depending on the version you have of the IDE.

How is all of this possible?  Because CCASM generates the procedure 
body, stack frame, and opcodes for that and the calling function and 
makes all the necessary adjustments to handle the type and size of 
parameters expected, and being passed in.

Local memory is also supported.  For example, when you put RMBs 
inside of a procedure, the label names become unique to the whole 
source code and the data gets pushed to the stack.  You reference all 
parameters and locals by  parameter,u  meaning register U is reserved 
by CCASM for within the procedure.

AND!  If this is not enough to wet your appetite.. nesting is 
supported!  This means you can call procedures from within 
procedures!  There's virtually no limit but you have to know where 
your S stack is and how much room it has just as with any ML 
program.  The trick is that the nested procedure being called has to 
be defined before the procedure you're in.

So, CCASM has gained a powerful compiler-like feature that I'm not 
sure any other 6809 "assembler" has.  Maybe someone will correct me 
on this and point me to that assembler.

Anybody up for building a CCASM library for Disk BASIC ML 
programs?  It would be in assembler only format since CCASM doesn't 
build object files yet, but wow what an incentive for others to start 
a project where most of the work is already done.

Another SUPER feature which will make maybe 2 people nervous and make 
others thrilled (I hope) is the minclude/mincludebin macro that I'm 
putting the final touches on.  This will be the secret to merging 
large data into your programs that gets stashed to the MMU blocks of 
your choice on LOADMing the .bin.  Sock Master confirmed that Donkey 
Kong uses this technique so you can rest assured that if noone's CoCo 
has crashed when loading that game that this is a good thing I'm 
adding to the assembler's list of powerful features.  In fact, Donkey 
Kong just stores values to the MMU registers and so far, the status 
should be that all CoCo 3's read back $00xxxxxx in the MMU registers 
during the LOADM command.  512k is the top platform from what I 
understand but those with over 512k could comment on this and help us 
all out.  I go an extra safety measure beyond that and just tell 
LOADM to hush it's mouth and just do the writes and load the 
program.  Any CoCo 3, any RAM size up to 2megs is supported, but the 
catch is that the .bin file will probably be limited to the size of 
the floppy disk it's stored on.

CCASM 5.0 hasn't been posted anywhere until I run more code through 
it to make sure there's no major bugs.

ALSO... :)  CCASM compiled under Linux and produced a working command 
the last time I tried which was version 4, I think.  The only changes 
needed are the LF/CR translator in case Linnie folks move Windows 
.asm files over... CCASM will handle them, too.

The Linux version of CCASM hasn't been posted anywhere yet, but was 
given to one person for testing.  I think I got a report back that it 
worked, but no further reports about test runs on more source files.