Author Topic: Assembly Programmers - Help Axe Optimize! (Read 154680 times)

Quigibo · « **on:** February 26, 2010, 03:52:51 pm »

I'm going to post most of the assembly routines I use in Axe Parser here to see if any of you asm programmers can help me with their optimizations.

I am always trying to optimize for size, not speed, unless it is significantly faster and close to the same size.
I would greatly prefer that it does not use any extra RAM to store temporary variables, but that's not that big of a deal.
No self modifying code or undocumented commands because I need to make this compatible for Apps and with the Nspire TI-84 emulator.

The most important thing right now is the clipped sprite routine since its really big. Here's what I got so far:
p_DrawOr8x8: push hl pop ix ;Input hl = Sprite ld b,7 ;Input c = Sprite X Position ld d,0 ;Input e = Sprite Y Position ld h,d ld a,c add a,b jr c,__ClipLeft sub 96+7 ret nc cpl cp b jr nc,__NoClipH __ClipRight: inc d jr __ClipHDone __ClipLeft: add a,89 ld c,a __ClipHDone: inc d ;d,c,e are updated __NoClipH: ld a,e add a,b jr c,__ClipTop sub 64+7 ret nc cpl cp b jr nc,__NoClipV jr __ClipBottom __ClipTop: inc ix inc e jr nz,__ClipTop __ClipBottom: ld b,a __NoClipV: ;b,ix,e are updated. dec d jr z,__NoFix inc e __NoFix: push de ld l,e ld d,h add hl,hl add hl,de add hl,hl add hl,hl ld e,c ld a,e srl e srl e srl e add hl,de ld de,plotSScreen-11 add hl,de pop de inc b and %00000111 jr z,__DrawOr8x8Aligned ld c,a __DrawOr8x8Loop: push bc ld b,c ld c,(ix+0) xor a __DrawOr8x8Shift: srl c rra djnz __DrawOr8x8Shift dec d jr z,__SkipRight or (hl) ld (hl),a __SkipRight: dec hl inc d jr z,__SkipLeft ld a,c or (hl) ld (hl),a __SkipLeft: ld c,13 add hl,bc inc ix pop bc djnz __DrawOr8x8Loop ret __DrawOr8x8Aligned: dec hl ld de,12 __DrawOr8x8AlignedLoop: ld a,(ix+0) or (hl) ld (hl),a inc ix add hl,de djnz __DrawOr8x8AlignedLoop ret __DrawOr8x8End:

If you spot anything that can be optimized, bold it so I can see what you changed, thanks!

DJ Omnimaga · « **Reply #1 on:** February 26, 2010, 04:57:59 pm »

I would prefer no extra RAM usage at all. Otherwise, games may not run on any TI-84+ manufactured after April 2007 and will not be compatible with the regular 83+, meaning a considerable drop in the author's audience.

Galandros · « **Reply #2 on:** February 26, 2010, 05:09:49 pm »

Quote from: DJ Omnimaga on February 26, 2010, 04:57:59 pm

I would prefer no extra RAM usage at all. Otherwise, games may not run on any TI-84+ manufactured after April 2007 and will not be compatible with the regular 83+, meaning a considerable drop in the author's audience.

Generally ram usage is just the routine needs some temporary bytes to store data. (bytes in the program itself or inserted in the TI-OS available RAM or free ram zones of the TI-OS) Only when you need a good amount of memory you use the extra ram pages.

Eeems · « **Reply #3 on:** February 26, 2010, 06:14:01 pm »

Aldo if I'm not wrong there is a little extra ram in the newer calcs, but not that much.

DJ Omnimaga · « **Reply #4 on:** February 26, 2010, 06:21:02 pm »

Yeah. I'm not sure if it's accessed the same way, though.

Galandros · « **Reply #5 on:** February 26, 2010, 07:11:58 pm »

In the new calcs only the page 53h is still there. It is same port as before. Dunno what 3rd party software uses it...

calc84maniac · « **Reply #6 on:** February 26, 2010, 08:43:34 pm »

Quote from: Galandros on February 26, 2010, 07:11:58 pm

In the new calcs only the page 53h is still there. It is same port as before. Dunno what 3rd party software uses it...

Actually, we don't know which one is still there. All we know is that pages $82-$87 appear to be the same 16K of physical memory.

ztrumpet · « **Reply #7 on:** February 27, 2010, 10:28:07 am »

Quote from: Galandros on February 26, 2010, 07:11:58 pm

In the new calcs only the page 53h is still there. It is same port as before. Dunno what 3rd party software uses it...

If I'm not mistaken, I think Omnicalc's Quick Apps uses it and it works fine on a new 84+se.

Quigibo · « **Reply #8 on:** February 27, 2010, 09:23:58 pm »

Safe Copy requires the undocumented instruction:
in f,(c)

