Kernel request thread

[vdub_bobby]

Ok, so I suggested this; now I will start up the thread.

 

bBASIC coders, what do you want in a kernel? Try to keep in mind the native restrictions of the hardware (you can't have 50 sprites on a single scanline with no flicker) and RAM limitations (you can't track X and Y coords of 100 sprites (200 coords > 128 bytes of RAM)), but don't feel like you can't contribute just cuz you haven't memorized the Stella Guide.

[vdub_bobby]

I'll kick things off by saying that batari asked me to develop a new kernel for bBASIC, which allows more than 2 sprites onscreen at once. Rather than taking half a page explaining the ins and outs of this kernel, just check out the attached demo and screenshot.

 

The one thing I will say is that it has a *symmetrical* PF - not the asymmetrical playfield of the current bB kernel.

 

Oh, and it isn't completely done, but it is mostly done.

 

Use the L joystick to move one of the sprites and the trigger to reset the ball/missiles.

 

Thoughts? You could make a simplified Go Fish! clone with this pretty easily.

bbk1.bin

Edited July 22, 2005 by vdub_bobby

[+batari]

I'll kick things off by saying that batari asked me to develop a new kernel for bBASIC, which allows more than 2 sprites onscreen at once.  Rather than taking half a page explaining the ins and outs of this kernel, just check out the attached demo and screenshot.

 

The one thing I will say is that it has a *symmetrical* PF - not the asymmetrical playfield of the current bB kernel.

 

Oh, and it isn't completely done, but it is mostly done.

 

Use the L joystick to move one of the sprites and the trigger to reset the ball/missiles.

 

Thoughts?  You could make a simplified Go Fish! clone with this pretty easily.

896574[/snapback]

This looks really good, and looks complete enough to give a preview of things to come!

 

I'll make sure to document the limitations of the new kernel - you can get lots of things on the screen at the cost of vertical placement limitations, but it should be capable of a wide variety of new games.

[kisrael]

HUUGE thumbs up!

 

How about a kernal with a static, ROM-based PF, but you could still have player graphics? Ideally with options for updating the PF every 1,2,3 or 4 scanlines?

 

Or would that take too much ROM?

 

Also someting with split scores would be sweet.

 

it would be super amazing if kernal pieces could be mix and match. Like, I'd love to see something like:

 

200 dokernal origPF

210 dokernal score_6digit

 

then you could make the score come above or below the game. And you could have other "subkernals", like one for a split 3 and 3 character score, or a big fat 2 digit PF-based score, or one for the 48-pixel graphics display...taking this idea to its (logical?) extreme you could even specify how many scanlines each subkernal takes up...

[vdub_bobby]

How about a kernal with a static, ROM-based PF, but you could still have player graphics? Ideally with options for updating the PF every 1,2,3 or 4 scanlines?

Symmetrical or asymmetrical?

[+batari]

HUUGE thumbs up!

 

How about a kernal with a static, ROM-based PF, but you could still have player graphics? Ideally with options for updating the PF every 1,2,3 or 4 scanlines?

 

Or would that take too much ROM?

 

Also someting with split scores would be sweet.

 

it would be super amazing if kernal pieces could be mix and match. Like, I'd love to see something like:

 

200 dokernal origPF

210 dokernal score_6digit

 

then you could make the score come above or below the game.  And you could have other "subkernals", like one for a split 3 and 3 character score, or a big fat 2 digit PF-based score, or one for the 48-pixel graphics display...taking this idea to its (logical?) extreme you could even specify how many scanlines each subkernal takes up...

896588[/snapback]

Baby steps for now... Someday this may all be possible, but for now, I don't want to bite off more than I can chew.

 

I can implement a ROM PF option in the original kernel without much trouble. Split scores are on the drawing board too. But the ability to move scores to the top or bottom of the screen should come sooner rather than later.

 

At any rate, what name would be most appropriate for Bob's kernel? I was thinking along the lines of Frogger, since that was the game I had in mind originally, but not "the Frogger kernel" since Frogger is trademarked.

[kisrael]

Baby steps for now... Someday this may all be possible, but for now, I don't want to bite off more than I can chew.

 

I can implement a ROM PF option in the original kernel without much trouble.  Split scores are on the drawing board too.  But the ability to move scores to the top or bottom of the screen should come sooner rather than later.

Oh, I know about the baby steps...but since it is a "Kernal Request" I thought I'd throw in some daydreaming...but nothing TOO implausible...

 

I'm not sure about what you wrote...you seem to reply "ROM PF = not too much trouble, Split Screens = on drawing board, but movable scores = sooner rather than later" -- so why the "but"?

 

