The nibble reading and writing commands have opposite endianness again. I would suggest changing p_NibSto to be big-endian like the reading commands currently are, since a lot of people complained about the nibble commands being little-endian. Which makes sense, because big-endian style is a lot better for things like reading from nibble tilemaps. Big-endian nibble order better corresponds with how hex data is added and displayed.

Why does that keep reversing?  I don't remember the last time I changed it... I'll fix it once again.

p_Safety is, well, I have no idea. It works, but it has lots of code that serves no apparent purpose. I'll post what I think the routine should probably look like following this list.

Haha!  I wish it could be that simple.  But as I mentioned in another thread and on Cemetech, there is actually a bug in the z80 hardware where if an interrupt occurs during a ld a,i instruction it will erroneously set the flags as if there was no interrupts, so a more robust test is needed unfortunately.  The one I'm using was invented by calc84maniac.  This was a bug I had for a long time; that custom interrupts would suddenly stop working after a minute or so.  And I'm so glad I finally fixed it!

Probably not a big deal, but if either p_FastCopy or p_DrawAndClr were called immediately after sending data to the LCD, the initial row setting would fail. This could be fixed by moving the safety call after the ld hl,plotSScreen and adding some waste instructions after the initial row setting.

Hmmm... I will double check this and change it if its as simple as moving a few instructions around.  I want to try to avoid waste instructions though.

Commands.htm still says that DispGraph^r and DispGraph^rr will not work at 15MHz.

I'll fix that.

But on the topic of constant optimizations, although For() loops with a constant upper bound got a slight upgrade, it missed the much larger upgrade that the constant comparisons received. Any chance of sneaking that into For() loops as well?

I'll get to that hopefully...

I think I might have mentioned this bug a while ago, and it's been around for a long time, but since it isn't fixed yet I'll mention it again. {CONST}rr, →{CONST}rr, and →{EXPR}rr are all broken. The first two compile into incorrect code, while the third won't compile.

How could something this big go unnoticed for so long!  I'll fix it right away.

Well, we used it for typing, which is assigning types to variables through inference rather than user specification.  Its also great for relational databases (like SQL) and it definitely has a lot of application with artificial intelligence and extracting meaning from sentences.

Basically, Text( lets you set the coordinates before displaying text, while Text uses the current coordinates and takes only a single argument (the string).

Actually, you can have as many arguments as you want for Text also, it just skips having to specify the X and Y value since you've presumably already set that.  The idea is to be exactly the same mapping from "Disp " and "Output(" to "Text " and "Text(".  The first set is for the cursor and the second set is for the pen.

Actually, constant definitions would be very easy to do and are already implemented, kind of.  That's exactly what Str1, Pic1, GDB1 are!  They just hold a constant value that happens to be a ram location.  But I could easily allow the programer to specify other values for these constants and the syntax would be very intuitive:

9001->Str1

This would use symbol space though, so its still limited to ~150 static variables including the regular static pointers.  Bun nonetheless, still generally useful since I don't think that many people actually run out of symbol space. 

EDIT:

Question:
What exactly happens if I leave a parenthesis open?  Obviously, it'll start glitching the program up, but in what ways?  What precisely does it do to the code?

Axe will add the parenthesis for you at the end of the line.  So if you had:

sin(A+cos(B->C

It becomes:

sin(A+cos(B->C))

Instead of what you might be trying to do:

sin(A+cos(B))->C

Oh wait a minute, I think that's the bug.  That was something I changed last minute and I forgot to remove it from the Axe.inc.  As you can tell by the Axiom SDK, that bit isn't even documented because I had removed it and replaced it with the Token indicator instead.  I shall remove it.  Either that, or more usefully, It can be the same thing as AXM_SUB except it parses as "ld hl,yourAxiom" instead of "call yourAxiom".  But then argument count for that would have to be restricted to 0 or 1.

That link is outdated for the Axiom SDK.  The current revision can be found in the "Developers" folder that comes with Axe 0.5.1.  This will be a lot harder to write in Asm by the way than it would be in pure Axe and I wouldn't attempt something this complicated unless you have a good asm background.

I think your library is the fine the way it is though.  If you want to make it more memory efficient, you can split it into sub-libraries.  For instance, you can have "LIB7CORE" for the core routines, "LIB7BUT" for all routines pertaining to buttons, and "LIB7WIND" for window routines.  That way, you only need to include the ones you are going to use.

I'm planning a major feature addition soon which I am dubbing "Axsembly" (Please excuse my lack of creativity with portmanteaus ).

Basically, it will allow direct assembly commands to be integrated directly into Axe... but while keeping the syntax looking almost exactly like regular Axe.  I will be using the lowercase letters for the registers and will allow a wide range of arithmetic instructions.  The major difference with Normal Axe syntax is that assignments are done with the equal sign instead of the store arrow (like in most programming languages) and only a limited range of instructions are allowed.  Both of these are to make Parsing on my side possible.  Everything else is basically the same as you're used to already.  There will also be a simple interface to transfer an Axe variable into a register for manipulation and then bring it back up.

For instance, the instruction "a=a+a" or "a=a*2" will both translate to the assembly instruction "add a,a".  However, "a=a*3" does not correspond to a single instruction, and therefore must be made by hand using 3 instructions like "b=a : a=a*2 : a=a+b".  There will also be some new operators like ++ which acts as an "inc" when used in a unary operation or an "add with carry" in a binary operation.  Different kinds of rotation will also be supported.  All these commands can be interwoven with current syntax, but I wouldn't rely on abusing the side effects because they can change from version to version.

This does have one conflict with Axe's current syntax however: The binary number prefix which is currently "b" will have to be changed to something else, but I think that command is used infrequently enough to not anger anyone who would be affected by this change.

I am hoping this will be a great introduction to assembly for new programmers who want to play around with it while staying in Axe's feature-rich environment.  This was a feature I was panning to add at the beginning, but then gave up, but just now thought of a way I could do it efficiently.