Ports 29-2C simply enable or disable the delays defined in port 2E for the 4 different speed modes. If all the delays are turned off in port 2E, it doesn't matter what speed that calculator is running at or if the delay bits are set in ports 29-2C. If ports 29-2C are like circuit breaker switches, port 2E is the master breaker switch. Turn it off, and it doesn't matter what the state of any of the other switches are.

At this rate, I'll have optimized just about every Axe routine eventually!

---

p_ToHex: 31 cycles faster.

Code: (Old code: 25 bytes, 670 cycles) [Select] p_ToHex: .db __ToHexEnd-$-1 ld b,4 ld de,vx_SptBuff push de __ToHexLoop: ld a,$1F __ToHexShift: add hl,hl rla jr nc,__ToHexShift daa add a,$A0 adc a,$40 ld (de),a inc de djnz __ToHexLoop xor a ld (de),a pop hl ret __ToHexEnd:

Code: (New code: 25 bytes, 639 cycles) [Select] p_ToHex: .db __ToHexEnd-$-1 ld bc,4<<8+$1F ld de,vx_SptBuff __ToHexLoop: ld a,c __ToHexShift: add hl,hl rla jr nc,__ToHexShift daa add a,$A0 adc a,$40 ld (de),a inc e djnz __ToHexLoop ex de,hl ld (hl),b ld l,vx_SptBuff&$FF ret __ToHexEnd:

---

p_ShiftLeft: 1 byte smaller, 67 cycles faster. You could save an additional 384 cycles by giving up the minor size savings and loading 12<<8+4 into de at the start of the routine and then replacing the immediate data operands in the loop with d and e.

Code: (Old code: 17 bytes, 27542 cycles) [Select] p_ShiftLeft: .db __ShiftLeftEnd-1-$ ld hl,plotSScreen+767 ld c,64 __ShiftLeftLoop: ld b,12 or a __ShiftLeftShift: rl (hl) dec hl djnz __ShiftLeftShift dec c jr nz,__ShiftLeftLoop ret __ShiftLeftEnd:

Code: (New code: 16 bytes, 27475 cycles) [Select] p_ShiftLeft: .db __ShiftLeftEnd-1-$ ld hl,plotSScreen+767 xor a __ShiftLeftLoop: ld b,12 __ShiftLeftShift: rl (hl) dec hl djnz __ShiftLeftShift add a,4 jr nz,__ShiftLeftLoop ret __ShiftLeftEnd:

---

p_ShiftRight: 1 byte smaller, 67 cycles faster. Same deal as p_ShiftLeft.

Code: (Old code: 17 bytes, 27542 cycles) [Select] p_ShiftRight: .db __ShiftRightEnd-1-$ ld hl,plotSScreen ld c,64 __ShiftRightLoop: ld b,12 or a __ShiftRightShift: rr (hl) inc hl djnz __ShiftRightShift dec c jr nz,__ShiftRightLoop ret __ShiftRightEnd:

Code: (New code: 16 bytes, 27475 cycles) [Select] p_ShiftRight: .db __ShiftRightEnd-1-$ ld hl,plotSScreen xor a __ShiftRightLoop: ld b,12 __ShiftRightShift: rr (hl) inc hl djnz __ShiftRightShift add a,4 jr nz,__ShiftRightLoop ret __ShiftRightEnd:

---

p_FreqOut: 1 byte smaller. Takes advantage of an absolute jump. This is a strange routine to optimize, because optimizing it results in it running about 15% faster which would result in slightly higher pitched and shorter notes. Although this command is rarely used, this augmentation might still make the optimization not worth it. Whether or not you include the optimization, it might be a good idea to change this routine to use p_Safety.

Code: (Old code: 23 bytes) [Select] p_FreqOut: .db __FreqOutEnd-1-$ xor a __FreqOutLoop1: push bc ld e,a __FreqOutLoop2: ld a,h or l jr z,__FreqOutDone dec hl dec bc ld a,b or c jr nz,__FreqOutLoop2 ld a,e xor %00000011 scf __FreqOutDone: pop bc out ($00),a ret nc jr __FreqOutLoop1 __FreqOutEnd:

Code: (New code: 22 bytes) [Select] p_FreqOut: .db __FreqOutEnd-1-$ xor a __FreqOutLoop1: push bc ld e,a __FreqOutLoop2: ld a,h or l jr z,__FreqOutDone cpd jp pe,__FreqOutLoop2 ld a,e xor %00000011 scf __FreqOutDone: pop bc out ($00),a ret nc jr __FreqOutLoop1 __FreqOutEnd:

---

p_IntSetup: 4 bytes smaller. I thought this was some pretty impressive work. And regarding interrupts, I still think the port 6 saving and restoring shenanigans aren't necessary for programs. The only reason port 6 would need to be restored to the value it held when interrupts were enabled is if the user is using a shell application in conjugation with their Axe program. In that case, either the designer of the shell application interface system could provide modified interrupt routines in an Axiom, or the user is probably intelligent enough to be able to provide their own interrupt routines. (Actually it wouldn't even need to be their own, they could just copy the one for applications from the Commands.inc file)

Code: (Old code: 42 bytes, a lot of cycles) [Select] p_IntSetup: .db __IntEnd-p_IntSetup-1 di ld de,$8B01 ld a,d ld i,a ld a,l ld hl,$8B00 ld b,e ld c,l ld (hl),$8A ldir and %00000110 out (4),a ld a,%00001000 out (3),a ld a,(hl) out (3),a ld d,a ld e,a ld c,__IntDataEnd-__IntData ld hl,$0000 ldir in a,(6) ld ($8A8A+__IntDataSMC-__IntData+1),a __IntEnd: .db rp_Ans,9

Code: (New code: 38 bytes, more cycles but who cares?) [Select] p_IntSetup: .db __IntEnd-p_IntSetup-1 di ld a,l ld hl,$8C06 ld de,$8C05 ld bc,$8C05-$8A8A and l out (4),a ld a,h out (3),a dec a ld i,a dec a out (3),a ld (hl),a lddr ld hl,$0000 ld c,__IntDataEnd-__IntData ldir in a,(6) ld ($8A8A+__IntDataSMC-__IntData+1),a __IntEnd: .db rp_Ans,11

---

p_DtoF: 2 bytes smaller. Takes advantage of a bcall to do the same thing. It appears that B_CALL(_SetXXXXOP2) always returns OP2+1, which could be used to save an additional 2 bytes, but this bcall could theoretically be changed in future OS versions and break this optimization.

Code: (Old code: 13 bytes, a lot of cycles) [Select] p_DtoF: .db 13 ex (sp),hl B_CALL(_SetXXXXOP2) ld hl,OP2 pop de ld bc,9 ldir

Code: (New code: 11 bytes, a lot plus a few cycles) [Select] p_DtoF: .db 11 ex (sp),hl B_CALL(_SetXXXXOP2) ld hl,OP2 pop de B_CALL(_Mov9B)

What are you referring to? I didn't use any square-like symbols in my code. Perhaps your computer is rendering a character wrong? This is what the code should look like:

Nope. And I'd personally stay away from group files as much as possible, they're made of pure evil.

You can copy a picture to a buffer and then draw whatever you want on top of it. Just copy the picture data to the buffer every frame before drawing anything else with code like this:

Copy([Pic1],L₆,768)


And you can't include the value of a variable in a data declaration because all the data is added to the program at compile time, whereas variables only have meaningful values at run time. If you must include a variable in a list of data, you can do something like the following:

Data(0,number,number,etc)→GDB0
variable→{GDB0}


You should always have error handling code when dealing with OS variable reading/creating. Here are routines for both directions, with error handling.


OS float to Axe variable:

If GetCalc("varA")  .var is the u token found at 2nd+7
float{}→A           .float{ is the fPart( token
Else
.Not found
End

Axe variable to OS float:

A→float{GetCalc("varA",7)}
!If  and 0
.Not enough RAM
End


Pause statements is a crude way, but it works well.

Wouldn't that make the game slower, not faster?

Quote from: Eeems on September 09, 2011, 02:44:55 pm

Frameskipping would speed it up. ( So only display every other frame ).

With that, the game speed would remain the same, but it would be even choppier (notes and such would pass at half speed but seemingly at 2 pixels per jump)

Each frame sent to the screen takes about 1/100th of a second, and on top of that there's the time needed to render the frame. Cutting out about 15-20 of these per second would certainly save a lot of processing time, allowing the game to run faster.