Will that be compatible with the Nspire? If anyone has one, could you please try adding this to any Axe Parser code and see if it crashes:

Asm(0E10ED70)

calc84maniac · « **Reply #9 on:** February 27, 2010, 10:21:03 pm »

Quote from: Quigibo on February 27, 2010, 09:23:58 pm

Safe Copy requires the undocumented instruction:
in f,(c)

Will that be compatible with the Nspire? If anyone has one, could you please try adding this to any Axe Parser code and see if it crashes:

Asm(0E10ED70)

It won't be compatible. But it doesn't require that instruction anyway. I always do this:

Code: [Select]

in a,($10)
rla
jr c,$-3 ;or was it "nc"?

DJ Omnimaga · « **Reply #10 on:** February 27, 2010, 11:58:30 pm »

Hopefully, though, maybe someone will write a 84+ emu for the Nspire to replace the current one, now that Ndless is out

Quigibo · « **Reply #11 on:** March 14, 2010, 03:23:09 am »

Does anyone know an efficient way to do signed multiplication for a 2's compliment system? I can't find any tutorials on the internet. My naive method is to remove and keep track of the sign bit for each term, multiply the positive versions together, and then add the new sign bit. Is there a better method?

This is what I'm using to get the sign bit out of de and keep track of it with the 'b' register. b starts at zero, so I can use bit 0 of b as the new sign bit if I repeat this for hl.

Code: [Select]

	bit	7,d
	jr	z,__MulSNotNeg
	inc	b
	xor	a
	sub	e
	ld	e,a
	sbc	a,a
	sub	d
	ld	d,a
__MulSNotNeg:

I would have to do the same thing for hl and then again at the end when I need to put the bit back so it seems like a lot of extra code...

calc84maniac · « **Reply #12 on:** March 14, 2010, 09:38:51 am »

No need at all. 16-bit * 16-bit -> 16-bit will give the same result for unsigned and signed arithmetic. Problem solved!

Seriously, try multiplying some signed values in your parser and you will get the right results.

Edit:
Scratch that, I just tried it myself. What is your normal multiplication routine?

Edit2:
I just disassembled it, and I think you are only doing an 8-bit * 16-bit multiplication. That could explain the bad outputs.

Galandros · « **Reply #13 on:** March 14, 2010, 10:17:13 am »

I have some ideas but I don't know how well it will be implemented:
There are some shift instructions that preserve the sign bit, for example sra. And sla is other arithmetic shift... Probably this isn't useful or as fast as other methods.
When the multiplication is finished you can set the correct sign based in the inputs.
You can probably use the sign flag to optimize.

neg is equivalent to cpl / inc a. Dunno how this goes into 16-bit pair registers.

calc84maniac · « **Reply #14 on:** March 14, 2010, 12:55:18 pm »

Here is your original multiplication routine:

Code: [Select]

 xor a
 or d
 jr nz,$+3
 ex de,hl
 ld a,l
 ld hl,0
_multloop:
 rra
 jr nc,$+3
 add hl,de
 sla e
 rl d
 or a
 jr nz,_multloop
 ret

Here is my modified signed version, only 8 extra bytes (all in the overhead). It multiplies two signed values, one of which is between -256 and 255.

Code: [Select]

 ld a,d
 rrca
 cp d
 jr nz,$+3
 ex de,hl
 xor a
 inc h
 jr nz,$+3
 sub e
 ld h,a
 ld a,l
 ld l,0
 or a	;Returns if multiplying by 0 or -256, also resets carry flag
 ret z
_multloop:
 rra
 jr nc,$+3
 add hl,de
 sla e
 rl d
 or a
 jr nz,_multloop
 ret

Author Topic: Assembly Programmers - Help Axe Optimize! (Read 154680 times)

Quigibo

Assembly Programmers - Help Axe Optimize!

DJ Omnimaga

Re: Assembly Programmers - Help Axe Optimize!

Galandros

Re: Assembly Programmers - Help Axe Optimize!

Eeems

Re: Assembly Programmers - Help Axe Optimize!

DJ Omnimaga

Re: Assembly Programmers - Help Axe Optimize!

Galandros

Re: Assembly Programmers - Help Axe Optimize!

calc84maniac

Re: Assembly Programmers - Help Axe Optimize!

ztrumpet

Re: Assembly Programmers - Help Axe Optimize!

Quigibo

Re: Assembly Programmers - Help Axe Optimize!

calc84maniac

Re: Assembly Programmers - Help Axe Optimize!

DJ Omnimaga

Re: Assembly Programmers - Help Axe Optimize!

Quigibo

Re: Assembly Programmers - Help Axe Optimize!

calc84maniac

Re: Assembly Programmers - Help Axe Optimize!

Galandros

Re: Assembly Programmers - Help Axe Optimize!

calc84maniac

Re: Assembly Programmers - Help Axe Optimize!