Me or Qigubio?

Aaah ok. Will the problems occurs only on certain calcs, btw?

Aaah ok. Wasn't it on random calcs, tho? I remember way back in 2004 as soon as the 84+ came out there were already people with LCD issues, including regular 83+

same here. I think this is a major hassle when you download a game for your new calc only to find out you will need an additional program.

They need to quit with their crappy LSD... er... LCDs

Alright, I made a big modification.  Its now only 7 bytes larger than the original routine now, still doesn't need to be initialized, and is significantly faster and better looking, but still just slow enough to work on any LCD without having to run fixer programs.

The only downside is that I use a shadow register.  That means this command should NEVER be used in an interrupt routine.  That's alright though becasue you should never have LCD commands inside of an interrupt anyway.  Its much better to just have the interrupt control a counter and then your drawing routine updates the LCD depending on the counter.

Let me know if this can be optimized more and still run on the slower LCDs.

p_Disp4Lvl:
di
ld a,$80
out ($10),a
ld (OP1),sp
ld sp,appbackupscreen - plotSScreen
ld e,(plotSScreen-appbackupscreen+12)&$ff
ld c,-$0C
ex af,af'
ld a,%11011011
inc (iy+asm_flag2)
jr z,__Disp4Lvlskip
add a,a
ld hl,(flags+asm_flag2)
inc l
jr z,__Disp4Lvlskip
rlca
ld (iy+asm_flag2),-2
__Disp4Lvlskip:
ld l,plotSScreen&$ff-1
ex af,af'
__Disp4Lvlentry:
ld a,c
add a,$2C
ld h,plotSScreen>>8
inc l
ld b,64
out ($10),a
__Disp4Lvlloop:
ld a,(hl)
add hl,sp
xor (hl)
ex af,af'
cp e                              <-- Epic coincidence that e just happened to be between 182 and 219
rra
ld d,a
ex af,af'
and d
xor (hl)
out ($11),a
ld d,(plotSScreen-appbackupscreen+12)>>8
add hl,de
djnz __Disp4Lvlloop
inc c
jr nz,__Disp4Lvlentry
__Disp4LvlDone:
ld sp,(OP1)
ei
ret
__Disp4LvlEnd:

Hmm, remember when I suggested you could use IX as a pointer to the variables for easier access when doing 8-bit operations? That would be too much of a hassle, we agreed. But what if you moved the variables to the END of savesscreen? Then they would be within the range of the IY register (which points 4 bytes after the end of savesscreen). Just something to consider

Hmm, remember when I suggested you could use IX as a pointer to the variables for easier access when doing 8-bit operations? That would be too much of a hassle, we agreed. But what if you moved the variables to the END of savesscreen? Then they would be within the range of the IY register (which points 4 bytes after the end of savesscreen). Just something to consider

Hmm... interesting proposition.  Although it would optimize some operations like addition and subtraction, there is still one key advantage to using the existing variable slots.  By using only the least significant bytes of those variables, you never need to do "conversions" when you switch from word to byte mode.  You have to get input and output somehow otherwise there's not much advantage to the new mode.  By being able to skip the conversions, I think that will save more memory in the long run than by using the iy or ix registers.

By the way, I've further optimized that grayscale command and its basically the same size as my original now except way faster which is excellent.

@ztrumpet: I'm not sure if it actually works, I'm going to assume calc83manic tested it on his hardware and got it to work since he proposed it, but the main issue here is compatibility.  This isn't the only sacrifice I've had to make.  There are a few other places where undocumented commands could make routines more efficient, but that wouldn't please the Nspire users.  I could add waste instructions to the super fast routine, but it really adds a lot to the size since I have to add 3 times as many.