Would it be possible to have normal and full compilation modes. So if a program runs at normal by default the code for changing the clock to normal at every dispgraph wouldn't be needed. Also this could be used by 83+ owners so that when they compile a program, full commands are ignored.

Full commands are already ignored in 83 Plus mode. In fact, if a Full command is run on an 83 Plus, HL returns zero and nothing happens. But I have seen the size of the Full command, and yes, I think it would be a good idea to have some option where Full and Normal are skipped.

I'm back, and this time with screen update routine optimizations! I've used 71 cycles as the target minimum delay between port outputs, because that's the number that you said worked for your calculator with a bad LCD driver. If you want these routines to target 72 or 73 cycles between port outputs instead, that's an easy modification for the first two routines. The grayscale routines could be harder.


EDIT: If you're going to use any of these, make sure to actually test them first.

EDIT 2: I previously didn't have an optimization for p_DispGS, but after more closely inspecting the routine, now I do!

---

p_FastCopy: 1 byte and 1548 cycles saved.

Code: (Original code: 46 bytes, ~59389 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_FastCopy: .db __FastCopyEnd-1-$ FastCopy: ld hl,plotSScreen ld a,$80 out ($10),a ld c,-$0C call $0000 ;Safety push af __FastCopyAgain: ld b,64 ;7 ld a,c ;4 add a,$2C ;7 out ($10),a ;11 ld a,(hl) ;7 (waste) inc de ;6 (waste) __FastCopyLoop: push af ;11 (waste) pop af ;10 (waste) ld de,12 ;10 ld a,(hl) ;7 add hl,de ;11 out ($11),a ;11 djnz __FastCopyLoop ;13/8 ld de,1-(12*64) ;10 add hl,de ;11 inc c ;4 jr nz,__FastCopyAgain ;12 __FastCopyRestore: pop af out ($20),a ret c ei ret __FastCopyEnd: .db rp_Ans,__FastCopyEnd-__FastCopyAgain+3

Code: (Optimized code: 45 bytes, ~57841 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_FastCopy: .db __FastCopyEnd-1-$ ld hl,plotSScreen ld c,-$0C ld a,$80 out ($10),a ;??cc into call $0000 push af __FastCopyAgain: push hl ld a,c add a,$2C out ($10),a ;many cc into, 73cc loop inc de ;waste ld b,64 __FastCopyLoop: ld a,(hl) ;waste inc de ;waste dec de ;waste ld de,12 ld a,(hl) add hl,de out ($11),a ;71cc into, 71cc loop djnz __FastCopyLoop pop hl inc hl inc c jr nz,__FastCopyAgain __FastCopyRestore: pop af out ($20),a ret c ei ret __FastCopyEnd: .db rp_Ans,__FastCopyEnd-p_FastCopy+11

---

p_DrawAndClr: 2 bytes and 1548 cycles saved. Pretty much the same optimization as above.

Code: (Original code: 47 bytes, ~59389 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_DrawAndClr: .db __DrawAndClrEnd-1-$ ld hl,plotSScreen ld a,$80 out ($10),a ld c,-$0C call $0000 ;Safety push af __DrawAndClrAgain: ld b,64 ;7 ld a,c ;4 add a,$2C ;7 out ($10),a ;11 ld a,(hl) ;7 (waste) inc de ;6 (waste) __DrawAndClrLoop: ld de,12 ;10 ld a,(hl) ;7 ld (hl),d ;7 ld (hl),d ;7 (waste) ld (hl),d ;7 (waste) add hl,de ;11 out ($11),a ;11 djnz __DrawAndClrLoop ;13/8 ld de,1-(12*64) ;10 add hl,de ;11 inc c ;4 jr nz,__DrawAndClrAgain ;12 __DrawAndClrRestore: pop af out ($20),a ret c ei ret __DrawAndClrEnd: .db rp_Ans,__DrawAndClrEnd-__DrawAndClrAgain+3

Code: (Optimized code: 45 bytes, ~57841 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_DrawAndClr: .db __FastCopyEnd-1-$ ld hl,plotSScreen ld c,-$0C ld a,$80 out ($10),a ;??cc into call $0000 push af __DrawAndClrAgain: push hl ld a,c add a,$2C out ($10),a ;many cc into, 73cc loop inc de ;waste ld b,64 __DrawAndClrLoop: inc de ;waste dec de ;waste ld de,12 ld a,(hl) ld (hl),d add hl,de out ($11),a ;71cc into, 71cc loop djnz __DrawAndClrLoop pop hl inc hl inc c jr nz,__DrawAndClrAgain __DrawAndClrRestore: pop af out ($20),a ret c ei ret __DrawAndClrEnd: .db rp_Ans,__DrawAndClrEnd-__DrawAndClrAgain+11

---

p_DispGS: ~4847 cycles faster! This is more of a bug fix than an optimization; the old routine copied 13 columns!

Code: (Original code: 66 bytes, ~63507 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_DispGS: .db __DispGSEnd-1-$ call $0000 push af ld a,$80 out ($10),a ld (OP2),sp ld hl,flags+asm_Flag2 rr (hl) sbc a,a xor %01010101 ld (hl),a ld c,a ld l,appbackupscreen&$ff-1 ld sp,plotSScreen-appbackupscreen __DispGSNext: ld a,l ;4 ld b,64 ;7 add a,$21-(appbackupscreen&$ff);7 out ($10),a ;11 Into loop: 59 T-states inc l ;4 ld h,appbackupscreen>>8 ;7 ld de,appbackupscreen-plotSScreen+12;11 __DispGSLoop: ld a,(hl) ;7 Loop: 61 T-states rrc c ;8 and c ;4 add hl,sp ;11 or (hl) ;7 out ($11),a ;11 add hl,de ;11 djnz __DispGSLoop ;13/8 Next Loop: 60 T-states ld a,l ;4 cp 12+(appbackupscreen&$ff);7 jr nz,__DispGSNext ;12 __DispGSDone: ld sp,(OP2) __DispGSRestore: pop af out ($20),a ret c ei ret __DispGSEnd: .db rp_Ans,__DispGSEnd-p_DispGS-2

Code: (Optimized code: 66 bytes, ~58660 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_DispGS: .db __DispGSEnd-1-$ call $0000 push af ld a,$80 out ($10),a ;many cc into ld (OP2),sp ld hl,flags+asm_Flag2 rr (hl) sbc a,a xor %01010101 ld (hl),a ld c,a ld l,appbackupscreen&$ff-1 ld sp,plotSScreen-appbackupscreen __DispGSNext: ld a,l ld b,64 add a,$20-(appbackupscreen&$ff-1) out ($10),a ;113cc into, 71cc loop inc hl ld h,appbackupscreen>>8 ld de,appbackupscreen-plotSScreen+12 __DispGSLoop: ld a,(hl) rrc c and c add hl,sp or (hl) out ($11),a ;71cc into, 72cc loop add hl,de djnz __DispGSLoop ld a,l cp 12+(appbackupscreen&$ff-1) jr nz,__DispGSNext __DispGSDone: ld sp,(OP2) __DispGSRestore: pop af out ($20),a ret c ei ret __DispGSEnd: .db rp_Ans,__DispGSEnd-p_DispGS-2

---

p_Disp4Lvl: 3 bytes larger, but ~7693 cycles faster! Extra bonuses: updates in row-major order for cleaner grayscale AND works with any pair of buffers!

Code: (Original code: 79 bytes, ~78433 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_Disp4Lvl: .db __Disp4LvlEnd-1-$ call $0000 push af ld (OP2+2),sp ld a,$80 out ($10),a ld sp,appbackupscreen - plotSScreen ld e,(plotSScreen-appbackupscreen+12)&$ff ld c,-$0C ex af,af' ld a,%11011011 ld hl,flags+asm_flag2 inc (hl) jr z,__Disp4Lvlskip add a,a ld b,(hl) inc b jr z,__Disp4Lvlskip rlca ld (hl),-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 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,(OP2+2) __Disp4LvlRestore: pop af out ($20),a ret c ei ret __Disp4LvlEnd: .db rp_Ans,__Disp4LvlEnd-p_Disp4Lvl-2

Code: (Optimized code: 82 bytes, ~70740 cycles with 3-cycle LCD port delay, excluding p_Safety) [Select] p_Disp4Lvl: .db __Disp4LvlEnd-1-$ ld hl,appBackUpScreen ld de,plotSScreen call $0000 push af push hl ld a,$07 out ($10),a ;many cc into ld a,%11011011 or a ld hl,flags+asm_flag2 inc (hl) jr z,__Disp4Lvlskip rra ld b,(hl) inc b jr z,__Disp4Lvlskip rra ld (hl),-2 __Disp4LvlSkip: ex af,af' pop hl ld a,$80 __Disp4LvlEntry: out ($10),a ;76+cc into, 71cc loop push af ex (sp),hl ;waste ex (sp),hl ;waste nop ;waste ld a,$20 out ($10),a ;71cc into ld b,12 __Disp4LvlLoop: ex af,af' rra ld c,a ex af,af' ld a,(de) xor (hl) and c xor (hl) inc de inc hl out ($11),a ;71cc into, 77cc loop djnz __Disp4LvlLoop inc bc ;waste ex af,af' rra ex af,af' pop af inc a bit 6,a jr z,__Disp4LvlEntry __Disp4LvlDone: ld a,$05 out ($10),a ;73cc into pop af out ($20),a ret c ei ret __Disp4LvlEnd: .db rp_Ans,__Disp4LvlEnd-p_Disp4Lvl-8

---

Also, I'm going to bump a few old optimization suggestions. They may have been skipped because Axe couldn't support them at the time, but in case it can now or in the near future, I'll make sure they aren't forgotten. And I'll throw in a new optimization that would also require an upgraded command parser.

And as a side note, would it be possible to reformat DS<() so that the variable is reinitialized to its maximum value at the End? That way, 3 bytes could be saved by having both the zero and not zero conditions using the same store command. For example:

Code: [Select]

ld hl,(var)
dec hl
ld a,h
or l
jp nz,DS_End
;Code inside statement goes here
ld hl,max
DS_End:
ld (var),hl


Now that you have absolute jumps implemented:

Code: (Original code) [Select] p_Exchange: .db 13 pop de ex (sp),hl pop bc ld a,(de) ldi dec hl ld (hl),a inc hl ld a,b or c jr nz,$-8

Code: (Optimized code) [Select] p_Exchange: .db 12 pop de ex (sp),hl pop bc __ExchangeLoop: ld a,(de) ldi dec hl ld (hl),a inc hl jp pe,__ExchangeLoop ;or is it po?

Code: (Original code: 27 bytes, ~220 cycles) [Select] p_DKeyVar: .db __DKeyVarEnd-1-$ dec l ld a,l rra rra rra and %00000111 inc a ld b,a ld a,%01111111 rlca djnz $-1 ld h,a ld a,l and %00000111 inc a ld b,a ld a,%10000000 rlca djnz $-1 ld l,a ret __DKeyVarEnd:

Code: (Optimized code: 23 bytes, ~259 cycles) [Select] p_DKeyVar: .db __DKeyVarEnd-1-$ ld c,l dec c ld a,c rra rra rra call __DKeyVarMask cpl ld h,a ld a,c __DKeyVarMask: and %00000111 inc a ld b,a ld a,%10000000 rlca djnz $-1 ld l,a ret __DKeyVarEnd:

Thanks for those! I was actually thinking of changing the 3 level grayscale to be row major too so I'm probably going to be using a whole new routine for that.

Runer, I was testing out your 4 level grayscale routine and I'm getting some really weird results.  Its literally showing black and white lines across the otherwise perfect gray that shift about every second.  When I add some pause between displays, it looks better, but still not as good as the column major routine.  The emulator makes it look fine, so I can't upload a screenshot, but try this upload on hardware.

Sorry for the late response, this is how the program looks on my calculator (see attachment).  I'm pretty sure it has nothing to do with the delay being too short since it looks better when I add more pause between each DispGraph.

Really?  Wabbitemu accepts it fine for me... It was just your routine replacing the current 4 level grayscale.  Random squares were drawn to each buffer and then it did a "Repeat getkey(15):DispGraphrr:End" loop.

Yeah, like I said, if I add pause to the loop, it looks better (pause 11 is perfect gray).  But my point is that I'm not sure anymore if having the routines row major is actually an advantage because the old routine produced just as perfect a gray when it was in sync yet it didn't have graphical problems when it wasn't.  This routine seems less resilient to changes in the pause time.

Maybe my calculator is just the exception though, I don't know what the statistics are for what percentage of calculators have bad LCDs.  Regardless, I don't think any single routine can produce perfect gray across ALL calculator models.  So I think I should just forget about column/row ordering and just stick with the smallest, fastest routines.