Here's one that I think would be pretty useful and easy to implement: custom interrupts that call the OS interrupt handler before starting or upon finishing. This would allow programmers to use commands like getKey or getKey^r with custom interrupts enabled, which could be very useful. Perhaps fnInt(LBL,FREQ)^r? If they wanted they could actually use this to speed up arrow key repeats as well.

The inc reg₁₆ and dec reg₁₆ instructions don't affect flags because they are very often used to simply advance a pointer in data as part of a routine that needs the flags for other information. Also, it's simple enough to make your own version that affects flags by using 8-bit inc or dec instead.

They don't affect the carry flag because the zero flag does pretty much the same thing, allowing data in the carry flag to be preserved. For inc reg₈, the zero flag is affected in the exact way the carry flag would be affected, both of which would be set if the register was 0xFF before the operation. For dec reg₈ it's not exactly the same, but it's very close. The zero flag would be set if the register was 0x01 whereas the carry flag would be set if the register was 0x00, but this can be easily corrected for by keeping the register's value at 1 above the value you actually want it to represent.

Sorry it took me so long to get together a routine, but I was busy with some other stuff. My routine is in the style of Xeda's routine. It reads from a 4-byte sprite and uses overwrite logic, and for the most part mimics her routine. Except it's improved.

• 7 bytes smaller
• ~160 cycles faster
• Doesn't use any RAM

It also allows for drawing to a buffer besides plotSScreen, although I didn't mention this because hers could easily be modified for this as well. You can also view the routine at http://typewith.me/Zv15SUf9Ve. Xeda or anyone else, feel free to grab this routine for your own projects.


PutSprite4x4:
;———————————————————54 bytes———————————————————;
;ENTRY POINT #1: PutSprite4x4
;—> Draws a 4x4 sprite to plotSScreen, aligned to a 24x16 grid
;INPUTS:    a=row (0-15)    c=column (0-23)    de=sprite
;OUTPUTS:   a=0    bc=12    de=sprite+4    hl=((row+4)*48)+(column/2)+plotSScreen
;FLAGS:     S=0  Z=1  H=0  V=0  N=1  C=column mod 2
;—————————————————~620 cycles——————————————————;
;ENTRY POINT #2: PutSprite4x4_AnyBuf
;—> Draws a 4x4 sprite to the specified buffer, aligned to a 24x16 grid
;INPUTS:    a=row (0-15)    c=column (0-23)    de=sprite    hl=buffer
;OUTPUTS:   a=0    bc=12    de=sprite+4    hl=((row+4)*48)+(column/2)+buffer
;FLAGS:     S=0  Z=1  H=0  V=0  N=1  C=column mod 2
;—————————————————~610 cycles——————————————————;
    ld hl,plotSScreen
PutSprite4x4_AnyBuf:
    push hl
    ld b,a
    add a,a
    add a,b
    add a,a
    add a,a
    ld h,0
    ld l,a
    ld b,h
    add hl,hl
    add hl,hl
    rr c
    rla
    add hl,bc
    pop bc
    add hl,bc
    ld bc,12
    rra
    ld a,4
__PutSprite4x4_Loop:
    push af
    ld a,(hl)
    jr c,__PutSprite4x4_Loop_AlignLeft
    and %00001111
    ld (hl),a
    ld a,(de)
    jr __PutSprite4x4_Loop_AlignEnd
    and %11110000
    ld (hl),a
    ld a,(de)
    rra
    rra
    rra
    rra
__PutSprite4x4_Loop_AlignEnd:
    or (hl)
    ld (hl),a
    add hl,bc
    inc de
    pop af
    dec a
    jr nz,__PutSprite4x4_Loop
    ret


EDIT: Found a way to save 12 more cycles.

Unfortunately, this isn't an Axe limitation, this is an OS limitation. Axe uses the OS text drawing routines, and the OS is incapable of drawing text to any buffer other than the front buffer.

fred30w, there's not much that can be done about the flickering. You won't experience any flickering playing at 100% zoom in black and white, but otherwise it's unavoidable. In the more zoomed-out black and white modes, the flickering you see is intentional. This is dithering to make the graphics easier to see at smaller zoom levels. And in grayscale mode, the flickering is just the nature of grayscale on the TI-83+/84+ calculators. The flickering will also be more pronounced in more CPU-intensive games, which is also unfortunately unavoidable.

---

And on a separate note, I now have a bug with Pokemon. Pokemon used to work fine on my calculator, but I now get what I believe is the not-enough-RAM pages error (Cartridge type is unsupported. Sorry for the inconvenience.) Unless the extra RAM pages disappeared from my calculator in the past week or so, I'm pretty sure they're still there.

The nibble reading bug should pretty much never happen, since it will only occur if you try to read from one of 6 bytes inside the routine itself. I could see this bug maybe cropping up in something like a memory viewer program, but that's about it.

However, the old nibble reading routines were only 1-3 bytes larger than the current ones, so I think it may just be best to revert the changes. I would suggest reverting the $0000-$7FFF routine as well, because if the user had switched a RAM page into the $4000 slot with the help of assembly, the "application" nibble reading routine would have even worse effects than the RAM reading routine, as it would always corrupt the target data. Be sure to get the endianness of the old nibble-reading routines correct, though.

There isn't really a need to revert changes to the nibble writing routine, because if the user is writing a nibble inside of the routine, they're in trouble no matter what routine is being used.

Code: (Original routine: 18 bytes, ~72 cycles) [Select] p_Nib1: .db __Nib1End-$-1 scf rr h rr l ld a,(hl) jr c,__Nib1Skip rrca rrca rrca rrca __Nib1Skip: and %00001111 ld l,a ld h,0 ret __Nib1End:

Code: (Optimized routine: 17 bytes, ~105 cycles) [Select] p_Nib1: .db __Nib1End-$-1 xor a scf rr h rr l ld b,(hl) __Nib1Loop: rrd ccf jr c,__Nib1Loop ld (hl),b ld l,a ld h,0 ret __Nib1End:

Code: (Original routine: 18 bytes, ~68 cycles) [Select] p_Nib2: .db __Nib2End-$-1 srl h rr l ld a,(hl) jr c,__Nib2Skip rrca rrca rrca rrca __Nib2Skip: and %00001111 ld l,a ld h,0 ret __Nib2End:

Code: (Optimized routine: 15 bytes, ~77 cycles) [Select] p_Nib2: .db __Nib2End-$-1 xor a srl h rr l rrd jr c,__Nib2Skip rld __Nib2Skip: ld l,a ld h,0 ret __Nib2End: