I want to better understand Bank Switching

jorotroid

Member
Some time ago, I wrote a Macro to change the values of the player's bounding box. Currently I am trying to write an input script that takes action base on the type of tiles near the player. While doing this, I needed to access the player's bounding box values to find the appropriate points to check for tile types. But by LDAing ObjectBboxLeft,y and ObjectWidth,y I only ever got back a value of 0. I then checked and found out my Macro to change the bounding box was actually doing nothing. After some sleuthing, I found that the bounding box data is stored in Bank 1C. I tried bank switching by setting Y to #$1C and calling JSR bankswitchY as it appears to be use elsewhere in the code, then after the code to get the values I need runs, setting the bank back to whatever it was before. Running my games with these changes will cause the game to freeze which seems to imply that either I am calling for a bank switch incorrectly or bank switches can't happen during an input script. Can anyone offer me any wisdom?

I can think of a few alternate ways I can get my desired effects, but bank switching during an input script seems like it would be the most ideal answer.
 

dale_coop

Moderator
Staff member
What exactly is your code? You did something like this?
Code:
	TYA
	STA tempy
	LDA currentBank
	STA prevBank
	LDY #$1C
	JSR bankswitchY
	LDY tempy

	;; HERE YOUR CODE 

	LDY prevBank
	JSR bankswitchY
	LDY tempy
 

jorotroid

Member
Similar.

Code:
LDA prevBank
PHA
LDA currentBank
STA prevBank
LDY #$1C
JSR bankswitchY
	
;; MY CODE HERE
	
LDY prevBank
JSR bankswitchY
PLA
STA prevBank

I didn't save Y to a temp variable because mainly I would need it for getting holding the object type and that happens in the normal collision detection routines. Additionally, I push the prevBank onto the stack in case that value is needed after the input scripts are done.
 

jorotroid

Member
Here is the code for the bounding box resizing for better context.

Code:
MACRO NewBoundingBoxHeight arg0
	LDA prevBank
	PHA
	LDA currentBank
	STA prevBank
	LDY #$1C
	JSR bankswitchY
	
	LDY Object_type,x
	LDA ObjectHeight,y
	LDA arg0
	STA ObjectHeight,y
	
	LDY prevBank
	JSR bankswitchY
	PLA
	STA prevBank
 

dale_coop

Moderator
Staff member
My knowledge is still limited... So I might ask completly idiot questions here but:
But maybe you can't call "STA ObjectHeight,y" because ObjectHeight is directly from a lut table?
Would be better if we could have LDA / STA Object_Height,x and use it in the collision scripts?
 

jorotroid

Member
I think in a recent post I made I said that stuff in a lut table is protected, but I think I was wrong. I'm now thinking that they were "protected" in the sense that they were in a lut table that was in a different bank than the one currently loaded. My knowledge is limited, too. I still have a lot to learn, too, so I don't think it's an idiotic question. I am making a lot of assumptions as I hack my way through the code.

And yeah, it would be nice to have Object_Height,x and etc, but I am doing my best to not add variables to the ObjectBytesRam as adding one variable there is really adding 12 variabes (one for each object). I could create User variables to hold just the player's bounding box data, but then I would have to go through the collision scripts to update them to use the the User variable if it is object 0 and do things as it normally would for all other objects. It might might be the way I ultimately need to go, but I'm hoping to find another way.
 

dale_coop

Moderator
Staff member
Yeah we are all learning here. It's fun!
More I use/read the code and more I am pretty sure that lut tables just can be read.
Understand your point of view for the Object_height,x
Hope it will be implemented in the next version, it will be so easier.

Yeah, a user variable may be a solution.
 

jorotroid

Member
dale_coop said:
Yeah we are all learning here. It's fun!

Most definitely. I am having a blast! Thanks for your input, coop.

For now, I can sweep most of this under the rug for what I have planned for my first demo, so I'll worry about it after I've released my demo.
 

dale_coop

Moderator
Staff member
jorotroid said:
For now, I can sweep most of this under the rug for what I have planned for my first demo, so I'll worry about it after I've released my demo.

Lol, yeah ;) I did same for a lot of my codes... until NESMaker is "complete" (=no more huge modifications in the codes/structures).
 

jorotroid

Member
I just had a thought that I wanted to write down related to this so that I can either try it out later or somebody can tell me if I'm crazy. Ok. With the NES as I understand it, it has two banks that it can see at one time. One set up to never change, (the static bank) and one set up to swap in and out with other banks (the dynamic bank). So with what I brought up in this thread, could I set up an island of code in the static bank to handle a bank switch to the desired in the dynamic bank that then switches and returns to the original bank? Basically, in the dynamic bank I would store which bank I want to switch to and the addresses of the information I want to modify or retrieve from the new bank. Then I would JSR to the static bank, take or modify the information, then bankswitch back to the original bank I was using and use RTS to continue the code as normal. I think that could work. The one thing I'm not sure how to do is how to store the address of the desired information to retrieve/modify. But if all I am using this just to resize the player's bounding box, then I don't really need to make this so general by storing the address before hand. I'll give it a shot when I'm finished with what I am currently working on (probably in week at the rate I'm going) unless anyone can point out an egregious misunderstanding I have demonstrated about how this all works.
 
Top Bottom