Dual Kernel Example Possible?

[+Gemintronic]

As a continuation of SeaGtGruffs explanation on how multiple score mini kernels are posible I was wondering if the standard and multi-sprite kernels could be used in the same game.

 

As my wildly inexperienced eyes would see it, you just create a main loop and call a gosub for each kernel. One would dig up the assembly for the kernels and just run them in-line.

 

Am I making any sense at all? Is this just a pipe dream since you must specify one kernel at compile time?

[+batari]

Currently the easiest way to combine kernels into one binary would be to create two distinct games with each kernel and manually combine them. You could most easily do two 4k games and add some assembly to jump from one to another, then manually combine them. This is what we've done before for collections of games. You could also combine 8k-16k games if you change the bankswitch hotspots for each carefully.

 

As for source-level integration, There are several issues that would need to be resolved before something like that could be possible. The kernels themselves currently can't live together in the same source code due to conflicting labels. Maybe that could be fixed by changing things around a bit, but more needs to be done.

 

The other issue is with how each kernel uses RAM. Each use different locations for user variables, score, players, and other things and I'm not sure how compatible they would be even if some things were moved around to match. If someone wishes to look at the RAM usage and see if things can be moved around at least well enough to keep user variables, that may help.

 

Regardless, you probably won't be able to have two kernels in a single bB source because the compiler handles certain objects differently depending on what kernel you are using. For example, player objects, the playfield, and some other things are handled very differently in each kernel and the compiler would need to somehow know which kernel each declaration is for.

 

A more likely scenario would involve two separate source files. They would be compiled into assembly files separately, and assembled together which would link them. In order to work, a few extra things would be needed such as global and local labels. Allowing multiple .bas files is something that's been on the todo list for years, and this would need to be working before anything with multiple kernels would be possible.

[abaudrand]

AAAARRGGGHHH !!!!!!!!!!

I was hoping I could mix a 4k bank with no_blank_line for titles, another 4k for a multisprite level, and the rest of banks for others level of my game...

I guess I should rethink all my game as I will never be able to mix them...

moreover I'm using a lot of variables (already reaching letter "m") and I guess you're meaning these variables are assigned depending which kernel you are using.

Edited August 9, 2010 by abaudrand

[yuppicide]

What bAtari is saying you will be able to do..

 

You'd make one 4k with no blank lines for title screen

You'd make one 4k for a multisprite level

Then make a third 4k with your other levels.. I don't think ONE level will take up 4k. So, with some ASM you'll be able to jump to the other banks.

 

I don't know the code required, but you can combine multiple binaries into one. RevEng had an example one day, but I couldn't get it to work.

 

Basically what he's saying is to make your title screen.. make it so when you press fire it will jump to the second 4k binary which would have your game. When something happens it will take you to that multisprite level and when something happens there it'll take you back.

 

If your game has a score, though, I don't know how it will carry over a score from bank to bank though.

Edited August 9, 2010 by yuppicide

[abaudrand]

yes, I have a score for player0... anyway, I'll finish all levels sharing the same kind of kernel for the moment and will do the others in the end. For the moment I'm still trying to understand the maths of the atari to solve my sliding effect trouble.