At any rate, what name would be most appropriate for Bob's kernel?  I was thinking along the lines of Frogger, since that was the game I had in mind originally, but not "the Frogger kernel" since Frogger is trademarked.

I'm kind of a geek, so I'd like something like "multisprite_sympf". I guess that's not much fun though.

 

"fishgo" since it was said you could write a simplified "go fish" in it?

 

or "multibob" or something silly like that...

[+batari]

I'm not sure about what you wrote...you seem to reply "ROM PF = not too much trouble, Split Screens = on drawing board, but movable scores = sooner rather than later" -- so why the "but"?

896601[/snapback]

"But" implies that top or bottom scores may come in the next release... ROM PF and split 3-digit scores little later.

[supercat]

"But" implies that top or bottom scores may come in the next release... ROM PF and split 3-digit scores little later.

896608[/snapback]

 

How hard would it be to add an option (static and/or run-time) to change the on-screen dimensions and positions of the playfield? The pixels right now are rather big and bulky--necessary to fill up the screen without using two much RAM, but not all games require filling the screen. A game like Breakout probably wouldn't need more than 11 rows, but it would benefit greatly from having the rows be smaller and located at the top of the screen.

[+batari]

"But" implies that top or bottom scores may come in the next release... ROM PF and split 3-digit scores little later.

896608[/snapback]

 

How hard would it be to add an option (static and/or run-time) to change the on-screen dimensions and positions of the playfield? The pixels right now are rather big and bulky--necessary to fill up the screen without using two much RAM, but not all games require filling the screen. A game like Breakout probably wouldn't need more than 11 rows, but it would benefit greatly from having the rows be smaller and located at the top of the screen.

896655[/snapback]

It wouldn't be too hard - I'll look into this.

[supercat]

It wouldn't be too hard - I'll look into this.

896657[/snapback]

 

As a brainstorm, if you can spare a couple bytes (and a few cycles between playfield 'rows') it might be useful to have a 'display list' which is accessed via indirect pointer and which lists, for each playfield 'row' the number of scan lines it should occupy and the source of the row's graphics. Using an indirect pointer for this would allow the user to switch among display lists during program execution, but would be much more 'affordable' than keeping display lists in RAM.

 

If the total size of all display lists was 256 bytes or less, the RAM requirement could be reduced to 1 byte (index into the start of the display list area). In that case, I would expect the display list code (run before each row of the screen) to look something like:

RowStart:
   ldx dispIndex
   lda DisplayList,x  ; Number of rows
   beq DisplayEnd
   sta shortcount
   inx
   lda DisplayList,x
   inx
   stx dispIndex
   tax
   lda 0,x
   sta column0
   lda 1,x
   sta column1
   lda 2,x
   sta column2
   lda 3,x
   sta column3
   ...
DisplayEnd:
   lda DisplayList+1,x
   sta dispIndex

Each display-list entry would contain the number of scan lines for which that row of playfield pixels should be displayed, and the source of the playfield data. Including the data source in the display list would allow for some more complex playfields than would otherwise be possible without increasing RAM requirements. The last display list entry would be a "0" followed by the index of the first display list entry for the current display list (thus avoiding the need to keep a pointer to the start of the current list in addition to a pointer to the current index within it).

[jjsonique]

I'll kick things off by saying that batari asked me to develop a new kernel for bBASIC, which allows more than 2 sprites onscreen at once.  Rather than taking half a page explaining the ins and outs of this kernel, just check out the attached demo and screenshot...

 

Thoughts?  You could make a simplified Go Fish! clone with this pretty easily. 

896574[/snapback]

 

This looks fantastic, vdub_bobby! I can't wait til this comes out! I've started making a game with bBasic, and was already plotting cumbersome ways to try to get around the 2 sprite limitation (mainly looping through changes to player0 and player1's sprite and location with different calls to drawscreen), but with the kernel you're working on I think I could forgoe those memory-consuming kludges.

[Jess Ragan]

I'll kick things off by saying that batari asked me to develop a new kernel for bBASIC, which allows more than 2 sprites onscreen at once.  Rather than taking half a page explaining the ins and outs of this kernel, just check out the attached demo and screenshot.

 

The one thing I will say is that it has a *symmetrical* PF - not the asymmetrical playfield of the current bB kernel.

 

Oh, and it isn't completely done, but it is mostly done.

 

Use the L joystick to move one of the sprites and the trigger to reset the ball/missiles.

 

Thoughts?  You could make a simplified Go Fish! clone with this pretty easily. 

896574[/snapback]

 

Holy shoehorn! That's incredible! All those onscreen players, without a hint of flicker... how DO you do it?!

 

One suggestion I would make is to allow the user to define color schemes for each player. Color layering was used to great effect in many Activision games; particularly Kaboom! with its famous striped-shirt bomber. It's why those games often look better than other 2600 titles, and the ability to layer colors would add immensely to Batari BASIC.

 

JR

[kisrael]

One suggestion I would make is to allow the user to define color schemes for each player.  Color layering was used to great effect in many Activision games; particularly Kaboom! with its famous striped-shirt bomber.  It's why those games often look better than other 2600 titles, and the ability to layer colors would add immensely to Batari BASIC.

I mention this in the Homesar thead...I agree with everything you say about color sprites (which is why I updated PlayerPal graphics editor) but kernals are so tight, you might have to give up some othe onscreen functionality to get that...

[Jess Ragan]

Is it possible to toggle between them in the BASIC programming code? Perhaps users could even specify which of the two functions they'd want at the beginning of the program...

 

JR

[potatohead]

How about?

 

usekernel [kernel name]

 

We can just give them names that sort of describe them, put those names into data statements, etc.. (Scary, but you know somebody is gonna do it.)

 

Put what the kernel does and it's memory map into the help file and let the users learn them as they need them.

 

However the naming and syntax go, the kernel we are using now should be the default kernel as it does not break anything already written.

Edited July 29, 2005 by potatohead

[+batari]

How about?

 

usekernel [kernel name]

 

We can just give them names that sort of describe them, put those names into data statements, etc..  (Scary, but you know somebody is gonna do it.)

 

Put what the kernel does and it's memory map into the help file and let the users learn them as they need them. 

 

However the naming and syntax go, the kernel we are using now should be the default kernel as it does not break anything already written.

900721[/snapback]

OK, so I'm trying to make bB more modular, so you can include only what you need to save space or include libraries for more complicated functions like fixed point math. Maybe kernels can be considered modules too and could be included in the same way.

 

There should be a default set of includes so that programmers don't have to write a long list of includes every time they write a simple program, and existing programs will still work.

 

But having a default set means you'd have to specifically uninclude something.

 

Therefore, the solution I've come up with is a "includes file." The default includes file will contain everything you are used to. If you want to include more or take things out, either modify the default includes file (not recommended but will work) use a different includes file. There would be a bB command to specify a different includes file.

 

Actually, there should be a few different include files packaged with bB for common combinations of kernels/modules. But you are welcome to make your own includes file and it will be fairly easy to do.

 

It's not really any harder this way, and it's much more powerful since you would have direct control over what modules or kernel (or kernels) get compiled in.

 

Is this a bad idea? Let me know before it all gets coded in...

Edited July 29, 2005 by batari

[Jess Ragan]

I've never really cared for include files myself. I took a C++ class in college and found it rather annoying that I had to mention four or five different include file references at the top of the code just to perform simple functions.

 

Having said that, I can understand their necessity in Batari BASIC. I just hope that the includes will be more user friendly than they are in C++. My suggestion is to give them logical names... for instance, including the standard graphics kernal and a multicolor player kernal in the same program could look like this...

 

initialization:

 

INCLUDE standard

INCLUDE multicolor

 

JR

 

P.S. I don't have too many complaints about the low resolution backgrounds, but what WOULD be really nice is the ability to select colors for each pixel, making puzzle games like Columns a possibility. Also, being able to create detailed border graphics (possibly with another kernal) would spice up games without requiring too much onscreen detail. I'm thinking of 8-bit strips of graphic data on either side of the screen, colored in layers.

[Thomas Jentzsch]

P.S.  I don't have too many complaints about the low resolution backgrounds, but what WOULD be really nice is the ability to select colors for each pixel, making puzzle games like Columns a possibility.

Each pixel won't work due to hardware and CPU time restrictions, but each pixel row shouldn't be a big problem.

[+batari]

It should be a little easier than C++. You don't need to specify every module in your Basic code that will included - just what set of modules, and you define the set in an external file. bB will be packaged with several standard sets so code is interchangeable without necessarily needing to also show the contents of your include file.

 

Basically, an include file will contain the names of the modules you want assembled in with your code. Right now, default.inc is the default, and it contains:

 

2600basicheader

std_kernel

startup

pf_drawing

pf_scrolling

std_routines

std_overscan

bB

2600basicfooter

 

This also specifies the order that the modules will appear in the generated assembly file. bB is the compiled Basic code.

 

The actual batari Basic source file would need no changes to include these modules.

 

If you wanted a different set of includes, you can use another file, such as:

 

include multisprite

 

Which would actually use the inclues from the multisprite.inc file. You can create your own include files or you can modify default.inc, though this isn't recommended if you want to keep your code portable.

 

I've never really cared for include files myself.  I took a C++ class in college and found it rather annoying that I had to mention four or five different include file references at the top of the code just to perform simple functions.

 

Having said that, I can understand their necessity in Batari BASIC.  I just hope that the includes will be more user friendly than they are in C++.  My suggestion is to give them logical names... for instance, including the standard graphics kernal and a multicolor player kernal in the same program could look like this...

 

initialization:

 

INCLUDE standard

INCLUDE multicolor

 

JR

 

P.S.  I don't have too many complaints about the low resolution backgrounds, but what WOULD be really nice is the ability to select colors for each pixel, making puzzle games like Columns a possibility.  Also, being able to create detailed border graphics (possibly with another kernal) would spice up games without requiring too much onscreen detail.  I'm thinking of 8-bit strips of graphic data on either side of the screen, colored in layers.

900740[/snapback]

[kisrael]

OK, so I'm trying to make bB more modular, so you can include only what you need to save space or include libraries for more complicated functions like fixed point math.  Maybe kernels can be considered modules too and could be included in the same way.

 

There should be a default set of includes so that programmers don't have to write a long list of includes every time they write a simple program, and existing programs will still work.

 

But having a default set means you'd have to specifically uninclude something.

 

Therefore, the solution I've come up with is a "includes file."  The default includes file will contain everything you are used to.  If you want to include more or take things out, either modify the default includes file (not recommended but will work) use a different includes file.  There would be a bB command to specify a different includes file.

 

Actually, there should be a few different include files packaged with bB for common combinations of kernels/modules.  But you are welcome to make your own includes file and it will be fairly easy to do.

 

It's not really any harder this way, and it's much more powerful since you would have direct control over what modules or kernel (or kernels) get compiled in.

 

Is this a bad idea?  Let me know before it all gets coded in...

Hmmm. Personally I don't mind include files that much, though I think technically they might not be needed, if the compiler "knew" what functions were in which module, it possibly could auto-include the appropriate modules. On the other hand, that might be too complex for you, or strange with things like a fixpoint math thing.

 

Also I'm not sure how many builtin functions are defined as subroutines and how many are just "inline text substitutions". It would be nice if any subroutine that is never called is left out of the ROM...

[vdub_bobby]

Is there any interest in a kernel that supports the paddles?

[kisrael]

I have a bit of interest...but what I'm REALLY jonesing for is something that can read all 4 paddles...but that's a ton of kernal time, plus my ideas would require 4 players and 4 missiles that can be placed anywhere, and so while I don't have much in mind for PF graphics, collision detection might be iffy, so maybe I just better call this a pipedream...

[Luigi301]

I'd like a ball and paddle kernel, I'm working on Breakout

Edited July 29, 2005 by Luigi301

[vdub_bobby]

I have a bit of interest...but what I'm REALLY jonesing for is something that can read all 4 paddles...but that's a ton of kernal time, plus my ideas would require 4 players and 4 missiles that can be placed anywhere, and so while I don't have much in mind for PF graphics, collision detection might be iffy, so maybe I just better call this a pipedream...

900920[/snapback]

Reading the paddle every scanline gets you pretty high resolution; you get a value between 0 and 192.

 

So. Reading paddles takes 9 cycles. So reading all four paddles every scanline isn't really feasible unless you only care to display 1 player and a symmetrical playfield, or 2 players, or 1 player and 1 missile...well, you get the idea.

 

But.

There are a couple of ways around this that come to mind:

1) If you don't need very high resolution on the paddles, you could read each paddle every 4th line. Then each paddle has a value between 0 and 48. This might be good enough, depending on what you are doing.

2) If you don't need a high sample rate, you could read each paddle on alternating frames; giving you the high resolution (0-192) for each paddle but only reading each one 15 times per second (as opposed to 60 times per second).

 

EDIT: I just noticed that you want 4 players and 4 missiles. You are aware that the 2600 only supports two players and two missiles? (I know you are )

 

So, what do you mean? 30 Hz flicker on everything?

 

ANOTHER EDIT: How about a paddle kernel where you specify which paddle to read? Then you can read all 4 paddles (alternating, at 15 reads per second) or 3, or 2, or just the one paddle, depending on what you want.

 

Plus, I think I can get 2 missiles (any height), 2 players (two-line resolution), and the asymmetrical playfield all on screen at once, with paddle reads. Well, I know I can, since that is basically what my Arkanoid-clone-demo kernel does.

Edited July 29, 2005 by vdub_bobby