The only mnemonics I don't spell out are push, pop, sub, add, out, and, dec and halt.

You don't pronounce mnemonics like neg, bit, and call as words?

Thanks, that will help me remembering the mnemonics. also, doesnt ret mean "return"?

Yes, it does.

z80man, the code for saving the CPU clock speed actually serves another useful purpose. It also saves the interrupt status, because the display routines have to disable interrupts to safely run. Because of the new display safety routine, if a program were designed to run at 15MHz, all it would need is one Full at the start and one copy of this safety routine. Removing any CPU speed instructions would only save about 20 bytes, not a very large savings. But I guess I still see the merits of your suggestion for people who want to crazily super-optimize.

Also, why is this in the Help Axe Optimize thread? It sounds more like a feature request.

Oh yeah, I see now that loading and storing big-endian values with constant pointers worked correctly before 0.5.2. I was partially correct in saying that the bug has been around for a while, though. Although constant pointers never had problems, when storing big-endian values was introduced in Axe 0.4.7, it didn't work for non-constant pointers right from its release. So this bug/feature lack has been around for almost half a year. And it went completely unnoticed until a month and a half ago, when I noticed it and posted the bug report here. Apparently you didn't see my report.

This bug must have been present for a long time, because I can't even find a version of Axe in which this bug doesn't exist. Storing a 2-byte value backwards to an expression pointer like →{}^rr throws a compile error. The error doesn't happen if the pointer is a constant, only if it's an expression.

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.

A few suggestions/bug reports regarding the new version of Axe:

• 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.
• 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.
• 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.
• Commands.htm still says that DispGraph^r and DispGraph^rr will not work at 15MHz.

Don't get me wrong though, the new update isn't all bad. The CPU speed and interrupt saving with display commands will make things a lot simpler, and I always love new constant optimizations, of which there were a ton. 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?


p_Safety: ;Output: af holds state to-be-pushed
.db __SafetyEnd-1-$ ;DESTROYS B, all other registers okay.
in a,($02) ;Save model settings
rla ;BE flag into carry
sbc a,a ;00 if BE else FF
jr z,__SafetyBE ;Check If model is base edition
in a,($20) ;Get current speed setting
__SafetyBE:
ld b,a ;Save speed setting
xor a
out ($20),a ;Set speed to slow
ld a,i ;pe if interrupts
di
ld a,b ;Restore speed setting
ret
__SafetyEnd:


In pure Axe it would be very difficult. The least of your problems would be copying a rectangular part of the image to the screen. A much larger obstacle would be that every Axe drawing and buffer command depends on using a 96x64 buffer, whereas it sounds like you would be using a 192x128 buffer.

The second code example you posted already works. But while checking for individual keys or any key is easy, what you suggest is not nearly as easy. This is a good example of the kind of function that could be useful in an Axiom, but isn't really needed enough (especially for its relative complexity compared to other key commands) to warrant making it a built-in feature.