N00b questions about bB

[LatchKeyKid]

Hey folks, I've been toying around with ideas for my first eventual homebrew and one idea that I have is an Adventure/Zelda style action rpg made using batari Basic.   I haven't programmed anything from scratch since the very early 90's so to say that I'm a n00b would probably be an understatement.  I've been looking over Random Terrain's guides and I think judging by the standard kernel's option chart (https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart) that it should work for what I want visually and gameplay-wise.  So that then brings up additional questions that I'm not sure of where to even start looking for their answers.

 

Can you switch banks for the display kernel specifically and run the intro screen/game logic/sound/everything else from another bank?   How much space does a multicolor playfield (10 rows on each screen with two colors typically most screens) without a border take up in the ROM?  I was hoping to have a Zelda style map with 16x10 screens but I have absolutely no idea how many banks that could take up just to store the playfield data (let alone all the sprites) and/or if I can switch between them (for example using a bank for two rows each of the map plus the sprites that will populate them).  

 

Thanks in advance and I'll probably have more questions once I finally get actually started on this project. 

[+Al_Nafuur]

20 hours ago, LatchKeyKid said:

Hey folks, I've been toying around with ideas for my first eventual homebrew and one idea that I have is an Adventure/Zelda style action rpg made using batari Basic.   I haven't programmed anything from scratch since the very early 90's so to say that I'm a n00b would probably be an understatement.  I've been looking over Random Terrain's guides and I think judging by the standard kernel's option chart (https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart) that it should work for what I want visually and gameplay-wise.  So that then brings up additional questions that I'm not sure of where to even start looking for their answers.

👍

20 hours ago, LatchKeyKid said:

Can you switch banks for the display kernel specifically and run the intro screen/game logic/sound/everything else from another bank?

Yes. Usually the bB kernel is used for the game and maybe for a simple playfield titlescreen. You just have to prepare the players and the playfield and call "drawscreen" in your game/titlescreen loop.  

 

You might also use the titlescreen kernel in another bank:

or use the WIP titlescreen + PF kernel:

 

 

20 hours ago, LatchKeyKid said:

   How much space does a multicolor playfield (10 rows on each screen with two colors typically most screens) without a border take up in the ROM? I was hoping to have a Zelda style map with 16x10 screens but I have absolutely no idea how many banks that could take up just to store the playfield data (let alone all the sprites)

If you use the "Standard Kernel" the bB playfield data needs 4 bytes per row + 1 byte for the color. The multisprite kernel only has 2 bytes per row and no color per row.

16x10x10x5 = 8000, so roughly 2 or 3 banks of data depending if you are using SC-RAM in your project or not.

 

20 hours ago, LatchKeyKid said:

and/or if I can switch between them (for example using a bank for two rows each of the map plus the sprites that will populate them).  

For the standard kernel you can define the playfield data in separate banks, but the players data will be "moved" by the compiler to the bB kernel bank (last bank). AFAIK the multisprite kernel also moves the playfield to this bank. 

 

 

[LatchKeyKid]

1 hour ago, Al_Nafuur said:

Yes. Usually the bB kernel is used for the game and maybe for a simple playfield titlescreen. You just have to prepare the players and the playfield and call "drawscreen" in your game/titlescreen loop. 

 

You might also use the titlescreen kernel in another bank:

 

If you use the "Standard Kernel" the bB playfield data needs 4 bytes per row + 1 byte for the color. The multisprite kernel only has 2 bytes per row and no color per row.

16x10x10x5 = 8000, so roughly 2 or 3 banks of data depending if you are using SC-RAM in your project or not.

 

For the standard kernel you can define the playfield data in separate banks, but the players data will be "moved" by the compiler to the bB kernel bank (last bank). AFAIK the multisprite kernel also moves the playfield to this bank. 

 

 

