Multicart: Ants/Star Box

[+atari2600land]

Here's my very first multicart game, and perhaps the first one in batari Basic history? Press reset for Ants and select for Star Box at the main screen. I just wanted you all to see this.

To start Ants, press fire. To return to main screen after the game is over, press fire

To start Star Box, press reset at Star Box title screen. To return to main screen after the game is over, press fire.

multicart.bas.bin

Edited July 23, 2006 by atari2600land

[SeaGtGruff]

Here's my very first multicart game, and perhaps the first one in batari Basic history?

I like the idea of a bB multicart, but it would be nice if you could a startup menu, and let the player pick the game from the menu. Also, if you use bankswitching, you could include more games in your multicart. If you need assistance with either or both of those things, I'd be happy to help.

 

Michael Rideout

[+atari2600land]

A startup menu would be nice. I don't even know what bankswitching is, let alone know how to do it. I could include more games in my cart if all of them together + startup screen is less than 4k, right? I would know how to spell the game titles if Batari Basic would let me go more than 8 bytes, for example, why can't I do this:

 

player0:

%111011101110111

 

I guess what I'm asking is how do people make sprites more than 8 pixels long in Batari Basic, if possible? And, if you've got the time, please help me do a better job with the startup menu. Here's the .bas file

multicart.bas

Edited July 23, 2006 by atari2600land

[SeaGtGruff]

A startup menu would be nice. I don't even know what bankswitching is, let alone know how to do it.

Bankswitching is a way to get larger games on the Atari. The Atari 2600 can "see" only 4K of game ROM, but if you have a way to switch that 4K ROM for a different 4K ROM while the game is playing, then you can make games that are 8K, 12K, 16K, or even larger.

 

There are several different bankswitching methods that have been created for the Atari 2600, but we can divide them up into three general categories:

 

(1) Methods that "see" the entire 4K ROM area as one bank, and switch between different 4K banks.

 

(2) Methods that divide the 4K ROM area into two or more smaller banks-- i.e., two 2K banks, or four 1K banks-- and then switch one or more of these 2K or 1K banks for other 2K or 1K banks.

 

(3) Methods that use one or the other of the above approaches, but also add additional RAM.

 

Last year I was able to modify bB 0.35 to allow the use of M-Network's "E7" method, which is a combination of (2) and (3)-- it divides the 4K ROM area into two 2K banks, and also adds 2K of extra RAM. This year I adapted this to bB 0.99, so I'm able to use E7 bankswitching for my Sudoku game.

 

For bB 0.99, batari added the ability to use Atari's bankswitching methods, which use approach (1)-- the entire 4K ROM area is one bank, and you can switch between different banks to get games that are 8K, 16K, or 32K. Furthermore, Atari's bankswitching methods can use an additional 128 bytes of RAM, so if you program your bB games to use Atari bankswitching, you can use that extra 128 bytes of RAM if you want! All you have to do is tell the emulator that you're using the version that has the extra RAM. And if you want to create actual cartridges, you can buy the 8K, 16K, or 32K boards from AtariAge, and I believe you can buy the 128-byte RAM chips from CPUWIZ.

 

Anyway, using Atari bankswitching with your bB 0.99 games is very easy. I'll convert your multicart to 8K bankswitching to show you how it's done.

 

I could include more games in my cart if all of them together + startup screen is less than 4k, right? I would know how to spell the game titles if Batari Basic would let me go more than 8 bytes, for example, why can't I do this:

 

player0:

%111011101110111

 

I guess what I'm asking is how do people make sprites more than 8 pixels long in Batari Basic, if possible? And, if you've got the time, please help me do a better job with the startup menu. Here's the .bas file

You can use only 8 bits per player, but if you display three close copies of each player, and position them just right, and use the video delay mode, then you can just barely change the player data fast enough to get six different player shapes that are side-by-side, which for all practical purposes gives you a 48-bit wide player. That's how most games get a game title, and is also the same method used to get the 6-digit score display.

 

