KermMartian wrote:
souvik1997 wrote:
I'm confused about the "bit Bitnumber, a" part. What is the 0 bit?
Consider a binary number 01100101. This is 0x65 in hexadecimal, or 101 in decimal. Bit 0 is the least-significant bit, that is, the bit all the way on the right in the 1s place. Bit 7 is the most-significant bit, that is, the bit all the way on the left in the 128s place.


Oh, now I understand. Thanks! Very Happy
Woot, go us. Smile Notice that proper combinations of bitting and calls lets you do 8-direction movement.
Are there any bcalls or opcodes I should not use to avoid messing up CALCnet?
bcalls: all. opcodes: di (or anything that messes with the cpu speed)
_player1537 wrote:
bcalls: all. opcodes: di (or anything that messes with the cpu speed)
That's an overstatement. Just take a look at the CALCnet Whitepaper or at the Interfacing CALCnet article on the DCS wiki. _vputs and _puts and related routines are known to disable interrupts, so re-enable interrupts after those, but there are few bcalls that you need to outright avoid.
Would this work for a basic movement engine?
A is the x coordinate, and L is the y coordinate

Code:
Start:                             
   push hl
   push af   
   call MoveEng
   ret   
MoveEng:
   ld a,$FE
   out (1),a
   nop
   nop
   in a,(1)
   cp $FE
   call z,Down
   cp $FD
   call z,Left
   cp $FB
   call z,Right
   cp $F7
   call z,Up
   ret   
Down:
   pop af
   pop hl
   dec l
   ret
Up:
   pop af
   pop hl
   inc l
   ret
Left:
   pop af
   pop hl
   dec a
   ret
Right:
   pop af
   pop hl
   inc a
   ret
1) What's with all the nested calls? You're allowed to use jr/jp, you know
2) Calls push onto the stack. Rets pop from the stack. You should (with few exceptions) have an equal number of pushes and pops in any routine that gets called. Your code as written will majorly crash. Smile
Is this better?

Code:
Start:                             ;main routines
   push hl
   push af   
   call MoveEng
   ret   
MoveEng:
   ld a,$FE
   out (1),a
   nop
   nop
   in a,(1)
   cp $FE
   jp z,Down
   cp $FD
   jp z,Left
   cp $FB
   jp z,Right
   cp $F7
   jp z,Up
   pop af
   pop hl
Key_Return:   
   ret   
Down:
   pop af
   pop hl
   dec l
   jp Key_Return
Up:
   pop af
   pop hl
   inc l
   jp Key_Return
Left:
   pop af
   pop hl
   dec a
   jp Key_Return
Right:
   pop af
   pop hl
   inc a
   jp Key_Return
No, you're just hiding the fact that you're still doing crazy stack stuff via your calls. Why not something like this?


Code:
Start:                             ;main routines
   ..code..
   call MoveEng
   ..more code..
   ret   
MoveEng:
   push af
     ld a,$FE
     out (1),a
     nop
     nop
     in a,(1)
     cp $FE
     jr z,Down
     cp $FD
     jr z,Left
     cp $FB
     jr z,Right
     cp $F7
     jr z,Up
     pop af
   ret
Down:
     pop af
   dec l
   ret
Up:
     pop af
   inc l
   ret
Left:
     pop af
   dec a
   ret
Right:
     pop af
   inc a
   ret


It looks like you're under the impression that registers are like variables in TI-BASIC, which is not the case. You definitely don't want to try to keep your X coordinate in a and your Y coordinate in L all the time.
So all I have to do is remove the push/pop hl?
souvik1997 wrote:
So all I have to do is remove the push/pop hl?
No. Notice how I reordered the push af to take place after you called and made sure to pop af before the next return. Also please note my comment that using a/l for your global coordinates will be such a headache.
I see that now. Also, is jr faster than jp?
Quote:
It looks like you're under the impression that registers are like variables in TI-BASIC, which is not the case. You definitely don't want to try to keep your X coordinate in a and your Y coordinate in L all the time.

Where should I store the coordinates?
Jr is two bytes, whereas jp is 3 bytes. Jr, however, can only go forwards or backwards a maximum of 128 bytes in your program, while jp can go anywhere in memory. Try something like this for your coordinates:


Code:
MySafeRAM   .equ   AppBackupScreen+129   ;[cf. GUI Memory Areas]
   ;CALCnet starts putting stuff at $9999. That leaves 295 bytes between AppBackupScreen
   ;and the start of the Cn2.2 stuff. Since the GUI stuff is reserving 129 bytes, that
   ;leaves us with 166 bytes
MySafeRAM2            .equ   $8A3A
XCoord               .equ MySafeRAM ;1 byte
YCoord               .equ XCoord+1 ;1 byte

   ...header...
Start:                             ;main routines
   ..code..
   call MoveEng
   ..more code..
   ret   
MoveEng:
     ld a,$FE
     out (1),a
     nop
     nop
     in a,(1)
     cp $FE
     jr z,Down
     cp $FD
     jr z,Left
     cp $FB
     jr z,Right
     cp $F7
     jr z,Up
     pop af
   ret
Down:
   ld hl,YCoord
   inc (hl)
   ret
Up:
   ld hl,YCoord
   dec (hl)
   ret
Left:
   ld hl,XCoord
   dec (hl)
   ret
Right:
   ld hl,XCoord
   inc (hl)
   ret
Alright, I added that. To display the sprite I would do something like this, right?

Code:
ld a,(XCoord)
ld l,(YCoord)
ld b,8
ld ix,Sprite
call iPutSprite
Close. You can only load into the accumulator ('a') from immediate (numerical) memory locations, so you'd need something like this:


Code:
ld a,(YCoord)
ld l,a
ld a,(XCoord)
ld b,8
ld ix,Sprite
call iPutSprite
or like this
Code:
ld hl,XCoord
ld a,(hl)
inc hl
ld l,(hl)
ld b,8
ld ix,Sprite
call iPutSprite
Ok, thanks for explaining that.
souvik1997 wrote:
Ok, thanks for explaining that.
Do those two pieces of code make sense? Be sure to ask if you run into anything that's confusing. Smile
FWIW, here is my movement and bounds checking code.
Code:
   ld hl,yship ;Used for Down / Up
   ld a,0FEh
   out (1),a
   nop \ nop ;Because KermM told me that my calculator will laugh at me :(
   in a,(1)
   bit 0,a
   jr nz,$+3   ;Down
   inc (hl)   ;--------------------------------
   bit 3,a
   jr nz,$+3   ;Up
   dec (hl)   ;--------------------------------
   ;Y extent checking
   ld a,(hl)
   cp maxY      ;Y too far up
   jr nz,$+3
   inc (hl)
   cp 56      ;Y too far down
   jr nz,$+3
   dec (hl)
   
   in a,(1)
   ld hl,xship ;used for Left / Right
   bit 1,a
   jr nz,$+3   ;Left
   dec (hl)   ;--------------------------------
   bit 2,a
   jr nz,$+3   ;Right
   inc (hl)   ;--------------------------------
   ;X extent checking
   bit 7,(hl)   ;Too far left check
   jr z,$+3
   inc (hl)
   ld a,(hl)   ;Too far right check
   cp maxX + 1
   jr nz,$+3
   dec (hl)
Very nice, although I propose that you forgot an inc hl in between the two main sctions.
I don't think I did, the code seems to work fine. I just pulled it straight from Raven2.asm. I think you didn't see the ld hl,yship in the second main section.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4 ... 26, 27, 28  Next
» View previous topic :: View next topic  
Page 3 of 28
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement