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.

I found the bug to the big endian reading/writing.  It just happened this version so it wasn't around before.  Its because I added the No-Op command which uses the illegal command size 0.  A zero normally signifies an immediate replacement when found right after a command and the no-op was right after the swap command so it was trying to replace pars of the swap command with the last thing in "ans" which would be the constant.  So I've moved the no-op operation to the top of the file instead so that its never trailing another command.  I realize I could just slap on the label to any zero byte in the file, but I'm trying to keep it readable.

Every time I had a certain feature to my program the game crashes when it happens.

What I'm adding is a Pxl-On(96,Z)^r and then a Horizontal -^r.

I made different programs with this feature (the Y of Pxl-On is random) in several games I made as prototypes and it always compiles well, runs well but crashes during runtime (I never get to see the feature).

So the thing is, is there any problem in the code or in the Parser? I can't give full code because this is for my entry.

Scout, neither of those should be able to cause crashes. When I wrote a quick test program with those two lines of code in a loop, nothing bad happened.

Also, Pxl-On(96,Z)^r does nothing because 96 is out of the bounds of the screen.

I actually managed to do it too, but it was a bit weird because it happened in two different programs. Thanks for checking it

Under the ZOOM menu in VARS, there's a bunch of changed tokens that give an ERR:BAD SYMBOL when I try to use them. None of them are mentioned in the documentation anyway....

In Axe 0.5.2, there seems to be a problem with constants and If [variable]<[constant].  When I replace GDB2 with 10, the code functions correctly.  For some reason, the If statement gives a false "true" when I use GDB2. 

For example,
10->GDB2
If K<GDB2
.GDB2 is not compiled correctly, so it shows a false true.
End
If 10=GDB2
.GDB2 is compiled correctly for some odd reason.
Text(0,0,":)")
.A smilie is displayed, so I know that GDB2 is supposed to be compiled as 10 (Here at least).
End

It's over 9000!!!!! in hex!