[Coco] ccasm question

[Johann Klasek]

On Mon, Mar 09, 2015 at 11:15:25PM -0400, Hugo Dufort wrote:
> Hi Robert,
> I don't know if it will make any sense or if I'm just being naive 
> (perhaps I'm not using ccasm properly?). Here is a code snippet. I 
> declare some global variables that will occupy some memory addresses 
> once compiled. I can used these variables everywhere in my code, but I 
> can't refer to them from a procedure such as HSCREEN. So if I want to 
> access these globally defined variables from HSCREEN, I'll have to pass 
> all their addresses to HSCREEN as parameters... or perhaps I should 
> organize them in a composite structure and pass the structure's base 
> address?

I prefer a structure referenced by a base address, something like this ...
(possibly not the exact syntax ...)

                 org 0
h.width          rmb 2
h.bytes_total    rmb 2
h.bytes_visible  rmb 2
h.height         rmb 1
h.colors         rmb 1 
h.mmu_basepage   rmb 1
h.low_addr       rmb 2

     org     3584

hdata           fdb    320, 160, 160
                fcb    192, 16, 2
                fdb    $4000

    ldu #hdata          global structure base address
    lda h.colors,u      access structure byte element
    ldx h.bytes_total,u access structure word element

> 
> =============
>     org     3584
> 
> hwidth    fdb    #320
> hbytes_total    fdb    #160
> hbytes_visible    fdb    #160
> hheight    fcb    #192
> hcolors    fcb    #16
> mmu_basepage    fcb    #2
> low_addr    fdb    #$4000

What meaning has a hash prefix for plain decimal numbers? I don't think
fcb needs a # to declare values ...

> procedure HSCREEN
> hscreen    proc    width:word,height:byte,colors:byte
>     begin    hscreen
>     ldx    #$ff98
>     lda    ,x
>     ora    #%10000000
>     sta    $ff98    video mode

x holds already the address ...
      sta    ,x

> testw    ldx    width,u
>     lda    colors,u
>     sta    hhcolors
[..]