RevEng Posted July 13, 2013 Share Posted July 13, 2013 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 4 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 13, 2013 Share Posted July 13, 2013 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: Quote Link to comment Share on other sites More sharing options...
Cybearg Posted July 14, 2013 Share Posted July 14, 2013 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? Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 14, 2013 Author Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
iesposta Posted July 14, 2013 Share Posted July 14, 2013 I thought the announcement was for _64K_? No? Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 14, 2013 Author Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 14, 2013 Share Posted July 14, 2013 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.. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 14, 2013 Author Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 14, 2013 Share Posted July 14, 2013 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! Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 14, 2013 Share Posted July 14, 2013 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? Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 14, 2013 Author Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 14, 2013 Share Posted July 14, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 14, 2013 Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 14, 2013 Share Posted July 14, 2013 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.. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 14, 2013 Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 14, 2013 Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 14, 2013 Share Posted July 14, 2013 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 14, 2013 Author Share Posted July 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
abaudrand Posted July 17, 2013 Share Posted July 17, 2013 Sorry to troll this thread but is the 64Ko forthcoming kernel will use the same technic (e.g. program banks separatly then recombine them) Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 17, 2013 Author Share Posted July 17, 2013 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. 2 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 17, 2013 Share Posted July 17, 2013 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 Quote Link to comment Share on other sites More sharing options...
abaudrand Posted July 17, 2013 Share Posted July 17, 2013 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 17, 2013 Share Posted July 17, 2013 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? Quote Link to comment Share on other sites More sharing options...
Sprybug Posted July 18, 2013 Share Posted July 18, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 18, 2013 Share Posted July 18, 2013 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.