Just having GDB000 and GDB001 sitting like that isn't including them as data. They get included as code just like any other code sitting on a line outside of any special directives. To include pointers as data, use the Data() directive (token: ∆List()), like this. The superscript r's mark that the values are 2-byte values:

.HEADER
[000D0917]->GDB000
Data(GDB000ʳ,GDB001ʳ)
.MAPDATA
[0119000101010001]
.more map data

Assuming all headers are 4 bytes and you had a pointer to a map header in S, you could then read the pointer to the previous map header with {S+4}^r and read the pointer to the next map header with {S+6}^r.

Alright, I'm guessing the issue was just a limitation in the number of replacements the Axiom system could perform in a single command. So not really a bug, but more of a lack of a feature to include infinitely many.

Two funky janitorial things to remember when using REP_NEXT in a command:

• Add 1 to the calculated command size at the start of the command header for each REP_NEXT used, and add 2 for each OFS_NEXT used. The redefining of the origin backwards in these macros causes this discrepancy.
• Make sure the origin at the start of the command code (the command body, not the command header) is 0.

Are both of these accounted for?

Since I don't even know what a toroid is... I think you're on your own for this one lol.



EDIT: Didn't see shmibs' post, here's my response to that: Doing the same thing with a custom assembly routine wouldn't be substantially smaller or faster, so I don't see a reason to implement such a command.

That would be insanely hard to code. Basically it's like drawing an arbitrarily sized sprite, which is hard enough, but on top of that the source data for the sprite doesn't have to be aligned to byte boundaries, you have to clip off any garbage in the leftmost and rightmost bytes, you have to draw the new sprite either from top to bottom and either from left to right according to the relative positions of the rectangles... It's a big mess.

Oh, I think the 24 consecutive calls might be the issue... Perhaps use a loop to do those calls, or absorb that command into the one that calls it so much.

I'm pretty sure that means that a command in your axiom has too deep of a reference, meaning it references a command which references a command which references a command, etc. I've never really looked at the axioms system because it's a bit of a mess, but I doubt you've actually built a linear chain of references that's long enough to hit the limit (which happens to be 8). I would guess that, more likely, you have a circular chain of references, like one command referencing itself, or two commands referencing each other. In the case of one command referencing itself, you can simply skip the reference replacement system and do a standard load preceded by REP_NEXT, call, or jump. In the case of two or more commands referencing each other... that might not work with the current axiom system. It's something that would have to be fixed in a rewrite, so I can't really promise a fix for it any time soon at all. But if they reference each other, that means you know that you need both of them present if either is called, so can't you combine them into one command?

I think there might be an issue with HLines() drawn off the screen.

What version of the command are you using? Because the 3-argument version is known to be broken in Axe 1.2.1.