Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Jerros on July 12, 2010, 09:22:44 am
-
I'm using the routine from the asm-in-28 tut, though the sprites display blurry and at the wrong coordinates.
The part of the "ClipSprXOR" label should be OK, since it's just copy/pasted from the tut, and it worked 100% fine before I turned the programm into an APP.
The routine I'm using to display sprites in an APP is:
(used random location and sprite, for exemple's sake)
xpos .equ AppBackUpScreen ; To prevent SMC
ypos .equ xpos+1 ; Tried +2 and even +9, don't know wether that makes a difference
clip_mask .equ ypos+1 ; or not, but just to be sure. It didn't work though...
LD A, 38 ; X position to display
LD (xpos), A
LD A, 54 ; Y position do display
LD (ypos), A
LD B, 9 ; Length of Sprite in Y direction
LD DE, (ypos)
LD IX, Sprite ; Label of sprite
CALL showsprite
Showsprite: ; Show Sprite (XOR)
CALL ClipSprXOR
b_call _GrBufCpy
ret
ClipSprXOR: ; Show Sprite XOR
LD A, %11111111
LD (clip_mask), A
LD A, E
OR A
JP M, ClipTop
SUB 64
RET NC
NEG
CP B
JR NC, VertClipDone
LD B, A
JR VertClipDone
ClipTop:
LD A, B
NEG
SUB E
RET NC
PUSH AF
ADD A, B
LD E, 0
LD B, E
LD C, A
ADD IX, BC
POP AF
NEG
LD B, A
VertClipDone:
LD C, 0
LD A, D
CP -7
JR NC, ClipLeft
CP 96
RET NC
CP 89
JR C, HorizClipDone
ClipRight:
AND 7
LD C, A
LD A, %11111111
FindRightMask:
ADD A, A
DEC C
JR NZ, FindRightMask
LD (clip_mask), A
LD A, D
JR HorizClipDone
ClipLeft:
AND 7
LD C, A
LD A, %11111111
FindLeftMask:
ADD A, A
DEC C
JR NZ, FindLeftMask
CPL
LD (clip_mask), A
LD A, D
ADD A, 96
LD C, 12
HorizClipDone:
LD H, 0
LD D, H
LD L, E
ADD HL, HL
ADD HL, DE
ADD HL, HL
ADD HL, HL
LD E, A
SRL E
SRL E
SRL E
ADD HL, DE
LD DE, PlotSScreen
ADD HL, DE
LD D, 0
LD E, C
SBC HL, DE
AND 7
JR Z, _Aligned
LD C, A
LD DE, 11
_RowLoop:
PUSH BC
LD B, C
LD A, (clip_mask)
AND (IX)
LD C, 0
_ShiftLoop:
SRL A
RR C
DJNZ _ShiftLoop
XOR (HL)
LD (HL), A
INC HL
LD A, C
XOR (HL)
LD (HL), A
ADD HL, DE
INC IX
POP BC
DJNZ _RowLoop
RET
_Aligned:
LD DE, 12
_PutLoop:
LD A, (IX)
XOR (HL)
LD (HL), A
INC IX
ADD HL, DE
DJNZ _PutLoop
RET
Sprite:
.DB %00011000
.DB %01111110
.DB %01111110
.DB %11100111
.DB %11100111
.DB %01111110
.DB %01111110
.DB %00011000
.DB %00011000
Doesn't work properly.
Where's my mistake?
Or is this just a wrong way of trying to display the sprites?
Thanks for any help!
-
I didn't read very far before I found an error. You need to switch xpos and ypos around. Where you have ld de, (yPos). e = y pos, but d = clip mask. Simple little fix.
-
Dang, I just realize I'veposted in the wrong place on the forums... :-\ Sorry!
About your reply, It has always worked before, before I turned it into an App, or is it failing now because of the .equ's at the start?
I should have mentioned that I'm a biggg newby at ASM...
Where do I need to switch the two around?
In the defining part at the start?
If you can please explain just a little what's wrong, then I perhaps understand it and can prevent similar mistakes in the future.
Is there an order in the defining part if I want to define lots of things?
Thanks alot for your reply, I'll look into it and hope I can fix it!
-
The topic seems to be in the right spot ??? (ASM programming)
Or do you mean you wanted to post it as a reply to another topic?
-
I really need glasses...
It is indeed at the place I meant it to be, sorry for any confusion caused.
-
Don't worry about it ^^
(On MaxCoderz forums, at first, the new topic button was called "Post" and the reply button was called "Reply". Many people got confused and started new topics as reply to other topics ;D)
-
Sorry for using dutch here but I think it is the most efficient way to help the topic starter out.
De onderstaande code is verkeerd
xpos .equ AppBackUpScreen ; To prevent SMC
ypos .equ xpos+1 ; Tried +2 and even +9, don't know wether that makes a difference
clip_mask .equ ypos+1
...
...
LD DE, (ypos)
waarom? omdat ypos = AppBackUpScreen +1 en omdat clip_mask = AppBackUpScreen+2. Aangezien DE een 16 bits register is komen zowel ypos als clip_mask in DE te staan. Dit kan er voor gaan zorgen (en dat doet het waarschijnlijk ook) dat de routine verderop niet meer werkt.
laten we even een voorbeeldje doornemen. stel:
xpos = 38
ypos = 54
clip_mask = 255
dat is hetzelfde als:
AppBackUpScreen = 68
AppBackUpScreen+1 = 54
AppBackUpScreen+2 = 255
door het commando
LD DE, (ypos)
doe je dit
LD DE, (AppBackUpScreen+1 & AppBackUpScreen+2) ;want DE wil twee bytes, niet een. Dus hij laadt nu wat in AppBackUpScreen+1 staat in E en wat in AppbackUpScreen+2 staat in D
dat betekent dat er dus in DE dit staat:
DE = 255+54= 309 ;decimaal
en dat is geen geldige ypositie op het scherm. Dit zorgt ervoor dat andere routines dus crashen of een overflow te verduren krijgen. Wat werkt dan wel?
uit mijn hoofd doe zou ik dit doen:
ypos .equ AppBackUpScreen
xpos .equ AppBackUpScreen+1
clip_mask .equ AppBackUpScreen+2
LD A, 38
LD (xpos), A
LD A, 54 ; Y position do display
LD (ypos), A
LD B, 9 ; Length of Sprite in Y direction
LD D, (xpos) ;ik weet niet of D =ypos of E=ypos maar je kan het altijd nog omdraaien
LD E, (ypos)
LD IX, Sprite ; Label of sprite
CALL showsprite
ik weet dus niet of dit werkt maar in ieder geval moet het probleem wel duidelijk zijn nu...
-
Just as an head up:
I feel that non-english posts made outside the dutch section of the forums (http://www.omnimaga.org/index.php?board=102.0 ) should include an english translation of them, especially help-related posts, so english users can understand, too (the help may be useful to others, too)
-
English (http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://www.omnimaga.org/index.php%3Ftopic%3D3744.msg47862;topicseen%23new&sl=nl&tl=en).
The reason you needed to switch them is because z80 is little endian. This means that the least significant byte comes first in memory. So say for instance
ld hl, $1234
ld (appBackUpScreen), hl
$1234 is stored in memory as 34 12. So to bring it back you would just ld hl, (appBackUpScreen), which would put 34 in l and 12 in h.
You want to have the same effect when you take out your coordinates. So you have to store y first because e is the least significant byte in de. That way, when you pull them back out, e gets the y pos and d gets the next byte in memory which is the x pos.
-
uit mijn hoofd doe zou ik dit doen:
ypos .equ AppBackUpScreen
xpos .equ AppBackUpScreen+1
clip_mask .equ AppBackUpScreen+2
LD A, 38
LD (xpos), A
LD A, 54 ; Y position do display
LD (ypos), A
LD B, 9 ; Length of Sprite in Y direction
LD D, (xpos) ;ik weet niet of D =ypos of E=ypos maar je kan het altijd nog omdraaien
LD E, (ypos)
LD IX, Sprite ; Label of sprite
CALL showsprite
ik weet dus niet of dit werkt maar in ieder geval moet het probleem wel duidelijk zijn nu...
Yay!
All I had to do was switch around xpos and ypos in the .equ part, didn't had to change anything else.
this is an example of something so small that I would never had found it without your help.
Oh, and doing
LD D, (xpos)
LD E, (ypos)
can't, since I just load Ypos into DE, not Xpos. (check the first post)
And I don't think its nessecary to do
ypos .equ AppBackUpScreen
xpos .equ AppBackUpScreen+1
clip_mask .equ AppBackUpScreen+2 ; Dont think the +2 is needed, because I justdo this:
ypos .equ AppBackUpScreen
xpos .equ ypos+1 ;I just do the previous statement +1, that doesn't result in errors (I think), because
clip_mask .equ xpos+1 ;I've even done +9 while the script wasnty working, and it still kept failing
Thanks alot!
This was one of the last hurdles to complete the programm, just 1 more thing to tacke but I'll ask (if needed only ofcource) that in another topic. (It's about permanently saving hi-scores/variables ect. in the archive in an APP)
Really, big thanks for all the help here. :)
-
Your best option for highscores in an APP is to save to an APPVAR. You can find good information on how to do that in the 83+ SDK: http://education.ti.com/downloads/guidebooks/sdk/83p/sdk83pguide.pdf
-
In case you want a more technical explanation why you can't use bcalls that use data in the app, here it is. The entire readable memory is divided into 4 sectors each 16KB in size. There are many pages, but they have to swapped around and replace an existing page to be used in that sector. Apps execute in the sector which is from $4000 to $7FFF as I'm sure you are aware. It is write protected, but permits reading and executing. The 1st sector is OS stuff and the last 2 are ram, programs, and the sp stack in normal circumstances.
Now here is where it gets interesting. The operating system is much larger than just that one page, so when you make a call to something like _PutS or _DispImage the calculator has to swap in the page of the OS that has that routine in it. And guess which sector it uses? Its the one at $4000 where the app is. That means your page is swapped out so the OS can call it's routine. Now when it tries to read the data you passed to it, its just going to be some random junk on that page and not the actual data you intended since your page isn't at that location anymore! That's why you either copy the data to ram or write your own routines to use it.