potatohead Posted August 11, 2005 Share Posted August 11, 2005 The BB program. In otherwords, have everything in one big file? I've been thinking about this for a little while now. The paddle issue led me down this path. If a person wants to go the hybrid route, or include special kernels, routines, etc... Those files must be edited. Since BB really runs everything through DASM, including the kernel would make for a perfectly portable package. If you have the source file, you have the game period. We already have a coupla games where specific kernels are being used for paddle, etc.... If we do this now and folks learn how to work this way, the overall batari package will remain simpler overall and games written today while the language is still seeing improvements have a higher chance of working tomorrow without having to carry around lots of kernel baggage. Thinking along the lines of: set kernel inline set headers inline ---------- Basic Program lives here------------ rem basic program might have it's own inline assembler code as well asm lda b sta c end -------------- Kernel and headers live here -------------- Lots of assembly stuff EOF. I know it seems wierd, but it will have some serious advantages once people start tinkering around with their kernels. Also, if another machine is targeted someday (which I eventually want to do), everything is there as well, making things simple for learning tweaking purposes. I'm not saying change the way things are now, just asking if this might be possible to add, that's all. I would sure love to be able to work this way in the near future. Quote Link to comment Share on other sites More sharing options...
kisrael Posted August 11, 2005 Share Posted August 11, 2005 The BB program. In otherwords, have everything in one big file? This would really crank up the complexity of code...intimidating to newbies to have this big old glob of ASM right there! And also it would lengthen it in general....I mean the ASM is never going to be huge huge, but still...there's something nice in the way a bB program listing is almost all game logic. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 11, 2005 Author Share Posted August 11, 2005 (edited) The BB program. In otherwords, have everything in one big file? This would really crank up the complexity of code...intimidating to newbies to have this big old glob of ASM right there! And also it would lengthen it in general....I mean the ASM is never going to be huge huge, but still...there's something nice in the way a bB program listing is almost all game logic. 909296[/snapback] ...that's exactly why I asked for the option. For anyone getting started, the current structure is just fine, recommended actually. It's possible to write a few lines and get something to happen. That's BASIC and it should not change. I'm just looking forward to hybrid development. If one starts building a kernel, the portability of the bb program is then lost. (Unless the files are sent along for the ride of course.) That is followed by instructions and such detailing what to put where, etc... We have a coupla examples right now. The standard kernel has been fragmented into several kernels. At this stage, those are well represented by the proposed set options. Once one decides to start tweaking at both levels, one file would be easier to manage, IMHO. And still be portable. Think of it as a scaling feature. If folks are going to cross the road from bb to full on assembly, this step would be key. Also, this does not disturb the clean game logic aspect of things. That part of the listing, will remain unchanged. Put the messy stuff at the bottom. For those wanting to use the IDE, there are advantages as well. One window, one rom image... Edited August 11, 2005 by potatohead Quote Link to comment Share on other sites More sharing options...
+batari Posted August 12, 2005 Share Posted August 12, 2005 In otherwords, have everything in one big file? 909448[/snapback] Yep - and it's been done. Solar Plexus uses an inline kernel that I wrote for the title screen. I'll post it again, along with a couple of fixes... I think this will work. To use, paste it at the end of your bB program, and access it by calling gosub titlescreen in a loop instead of using drawscreen. Of course, you will want to change the graphics data in the data statements to your own graphics. title.bas 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.