Apologies as I don't know how to get to the bbs code to break up the quote into parts like you did.   Thanks again and that's what I was hoping to hear.  It's probably too ambitious but I was hoping to divide up the game into a title screen and end scene bank, an actual game logic bank, and multiple map based kernel banks though I wasn't sure how realistic that was with bB.  I just had no clue if that was going to even remotely fit in what now seems like the standard 32k/8 bank size.  It sounds like it might be possible so now the giant limiting factor is more my own (lack of) knowledge base moreso than the platform/toolkit I'd be using.  At this point I've got the map done (theoretically to the limits of the standard kernel/2600) along with various sprite designs/animations but no actual coding.  I don't plan on using any extra RAM or cart add ons but obviously I say that again without any real practical coding experience regarding whether the scope of what I'm planning is possible on the original hardware only with bB. 

 

Regarding the last sentence, do you mean that the playfield data is its own dedicated bank with nothing else in it like player sprites?  I had assumed (with no real knowledge) that they were more "kernel" banks and just carried what was needed to display on the screen.  By player data, does that refer to player position and various inventory like equipment/statuses and such?  Thanks again for answering the questions.

[LatchKeyKid]

Another question for those with experience with bB... do you have to manually count CPU cycles to make sure you're not going over?   I see options like pfpixel that add cycles and I was curious if using those types of options with bB are accounted for by the compiler/program before running in the emulator.   For example with more fundamental aspects, can you always add sound effects and music with the basic kernel or is that dependent on whether both sprites are moving and animated and whether the missiles and ball are active?

 

Also, does anyone know of an annotated/commented example of a multiscreen "adventure" style game using bB whose bas files can be "hacked"?   I see lots of excellent example programs of individual elements (like the above mentioned pfpixel) but was curious if there were genre starter programs to play around with somewhere.

Edited September 21, 2023 by LatchKeyKid

[+KaeruYojimbo]

47 minutes ago, LatchKeyKid said:

I was curious if using those types of options with bB are accounted for by the compiler/program before running in the emulator. 

No, the compiler won't tell you if you go too many cycles, and it won't compensate in any way to try to get your cycle count down. Unfortunately (or maybe fortunately if you only plan on playing your game in emulation), Stella by default does compensate for it, so if there are issues that will cause problems on real hardware, they won't always show up in Stella in the default settings.

 

47 minutes ago, LatchKeyKid said:

can you always add sound effects and music with the basic kernel or is that dependent on whether both sprites are moving and animated and whether the missiles and ball are active?

You can add sound at any time, it's not dependent on anything else.

[LatchKeyKid]

9 minutes ago, KaeruYojimbo said:

No, the compiler won't tell you if you go too many cycles, and it won't compensate in any way to try to get your cycle count down. Unfortunately (or maybe fortunately if you only plan on playing your game in emulation), Stella by default does compensate for it, so if there are issues that will cause problems on real hardware, they won't always show up in Stella.

 

You can add sound at any time, it's not dependent on anything else.

If I were ever to get off my lazy butt and make a homebrew, I'd definitely want it to work on original hardware as well as emulation.  Thanks for the clarification.  With regards to the sound, sorry if it wasn't clear there but I was also referring to CPU cycles and not an inherent clash between the features.   I assume that having all those active at the same time bites heavily into the CPU cycle budget (both player sprites animated and moving, with balls and missiles active, while music and sound effects are playing).

Edited September 21, 2023 by LatchKeyKid
typo

[+KaeruYojimbo]

1 minute ago, LatchKeyKid said:

If I were ever to get off my lazy butt and make a homebrew, I'd definitely want it to work on original hardware as well as emulation.  Thanks for the clarification.  With regards to the sound, sorry if it wasn't clear there but I was also referring to CPU cycles and not an inherent class between the features.   I assume that having all those active at the same time bites heavily into the CPU cycle budget (both player sprites animated and moving, with balls and missiles active, while music and sound effects are playing).

I don't know exactly how many cycles sound effects take, but I've never had any issues caused by sounds playing while multiple objects are moving.

[+Karl G]