batari BASIC uses canned kernels, and (as far as I know) there are only two canned kernels right now. What I'm thinking of doing is basically creating a new canned kernel for doing title screens or menu screens. I haven't tried it yet, but it should be easy-- the hardest part will be making it flexible, and integrating it into bB.

 

Or, instead of creating a new canned kernel, you could create a custom kernel for a specific title screen or menu screen.

 

Michael Rideout

[Dragnerok X]

I guess what I'm asking is how do people make sprites more than 8 pixels long in Batari Basic, if possible? And, if you've got the time, please help me do a better job with the startup menu. Here's the .bas file

 

I actually figured out a pretty easy way to do that. What I do is take two sprites, put them on the same y position, and for the x put the second player 8 places from the first. That way you get a 16 pixel long sprite! The only bad thing is you only have one sprite to use, but it's great for title screens (Atari OS)!

[SeaGtGruff]

I haven't done anything in the way of a menu screen yet, but I did make a few small changes so the game is bankswitched, to show you how to do that. The selection screen and the Ants game are in the first bank, and the Star Box game is in the second bank.

 

First, you need to tell bB how big the game will be-- 2K, 4K, 8K, 16K, or 32K. If it's 2K or 4K, there is no bankswitching. If it's 8K, 16K, or 32K, bB compiles the game so it can have bankswitching, even if you don't actually use more than one bank. So I added a "set romsize 8k" command at the beginning of your program:

 

 set romsize 8k
10 rem Ants/Star Box Multicart - both games by Chris Read
20 COLUBK=0 : COLUP0=128 : COLUP1=128 : scorecolor=0 : missile0x=200 : missile0y=200

It turns out you don't need to tell bB where bank 1 begins-- and if you try to do so, bB will compile the program incorrectly (it won't be the correct size, there will be extra bytes in it because the extra bankswitch code that's in every bank will begin in the wrong address or something).

 

However, you do need to tell bB where bank 2 (or 3, or 4, etc.) begin in the program. All you do is add a line that says "bank 2" (or 3, or 4, etc.) in the spot where you want the next bank to begin, like this:

 

400 g=g+1
 if g>1 then AUDV0=6 : AUDC0= 12 : AUDF0 = 4
 if g=100 then goto 219
402 goto 400

 bank 2

1010 rem Star Box - by Chris Read
1020 set smartbranching on
1030 w=40
1031 COLUBK=0 : COLUP0=244

The only other thing you have to do is add a "bank#" command after a "goto" or "gosub" if it's going to a line in a different bank, like this:

 

40 player0x=85 : player0y=70 : player1x=105 : player1y=70
45 REFP0=8
50 drawscreen
80 if switchreset then goto 101
90 if switchselect then goto 1010 bank2
95 goto 20

101 rem Ants!
102 set smartbranching on

and this:

 

1330 if joy0fire then goto 10 bank1
1340 drawscreen
1350 goto 1300

However, to make Star Box work after I added bankswitching, I had to change these lines:

 

1104 d=rand : t=0
 if d>80 || d<20 then goto 1104
1105 c=rand
 if c>150 || c<50 then goto 1105

Michael Rideout

multicart0.bas

multicart0.bas.bin

Edited July 27, 2006 by SeaGtGruff

[+atari2600land]

Cool!

a few questions.

#1 - how many banks are allowed?

#2 - could you have a game that's 12k or 24k or any number in between with Batari Basic? Because i've noticed that there are a few 2600 Starpath games that are 12k.

#3 - what if the whole game is just one and needs to be bigger than 4k? Is there a certain way to tell where to begin another bank (i guess it depends on the game, huh?) or just when you fill up 4k, you switch to bank 2. So in order to get to another bank, you just type a line of:

 

goto 10 bank 2

 

Guess I can make some more of Super Maria Sisters, although I won't turn anything above 4k into a cartridge because making a 8k, 16k and 32k cartridge costs more.

[SeaGtGruff]

Cool!

a few questions.

#1 - how many banks are allowed?

That depends on the bankswitching method used. Since bB uses the standard Atari methods, which let you create games that are 8K, 16K, or 32K, the number of banks depends on the ROM size-- just divide the ROM size by 4K, and that's how many banks there are, as follows:

 

8K / 4K = 2 banks

 

16K / 4K = 4 banks

 

32K / 4K = 8 banks

 

With other methods, it depends on how large each bank is-- 4K, 2K, 1K, etc. For example, the E7 or M-Network method uses banks that are 2K each, and the total ROM size is 16K, so that means there are 16K / 2K = 8 banks (plus some extra RAM banks).

 

#2 - could you have a game that's 12k or 24k or any number in between with Batari Basic? Because i've noticed that there are a few 2600 Starpath games that are 12k.

No and yes. bB 0.99 uses the standard Atari bankswitching methods, so it can create only 8K, 16K, or 32K bankswitched games. But you can customize bB to work with other bankswitching methods-- like the Starpath method-- as long as you know how to do that (and I don't advise trying it if you don't know what to do, since you could break bB if you mess up).

 

#3 - what if the whole game is just one and needs to be bigger than 4k? Is there a certain way to tell where to begin another bank (i guess it depends on the game, huh?) or just when you fill up 4k, you switch to bank 2. So in order to get to another bank, you just type a line of:

 

goto 10 bank 2

Yes, you can make one game that uses two or more banks. Most bankswitched games are just one game, rather than a multicart game. So all you need to do (in bB) is add a line telling it where the next bank begins, like this:

 

 set romsize 32k
 rem * insert a bunch of code here, this code will be in bank1 *

 bank 2
 rem * insert a bunch of code here, this code will be in bank2 *

 bank 3
 rem * insert a bunch of code here, this code will be in bank3 *

 bank 4
 rem * insert a bunch of code here, this code will be in bank4 *

 bank 5
 rem * insert a bunch of code here, this code will be in bank5 *

 bank 6
 rem * insert a bunch of code here, this code will be in bank6 *

 bank 7
 rem * insert a bunch of code here, this code will be in bank7 *

 bank 8
 rem * insert a bunch of code here, this code will be in bank8 *

If your program basically runs in a straight line-- i.e., the code in bank1 continues into bank2, the code in bank2 continues into bank3, the code in bank3 continues into bank4, etc.-- then you must add a goto line at the end of each bank to jump to the beginning of the next bank, like this:

 

 set romsize 32k
10000 rem * insert a bunch of code here, this code will be in bank1 *
 goto 20000 bank2

 bank 2
20000 rem * insert a bunch of code here, this code will be in bank2 *
 goto 30000 bank3

 bank 3
30000 rem * insert a bunch of code here, this code will be in bank3 *
 goto 40000 bank4

 bank 4
40000 rem * insert a bunch of code here, this code will be in bank4 *

Or-- if you organize your game code fairly well-- you can use bank1 for one purpose (like the main kernel or game loop), use bank2 for another purpose (like a bunch of related subroutines and data), use bank3 for some other purpose, etc. In the case of your Super Maria Sisters game, you could use bank1 for the first few screens, use bank2 for the next few screens, etc. By spreading the screens out across different banks, you'll have more room to make each screen more complex. But you will probably also want to take certain types of common routines that get called a lot, and put them in a bank by themselves, so you can call them from any of the other banks instead of having to duplicate those routines in every bank.

 

Guess I can make some more of Super Maria Sisters, although I won't turn anything above 4k into a cartridge because making a 8k, 16k and 32k cartridge costs more.

I guess that depends on how and where you get your cartridges made. If the price difference isn't too bad, you might want to consider it.

 

Michael Rideout

[+Atarius Maximus]

One thing I learned when increasing my Jumper game from 4k to 16k is that the graphics must reside in the same bank as the kernel, all of the extra space can only be filled with bb Code. Even if you specify different banks for the graphics in the code, when it compiles it will fill the same one. As a result, there's a limitation on how many different playfields you can create, you can't fill all the banks with graphics. Here's a few of batari's quotes about it from the jumper thread:

 

You can only put bB code in the remaining banks right now (no graphics). To do this, you need to specify where the next bank begins, using "bank x" where x is the next bank (1-4 for 16k, 1-8 for 32k.) Furthermore, for any gotos or gosubs that occur from one bank to another, you must specify where the target is, with "bankx" after the statement. For returns, you don't need to do anything special, but there are some options to make things a little more efficient.

Graphics must go in the same bank as the kernel. There's really no way around this restriction, except for making multiple copies of the kernel, but bB doesn't support this feature (and it will be a while before it does.)

[SeaGtGruff]

One thing I learned when increasing my Jumper game from 4k to 16k is that the graphics must reside in the same bank as the kernel, all of the extra space can only be filled with bb Code. Even if you specify different banks for the graphics in the code, when it compiles it will fill the same one. As a result, there's a limitation on how many different playfields you can create, you can't fill all the banks with graphics. Here's a few of batari's quotes about it from the jumper thread:

 

You can only put bB code in the remaining banks right now (no graphics). To do this, you need to specify where the next bank begins, using "bank x" where x is the next bank (1-4 for 16k, 1-8 for 32k.) Furthermore, for any gotos or gosubs that occur from one bank to another, you must specify where the target is, with "bankx" after the statement. For returns, you don't need to do anything special, but there are some options to make things a little more efficient.

Graphics must go in the same bank as the kernel. There's really no way around this restriction, except for making multiple copies of the kernel, but bB doesn't support this feature (and it will be a while before it does.)

First of all, I think this applies specifically to the *canned* kernels that come with bB, because if you write your own custom kernel, then you can do stuff like put a JMP or JSR to a different bank in the middle of the kernel, and then JMP or RTS back to the first bank when you're done-- assuming you know what you're doing, and have a legitimate reason for wanting to do that.

 

Anyway, I'm not so sure that this rule still applies, unless it depends on what "the same bank as the kernel" means. The way I understand "the kernel," it's the actual display loop that draws the screen, or the thing (routine) that gets performed whenever you say "drawscreen." But another possible meaning is "a loop that performs the main game logic and then calls the 'drawscreen' routine." The thing is, I think bB puts the canned kernel in the last bank-- BUT YOU CAN CALL DRAWSCREEN FROM ANY BANK, AND YOU CAN DEFINE THE PLAYER GRAPHICS DATA IN ANY BANK. I'm sure you can, because I did it when I split the Ants/Star Box multicart into two banks-- each game is in a different bank, and has its own drawscreen commands and player data statements in that bank. So if the restriction is still in existence, it must refer to putting the graphics data in the same bank as the drawscreen statement which uses it. For example, I guess you can't gosub to a routine in another bank to perform a player0 data statement, then return back to the previous bank and do the drawscreen statement. But if that's the case, then I don't see that it really matters that much, because the drawscreen command doesn't involve a lot of code-- it's just a JSR-- so you could gosub to another bank to set the graphics data for a particular screen and then do drawscreen for that screen, then return back to the previous bank to do whatever else you need to do-- check the collisions, read the input devices, etc. So there's no reason why you can't have lots and lots of screens, and divide them up across different banks (e.g., levels 1 - 4 in bank 1, levels 5 - 8 in bank 2, levels 9 - 12 in bank 3, etc.). That is, unless I'm seriously missing something-- and all I know is that the bankswitched multicart works, and there is graphics data and drawscreen in both banks.

 

Michael Rideout

[+atari2600land]

I managed to make a multi-cart with 4K. It only has 2 games, and they're both set in outer space, so I call the pair "Spaced Out." It has "Star Box" which was in a different topic, and "Humans" which should be near the top of the Homebrew forums, as I just posted that game recently. The menu is a WIP, though. I might spruce it up a little bit more.

spacedout.bin

[+atari2600land]

Newest version with better title screen and shooting problem in Humans fixed.

spacedoutv3.bin

[MausBoy]

Has anyone else done any testing on these bankswitching theories?

 

I'm having a problem with code compiling, where I get a "source is reverse-indexed" error if i try to add even one more player or playfield defination to bank 1 or bank 2 in an 8k game. Maybe the above has something to do with it?

[s0c7]

Has anyone else done any testing on these bankswitching theories?

 

I'm having a problem with code compiling, where I get a "source is reverse-indexed" error if i try to add even one more player or playfield defination to bank 1 or bank 2 in an 8k game. Maybe the above has something to do with it?

 

Back when I was putting all my games in a single 16k multicart bin I noticed it seemed to work more or less like this:

 

You can define graphics in any bank, BUT it is going to relocate them to whatever the last bank is (2 for 8k, 4 for 16k, etc.) I'm not 100% sure whether playfields do this or not. They didn't seem to.

 

So, my guess is your problem is probably that you don't have much room in bank2. It doesn't matter if you add them to bank1 or 2 because they wind up in bank2. Thus you run out of space. Sounds like you need to increase the game to 16k, and don't put any game code in the last bank.

[SeaGtGruff]

Back when I was putting all my games in a single 16k multicart bin I noticed it seemed to work more or less like this:

 

You can define graphics in any bank, BUT it is going to relocate them to whatever the last bank is (2 for 8k, 4 for 16k, etc.) I'm not 100% sure whether playfields do this or not. They didn't seem to.

Huh, I didn't know that! I'll have to check it out, because if that's how it works (and it makes sense that it would, now that you mention it), then it's an important fact to keep in mind when designing a bankswitched game in bB.

 

MR

[s0c7]

Just to clarify - you can put game code in the last bank, but you should wait until you're mostly done with the graphics to make sure you have enough space.

[SeaGtGruff]

Just to clarify - you can put game code in the last bank, but you should wait until you're mostly done with the graphics to make sure you have enough space.

Yes, I figured that!

 

And... I just confirmed that all graphics DO INDEED go into the last bank, INCLUDING the playfield! In fact, when I defined the playfield and the player in bank 1, the player worked fine, but NOT the playfield. The only way I could get the playfield to work (in my simple preliminary test) was to put the playfield in bank 2. In fact, since bB is going to store all of the graphics data into the last bank, anyway, it makes the most sense to go ahead and code all of the graphics data in the last bank, and use gosubs to set the players or playfields as needed. I'm going to post the code for my simple little test in the "toxic code" thread, because I think it may explain some of Mausboy's problems with the playfield. I haven't tried yet to see how the "graphics" for the missiles or ball are handled.

 

MR

[s0c7]

 

In fact, when I defined the playfield and the player in bank 1, the player worked fine, but NOT the playfield. The only way I could get the playfield to work (in my simple preliminary test) was to put the playfield in bank 2.

 

MR

 

I never had that issue. I've defined the playfield in every bank without issue, but I was using 99b and the old pf commands (pfhline, etc.)

Edited September 6, 2006 by s0c7

[MausBoy]

So maybe that is a proper solution to my woes, I should redo the playfields in commands instead of tables, so I can save all of the final bank for player graphics. I have much more than 4k worth of player graphics anyway, so this is a huge bummer.

[SeaGtGruff]

So maybe that is a proper solution to my woes, I should redo the playfields in commands instead of tables, so I can save all of the final bank for player graphics. I have much more than 4k worth of player graphics anyway, so this is a huge bummer.

You might be able to optimize your player graphics data. For example, when I was moving player graphics data into bank 4, I noticed that some player data tables had a lot of %00000000 lines at the top (or bottom). Presumably this had something to do with the total "player height" that you were going for, and for some frames/rotations/whatnots a player wasn't actually using all of its possible lines at the top or bottom. However, you can eliminate the blank data lines if you modify the player's vertical position accordingly. I don't know how much ROM you can save that way, but it might be worth looking into. And I haven't looked at all of your player data, but there might be places where you can save ROM by reusing player data. For instance, if you have two player shapes that are mirror images of each other, you can use a single shape and use the player reflect mode to make the player display as a mirror image of itself. So before you give up, you might want to look into those possibilities. Also, you *might* be able to customize bB a little bit so that you can store more graphics data in the other banks, but I'm not sure about that yet.

 

MR

[+atari2600land]

Isn't bank 4 the one that's 16K?

[MausBoy]

Sorry for hijacking one of your threads a2600l, I hope you are learning something too.

 

MR - I hadn't thought of removing the blank lines, since I did all that before I was worried about space. I do use the mirror effect though whenever possible, so that is out. I'll remove all blank lines, convert playfield: tables to playfield graphic commands, and remove whatever graphics don't fit, and not have nearly the game I was going for but that's how it goes.

 

It's really too bad there isn't an "Append" feature, where you can define player graphics to get stuck onto the bottom of the graphic already in use, since so many of the graphics I use are exactly the same from a certain point up. Now THAT would save some major space.

[+atari2600land]

Sorry for hijacking one of your threads a2600l, I hope you are learning something too.

As long as you don't force me to go to Cuba, it's fine.

 

Why won't this work? There's different sized banks, right? The last bank is 16K in size, right? Since the graphics are stored in the last bank, wouldn't that mean you can store all the graphics in the last bank, which would mean you could store 16K worth of graphics in the last bank instead of just 4K?

[MausBoy]

No, with 16k banswitched game, you end up with four banks at 4k each, 4x4=16. So that means I can do 12k worth of code, but only 4k worth of graphics, if only the last bank can hold graphics.

[SeaGtGruff]

No, with 16k banswitched game, you end up with four banks at 4k each, 4x4=16. So that means I can do 12k worth of code, but only 4k worth of graphics, if only the last bank can hold graphics.

Actually, less than 4K of graphics, because bB puts its own routines in the last bank as well, and they take up around 1.5K I *think* (maybe less, I forget), so I think you have a little more than 2K available for graphics. I'll investigate further and post my findings.

 

By the way, if I can figure out how to get bB to work with the Superchip (extra 128 bytes of RAM), I *might* be able to hack a custom version of bB that would move the player data into the extra RAM, in which case you would be able to move the player graphics into RAM in sections, such that you could reuse the data instead of having to redefine it every time-- kind of like a flip book or whatever with a top section, middle section, and bottom section where you can mix John's head with Billy's body and Mary's feet, or Ginger's head with John's body and Larry's feet, etc.

 

But that's *if* I can get bB to work with the Superchip, and that's a big if, because I think it might require some kind of changes in the preprocess/2600basic/postprocess compile programs, to modify the way bB sets up the different banks when you're using bankswitching.

 

And by the way, don't think that you *have* to do everything in bB. What I mean is, you could develop your game up to a certain point in bB, and then take the resulting .asm file and start working on it from there, using pure assembly and DASM, bypassing any further use of the bB compiler. If you go and read the readme file from the first release of bB (0.1), I seem to recall that that sort of thing was mentioned, or maybe it was in the posts in the forums-- in other words, you would use bB to quickly develop a game to a certain stage, then migrate the resulting .asm code to pure assembly so you could optimize the code or do stuff that bB can't handle-- which is not a slight toward bB, because it's a simple fact that a generic tool (which is what bB is, in a sense) can only do so much, and if you want to do things that the generic tool can't accomplish (or can't accomplish as well as you'd like), then you need to get a specialized tool. So that's like pushing bB's canned kernel to its limits in your program, then working on the .asm file to modify the generic kernel into something more specialized.

 

MR