It is currently Mon Nov 20, 2017 2:46 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1386 posts ]  Go to page Previous  1 ... 28, 29, 30, 31, 32, 33, 34 ... 93  Next
Author Message
 Post subject:
PostPosted: Fri Feb 17, 2012 6:59 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
You have to pay attention not to push more bytes than you have allocated for the stack, but that's basically it. Most people just use the whole page ($0100-$01FF) for it, and filling 256 bytes with temporary data isn't easy, so you're probably safe.

The only events that use the stack non-explicitly are interrupts and jumps to subroutines. When you JSR to a subroutine, the current PC (the program counter, an internal register that points to the instruction being executed) is backed up to the stack, so that you can return to that point of the program with RTS. Interrupts also save the PC, as well as the processor status, so that the CPU can resume its work later (after an RTI), like the interrupt never happened.

Those things don't get in the way of using the stack normally (PHA, PLA, PHP and PLP), since even if an interrupt happens in the middle of you using the stack, whatever is put there will be removed when the returning from the interrupt, so the stack will be exactly like it was before the interrupt.

It's also pretty safe to manipulate the middle of the stack using the X register, since only the top of it will be modified in case of interrupts.

What can cause problems is an interrupt firing when you are directly manipulating the stack pointer (through TSX and TXS)... If S is not pointing to the top of the stack, parts of it might get corrupted. You probably want to avoid this kind of stack manipulation.

What you want to do (push 4 values for using later) is perfectly safe, you just have to remember to remove everything you put on the stack. I for example have made the mistake of putting some values in the stack, and then some logic decisions made the program not need those values anymore, and I just forgot to take them off the stack. Over time, the forgotten values accumulated and caused a stack overflow and the program crashed.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 19, 2012 12:16 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
tokumaru, thank you so much!!! :D Your stack explanation here brought back the feeling that you could make a great author! :) I would be excited to buy your NES assembly-guide-book-type-thing. :mrgreen: And it would be nice to share with others. :)

Kasumi, I owe you a response... and it is coming, I promise. Hope you are doing well. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 19, 2012 12:44 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
unregistered wrote:
I would be excited to buy your NES assembly-guide-book-type-thing.

Hell no, I'm a terrible teacher! :roll:


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 20, 2012 2:47 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
If I have an accumulator value id like to keep... for a little while; would it be dangerous to leave it in the accumulator for about 10-12 cycles? Is it safe, like the stack is, from interrupts and subroutines? This might be a sub-par question. :oops:


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 20, 2012 3:03 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19233
Location: NE Indiana, USA (NTSC)
What is in the accumulator will stay in the accumulator until power-off unless another instruction changes it. Interrupt handlers are supposed to always save and restore all registers that they use, but any other subroutine might preserve the accumulator, or it might overwrite it. When you make your subroutine, be sure to add a comment stating what registers it overwrites. For example, a controller reading subroutine might have a comment at the top that it "trashes A and X; preserves Y".


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 20, 2012 3:10 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
Wow that's really good. :D Thanks tepples!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 01, 2012 3:28 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
Could my code here be done in an easier way?


Code:
    asl a ;checks and saves upper left tile
    bmi +
    lda #$00
    jmp ++n
  + lda #$01
++n sta upleft
   
    asl a ;checks and saves upper right tile
    bmi +
    lda #$00
    jmp ++n
  + lda #$01
++n sta upright
   
    asl a ;checks and saves lower left tile
    bmi +
    lda #$00
    jmp ++n
  + lda #$01
++n sta loleft

    asl a ;checks and saves lower right tile
    bmi +
    lda #$00
    jmp ++n
  + lda #$01
++n sta loright


