Updated for the past week of bug reports, feature requests, and optimization suggestions. Also updated for the release of Axe 1.1.1!

Yes. X?Y produces the same code as If X : Y : End, and X?Y,Z produces the same code as If X : Y : Else : Z : End.

Quote from: epic7 on December 17, 2011, 12:51:07 pm

getKey(2)?X--

Evidently not, when I tried something like that it threw an error at compile-time.

I get no such error, and there should be no difference between the two syntaxes. You mentioned something about Pt-X commands not working in them, and this is true, but not because of a syntax difference. It's because Axe requires that some comamnds start a line, and the Pt-X commands are among them, so you can't use them mid-line in an inline conditional.

It's probably worth mentioning that, for flipping sprites during program execution, you don't have to implement those algorithms yourself. Just use the built-in flipH() and flipV() commands.

That edit was helpful, it gave me a hunch as to what the problem was and (I think) that hunch was correct. Unfortunately, the fix for this problem will cost a byte and about 70 cycles. It will still be about 20% faster than the small routine though. And it still relies on the more common p_Mul instead of p_MulFull, so being 17 bytes larger might still be worth it.

Faster routine: 35 bytes, ~900 cycles Code: [Select] p_88Mul: .db __88MulEnd-1-$ push hl ld c,l ld a,h ld l,0 ld b,b \ .db 8 \ call $3F00+sub_Mul ld b,8 __88MulNext: add hl,hl rla rl c jr nc,__88MulSkip add hl,de adc a,0 __88MulSkip: djnz __88MulNext pop bc bit 7,b jr z,$+3 sub e ld l,h ld h,a bit 7,d ret z sub c ld h,a ret __88MulEnd:

I think I can explain the asymmetry of the size-optimized version. Because it adjusts signs differently, I think it now rounds down instead of towards zero like the old routine.

However, I have no clue what is going on with the speed-optimized routine. Can you look at the debugger and confirm that the call to sub_Mul is actually entering where it's supposed to be entering, at __MulByte? Because I wouldn't be surprised if the fact that you probably had to add the offset call macro for call nz,__MulByte in p_Mul is messing up the offset calls due to its own size.

Well I was messing around with grayscale, and this happened. I have no idea what is going on here. Does the screen have some strange physical quality that is causing this? Left is supposed to be white, middle is supposed to be gray, right is supposed to be black. However, the middle appears to be cycling between dark gray and super-white. Also the center of the screen has more wild contrast changes than areas further away from the center.








EDIT: I have attached the program I used to observe this strange effect. It will only work on 15MHz calculators. Use +/- to tune the frequency, CLEAR to quit. Don't press - too much or it will probably crash! I can't easily give the source because it is part Axe, part Axiom, and part raw hex edited. But if you do look at the disassembly of it, please don't mind any unoptimized code or code that seems out of place, I never actually meant to release this.


EDIT 2: PLEASE READ THIS BEFORE DOWNLOADING

Alternating pixels between black and white at the same speed as the LCD controller alternates between positive and negative voltages means that those pixels receive only the positive pulses or only the negative pulses, effectively creating direct current just like the controller is supposed to prevent.
In summary: Don't use this effect unless you want to screw up your screen.

Here's a very optimized way to convert a 16-bit signed number into an 8-bit signed number in a with overflow handling (if hl<-128, a=-128; if hl>127, a=127). Two added bonus to being super small and super fast are that it destroys nothing and that you could easily modify it to make the input a 16-bit register other than hl.

Signed16To8:
ld a,l
add a,a
sbc a,a
sub h
ld a,l
ret z
ld a,h
add a,a
sbc a,a
xor %01111111
ret