bB 256k, 128k, 64k, 32k, 16k, Multikernel Frameworks

[RevEng]

I've created bB frameworks for the new 256k and 128k boards by CPUWIZ, and I've also included 64k and 32k frameworks here, as well as superchip versions of all, for completeness.

 

In a nutshell, these frameworks provide an example of how to build up a larger game out of individual 4k projects.

 

While this makes it a bit more cumbersome to build a game - I'd only recommend it for people that are very familiar with bB and the build process - it has the benefit of doing away with some bB limitations that people sometimes complain about...

• Each bank can have a different instance of the kernel. This means different sprite definitions, different playfields, different kernel compile options.
• There can be multiple banks with title screens. Use them for their intended purpose, game over screens, in-game displays, hidden easter egg screens, scrolling game credits, or whatever.

It should be pointed out that the framework can't be used to mix completely different kernels, like the multisprite and standard kernels, due to the fact they use different vcs initialization and differing memory maps.

 

 

How the framework works

 

Each 4k project is built separately, with a custom bB score_graphics.asm file that adds a bankswitch table to the binary. Each project except for the "bank 1" project gets a custom bB 2600basicfooter.asm file that ensures bank 1 is the start-up bank.

 

When you want to change to another bank, you just issue a "temp1=switchbank(#)" in your bB code. This will switch banks and starts running the bB code at the top of the selected bank. It's up to you to decide how to make that work within your game flow.

 

If you want to make an empty bank/project without a standard kernel, you just need to stick a dummy std_kernel.asm in your project. The framework includes an example of this with the titlescreen held in bank 8. It's also recommended you use a custom default.inc in any bank without a kernel, to remove unused bB routines, e.g. the playfield routines.

 

 

Putting it all together

 

To build the project you need to build each bank individually (as you usually do) and then glue all the binaries together by double-clicking the included "make.bat" file (windows) or typing "make" from the parent directory. (Linux, probably OSX)

 

The sample bin is also attached here. The score displays the current bank, and pressing the fire button brings you to the next bank.

 

To run 128k or 256k binaries in emulation, you'll need stella 3.9.3 or later. To run 128k or 256k binaries on real hardware, you'll need an eeprom burner and a board from CPUWIZ, or the forthcoming Harmony Encore.

 

16kMultikernelFramework.zip

16kSCMultikernelFramework.zip

32kMultikernelFramework.zip

32kSCMultikernelFramework.zip

64kMultikernelFramework.zip

64kSCMultikernelFramework.zip

128kMultikernelFramework.zip

128kSCMultikernelFramework.zip

256kMultikernelFramework.zip

256kSCMultikernelFramework.zip

 

Special thanks to CPUWIZ, stephena, and batari for laying the groundwork.

[+Random Terrain]

So I can replace the 32k Multikernel Framework link and the 64k Multikernel Framework link on the bB page with just one to this thread?

[RevEng]

Yup, that's right. I figured it would be easier with it all in one thread.

[CPUWIZ]

Crap, now I have to re-route the board design (some traces are too close) and actually have them made.

[RevEng]

It will take them a while to fill up 128k or 256k, so you have some time.

[+Gemintronic]

Now that I know it's %100 percent possible to make a 256k game my next project will be designed as such. THANKS REVENG AND CPUWIZ!!!!!!!

 

As a side I realized the last question in the CPUWIZ 128k 265k cart topic was never addressed:

http://atariage.com/forums/topic/219144-new-homebrew-board-coming-soon/?do=findComment&comment=2876504

 

Should I plan on scrounging around for donor SARA carts?

[CPUWIZ]

If you need SARA, yes. I have some ideas about a pin compatible replacement, but it is just that, I doubt it'd be "cheap".

[Sprybug]

Here's a totally ridiculous idea I thought up.

Would this be able to support a game that used the entire 128k or 256k?

Not saying I would make such a game (although I could.....)

[RetroFiends]

This is absolutely insane. This is NES ROM size territory. We're talking, near the end of the console's life NES ROM sizes.
I'm just going to go out on a limb here and guess my Harmony isn't going to touch these ROMs?
Edit: Of course it wouldn't, and it says so in the thread. I Just saw 256 and my mind was blown across the wall.

Edited January 21, 2014 by RetroFiends

[RevEng]

Would this be able to support a game that used the entire 128k or 256k?

That's totally the point of it, though you need to write your game in 4k modules. Conceptually it's not all that different from regular bB bankswitching, except for 2 things...

 

1. each bank is compiled as a separate 4k bB project. (but can jump to any other 4k module at any time.)

