Jump to content

Photo

Do you have any Bank Switching tips?


7 replies to this topic

#1 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,235 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Sep 2, 2010 12:01 PM

Do you have any Bank Switching tips? We have Bank Switching threads like these:

http://www.atariage....32#entry1456132

http://www.atariage....pfhlinepfvline/

Problem is they don't mention any tips about the best place to put your main loop or other things we might need to know. And since graphics are automatically put in the last bank anyway by bB, should I move stuff like the following from the bank that contains the main loop and put it in the last bank:

P0_Up_00
   player0:
   %01011010
   %01100110
   111100
   %01111110
   %11111111
   011000
   011000
   011000
end
   goto Done_J0

P0_Up_01
   player0:
   %01100110
   %01000010
   %10111101
   %01111110
   %11111111
   011000
   011000
   011000
end
   goto Done_J0

P0_Up_02
   player0:
   %01000010
   %11000011
   %10111101
   %01111110
   %11111111
   011000
   011000
   011000
end
   goto Done_J0

P0_Up_03
   player0:
   %11100111
   %11000011
   %10111101
   %01111110
   %11111111
   011000
   011000
   011000
end
   goto Done_J0

Of course, I'd have to change the gotos to include bank info, but would it save any bytes in the bank that contains the main loop by not having code like that in there?

A lot of things about Bank Switching have been explained, but it still seems a little fuzzy around the edges.

Edited by Random Terrain, Thu Sep 2, 2010 12:02 PM.


#2 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,851 posts

Posted Thu Sep 2, 2010 1:04 PM

Don't forget Batari has some feedback on using functions in a multi-bank game here:
http://www.atariage....ice-with-banks/

I'm thinking about working around the images-in-last-bank by using pfline and pfpixel commands in a different bank. I'm not sure if that's a tip or not.

Edited by theloon, Thu Sep 2, 2010 1:06 PM.


#3 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,235 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Sep 2, 2010 1:06 PM

Don't forget Batari has some feedback on using functions in a multi-bank game here:
http://www.atariage....ice-with-banks/

Thanks.

#4 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,704 posts
  • Bitnik
  • Location:Canada

Posted Thu Sep 2, 2010 3:07 PM

... And since graphics are automatically put in the last bank anyway by bB, should I move stuff like the following from the bank that contains the main loop and put it in the last bank...

No.

The only thing a bB player0x: statement does is set a pointer to that particular block of graphics data. Your program doesn't actually need to be in the last bank when that happens.

The best tip I can give is a general one - try to organise your code and data so the number of bank switches are minimised - because bank switching is very costly cyclewise.

#5 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,235 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Sep 2, 2010 3:15 PM

... And since graphics are automatically put in the last bank anyway by bB, should I move stuff like the following from the bank that contains the main loop and put it in the last bank...

No.

The only thing a bB player0x: statement does is set a pointer to that particular block of graphics data. Your program doesn't actually need to be in the last bank when that happens.

The best tip I can give is a general one - try to organise your code and data so the number of bank switches are minimised - because bank switching is very costly cyclewise.

Thanks. That will save some time. I won't have to convert a boatload of gotos.

#6 freshbrood OFFLINE  

freshbrood

    Star Raider

  • 56 posts

Posted Sat Feb 18, 2017 5:22 PM

No.

The only thing a bB player0x: statement does is set a pointer to that particular block of graphics data. Your program doesn't actually need to be in the last bank when that happens.

The best tip I can give is a general one - try to organise your code and data so the number of bank switches are minimised - because bank switching is very costly cyclewise.

 

 

When you say "very costly cyclewise", does this mean it will tend to slowdown the speed of the screen updates?

 

Or add a significant amount of memory to the program?

 

And if the answer is BOTH, which impacts the program MORE? Eating up SPEED, or eating up ROM?


Edited by freshbrood, Sat Feb 18, 2017 5:23 PM.


#7 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,704 posts
  • Bitnik
  • Location:Canada

Posted Sat Feb 18, 2017 6:04 PM

When you say "very costly cyclewise", does this mean it will tend to slowdown the speed of the screen updates?

Or add a significant amount of memory to the program?

And if the answer is BOTH, which impacts the program MORE? Eating up SPEED, or eating up ROM?


The answer is both, with "very costly cyclewise" being a relative thing. A few bankswitches isn't going to be noticed. But if you break out each logical unit of code into a subroutine and use bankswitching to reach them, you'll use too many cycles in each frame, and eat up your ROM.

To answer your implicit question about cycles, if you use too many cycles between drawscreen commands your game will draw too many lines per frame. This causes problems with the display, in the form of bouncing and rolling.

As for "which impacts the program MORE", these are 2 entirely different kinds of resources - cycles vs. bytes of ROM - so a "MORE" comparison doesn't makes sense. If your game is tight for ROM, you're going to care about every byte of ROM wasted. If your game is tight for cycles, you'll care about saving those.

Generally speaking, on a system as tight for resources as the 2600 is, you want to be as frugal as possible with every resource. Spend those resources for good effects and good game design, but don't waste them on internal code flow. The player doesn't benefit from that.

#8 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,851 posts

Posted Sun Feb 19, 2017 5:05 PM

I think the best advice on bank switching is: don't program for bank switching. What I mean is use every 4k like it was a separate game. If you have, say, 2 different game modes separate them by bank.

 

Do not try to micro manage and shift around sub routines and code. It's slower, buggier and harder to manage and understand in the end.  

Here is one typical layout for my 16k games:

 

BANK 1 - bB template music data and music playback engine. Title screen handling code.

BANK 2 - Data for the title screen kernel. Generic user routines such as high score tallying.  "Game over" or "You Win" display handling.

BANK 3 - Entire game engine or one entire game mode

BANK 4 - Used up by mystery bB stuff. Sometimes generic user routines that aren't called often.

 

Larger games follow the same pattern - just keeping BANK 3 on down into individual game modes and the very last bank scarcely used due to the mystery bB stuff. Yes, I know it really isn't a mystery. I just prefer to not rely on the last bank as much.

 

Why did I choose bank 1 for music and bank 2 for title screen data?  Over the years I've noticed less frustrating, weird breakage this way.  You also don't want to jump really far between banks.  Not that it isn't possible or properly bug tested by RevEng and Batari.  I've just had mystery issues that happen to coincide with code spread between banks - say, code in bank 2 trying to call stuff from bank 6.  This is just my personal experience with not much to back it up.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users