[Coco] Kinda disappointed with 6809 assemblers

[William Astle]

On 13-01-30 09:03 PM, Luis Antoniosi (CoCoDemus) wrote:
> array fcb 0,0,0,0,0,0,0...,0 ???
>
> what if my array was sized set by the size of the code ? impossible.

Try using "FILL <size>,<value>" - it escaped the documentation but it is 
available.

> I have a game using some 8k memory banks mapping, and I need to include a
> binary file into a determined bank since it's a ROM file, that would be:
>
> org 16384
> WORLD11BIN: incbin "data\WORLD11.MGL",0x108,0x1000
> ds BANK_SIZE - ($$ % 8192),0ffh

Again, "FILL" is probably what you need. "*" is the name for the current 
assembly address, by the way. The offset and size idea for includebin is 
something I might add in the future. But remember, I'm only one person 
who is earning nothing for developing lwasm so it does not take first 
priority on my things to do list.

> lda (KEY_RIGHT >> 8),x
> bita #($01 << (KEY_RIGHT & $00ff))
>
> but I can only use very basic math operations on it and shifts and ands are
> out.

Part of your problem with the above lines is that you have spaces in the 
operand field. Those are not permitted in the source format supported by 
lwasm. (There are technical reasons for that; it wasn't a design choice.)

For the record, & and | should both work. However, bit shifts are not 
supported. To be honest, you're the first person to comment about bit 
shifting. I can add those to the "features to be added" list, though, 
since I can see it would be useful.

>
> BTW the code above core dumps with lwasm, also a single cmpx with no
> parameters crashes too.

Okay, the crashes were definite bugs. Anything that triggers a 
segmentation fault is definitely a bug. Thank you for reporting that. 
They're fixed in the current mercurial tree so that it says "bad 
operand" instead.