There must be an easier way to transfer a bit to the accumulator... please tell me that. :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 01, 2012 3:54 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
rol a:rol a:and #1 ?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 01, 2012 4:13 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
aaaaaaah!! Thank you Shiru! :D ...AND #1!!!!!!!!!!!!!!!!!!!!!!!!!! YEAY!!


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 09, 2012 5:07 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
Now it has come to using oddRow and evenRow... I have to ask this question... someone will have an answer. The first row of tiles of the screen is not the first scanline, but the first eight scanlines and so this does not concern scanlines. ...I think. :oops: Should I start creating the screen with oddRow or evenRow? Is that top line up there line 0 - even - OR line 1 - odd?


Last edited by unregistered on Fri Mar 09, 2012 7:55 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 09, 2012 5:40 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
No matter how many times I read I really can't understand the question... for what purpose would you be using these oddRow and evenRow variables you speak of?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 09, 2012 7:41 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
tokumaru wrote:
... for what purpose would you be using these oddRow and evenRow variables you speak of?


In my code idea there are two rows each 32 bytes. Then there is the screenArray; 240 bytes. I'm trying to fill both rows with values for collision... then add them both to screenArray... then clear oddRow and evenRow and fill them both again with new values for collision... then add them both to screenArray...etc.

edit: ok, I found the first mention of my plan on page 29. That was in December but I'm still learning and building; getting better. :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 09, 2012 10:20 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1035
I'm still confused.

oddRow and evenRow have to be RAM, otherwise you wouldn't be mentioning putting new values in them.

This being true, why do you want to put anything in them only to move them someplace else? Just put the values you will load (inevitably from ROM) directly into ScreenArray. Is there any reason for that first step of putting the values into oddRow and evenRow? What do you plan to do with ScreenArray? You're putting things here to do what with them? Load a value from them to check collision, or store them to the PPU? I've only got part of your plan.

The response I made to the post you linked made the assumption that the row labels were data in ROM. Your plan seems to be different, so help me understand all the steps.

Quote:
Should I start creating the screen with oddRow or evenRow? Is that top line up there line 0 - even - OR line 1 - odd?

I don't know. Isn't it your data format? You define what's stored, where it's stored, how it's stored, what it's called and what it does.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 10, 2012 7:15 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
I'm as confused as Kasumi is...

The way you are asking makes it seem like there's only 1 way to do things, and that this way always uses these variables you mentioned. But actually, collision detection can be done in a thousand different ways, and we have given you some ideas to help shape the solution you'll be using in your game.

But since it's your game, everything is ultimately your choice and your design. Particularly, I don't remember everything we talked here, and I don't know exactly what solution you used, so if you want very specific help with your implementation you'll need to give us more details about how you're doing things.

All this data moving seems unnecessary to me as well, there must be a way to decode the maps from ROM into ScreenArray directly. For us to discuss that, you have to tell us how the maps and collision info are stored in the ROM, and what you want ScreenArray to contain.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 12, 2012 2:35 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
Kasumi wrote:
why do you want to put anything in them only to move them someplace else? Just put the values you will load (inevitably from ROM) directly into ScreenArray. Is there any reason for that first step of putting the values into oddRow and evenRow?

I thought loading two rows of stuff would be hard, but still possible for me to do. And I thought that once I completed that it would be easy to make a loop to run it again. Now, I see your point! :) It would be much faster if I wrote to ScreenArray directly.
Kasumi wrote:
What do you plan to do with ScreenArray? You're putting things here to do what with them? Load a value from them to check collision, or store them to the PPU? I've only got part of your plan.

I plan to use ScreenArray to check collision and to set the PPU. I'm going to try writing the values directly into ScreenArray. :)

tokumaru wrote:
The way you are asking makes it seem like there's only 1 way to do things, and that this way always uses these variables you mentioned. But actually, collision detection can be done in a thousand different ways, and we have given you some ideas to help shape the solution you'll be using in your game.

Yes, ok, then I need to create my way... just one of the thousand.

Thanks Kasumi and tokumaru! :D


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1386 posts ]  Go to page Previous  1 ... 28, 29, 30, 31, 32, 33, 34 ... 93  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group