What is the least buggy version of bB and any new tips?

[+Random Terrain]

I've been busy doing other things for a while, but I'll soon want to experiment with bB again. Does anyone know which is the latest, most bug-free version? Do we have 32k of space yet?

 

Any new tips or discoveries that I and others should know about?

 

 

Thanks.

[Shawn]

I've been busy doing other things for a while, but I'll soon want to experiment with bB again. Does anyone know which is the latest, most bug-free version? Do we have 32k of space yet?

 

Any new tips or discoveries that I and others should know about?

 

 

Thanks.

 

Heck if there is 32k I might even be able to get a game going seeing as I would need 32k worth of code to write something that should fit into 8k with my amazing basic skills and all

[+Random Terrain]

Heck if there is 32k I might even be able to get a game going seeing as I would need 32k worth of code to write something that should fit into 8k with my amazing basic skills and all

Yep, 32k is either here or on the way:

 

http://www.atariage.com/forums/index.php?s...st&p=983671

[+batari]

Heck if there is 32k I might even be able to get a game going seeing as I would need 32k worth of code to write something that should fit into 8k with my amazing basic skills and all

Yep, 32k is either here or on the way:

 

http://www.atariage.com/forums/index.php?s...st&p=983671

32k is possible now, with any of the bleeding edge builds (0.99a, b, or c).

 

As far as "most stable" version of bB, I'd say 0.99b. Less stable but with nicer features, such as a multicolor playfield, and sprites, is 0.99c. This version is unreleased, but I've given out a few copies upon request.

[SeaGtGruff]

Yep, 32k is either here or on the way:

32K in bB is here now. All you have to do is (1) use the "set romsize 32k" command in your bB program, (2) use the "bank n" command-- e.g., "bank 5"-- to tell bB where a new bank begins, and (3) use the "goto label bankn" or "gosub label bankn" commands-- e.g., "goto level_4 bank6"-- to move from one bank to another. That may be slightly simplified, and there can be things you need to watch out for-- e.g., do *NOT* try to begin the first bank with a "bank 1" command, or it will mess up bB and cause the compiled ROM image to be a funky number of bytes-- but it really is that simple for the most part.

 

Furthermore, since the three bankswitching methods which bB now officially supports-- F8 (8K Atari), F6 (16K Atari), and F4 (32K Atari)-- can be used in conjunction with the "super chip," that means you now have the ability to access 128 bytes of extra RAM if you want to, as long as you use some ORG statements to skip over the addresses where the extra RAM is written to or read from. I haven't tried that yet, but I think you'll probably need to customize bB a little bit to make sure it doesn't try to use those addresses itself (i.e., when compiling its own builtin routines in the ROM space). Plus, you may need to specifically tell your chosen emulator which bankswitching method to use for your bB game (e.g., F4 vs. F4SC), because the emulator might not be able to auto-detect which bankswitching method it should use.

 

Michael Rideout

[+Random Terrain]

32k is possible now, with any of the bleeding edge builds (0.99a, b, or c).

 

As far as "most stable" version of bB, I'd say 0.99b. Less stable but with nicer features, such as a multicolor playfield, and sprites, is 0.99c. This version is unreleased, but I've given out a few copies upon request.

Thanks. Do you think you might have a more stable version of 0.99c coming out this year? It sure will be cool to have a multicolor playfield and sprites to play with. We can try to make some of our own Imagic-like games!

 

 

32K in bB is here now. All you have to do is (1) use the "set romsize 32k" command in your bB program, (2) use the "bank n" command-- e.g., "bank 5"-- to tell bB where a new bank begins, and (3) use the "goto label bankn" or "gosub label bankn" commands-- e.g., "goto level_4 bank6"-- to move from one bank to another. That may be slightly simplified, and there can be things you need to watch out for-- e.g., do *NOT* try to begin the first bank with a "bank 1" command, or it will mess up bB and cause the compiled ROM image to be a funky number of bytes-- but it really is that simple for the most part.

Thanks. I'm not sure how I would figure out how much code should fit in a bank. Have you guys discussed this in another thread that I can read?

 

I like to compare working with bB to working on the Vic-20 back in 1983 and my Vic-20 had 3.5k to use and an 8k RAM cartridge. That's only 11.5k, but I had lots of room to experiment compared to the usual 3.5k, so 32k should give me the freedom to do all kinds of things I always wanted to try but never could until now on a classic computer or video game system.

Edited July 29, 2006 by Random Terrain

[SeaGtGruff]

I'm not sure how I would figure out how much code should fit in a bank.

When you compile a bB game that uses bankswitching, you get a listing of how much space is left in each of the banks, like this:

 

  4021 bytes of ROM space left in bank 1
  4052 bytes of ROM space left in bank 2
  4052 bytes of ROM space left in bank 3
  4052 bytes of ROM space left in bank 4
  4052 bytes of ROM space left in bank 5
  4052 bytes of ROM space left in bank 6
  4052 bytes of ROM space left in bank 7
  2789 bytes of ROM space left in bank 8

The listing above is from compiling a program that has "nothing" in banks 2 through 8, and only a tiny bit of code in bank 1. With this type of bankswitching (F8, F6, or F4), each bank is 4096 bytes, so an "empty" bank has 44 bytes of code that bB puts at the beginning of every bank for bankswitching purposes. The last bank is a special case, because that's where bB puts all of its own routines, hence the last bank (in this case, bank 8 ) will always have less ROM space available for your program than the other banks will. When you start writing your program, bB automatically puts it in bank 1, unless you use the "bank n" statement to tell bB to do otherwise.

 