18 minutes ago, LatchKeyKid said:

If I were ever to get off my lazy butt and make a homebrew, I'd definitely want it to work on original hardware as well as emulation.  Thanks for the clarification.  With regards to the sound, sorry if it wasn't clear there but I was also referring to CPU cycles and not an inherent clash between the features.   I assume that having all those active at the same time bites heavily into the CPU cycle budget (both player sprites animated and moving, with balls and missiles active, while music and sound effects are playing).

Not really. Player graphic setup is done "under the hood" in bB in the vblank time slice, whereas bB code is generally run during the overscan time slice. Sound registers don't take long to set, and are generally at most only set once per frame, as the Atari will keep playing the sound that is set until you tell it to do otherwise.

 

You will be able to tell if your game uses too many CPU cycles in a frame when the screen "jumps". This happens when the code goes over the number of cycles available in the overscan time slice where your coe runs, so too many scan lines are generated by the Atari or Stella, causing a visible jump or roll of the screen.

 

There is generally no need to go to the extremes of counting cycles in a bB program (and that is hard to do anyway unless you are working directly in assembly), but if you see that your game is using too many cycles, then you need to do things to reduce this, and/or spread what you are doing over multiple frames (not every task has to be run 60 times a second).

[LatchKeyKid]

Thanks and that's great to hear.  I figured I'd end up just looking line by line in Stella at the CPU count to see what the count was if something didn't work though finding the exact spot in the code might be a bit more difficult since I'm guessing I'd have to do that in assembly.

[KevKelley]

5 hours ago, LatchKeyKid said:

do you have to manually count CPU cycles to make sure you're not going over?

not really… but I suppose it is good to have a general idea of what things do or what some best practices are. I think there are some threads in this forum that do say what uses more (i.e. gosub vs goto).

 

I have found my programs usually don’t run afoul of the scanline issue until I do something that conflicts with another part of the code and then I go on a trial and error hunt for the culprit. 

[KevKelley]

1 hour ago, LatchKeyKid said:

Thanks and that's great to hear.  I figured I'd end up just looking line by line in Stella at the CPU count to see what the count was if something didn't work though finding the exact spot in the code might be a bit more difficult since I'm guessing I'd have to do that in assembly.

I put the developer settings on so I see the scanlines on the top corner. And in some programs where it happens so infrequent that I try to find the issue I may add a break in the command line in Stella to kind of pinpoint things. 

[LatchKeyKid]

17 minutes ago, KevKelley said:

I put the developer settings on so I see the scanlines on the top corner. And in some programs where it happens so infrequent that I try to find the issue I may add a break in the command line in Stella to kind of pinpoint things. 

Thanks for the answers.  My only personal experience was pressing "~" in Stella and going line by line out of curiosity to see how many cycles were used and I figured I'd end up doing that if I had a problem.

[KevKelley]

3 hours ago, LatchKeyKid said:

Thanks for the answers.  My only personal experience was pressing "~" in Stella and going line by line out of curiosity to see how many cycles were used and I figured I'd end up doing that if I had a problem.

That’s usually what I’ll do. I will play until I see a jump and then do my best to replicate it and when it happens again I go into the debugger and try to see what was being done. 
 

I’d look at things like controller inputs or sprite locations or whatever else and compare to each scanline issue. Then I go back to my code and try to narrow down the cause. Sometimes I feel I have no clue what I’m looking for but I feel I’ve gotten better at it. 

[LatchKeyKid]

So I was making my latest set of sprites for another game that I hope to someday make and I was as usual trying to make them in accordance with the basic kernel options that I envision using (admittedly in ignorance as a non-programmer so far) and a question came up.   Do you set the kernel options only once in the bank you're using them or can you change them on the fly?  For example, some of my enemy sprites will use their missiles so I don't plan on making them multicolor as I'd lose the use of the missile sprite... but others won't be shooting and would more be obstacles.  Since with basic kernel you can only have one of each sprite on screen at any one time (as opposed to the aptly named multisprite and DPC kernels), can you change that in between frames depending on which sprite you're planning on using next?  Is there a difference in the answer depending on which option we're talking about? 

 

