Jump to content
IGNORED

32k Multikernel Framework


RevEng

Recommended Posts

32k multikernel framework

 

I've put together a 32k multikernel framework. In a nutshell, it's an example of how to build up a 32k 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 does away with some bB limitations that people often 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 have different vcs initialization (which only happens when the first bank starts up) 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 "goto bank#_entry" in your bB code. This will switch banks and start with 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.

 

multikernel.130713.zip

multikernel.bas.bin

  • Like 4
Link to comment
Share on other sites

The bad news is: each 4k must share code and graphics. Those graphics probably wont survive switching banks with this scheme.

The good news is: each 4k must share code and graphics. You can have more graphics than any regular 4k-32k could EVER have.

 

Think of a game that has the same game engine in each bank. The only difference is the level layout and monsters. You could probably have more different types of monsters than in a regular 32k game by FAR if each bank had its own monster graphics.

 

OR, think about an animated 3D maze/dungeon game. Instead of trying to cram ALL the animations for moving about the 3D dungeon you could separate the animations per bank. With that much room you could easily make a game like Phantasy Star:

Link to comment
Share on other sites

But wouldn't the memory be cleared each time the kernel was loaded?

 

I don't fully understand Deb's description. I assumed this is the same framework he gave me for the compilation I am working on. With what I have, each 4k bank is isolated, able to have any kernel, and memory is wiped by jumping. Is this one different, Rev?

Link to comment
Share on other sites

This is different. Your game compilation does initialization after bank switching to different games because the kernels differ and require setup. Also, it's a sensible thing to do for different games.

 

For this framework, initialization only happens once, when bank 1 starts up after power-on. After that the memory isn't touched, so it remains consistent between the games.

Link to comment
Share on other sites

Your understanding is spot on. When you call drawscreen in any given project/bank, it only has access to graphics defined in that bank. So any graphic that you want to be common between banks will need to be duplicated in those banks.

 

Its a good solution for a bB game that requires a wide variety of graphics, or a variety of kernel options. The standard 32k kernel is the better solution for a game with very few graphics and a lot of non-graphic data or code.

Link to comment
Share on other sites

You can create a bank without a standard kernel for your music code, same as I did for the titlescreen bank. You just have to jump to a bank with a kernel before you call drawscreen.

 

The bankswitch code takes about the same time as a regular bB bankswitch, give or take a cycle or two.

Link to comment
Share on other sites

You can create a bank without a standard kernel for your music code, same as I did for the titlescreen bank. You just have to jump to a bank with a kernel before you call drawscreen.

 

The bankswitch code takes about the same time as a regular bB bankswitch, give or take a cycle or two.

 

That's good news. I wonder what it would look like if you tried to flip between three banks with different kernel option setups so two banks would have two multicolored sprites each and one bank would have both missiles available, giving you 4 multicolored sprites and two missiles. Even if you could do that, everything would be separate, so you wouldn't be able to use collision detection.

Link to comment
Share on other sites

That's good news. I wonder what it would look like if you tried to flip between three banks with different kernel option setups so two banks would have two multicolored sprites each and one bank would have both missiles available, giving you 4 multicolored sprites and two missiles. Even if you could do that, everything would be separate, so you wouldn't be able to use collision detection.

 

My theory is that collision detection would be just fine. The problem is, when you switch banks and do a drawscreen the current limitations apply. So if missile1 isn't allowed then it wont appear on the frame using the kernel that doesn't allow missile1. Likewise the multi-colored sprites would revert to single color on the kernel that can't support that. You'd be stuck with half-tones for multi-color since they'd appear every other frame.

 

Another thing that I didn't think about is how multi-color and single color sprite data is laid out by bB. it could be the case where even if you did duplicate sprite per bank the color lookup data may be "in the way" and not end up aligned..

Link to comment
Share on other sites

My theory is that collision detection would be just fine. The problem is, when you switch banks and do a drawscreen the current limitations apply. So if missile1 isn't allowed then it wont appear on the frame using the kernel that doesn't allow missile1. Likewise the multi-colored sprites would revert to single color on the kernel that can't support that. You'd be stuck with half-tones for multi-color since they'd appear every other frame.

 

Since most people don't seem to mind flicker, it might be worth it if collision detection would still work. It would probably be easier than doing the flickering yourself.

Link to comment
Share on other sites

Since most people don't seem to mind flicker, it might be worth it if collision detection would still work. It would probably be easier than doing the flickering yourself.

 

I agree. The only concern is if batari used the displaced variables for something else. Like if a kernel mode that disallows missile1 actually used missile1x/missile1y.

 

As a side I hope one of your color tool web pages eventually supports the flickering of two colors to experiment with color combos that hurt peoples eyes less.

Link to comment
Share on other sites

I agree. The only concern is if batari used the displaced variables for something else. Like if a kernel mode that disallows missile1 actually used missile1x/missile1y.

 

I could be wrong, but I don't think any of them do since you can still put missiles on the screen as top to bottom strips:

 

atariage.com/forums/topic/212560-missile1x-free-when-using-player1colors/#entry2758217

Link to comment
Share on other sites

Some of the variables between options overlap, so you'd need to fix that before switching between kernels..

 

For example, missile1height and missile1y are used for player1color (2 bytes)

 

So if you switch from a kernel with player1color to a kernel with missile1, you need to set missile1 height and y. To switch back, you'll need to use the player1color: command prior to the drawscreen.

 

When in doubt, open up 2600basic.h (standard kernel) or multisprite.h (multisprite kernel) to see which values are shared.

Link to comment
Share on other sites

No. The upcoming 64k EF bankswitching support will be native bB, and behave the same as the other native bank switching formats. (graphics go in last bank, etc.)

 

However, I do plan to eventually follow up with a "64k Multikernel Framework". This framework will be the same as the one in this thread, only bigger.

 

Choice is good.

  • Like 2
Link to comment
Share on other sites

Added a link to this thread on the bB page:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#akmme_32k_multikernel_framework

 

 

If jwierer can find the time, I wonder if this could be merged with VbB in some way like he did with other things?

Link to comment
Share on other sites

Oh boy, another thing to play around with after I'm finished with Zippy. I'm so glad that BB is being further developed on. It has a lot of potential to do great things. I'm curious about the benefits of a different kernel per bank. Let's say in one bank you set up the kernel to be able to do various playfield heights, but don't add playfield colors because you don't want it to be fixed, because you'll be changing the widths during the game. Would having no playfield heights and playfield colors in another bank be a workaround for that or will your columns become an even 8 again but now you have colors? If so that'd be a little disappointing, however this multikernel option would still give you the option of having one level with certain aspects, while in whole other level (in a different bank), you can do different things just because the design of the level calls for it.

  • Like 1
Link to comment
Share on other sites

I think you're correct in assuming the effects in one kernel do not blend with another. It would be interesting to have separate drawscreen commands for every kernel combination we want. As it is we "waste" a whole bank on one particular kernel combination. Also, the fact that graphics and playfields get stored per bank will probably bite me in the arse. Still. Progress!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...