Jump to content

Photo

32k Multikernel Framework


39 replies to this topic

#1 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sat Jul 13, 2013 1:45 PM

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.

Attached File  multikernel.130713.zip   65.2KB   175 downloads
Attached File  multikernel.bas.bin   32KB   176 downloads

#2 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Sat Jul 13, 2013 5:08 PM

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:


#3 Cybearg OFFLINE  

Cybearg

    Dragonstomper

  • 950 posts

Posted Sat Jul 13, 2013 6:23 PM

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?

#4 RevEng OFFLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sat Jul 13, 2013 6:32 PM

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.

#5 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,831 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Jul 13, 2013 7:01 PM

I thought the announcement was for _64K_?
No?

#6 RevEng OFFLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sat Jul 13, 2013 7:24 PM

Different project. This one allows you to have multiple kernel and titlescreen banks in a 32k game, increasing the amount of graphics your game can use.

#7 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Sat Jul 13, 2013 10:05 PM

Was I assuming too much when I theorized sprites get forgotten between banks? My theory is that the player1/0pointers will be in the same place but the actual graphic data will be whatever is present in the new bank..

#8 RevEng OFFLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sat Jul 13, 2013 10:44 PM

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.

#9 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Sat Jul 13, 2013 11:21 PM

Yet another disadvantage that can be turned into an advantage! If the player0/1pointer stays the same you can arrange the graphics to be in sequence. Imagine having enough frames to re-make Karateka!

#10 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,789 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jul 14, 2013 12:01 AM

Does this mean you could no longer use up a whole bank just for sound effects or music?

How much time does it take to switch between banks? Does it take longer than it does normally?

#11 RevEng OFFLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sun Jul 14, 2013 12:16 AM

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.

#12 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Sun Jul 14, 2013 12:29 AM

I can't express just how stoked I am about this and your 64k expansion for bB. This is a huge leap forward for bB games! For now all I can do is promise that I personally will make better art with your contributions :)

#13 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,789 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jul 14, 2013 12:36 AM

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.

#14 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Sun Jul 14, 2013 1:10 AM

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..

#15 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,789 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jul 14, 2013 1:22 AM

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.

#16 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Sun Jul 14, 2013 1:56 AM

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.

#17 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,789 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jul 14, 2013 2:29 AM

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

#18 RevEng OFFLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sun Jul 14, 2013 9:34 AM

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.

#19 abaudrand OFFLINE  

abaudrand

    Chopper Commander

  • 241 posts

Posted Wed Jul 17, 2013 1:29 PM

Sorry to troll this thread but is the 64Ko forthcoming kernel will use the same technic (e.g. program banks separatly then recombine them)

#20 RevEng OFFLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,992 posts
  • Bitnik
  • Location:bottom of the stack

Posted Wed Jul 17, 2013 2:04 PM

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.

#21 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Wed Jul 17, 2013 2:23 PM

Choice is good? What happens if one of us suggests a hybrid mode with 32k in one kernel and the other 32k in 8 separate kernels? Sounds like a nightmare to me :)

#22 abaudrand OFFLINE  

abaudrand

    Chopper Commander

  • 241 posts

Posted Wed Jul 17, 2013 3:03 PM

thanks for the quick reply and I feel greatly relieved about it. I was afraid I had to reorganize completly my scheme . Just waiting Batari to update the tool :)

#23 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,789 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Jul 17, 2013 3:31 PM

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?

#24 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 563 posts

Posted Thu Jul 18, 2013 5:07 AM

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.

#25 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,210 posts

Posted Thu Jul 18, 2013 6:03 AM

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!




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users