RevEng Posted November 30, 2013 Share Posted November 30, 2013 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? Quote Link to comment Share on other sites More sharing options...
jwierer Posted November 30, 2013 Share Posted November 30, 2013 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 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 30, 2013 Author Share Posted November 30, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 1, 2013 Share Posted December 1, 2013 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 1, 2013 Author Share Posted December 1, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 2, 2013 Share Posted December 2, 2013 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 2, 2013 Author Share Posted December 2, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
jwierer Posted December 4, 2013 Share Posted December 4, 2013 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 4, 2013 Author Share Posted December 4, 2013 I agree 100%, Jeff. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 4, 2013 Share Posted December 4, 2013 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 4, 2013 Author Share Posted December 4, 2013 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. 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.