Completed games using a multikernel framework?

[graywest]

Hello all,

 

Has anyone out there completed a game using any of the multikernel frameworks? If so, do you have a link to a .bin?

 

I have a working game using the 32kb multikernel framework and I was curious to see what others have done.

 

My game isn't quite ready to show off yet, but I should have a .bin for testing in the next month or so.

 

Thanks!

[+Gemintronic]

I'm biding my time until I can secure 256k ROM boards.

 

You're pretty much a trailblazer here. I'd love to here if you've had success mixing and matching kernel options. I know multi sprite and standard didn't mix well (blank screen).

[+Karl G]

I believe CPUWiz has a number of 256K boards?

[+Gemintronic]

I believe CPUWiz has a number of 256K boards?

 

Haven't checked the status/availability in awhile. I respect him too much to bug him like an excited teenager. Plus, this year has been rough

[graywest]

I'm biding my time until I can secure 256k ROM boards.

 

You're pretty much a trailblazer here. I'd love to here if you've had success mixing and matching kernel options. I know multi sprite and standard didn't mix well (blank screen).

 

Cool. Yes, everything works as advertised with the multikernel framework. I have been using only standard kernels - no multisprite.

 

It's nice to be able to include things like multiple title screens. I use one for a "proper" title screen, one for a status screen, one for a "game over" screen, etc. I also try to make my games look as little like "default" Batari Basic games as possible, so it's nice to be able to switch kernel options to avoid the blank horizontal background lines, etc. Sort of like having multiple graphics modes if you've ever programmed on the Atari 8 bit computers.

 

Also, it's great not having to worry about bankswitching. Though my game is fairly modular so I've been able to fit everything into self-contained 4kb blocks, more or less, so your mileage may vary on this one. There are a few variables (score, level, etc.) that I've reserved to be maintained across all kernels, everything else is local to the kernel.

 

There are a couple of tricky things that I had to figure out to make everything work properly. For example, if you have a variable that you'll be using across two kernels, you'll still need to dim the variable in both. Seems obvious now, but it took some work to figure out how the memory sharing would work the first time around.

 

There are still a couple of issues that I'm trying to work out. For example, when switching kernels, the screen will occasionally "jump" on the very first frame. Not a huge issue, and I'm still not sure if it's my code, or something related to the multikernel framework. I'm still working on it. Also, using the offscreen playfield variables (var44 - var47) caused some pixel-high lines to appear above the score when switching kernels. I cleared those variables out and used standard variables instead, and that seemed to fix the problem.

 

Also, I had been using the Crimson Editor toolchain for all of my dev work up until I started with the multikernel framework. (Mostly because I couldn't get older versions of Visual Batari Basic to keep my settings between sessions under Windows 10.) I couldn't get the multikernel framework to compile with my old setup, so I switched over to the latest version of VBB. Everything worked fine after that.

[+Gemintronic]

 

Cool. Yes, everything works as advertised with the multikernel framework. I have been using only standard kernels - no multisprite.

 

 

Perhaps since we can't prevent screen roll and artifacts during some bank switches we could mitigate it. Say, have a section to clear the screen and color the sprites and playfield black before making the jump. Maybe doing an extra drawscreen immediately before the bank switch.

 

I realize it's bad form to ask the inquirer things he's asking about, but..

 

Have you experimented with switching between standard kernel variations. Say, one bank "player1colors playercolors pfcolors" and another "pfcolors no_blank_lines"?

Hopefully our findings will inspire others to take the plunge

[graywest]

 

 

Perhaps since we can't prevent screen roll and artifacts during some bank switches we could mitigate it. Say, have a section to clear the screen and color the sprites and playfield black before making the jump. Maybe doing an extra drawscreen immediately before the bank switch.

 

I realize it's bad form to ask the inquirer things he's asking about, but..

 

Have you experimented with switching between standard kernel variations. Say, one bank "player1colors playercolors pfcolors" and another "pfcolors no_blank_lines"?

Hopefully our findings will inspire others to take the plunge

 

 

I tried inserting an extra drawscreen immediately before the bank switch, and immediately upon entering the new bank. It still jumps occasionally, which is strange because it doesn't happen EVERY time I restart the game, even from a complete cold start in the emulator. Could be a quirk of the Stella emulator, but I'm not sure. I need to try this on real hardware. Luckily, it isn't too noticeable.

 

I do have several different standard kernel variations:

 

pfcolors pfheights

pfcolors no_blank_lines

no_blank_lines

 

Plus several titlescreen kernel banks that have other things like data strings in them.

 

Everything works very well, on the whole. One of these days I'll probably post all of my source code for this game so that others can see how the multikernel frameworks work.

[+Karl G]

You may need to reinitialize pfheights values each time you enter a bank that uses that kernel option