2. the "switchbank" command will drop you at the top of the bB code in the destination bank/module, rather than at a specific label. Its up to you to manage the flow from there. (easily done with a variable and on...goto, if there's more than one destination routine)

 

I chose this whole framework thing for the new formats because native 128k and 256k support in bB seemed silly, with the current restriction that all of the graphics data needs to go in the last bank, sharing 4k of space with the kernel. (and lifting that restriction in another way isn't feasible)

[+Gemintronic]

Sounds like there's at least two developers on board for 256k development. How about a full motion rotoscoped Seaweed Assault?

[RetroFiends]

I already have some ideas...
Are the boards required already available?
And on the topic of EPROM Burners, what would you recommend?

[+Gemintronic]

are the boards required already available?

Crap, now I have to re-route the board design (some traces are too close) and actually have them made.

 

I've been anticipating this move from 64k boards to 256k. The best plan is allocating game engine sections per 16 different banks. When 256k boards become reality then you can just allocate 4x the space for each part of your game

[iesposta]

Here's a totally ridiculous idea I thought up.

Would this be able to support a game that used the entire 128k or 256k?

Not saying I would make such a game (although I could.....)

Is your Zippy programmed this way? (Separate 4K projects?)

[+Gemintronic]

I'm not sure if custom multi-sprite kernels work with this framework but I plan on trying the one used in Flappy by iesposta:

http://atariage.com/forums/topic/222161-flappy-my-1st-released-game/

 

Will report back when I have a chance to try it!

[+Gemintronic]

I'm not sure if custom multi-sprite kernels work with this framework but I plan on trying the one used in Flappy by iesposta:

http://atariage.com/forums/topic/222161-flappy-my-1st-released-game/

 

Will report back when I have a chance to try it!

 

Okay! I have confirmed that you can put a custom multisprite_kernel.asm in each bank folder and successfully compile a multi-kernel framework game!

 

On a different subject.. would it be possible to edit the score graphics in the bank folders?

 

I mean, manually editing the score_asm data:

 

.byte %00111100

.byte %01100110

.byte %01100110

.byte %01100110

.byte %01100110

.byte %01100110

.byte %01100110

.byte %00111100

 

Does the bank switching code rely on them being the stock font?

 

UPDATE: Seems to work when I hax the score font. Probably would barf if I tried expanding the score to a full 16 characters..

 

UPDATE II: I just mixed and matched multi-sprite and standard kernels. It CAN compile a working ROM but there are collisions between kernels that need to be dealt with. So, this goes from "can not" to "you better know what you're doing" territory!

[Sprybug]

Is your Zippy programmed this way? (Separate 4K projects?)

Nope. The entire source is in one file, each bank separated with the bank # function. I'm on my next project now and I'm looking at how easy it is to implement multikernel functionality without me having to jump through too many hoops to make it happen. My brain can only hand so much at the same time. These games I make require a lot of my logical brain, and to take on well you gotta do this, this, this, this and this to employ this technique...not sure if my brain could handle another thing like that.

[STGraves]

I've created bB frameworks for the new 256k and 128k boards by CPUWIZ, and I've also included 64k and 32k frameworks here, as well as superchip versions of all, for completeness.

 

In a nutshell, these frameworks provide an example of how to build up a larger game out of individual 4k projects.

 

While this makes it a bit more cumbersome to build a game - I'd only recommend it for people that are very familiar with bB and the build process - it has the benefit of doing away with some bB limitations that people sometimes complain about...

• Each bank can have a different instance of the kernel. This means different sprite definitions, different playfields, different kernel compile options.
• There can be multiple banks with title screens. Use them for their intended purpose, game over screens, in-game displays, hidden easter egg screens, scrolling game credits, or whatever.

It should be pointed out that the framework can't be used to mix completely different kernels, like the multisprite and standard kernels, due to the fact they use different vcs initialization and differing memory maps.

 

 

How the framework works

 

Each 4k project is built separately, with a custom bB score_graphics.asm file that adds a bankswitch table to the binary. Each project except for the "bank 1" project gets a custom bB 2600basicfooter.asm file that ensures bank 1 is the start-up bank.

 

When you want to change to another bank, you just issue a "temp1=switchbank(#)" in your bB code. This will switch banks and starts running the bB code at the top of the selected bank. It's up to you to decide how to make that work within your game flow.

 

If you want to make an empty bank/project without a standard kernel, you just need to stick a dummy std_kernel.asm in your project. The framework includes an example of this with the titlescreen held in bank 8. It's also recommended you use a custom default.inc in any bank without a kernel, to remove unused bB routines, e.g. the playfield routines.

 

 

Putting it all together

 

To build the project you need to build each bank individually (as you usually do) and then glue all the binaries together by double-clicking the included "make.bat" file (windows) or typing "make" from the parent directory. (Linux, probably OSX)

 

The sample bin is also attached here. The score displays the current bank, and pressing the fire button brings you to the next bank.

 

To run 128k or 256k binaries in emulation, you'll need stella 3.9.3 or later. To run 128k or 256k binaries on real hardware, you'll need an eeprom burner and a board from CPUWIZ, or the forthcoming Harmony Encore.

 

 

32kMultikernelFramework.zip

32kSCMultikernelFramework.zip

64kMultikernelFramework.zip

64kSCMultikernelFramework.zip

128kMultikernelFramework.zip

128kSCMultikernelFramework.zip

256kMultikernelFramework.zip

256kSCMultikernelFramework.zip

 

Special thanks to CPUWIZ, stephena, and batari for laying the groundwork.

 

How can I use it in bB, I tried but with no luck, I want to use it to add 1 title screen, 1 dead screen, and perhaps 1 or 2 level transition screens, help please

[+Random Terrain]

Since theloon brought it up, maybe he can walk you through it step by step.

[+Gemintronic]

Since theloon brought it up, maybe he can walk you through it step by step.

 

I had to admit that it's an advanced technique that I hardly know I personally still scavenge the preview code that VisualbB uses for demo'ing a title screen. It'll take me awhile to get back into bB and cough up some example code. Gotta finish a Sega Genesis game first and then get back into my 256k Tunnels & Trolls game.

[graywest]

I've probably missed something simple, but I'm having a hard time getting my 32kb multikernel project to compile. I'm starting with the first 4kb bank that I've created.

 

Basically, it barfs when I get to the line that switches banks:

if joy0fire then temp1=switchbank(2)

 

Throws an unresolved symbol list with a whole bunch of things in it. Compiling without that line works fine.

 

I'm using Crimson Editor - have not had any problems with this setup. Do I need to include the additional .asm files that came with the 32kb Multikernel Framework example? Like bank1.bas.asm, score_graphics.asm, and 2600basicheader.asm? I tried that and got some other errors.

 

Other things I've tried - trying to compile the original, unedited bank1.bas from the 32kb Multikernel Framework example also throws an "unresolved symbol list" on switchbank. Leads me to believe that I'm missing files that add that switchbank keyword to bB.

 

This is my first try at using the multikernel framework, so apologies if this is a dumb question. Thanks for the help!

 

Each 4k project is built separately, with a custom bB score_graphics.asm file that adds a bankswitch table to the binary. Each project except for the "bank 1" project gets a custom bB 2600basicfooter.asm file that ensures bank 1 is the start-up bank.

When you want to change to another bank, you just issue a "temp1=switchbank(#)" in your bB code. This will switch banks and starts running the bB code at the top of the selected bank. It's up to you to decide how to make that work within your game flow.

Edited August 16, 2018 by graywest

[RevEng]

You need the score_graphics.asm and 2600basicheader.asm present in each bank's folder. bB uses these files instead of the official ones, if it finds them in the same folder as your basic file.

 

If you have the files present already, then your crimson editor may not be switching the working directory to your project directory, when it does the build. This may break other advanced stuff, like includes.

[graywest]

You need the score_graphics.asm and 2600basicheader.asm present in each bank's folder. bB uses these files instead of the official ones, if it finds them in the same folder as your basic file.

 

If you have the files present already, then your crimson editor may not be switching the working directory to your project directory, when it does the build. This may break other advanced stuff, like includes.

 

Thanks!! I switched over to using the latest Visual Batari Basic, and that seems to have fixed the issue. Everything is compiling correctly now and I was able to build the 32kb .bin. I think you're right about Crimson Editor and the working directory.

 

There may be a way to get it working in Crimson Editor, but this seemed to be the easier solution for me.

[+Gemintronic]

Does the framework support extra characters? I tried manually adding A-F and the compiler did not like it. I also tried editing score_graphics.asm.21stcentury and using the const font=.21stcentury with the same result.

[RevEng]

It doesn't restrict you from using extra characters, but you need to make changes uniformly for all banks.

 

i.e. When you edit the provided score_graphics.asm in one bank (and change the start of the graphics to allow for more characters) you need to modify the score_graphics.asm graphics start location similarly in all banks.

 

The underlying reasons you need to do this are 1)bank-switch routines normally need to be the same place in each bank, and 2)the bank-switch switch routine for these frameworks is in the score_graphics file, right after the graphics data.