Yes- constants and labels are the same thing!
The only major limitation is that once you start operating on addresses with macros and doing compile-time calculations, you must declare those labels before referencing them in expressions. In some instances this may require you to use `:org` to assemble your program in a non-linear fashion.
Ahh, so that's what's going wrong. That's pretty annoying :/ I have a shit-ton of data that I need to reference in this way. I guess the data is going to the top of the file, cluttering up the place, if there is no other way.
I was just getting used to the jump0 trick, until I realised that I have 48 entries in the table and 47 * 6 = 282, which is more than v0 can hold... So v0 is overflowing and giving me errors... o_0'
If I want to have the data before my code, can I do something like this?
:org end-of-code <data> :org 200 : main <code> : end-of-code
This particular code gives me an "Undefined name 'end-of-code'".
Edit: Never mind! I don't have to move all the code under the data, I just have to move the look-up table under the data. Problem solved! Thanks guys :)
:org can't deal with a forward reference either. It would kinda require the assembler to contain a constraint solver to support that sort of thing in full generality.
For an XO-CHIP game, I'd recommend using a pair of macros something like the following:
:calc CODE_POS { 0x200 }
:calc DATA_POS { 0x1000 }
:macro to-code { :calc DATA_POS { HERE } :org { CODE_POS } }
:macro to-data { :calc CODE_POS { HERE } :org { DATA_POS } }
The idea is to reserve the low 4kb of RAM for code, and then position all of your data afterwards. By invoking these macros in turn, we can alternate between defining data and defining code, and thus keep related information together within our source code. Then it's easy enough to define "high RAM" addresses before we need to build pointers to them, for example.
: main
jump draw-smile
to-data
: smile 0x50 0x00 0x88 0x70
to-code
: draw-smile
i := long smile
sprite v0 v0 4
This will often waste a bit of space in the gap between "code" and "data", but you can manually tweak the initial value of "DATA_POS" if things get really tight.
Make sense?
edit: And, yes, you're absolutely right: for your specific case you just have to put the lookup table in the right place. :)