nesdev.com

In the spirit of the last post, here's some "goodies" of mine. They are pseudo-ops that just reduce the number of lines of code, however one should always be cautious because they can possibly emit alot of instructions, so they can create a false impression of program compactness. Also, one may call it heresy that those pseudo-ops are more than 3 characters, and that it may look like another cpu instruction set: no, my goal isn't to implement another processor in a 6502, it is just to save a bit of typing while having some fun with ca65's macro system.

push/pop:

The idea here is that you specify what you want to push/pull to/from the stack; A, X, Y and P can be specified along with memory locations. push pushes all the args in the order specified and pop pops them in reverse order, so the following:

...will save and restore correctly the specified registers and the memory location. Of course, A should be first (or second, if P is first) in the list if one want to save A, or else A won't be correctly saved/restored without a warning.

Also, push accepts regular immediate (8-bit) arguments but also 'absolute' arguments with =: one can push absolute addresses, and those addresses are pushed in the same order that jsr and brk does. So the following is a slow and convoluted way to jump at somelabel:


mov/movw:

mov is trivial so won't explain, but is included here nevertheless because movw uses it. The latter moves a word (which can be immediate) into some address; it assumes words are stored into consecutive byte addresses. dest and src can even use absolute or zeropage indexed addressing mode if you use curly braces:

Limitations: it can only use A for transfers, it does not fit well with the use of the struct-of-array "idiom", and if you try to use indexed indirect addressing, it will silently break because it will be converted into absolute indexed (oh nevermind, it gives errors fortunately, but one should be cautious when using parens, it should not begin with an open parens, that how ca65 tells if it's absolute or indirect addressing).

_________________
((λ (x) (x x)) (λ (x) (x x)))

Was working on the aforementioned stuff and came up with an idea to help with .define style macros.
These can be very helpful in some cases: they can be used anywhere, as compared to regular macros which are required to be at the beginning of a line. As well, they are the only "variable" in ca65 that can be assigned a string. They are constants, but they can be undefined and redefined, so they can be treated as variables. The problem is that they can get really tricky, for example:



This will output NO, since the .define macros always resolve to their value, which is BAR, and BAR is not defined. They only way they don't resolve to their value is when using .undefine

To make things simpler I use this:


With these macros you can:


This also has the advantage that you can use define or undefine at anytime, whereaas with the original .define and .undefine, ca65 would output an error if the identifier was not defined/undefined properly first.

How to evaluate unknown amount of parameters:

You could probably do this with just a repeat as well, but I find recursion the easiest way. The simplest way is to just list a bunch of parameters and hope you have enough and recurse on them, but more flexible is something like:



Then one would call the macro with as many parameters as they want, but the parameters must be in in curly braces "{}".
This isn't a big deal but it allows for some flexibility where you may want other parameters passed that are not a part of the variable amount of parameters:

Here's a fairly convenient way to create custom character mappings based on a tileset. "#" is used to notate unused characters.

EDIT: Note that line continuation has to be enabled with ".linecont +" for this to work as is.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

That's pretty nice. Just note to be careful that redefining the charset doesn't cause things like "NES" in the iNES header to be changed.

Yep, that was the first pitfall I encountered when using the cc65 suite. cl65 uses the c64 charmap by default (because the default target is c64), and that "corrupted" the iNES header.

_________________
((λ (x) (x x)) (λ (x) (x x)))

On the same note, here are a couple of macros I've used to save/restore the charmap before modifying it. They save the original character map, and then set a "direct" mapping 1..255 => 1..255. Note that in this implementation __saveCharMap opens a new scope, so it may not be usable under all circumstances (but was fine for what I was doing).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Is it possible in ca65 to tell some string literals to use ASCII and some to use custom character sets? My own assembler has this feature, and if you need it in ca65 too then perhaps you should add such a thing.

_________________
.

ca65 can change the charmap "dynamically", so yes it is possible (or thefox' last macro wouldn't work/would have no practical use). It would even be possible to do it less verbosely using macros—which would look much like the last macro.

_________________
((λ (x) (x x)) (λ (x) (x x)))

Wrote a little macro to parse fixed point numbers (to be used as constants in code) from strings. It has some limitations, main one being that only a limited number of digits can be used (otherwise overflows in the 32-bit arithmetic). Improvements are welcome.

Example of usage:

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Here's a simple one I came up with a while ago to deal with the problem of referencing structures of arrays generated by external tools:

Example:

It just measures the size of the included file and divides it by the number of labels (which is the number of arrays) to find the length of the arrays and distribute the labels accordingly.

Today I found myself needing to trim strings from the left or from the right, so I came up with these:


Usage:


Getting characters from the left is easy, .sprintf alone can do it, but getting them from the right was much trickier. The function calls itself recursively to build the final string character by character. Does anyone know of a better way to do this?

Not sure if it'd work in ca65, but in C sprintf you'd do


Dynamic length, etc left as an exercise to the viewer.

Doesn't work in ca65, strings are not pointers there.

Strings are bit of second class citizens in ca65, so it's not uncommon to end up with hacks like that. Maybe new builtin functions (e.g., .strleft, .strright and .strmid) should be added to complement .left, .right and .mid. The macro you gave might expand to quite inefficient code (not exactly sure when ca65 evaluates certain parts of it).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi