General questions about kernels, bank switching...

[abaudrand]

Hi,

 

I'm starting to question myself about which kernels to choose for the game as choice make limitations later.

Is it possible to "mix" differents kernels within the same game? For exemple, I would like to have no blank line for the main title or final screen then as I need missiles for the Ingame, I would like to remove this kernel.

The other question concern the bank switching: Can I store a variable thru the entire game despite I switch bank? I want to alternate dragon shooting and horse riding (which I guess will be stored in different bank) but I need to have acces to variable to know where the player is in the game progression.

 

P.S: for those who are interested about where I am in Dragons' Nights, I'm struggling to make the missile of the dragon into a different color so I'm trying to learn the flickering

[SeaGtGruff]

Hi,

 

I'm starting to question myself about which kernels to choose for the game as choice make limitations later.

Is it possible to "mix" differents kernels within the same game? For exemple, I would like to have no blank line for the main title or final screen then as I need missiles for the Ingame, I would like to remove this kernel.

If you program in assembly language, you can use as many different kernels as you want in a game.

 

If you program exclusively in batari Basic "out of the box" or unmodified, you're stuck with using just one kernel in a game. However, you can use two or more kernels in batari Basic programs if you want-- but right now, you have to use assembly language to do it.

 

One way to do it is to write one or more kernels of your own in assembly language, and include them directly inside your batari Basic program using the "asm" command. If you do this, there are two things you need to keep in mind: (1) You need to use unique labels for your kernel routines, so they don't conflict with the labels that batari Basic uses for its own kernel routines. And (2) you need to call your kernels using the "gosub" command instead of the "drawscreen" command.

 

Another way to do it is to write one or more kernels of your own in assembly language, and save them as separate .ASM files. This has the same issues as the first method (i.e., the need for unique labels for the routines, and the need to call them with the "gosub" command), but it has the added advantage that you can use the "include" command to include the extra kernels in many different batari Basic programs-- assuming the extra kernels are generic enough to be useful in more than one game.

 

A third way to do it is to edit the assembly language code that's created from the batari Basic code. When you compile a batari Basic program, it gets converted into an assembly language program, and then the assembly language programs gets assembled into the final ROM image. So after you compile your batari Basic program, you can edit the assembly language program that was created, and modify it to add one or more extra kernels. I'll come back to this in a bit.

 

Actually, there's another alternative to using assembly language, which is to write the extra kernel(s) using batari Basic commands instead of assembly language commands. A while back I wrote a batari Basic program to display all 128 NTSC-Atari colors on the screen at once using batari Basic commands for the kernel, to demonstrate that this is possible. However, this method does require you to be familiar with how the 2600 draws the screen, and if you're familiar with how that works, then you're probably also capable of writing the kernel in assembly language, anyway. Also, when you use batari Basic commands to create a kernel, some things are going to be a little slower than if you'd just used assembly language commands, due to the way most batari Basic commands work. Furthermore, using batari Basic commands usually makes it harder to keep track of the precise timing needed by some kernels, so it could be difficult or even impossible to achieve the kind of precise timing that your custom kernel might need.

 

The other question concern the bank switching: Can I store a variable thru the entire game despite I switch bank? I want to alternate dragon shooting and horse riding (which I guess will be stored in different bank) but I need to have acces to variable to know where the player is in the game progression.

Variables must be in RAM, otherwise their values can't be changed while the program is running. There are two kinds of RAM in 2600 games-- the builtin RAM that's located in page zero, and expansion RAM that's included on the game cartridge (if the cart is of a type that includes expansion RAM).

 

The builtin zero-page RAM (also called "RIOT RAM," since it's provided by the 2600's 6532 RIOT chip-- "RIOT" stands for "RAM-Input-Output-Timer") is always available to the different banks of a bank-switched game, because when you switch banks, it switches all or part of the cartridge memory space (depending on the bank-switching method used), but doesn't switch the page-zero RAM. Therefore, your variables will be accessible to all banks.

 

The more common types of expansion RAM (e.g., the SARA chip, or "Superchip") are also accessible to all banks, even though the expansion RAM is located within the cartridge memory space, because the cartridges that use those methods are built such that the expansion RAM is always present, no matter which bank you switch to.

 

Some cartridge formats and bank-switching methods have expansion RAM that can also be switched, just like with ROM banks. One example of this is the "E7" method. If you're using one of these methods, and you store a variable in RAM that can be switched, then you'll need to make sure you switch to the RAM bank that holds a particular variable before you try to access that variable.

 

Since you're fairly new to batari Basic and 2600 programming, I'll assume that you'll be using an unmodified version of batari Basic, with either the 8k, 16k, 32k, 8kSC, 16kSC, or 32kSC formats. In that case, you don't need to worry about the variables, because they'll always be accessible, no matter which bank you switch to.

 

If you want to use the "no_blank_lines" option on the title screen and end screen, but not on the main game screen, perhaps the easiest possibility would be to create two separate batari Basic programs-- one for the title screen and end screen, and the other for the main game. You could compile the two programs separately, then edit the resulting assembly language programs together so they can be re-assembled into a single ROM. This would probably end up wasting a good bit of ROM, but that's okay. The program for the title screen and end screen-- which would also contain the code for launching the game from the title screen (and perhaps re-launching the game from the end screen, unless the end screen is always going to return to the title screen anyway) could easily fit into a 4k game. Then you could write the second program for the main game, probably as a bank-switched game. If you keep the first bank empty, it should make it easier to take the assembly language program for the title screen, end screen, and game-launching code, and add it into the assembly language program for the main game. You'd have to modify some of the labels in one of the kernels, so the two kernels don't conflict with each other.

 

I won't make any promises (in case I can't keep them!), but I'll see if I can work up a few examples to illustrate some of these options.

 

Michael

[+Gemintronic]

Oh man oh man oh man oh man!!! I'm going to read and reread SeaGtGruff wisdom until I start seeing Jaguar cubes!

 

I'd like an example of that gosub technique in Batari if at all possible. THANK YOU for the info so far though!

 

Someday I'd like to rock RevEngs title screen kernel and then switch back to a different kernel. Or, maybe swap score kernels mid game.. ooooooOOOoh, the possibilities! :!: :!:

[abaudrand]

Thanks for the explanations. I'm greatly relieved about the variables which are available thru the entire game.

For my mind's sake, I guess I will keep a simple title screen and endscreen "kernel" compatible with the rest of the game just for testing it and as a bridge with the rest of the game. Once the game will be ready, I'll rewrite a module of 4k with different kernel and ask for help once I'm done with all other matters.

 

I've just found and bought on ebay a complete atari 7800 and once I've sell enough old stuff, I'll order an harmony cartridge to test what I'm doing on TV as I wonder about the flickering with Stella. You can't imagine how I'm happy to use batari and create a video game.

Regards.