Random questions about bankswitching

[+Random Terrain]

Now that I have tried bankswitching, it's kind of a pain to convert a 4k game. Code has to be rearranged and some gotos/gosubs will have to be told to jump to other banks. I'd rather just use bankswitching from the start so I don't have to rearrange and edit code.

 

Question Set #1

 

If I would ever make a game that is good enough to deserve its own cartridge, is there a problem going as high as 32k? Does it cost too much if even if you don't use Superchip RAM?

 

 

 

Question Set #2

 

So what do you think? How high should you go? Instead of starting at 8k or 16k, should you just start at 32k and stop worrying about which size is best? Fill up those banks with as many goodies as you can and give people all of the variations and AI you can stuff in there?

 

 

Speaking of bankswitching, did I read this correctly:

 

http://www.atariage.com/forums/index.php?s...p;#entry1456132

Additionally, batari Basic needs to store most of the graphics data in the last bank, so it can access the graphics data while executing its display kernel. Even if you put your "player0:" or "player1:" graphics statements in one of the other banks, the actual graphics data will be stored in the last bank anyway.

Question Set #3

 

So we have less than 4k for graphics, no matter what? And if most graphics data is stored there, what kind of graphics data is not stuffed in there?

 

 

 

Thanks.

[supercat]

The price for a 32K game is the same as the price for a 16K game or a "normal" 8K game. Toyshop Trouble used a special cheaper 8K cart design, but the bank switching method it uses is incompatible with other games.

 

Stella's Stocking used a 64K design which was cheaper than the normal 8/16/32K cart, but it's incompatible with anything else.

 

I think 16K is probably a good target size. It's consistent with many of the better games from back in the day, but it allows room to grow if things don't fit. If you target 32K and your code doesn't fit, you're sorta stuck.

 

As for putting all the graphics in one bank, it might be necessary to have multiple banks for graphics if only one bank's worth of graphics will ever be used in a single frame. This would likely require duplicating a lot of graphics data between banks, limiting the usefulness of the ability.

Edited October 14, 2008 by supercat

[+Random Terrain]

Thanks. Then I'll start with 16k. Maybe that's all I'll need anyway since the major part of any program I've played around with so far has fit within the 4k limit. It's the extra junk that takes up so much room.

[SeaGtGruff]

Speaking of bankswitching, did I read this correctly:

 

http://www.atariage.com/forums/index.php?s...p;#entry1456132

Additionally, batari Basic needs to store most of the graphics data in the last bank, so it can access the graphics data while executing its display kernel. Even if you put your "player0:" or "player1:" graphics statements in one of the other banks, the actual graphics data will be stored in the last bank anyway.

Question Set #3

 

So we have less than 4k for graphics, no matter what? And if most graphics data is stored there, what kind of graphics data is not stuffed in there?

Graphics that are loaded from RAM can be defined in any bank, because RAM is accessible from any bank. For Superchip and non-Superchip bankswitching of the standard kernel, the playfield is loaded from RAM, so the playfield statements can be in any bank.

 

As far as I know, graphics that are loaded from ROM must be stored in the same bank as the kernel, because the kernel needs to be able to load the graphics without having to bankswitch while the screen is being drawn. That means the player graphics must be stored in the last bank, where the kernel is. You can still use player0 and player1 statements in the other banks, because the pointers to the player graphics are stored in RAM-- but the actual data will be stored in the last bank.

 

One way around this is to relocate the player graphics to RAM. If you're using two players, and each one is 8 lines tall, that means you'll need 16 bytes of RAM for the players. In most cases, that probably means you'll need to use the Superchip option, which puts the playfield in Superchip RAM and gives you more zero-page RAM for other things, such as the players. But relocating the player graphics to RAM means you can't use the player0 and player1 statements, because they store the player data in ROM, so you'll need to store the player shapes in data tables of your own. Plus, you'll need to copy the shape data from ROM to RAM, which will use up some of your time cycles. Still, you won't need to do that during each loop, just whenever you want to change the player shapes.

 

Michael

[+Random Terrain]

Thanks for the info.

[jrok]

Well, I'm a total newbie but the way I've been approaching Atari design so far is to start out with all the bells and whistles (32kSC bankswitched) see how much memory is actually being used to do the most important things I want the game to do, and then pare back on the code and the number of banks used. So far I've been keeping all my routines in 4 banks and haven't even come close to filling them up yet, so I'm hoping I will end up with a 16K game.

[+Random Terrain]

Well, I'm a total newbie but the way I've been approaching Atari design so far is to start out with all the bells and whistles (32kSC bankswitched) see how much memory is actually being used to do the most important things I want the game to do, and then pare back on the code and the number of banks used. So far I've been keeping all my routines in 4 banks and haven't even come close to filling them up yet, so I'm hoping I will end up with a 16K game.

Are you having any trouble using Superchip RAM? Is it less complicated to use than it looks?

 

About filling up banks, I can do that without blinking. I'm a master of bloated code. Right now I'm working on a new 'random' maze and since I'm not good at dreaming up some kind of amazing algorithm that can create a maze using only a few lines of code, I'm forcing the maze into existence by splitting the maze up into three parts (7 random pieces each) and making sure all of the pieces fit. This bloated maze code embarrassingly takes up a bank and a half. If anyone saw the code, there would be instant, involuntary finger pointing and laughing, but at least the code works. I'm glad we can go up to 32k because I'll probably need it.

[jrok]

Are you having any trouble using Superchip RAM? Is it less complicated to use than it looks?

 

You know, I wasn't having trouble until I started to incorporate bankswitching. I had myriad problems trying to use batari's

included bankswitching routine, but then I tried using SeaGtGruff's superchipheader_SC.asm and most of the problems disapeared. The only trouble that remains is that I get compiler errors when I try to use negative fixed-point variables and

bankswitching, but I'm not smart enough to know what's going on there. I shelved it for now to hopefully figure it out at a later date.

 

About filling up banks, I can do that without blinking. I'm a master of bloated code.

 

That's the main reason I haven't posted much of my bB source yet. I just know it's just sloppy work, and its probably due to years of grinding out fast and dirty projects with IDEs like Flash, where your code can be a total pig-sty and still compile. Actually, one of the reasons I decided to take up this hobby is to force myself to be a more efficient programmer and hopefully develop better work habits... but so far I'm still a bloody hack.

[+Random Terrain]

Thanks, so it's probably a good idea for me to leave Superchip RAM alone for now. I'll keep it nice and simple at this time and maybe Superchip RAM will become a little easier to use the next time bB is updated.