creaothceann wrote:Even if the program compiles, wouldn't you have to jump over the .db bytes?
Excellent point. Otherwise the table will execute as code, namely (if I haven't screwed this up):
which will corrupt the stack and then waste 6 cycles doing basically nothing (unless there's SRAM at $4824, in which case it will be corrupted too).
You might want to put the table in a separate section, or at least after the end of your code. I've done the 'jump over the table' trick myself, but it was in a test code I figured I was unlikely to reuse, so I cared more about not having to scroll around in the file than about performance or maintainability.
andylatham82 wrote:Ah actually I see that $8108 is the address of the table itself. Is there a way to manage the creation of the table better so that it works with LDA instead of LDA.w?
There's no need really. Using
.w just tells WLA that you want to use the absolute-addressed version of the instruction, so it can use a full 16-bit operand. Using direct page would be slightly faster, but unless you want to figure out how to tell WLA to only use the bottom half of the label, you'd need to use page zero, and unless your data bank is a HiROM region (it shouldn't be), page zero is in shadow RAM, so you'd have to spend more effort loading the table into RAM at boot. Furthermore, you'd need to be sure the direct page register was pointing at page zero before using this subroutine, since in general it's not.
Less trouble to just use absolute addressing.
WLA DX is weird sometimes. Usually it gets this sort of thing right, but every now and then I run into a goofy error; more than once I've resorted to using
.db statements to specify instructions directly in hex because WLA refused to assemble the code I wanted. This might just have been me not understanding how to force the assembler to work, and to be fair 65C816 code is a lot harder to assemble than 6502 code - not that that's relevant to
this particular error...