So when you write a bB game, you can start by using "set romsize 4k" to get a standard game, and keep your eye on how many bytes are left each time you compile it. When you reach a point where you can't squeeze anything more into 4K, change to "set romsize 8k" and recompile. Just by doing that, you'll automatically have a little more than 1K of extra ROM for your game, even without using the "bank 2" statement, since the 1.17K of ROM that bB needs for its own routines will get moved to bank 2. When you finally fill up bank 1 with your game, use the "bank 2" statement to start putting the rest of your game code in bank 2. Then, if you get to where you have no more space in banks 1 and 2, you can change to "set romsize 16k" and continue on, and later (if needed) "set romsize 32k."

 

Michael Rideout

Edited July 29, 2006 by SeaGtGruff

[+Random Terrain]

So when you write a bB game, you can start by using "set romsize 4k" to get a standard game, and keep your eye on how many bytes are left each time you compile it. When you reach a point where you can't squeeze anything more into 4K, change to "set romsize 8k" and recompile. Just by doing that, you'll automatically have a little more than 1K of extra ROM for your game, even without using the "bank 2" statement, since the 1.17K of ROM that bB needs for its own routines will get moved to bank 2. When you finally fill up bank 1 with your game, use the "bank 2" statement to start putting the rest of your game code in bank 2. Then, if you get to where you have no more space in banks 1 and 2, you can change to "set romsize 16k" and continue on, and later (if needed) "set romsize 32k."

Thanks. That seems like a better way to do it than what I imagined.

Edited July 29, 2006 by Random Terrain

[+batari]

Thanks. I'm not sure how I would figure out how much code should fit in a bank.

By trial and error, but that's not as bad as it sounds, as the assembler will tell you how much space is available in each bank. If one bank gets too full, it will show a negative number, which indicates how much space you would need to remove from that particular bank.

[+Random Terrain]

By trial and error, but that's not as bad as it sounds, as the assembler will tell you how much space is available in each bank. If one bank gets too full, it will show a negative number, which indicates how much space you would need to remove from that particular bank.

Thanks. Yep, from what you and SeaGtGruff have said, it doesn't seem like it will be hard at all. If I remember correctly, we already had to compile a program to see how much space we had left, so this will be just as easy to understand.

[SeaGtGruff]

When you finally fill up bank 1 with your game, use the "bank 2" statement to start putting the rest of your game code in bank 2.

Thanks. That seems like a better way to do it than what I imagined.

I should add, if you want your code to simply continue from bank 1 into bank 2, you'll need to use a "goto linelabel bank2" statement. And if you need to loop back to a line label in bank 1, you'll need to use a "goto linelabel bank1" statement. Following is a simple program to illustrate:

 

  set romsize 8k : rem * Tell bB to use F8 bankswitching.

  rem * Bank 1 starts here. *************************************

  rem * Define the variables.
  dim color = a
  dim frame = b

  rem * Initialize the variables.
  color = 0
  frame = 0

loop
  COLUBK = color
  drawscreen

  rem * Let's pretend we just used up bank 1's ROM space.
  goto game2 bank2 : rem * Continue in bank 2, just for fun.

  bank 2 : rem * Bank 2 starts here. ****************************

game2
  frame = frame + 1
  if frame = 30 then frame = 0 : color = color + 2

  rem * Let's pretend we need to loop back to bank 1.
  goto loop bank1 : rem * Loop back to bank 1, just for fun.

Or you could put your main code in bank 1, and use bank 2 for your subroutines:

 

  set romsize 8k : rem * Tell bB to use F8 bankswitching.

  rem * Bank 1 starts here. *************************************

  rem * Define the variables.
  dim color = a
  dim frame = b

  rem * Initialize the variables.
  color = 0
  frame = 0

loop
  COLUBK = color
  drawscreen

  rem * Now let's perform a subroutine.
  gosub next_frame bank2 : rem * The subroutine is in bank 2.

  rem * Back to the loop to draw the next frame.
  goto loop

  bank 2 : rem * Bank 2 starts here. ****************************

next_frame
  frame = frame + 1
  if frame = 30 then frame = 0 : color = color + 2

  rem * Now we're ready to return from the subroutine.
  rem * bB automatically knows to return to bank 1.
  return

Michael Rideout

[+Random Terrain]

Thanks. Besides what you were talking about, from looking at your sample code it seems that each bank can use variables from other banks without forgetting. If A equals 5 in one bank, it will still equal 5 in another. That's nice to know.

[SeaGtGruff]

With this type of bankswitching (F8, F6, or F4), each bank is 4096 bytes, so an "empty" bank has 44 bytes of code that bB puts at the beginning of every bank for bankswitching purposes.

I was mistaken, bB puts the extra bankswitching code at the *end* of each bank, not the beginning.

 

Also, I've been working on using the Superchip's extra RAM (on an emulator, of course), but it's a lot harder than I expected. I don't have any trouble reserving 256 bytes at the beginning of each bank (even before bB's routines in the last bank), but for some reason it breaks the kernel, and I haven't figured out why yet. Also, the way I'm currently reserving the 256 bytes for the Superchip is messy, and the ideal way to do it will require making changes to the bB compiler-- not just to the includes files, but to the actual compiler (.exe). So if I can get it working the messy way, I'll have to give the details to batari so he can modify bB as needed.

 

Michael Rideout