the evolution of multikernel frameworks... spitballing

[RevEng]

I've mostly finished up support for the 256k and 128k multikernel frameworks, which were based on the existing 64k multikernel framework, but the new frameworks now have optional SC support added. (and I've backported the SC support to the 64k multikernel framework. A release is pending)

 

While multikernel frameworks are presently the only sane way to add support for these massive formats to bB - otherwise you'd have 32 or 64 banks and only 1 of them that can hold all the graphics, shared with the kernel - I think there's a way to automate the rough edges away from the multikernel frameworks.

 

Picture a multikernel source editor, where you choose a target format and default canned kernel, and it gives you tabs for each bank. Each tab represents a mini-project for that bank. You can enable/disable the bank getting a kernel, titlescreen kernel, etc. with check-boxes.

 

Building all the banks in the project and gluing them into a binary would be automated.

 

Taking it a step further, the bankswitching between banks could be made to work more like existing bB bankswitching. The source editor would build each bank that it could normally. If a bank tries to bankswitch to a label in another bank, the editor would try to import the label symbol from that bank. The editor would do multiple dasm passes, trying to compile remaining banks by importing labels from other banks as they get resolved in each attempt.

 

if you're not familiar with dasm, labels, and symbols, just ignore the techno babble in the last paragraph. The take away is that each bank's project could be allowed bankswitch to an exact destination in another bank, rather than just switching to the top of a bank as the multikernel framework does now.

 

I'm not saying I'd write the above. I just don't have the time to start writing and supporting a gui tool. But I do see it as the ultimate solution in producing large ROM formats in bB.

 

I know some people are going to say "add it to vbb", but I think this is a huge change, and it could be possibly confusing when people are building the existing monolithic formats.

 

Are large formats so much of a niche that we should just leave the rough edges on the frameworks? Is an editor solution like this inevitable? Other thoughts? tl;dr?

[jwierer]

I started adding multikernel support to vbB when the 32K kernel came out. it looks like this.

 

 

You select the zip file with the latest kernel and it builds a grouped set of projects. You can choose to right click on the top most container and compiler all the sub projects and then combine into a single bin. It works and I think it would be easy to expand it for 64k, 128, or 256k.

 

The other thing I was playing with was the ability to specify which compiler you want to use to compile the .bas. I think we're still in a state where some versions of the compiler perform some things better than others, so if you know one that works particularly well with your game you can place this at the beginning (or anywhere really).

 

REM FORCECOMPILER=<path>

 

I just need to find some time to test it with the latest. Work and family aren't affording me much time to code outside of work right now

 

-Jeff

[RevEng]

Wow! That's great news, Jeff, and it's looking really good!

 

I hear you on the free time thing. I wouldn't sweat testing 128k and 256k (which I haven't even released yet) until stephena gets a chance to incorporate the patch I sent him into stella.

 

One thing that would be handy with the multikernel support, is if there was a way for the user to easily dump the kernel from a bank to save space. This should just require a "std_kernel.asm" file be created in the bank, just containing a "kernel" label and nothing else.

[+Random Terrain]

I personally may never use it because I'd like to use the DPC+ kernel now that you've fixed it up so I can finally have 10 multicolored sprites that are more detailed and a higher resolution playfield. I'm still kind of 'depressed' about only having 26 variables, so I haven't been able to make myself do any more work on DPC+ example programs, including the Breakout rip-off. I feel like I'm mentally stuck in quicksand.

[RevEng]

The nice thing is we now have choices for large formats. Despite all of the advantages to DPC+, there are disadvantages too, like space for big projects.

[+Gemintronic]

The ultimate goal should be one seamless code window for 64k+ projects. I really don't want to be bogged down by having a separate entry for each 4k bank.

 

VisualbB should have an option to start a 64k+ project and then present one code window. Each bank should have its own set kernel options line.

 

What's mentioned so far can work for now (and thank you RevEng and jwierer for the effort!).. but, with CPUWIZ conjuring up 256k boards that's 64 separate banks to keep track of.

[RevEng]

I think you're right, theloon. If the interface bits are moved to basic syntax instead, much of the GUI management goes away. A CLI program can parse the basic file first, splitting any multikernel programs behind the scenes. This would also make easy multikernel management portable.

 

I'm going to chew on this for a while before I commit to doing it. Time is super short, and batari has never weighed in as to whether he'd adopt any of my temporary fork.

[jwierer]

I could easily put in vbB specific commands so you could have a single file to manage, but that would be breaking the language. From a purist perspective, it should compile with bB alone and vbB should just remain an IDE on top of the compiler.

 

-Jeff

[RevEng]

I agree 100%, Jeff.

[+Gemintronic]

I think you can have your cake and eat it too. Have a single text editor window for multi bank projects but save a meta project file that includes each individual bank.bas and folder.

 

I don't know if I explained that properly. Basically, have a project file that Vbb reads to gather all the individual .bas files and present one code window to the user.

 

This would leave the language untouched as you just have to check for "set romsize 64k" and seperate each bank.bas file at the " bank x" lines.

[RevEng]

This would leave the language untouched as you just have to check for "set romsize 64k" and seperate each bank.bas file at the " bank x" lines.

I think we shouldn't be allowing programs in vbb that won't compile directly in bB proper. It fractures the language into 2 dialects. Some people will post source examples copied from their "single source window" that won't compile in other people's systems.

 

If we take on some small additions to the language (probably lesser in scope than I've already done with other changes) there's no reason why a new bB CLI tool couldn't identify that the source file is "multikernel", and break up the source into temporary bank directories for the usual programs to digest. All of that would be orchestrated by 2600bas.bat (or 2600basic.sh) and transparent to the users and vbb.

 

I've been chewing on it for a bit, and I think most of the things that can be done today with the frameworks could be accomplished with this sort of scheme...

 

 rem ** we use this only in the first bank, near the top
 set multikernel 64k 

 rem ** a new option for "kernel", to not include a default bB kernel in this bank...
 set kernel none

 rem ...bB code here...

 rem ** if we use multiple titlescreens, they need a unique directory name... 
 asm
 include "titlescreen_b1/asm/titlescreen.asm"
end

 bank 2

 set kernel_options player1colors

 rem ...bB code here...

 bank 3

 rem ** if you need to get really fancy, you can change the default multikernel inc file 
 includesfile "multikernel_bank3.inc"

 [...] 

I'm still not decided on if this thing will have bankswitch+goto, as that would add a lot of logic outside of dasm, pulling in resolved labels from other (partially) compiled banks in an attempt to make that bankswitch+goto correctly resolve. (this is why the multikernel frameworks just punt, and start running at bB program at the top of the called bank)

 

gosub/return would likely be in-bank only, to avoid using 6 bytes of stack for each call.