Additionally, how customizable are the score minikernels in bB?   Can you customize them into more gameplay elements instead of HUD type items?   I don't expect them to directly interact with the main kernel via collisions and such but I was curious if you can have a "gun barrel" sprite for shooting games down there or a car sprite (or even dashboard or cockpit) instead of just numbers and icons in driving/flying games.

Edited October 16, 2023 by LatchKeyKid

[+splendidnut]

8 minutes ago, LatchKeyKid said:

Do you set the kernel options only once in the bank you're using them or can you change them on the fly?

Kernel options define how the kernel is built during compile/build time, so they can only be set once.  They cannot be changed on the fly.

 

10 minutes ago, LatchKeyKid said:

Additionally, how customizable are the score minikernels in bB?

Mini-kernels can be customized any way you want... if you're willing to do the ASM coding necessary to accomplish that.

 

[LatchKeyKid]

14 minutes ago, splendidnut said:

Kernel options define how the kernel is built during compile/build time, so they can only be set once.  They cannot be changed on the fly.

 

Mini-kernels can be customized any way you want... if you're willing to do the ASM coding necessary to accomplish that.

 

Thanks for the quick answer.  I figured the kernel options were one and done but a guy can hope!      For the mini-kernels, I wasn't sure if they were written in bB and could be modified that way (just like you write the core game in bB) instead of going to ASM.

Edited October 16, 2023 by LatchKeyKid

[+Karl G]

Assuming that you are looking for a moving sprite in the minikernel area (since you mentioned a gun), then one option would be RevEng's paddle minikernel:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#paddle_minikernel

 

[LatchKeyKid]

Thanks!  I get a shimmering effect on it in stella so I'm not sure if that's a more modern emulator incompatibility.   From the name (pfcolpad2) and the description, I assume that it's drawn using the playfield and not sprites but then it says it can be anything including a space ship.  @RevEng Has this been updated or modified in the years since?  Could you clarify whether the object is a full sprite or PF blocks?   Regardless, it's a good resource/option that I wasn't aware of.

[RevEng]

I haven't updated or modified it since that post. The "paddle"is a full player sprite - thepfcolpad2 demo name is from Gemintronic's original demo, which I just added the paddle minikernel to. No idea on the shimmering.

[LatchKeyKid]

Thanks for the clarification and I'm glad to hear it!

[LatchKeyKid]

I'm curious if anyone can give an example of a game using the pfpixel technique to specifically ADD playfield blocks to the screen instead of destroying them like the bB examples.  While the below is obviously a bB link, it's an example of something I'd like to use and I'd be interested in looking at other ASM coded games that utilize the technique as well to a limited degree (CPU cycles allowing!).

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#pfpixel

 

The only example that I can think of that uses this type of mechanic (the player's actions adding playfield blocks) is the excellent Zookeeper homebrew title by Champ Games.   Are there other homebrews that do this?  Any original official releases from back in the heyday of the 2600?  Thanks in advance for any examples. 

 

 

 

[+Random Terrain]

Here are two versions of a drawing program:

 

https://forums.atariage.com/topic/122998-double-click-draw/?do=findComment&comment=1487708

 

https://forums.atariage.com/topic/122998-double-click-draw/?do=findComment&comment=1487807

 

[KevKelley]

I used pfpixel to draw or erase playfield blocks in the Field Draw option in Cone Ball.

 

In also use it to mow the field in Lawn Boy, but to erase it would be the same but in reverse . 

[LatchKeyKid]

Thanks for the examples and I'll take a look at them tonight!   I was brainstorming for an original game and wanted to give it a unique spin and it seemed like a relatively underused technique that I could add to a game concept I have.

[+KaeruYojimbo]

I use pfpixel in Sky Destroyer/WATA Invaders.