[Coco] ccasm question

[Robert Gault]

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?
>
> =============
>      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
>
> procedure HSCREEN
> hscreen    proc    width:word,height:byte,colors:byte
>      begin    hscreen
>      ldx    #$ff98
>      lda    ,x
>      ora    #%10000000
>      sta    $ff98    video mode
> testw    ldx    width,u
>      lda    colors,u
>      sta    hhcolors
> [...snip...]
> =============
>
>

There may be typos above but if this was "cut and paste" you have defined 
hwidth, hcolors, and hheight but used width, colors, hhcolors, and height. Since 
the entire procedure is not shown, you may or may not be missing the endproc.

So, the procedure was called with undefined terms in the proc line. Both colors 
and hhcolors are in the procedure but neither is defined.

The procedure itself may be wrong as it looks like hhcolors may be intended as a 
palette but does not change. You will only change a single palette value with 
the code shown but have 16 in mind as that is the value of hcolors.
What is the intent of this procedure?

Robert


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com