Ramsection Variables can't have larger than 8 bit value for address (65816)

[Scryfox]

I have been attempting to place ramsections in slots that are defined as starting after $0000, but every time I have attempted to do so I get the error that the value (address) of the variable is larger than an 8 bit value. Each slot started at at $2000 at earliest, as I am attempting to start placing my variables after the stack. Thanks for any insight you may have!

[vhelin]

Could you provide us with some source code that doesn't work. Or just the critical (memory map, ram sections, and how you access the variables in ramsections) parts?

[Scryfox]

Absolutely, sorry! I was able to get them working earlier by adding a slot at $0000 and a second one at $8000, having my rom sections placed in slot 1 and ram in slot 0. Thanks for your consideration and if there is anything else I can provide, I am happy to!

Memory Map:

.MEMORYMAP                      
    SLOTSIZE $2000
    SLOT 0 $0000                  
    SLOT 1 $2000                  
    SLOT 2 $4000                  
    SLOT 3 $6000                  
    SLOTSIZE $8000                
    DEFAULTSLOT 4                 
    SLOT 4 $8000                  
.ENDME          

.ROMBANKSIZE $8000              ; Every ROM bank is 32 KBytes in size
.ROMBANKS 8                   ; 2 Mbits - Tell WLA we want to use 8 ROM Banks

.LOROM

RamSections:

.RAMSECTION "Controller Statuses" BANK $7E SLOT $0
     Joy1Raw         dw
     Joy1Press       dw
     Joy1Held        dw 
.ENDS

Ram Access:

.SECTION "Read Controllers" FREE
Joypad:                         ; Read controllers

lda $4212
and #$81
bne Joypad

rep #$30            ; A/X/Y - 16 bit ; Player 1
ldx Joy1Raw         ; load log of last frame's RAW read of $4218
                    ; the log will be 0 the first time read of course..
lda $4218           ; Read current frame's RAW joypad data
sta Joy1Raw         ; save it for next frame.. (last frame log is still in X)

txa                 ; transfer last frame input from X -> A (it's still in X)
eor Joy1Raw         ; Xor last frame input with current frame input
                    ; shows the changes in input
                    ; buttons just pressed or just released become set.
                    ; Held or unactive buttons are 0
and Joy1Raw         ; AND changes to current frame's input.
                    ; this ends up leaving you with the only the buttons that
                    ; are pressed.. It's MAGIC!
sta Joy1Press       ; Store just pressed buttons
txa                 ; Transfer last frame input from X -> A again
and Joy1Raw         ; Find buttons that are still pressed (held)
sta Joy1Held        ; by storing only buttons that are pressed both frames
sep #$20
ldx #$0000      ; we'll clear recorded input if pad is invalid

lda $4016       ; Pad 1 - now we read this (after we stored a 0 to it earlier)
bne Connected     ; $4016 returns 0 if not connected, 1 if connected
stx Joy1Raw     ; otherwise clear all recorded input.. it's not valid..
stx Joy1Press
stx Joy1Held
Connected:
rtl

.ends

[vhelin]

I think WLA is a bit stupid here, and tries to use the 8-bit version of e.g., LDX here. So instead of writing

ldx Joy1Raw

help WLA a little, and type

ldx Joy1Raw.w

which will force WLA to use the 16-bit version of LDX. For 65816 you'll find .L (24-bit) useful, too.

This limitation has been long in WLA, it's not very smart. The assembler tries to create as small binary as possible and will default to 8-bit versions of the opcodes if it doesn't know the real size of the operand. And in the case of labels it's the linker WLALINK that places the labels into memory and gets to know the sizes of the labels, but that's after the assembler has finished its work...

For this to be automatic we would need to perhaps merge the assembler and the linker, make the assembler to use 16-bit versions of the opcodes in case of labels, or something like that, but currently you'll need to give hints to the assembler with .B, .W and .L...

[Scryfox]

Awesome, thanks for the response! This works great for now, I appreciate the help and all the work you have put into this awesome project!

[Scryfox]

I do have a quick question that is similar, it seems as though the ram sections are accessed using long addressing but rather absolute addressing. As a result, I must currently change the bank I am using when accessing the ram section. I am just curious if I am missing something. Thanks!

[vhelin]

I've never written a line of 65816 code myself, so I don't know much about it, but...

With absolute addressing you mean .w (16-bit) and with long address you mean .l (24-bit)? If you want use long address, why not write

ldx Joy1Raw.l

instead of

ldx Joy1Raw.w

?