Kernel request thread

[jjsonique]

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...

 

I think includes would be a great idea, and would be very useful for allowing programmers to "pick and choose" which kernel elements they want for their own game. Please go forward with it.

[kisrael]

You're right; I meant 30 mhz flicker.

But then collision detection would either depend on some weird round robin rules or have to be done by comparing positions; not fun.

 

Not reading every paddle every frame never occured to me, but would probably still have pretty decent results. 30hz or even 15hz is probably still pretty grand (I wonder what Warlords does)

 

The other thing to keep in mind is padle games should likely only use a small range of the paddle...it has a LOT more side to side movement than does a human wrist!

[vdub_bobby]

You're right; I meant 30 mhz flicker.

But then collision detection would either depend on some weird round robin rules or have to be done by comparing positions; not fun.

Yeah, flicker complicates collision detection. It took a big chunk of ROM, a lot of testing, and a lot of headaches to get the (software) collision detection in Go Fish! to work correctly. But, ultimately, software collision detection is the programmer's problem, not the kernel's!

Not reading every paddle every frame never occured to me, but would probably still have pretty decent results.  30hz or even 15hz is probably still pretty grand (I wonder what Warlords does)

Me too. Maybe a combination of the two methods?

The other thing to keep in mind is padle games should likely only use a small range of the paddle...it has a LOT more side to side movement than does a human wrist!

900950[/snapback]

There was a short discussion of this on [stella] a while back - I think the range is from less than 1 scanline to more than 1 frame! So you aren't ever going to read the entire range of the paddle.

[vdub_bobby]

How about interest in a maze kernel? Think Dark Cavern, Pac-Man, Ms. Pac-Man, Alien, Berzerk; symmetrical, in other words.

 

Or asymmetrical, like in Venture?

[kisrael]

You're right; I meant 30 mhz flicker.

But then collision detection would either depend on some weird round robin rules or have to be done by comparing positions; not fun.

Yeah, flicker complicates collision detection. It took a big chunk of ROM, a lot of testing, and a lot of headaches to get the (software) collision detection in Go Fish! to work correctly. But, ultimately, software collision detection is the programmer's problem, not the kernel's!

Yeah, but hardware based collision detection is one of the very, very few things an atari programmer has going for him or her...it's tough to give it up!

 

The other thing to keep in mind is padle games should likely only use a small range of the paddle...it has a LOT more side to side movement than does a human wrist!

There was a short discussion of this on [stella] a while back - I think the range is from less than 1 scanline to more than 1 frame! So you aren't ever going to read the entire range of the paddle.

I remember that talk, and there were two seperate ranges discussed:

time and space. Timewise, how long with the thing take to discharge, and that could be at the extreme ranges you mentioned. Spacewise, though, and I think this is the saving grace, it's ok to just read something bigger than a scanline (or two?) and smaller than a frame, that should be a decent chunk of the paddles twisting range, and probably greater than the human wrist's twisting range...

 

Hmm. I actually haven't thought about if drawkernal is handing the vblank as well. I don't know if bB is giving full use of vblank AND overscan or just one or the other? Since I assume drawkernal is doing the vsync...must be overscan only? (I know I should crack open the ASM.) At somepoint it might be nice to seperate vblank and kernaldrawing, so that the (slightly more advanced programmer) can play with both vblank and overscan time...or am I missing something?

[jjsonique]

How about interest in a maze kernel?  Think Dark Cavern, Pac-Man, Ms. Pac-Man, Alien, Berzerk; symmetrical, in other words.

 

Or asymmetrical, like in Venture?

900999[/snapback]

 

I'd be pretty interested in an asymmetrical maze kernel (though a symmetrical would also be fine, since I imagine it saves a considerable amount of memory and/or cycles).

 

And I'm salivating with anticipation for your multi-sprite kernel, of course.

Edited July 29, 2005 by jjsonique

[vdub_bobby]

Hmm.  I actually haven't thought about if drawkernal is handing the vblank as well.  I don't know if bB is giving full use of vblank AND overscan or just one or the other? Since I assume drawkernal is doing the vsync...must be overscan only? (I know I should crack open the ASM.)  At somepoint it might be nice to seperate vblank and kernaldrawing, so that the (slightly more advanced programmer) can play with both vblank and overscan time...or am I missing something?

901015[/snapback]

I'm pretty sure that the current bB only gives you the overscan to play with. Vblank belongs to bB.

 

batari has stated a couple of times that bB gives the programmer about 2700 cycles, which translates to ~35.5 scanlines. I think you have the overscan plus a few unused scanlines from the visible kernel.

[+batari]

Hmm.  I actually haven't thought about if drawkernal is handing the vblank as well.  I don't know if bB is giving full use of vblank AND overscan or just one or the other? Since I assume drawkernal is doing the vsync...must be overscan only? (I know I should crack open the ASM.)  At somepoint it might be nice to seperate vblank and kernaldrawing, so that the (slightly more advanced programmer) can play with both vblank and overscan time...or am I missing something?

901015[/snapback]

I'm pretty sure that the current bB only gives you the overscan to play with. Vblank belongs to bB.

 

batari has stated a couple of times that bB gives the programmer about 2700 cycles, which translates to ~35.5 scanlines. I think you have the overscan plus a few unused scanlines from the visible kernel.

901034[/snapback]

That is correct. I couldn't imagine how I would automatically spread code over two distinct areas (vblank and overscan) so I just put it all in one place.

 

It's good I did in a way, since Vblank contains five sprite repositioning routines which can take a lot of time if all sprites have large x-values (exceeding 165, that is, which actually wraps to the next scanline.)

 

The above is also part of the reason why allowing any kernel as a subkernel is a little tough to do, and would make things worse, not better. Instantly, you move calculations out of vblank and into the kernel itself, which requires a bunch of blank lines at the very least. For example, making the current kernel truly modular would mean moving all five repositioning routines out of vblank since you can't be sure what other subkernels might do, and the five repos routines take a lot of time.

 

All in all, kernels work (and look) much better if they are packaged as one unit. This might require dozens of different kernels with small changes, but I think that good documentation will make it clear which kernels do what.

[+batari]

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...

900759[/snapback]

Auto-including of modules did occur to me, but I decided against it. Part of the reason is that it's easier to code, but the other part is because I want to make it possible for people to create their own modules without needing to crack into bB's C source to figure out how to auto-include them.

 

Basically, support for a user module would make it possible to include a user-defined set of functions or subroutines, and could be written in bB or totally in asm. A subroutine would be just that - something that is accessed from the mainline program by gosub. A function would require a number of input values and could return values as well - there should be direct support for returning a single 8-bit value (or perhaps 8.8 fixed point too) and indirect support for returning multiple values by assigning to the temp vars and accessing them after calling the function.

[kisrael]

Yeah i can see the logic now...I forgot the overhead of what bB takes care of for the user. If it weren't for that, I could see stuff like

 

100 vblank

[some game logic]

500 drawkernal

[more logic]

800 goto 100

 

but that's more in the "bB as stepping stone to ASM" mode than "bB as easy to use BASIC" mode.

[supercat]

Yeah i can see the logic now...I forgot the overhead of what bB takes care of for the user. If it weren't for that, I could see stuff like

 

100  vblank

  [some game logic]

500  drawkernal

[more logic]

800 goto 100

 

but that's more in the "bB as stepping stone to ASM" mode than "bB as easy to use BASIC" mode.

901065[/snapback]

 

How about providing that if a subroutine called vblank exists, it will be jmp'ed from within drawscreen and must exit via jmp to vblankexit? This would allow users who wanted to max out their scan line usage to do so, without complicating anything for people who didn't.

[vdub_bobby]

How about providing that if a subroutine called vblank exists, it will be jmp'ed from within drawscreen and must exit via jmp to vblankexit?  This would allow users who wanted to max out their scan line usage to do so, without complicating anything for people who didn't.

901086[/snapback]

Why not jsr to it and have it exit with a "return"?

[supercat]

Why not jsr to it and have it exit with a "return"?

901088[/snapback]

 

An extra two bytes on the stack for no good reason.

[+batari]

Yeah i can see the logic now...I forgot the overhead of what bB takes care of for the user. If it weren't for that, I could see stuff like

 

100  vblank

  [some game logic]

500  drawkernal

[more logic]

800 goto 100

 

but that's more in the "bB as stepping stone to ASM" mode than "bB as easy to use BASIC" mode.

901065[/snapback]

 

How about providing that if a subroutine called vblank exists, it will be jmp'ed from within drawscreen and must exit via jmp to vblankexit? This would allow users who wanted to max out their scan line usage to do so, without complicating anything for people who didn't.

901086[/snapback]

I could do this easily enough, but it would be done by placing a bB module in vblank by use of organizing the includes in an includes file.

[vdub_bobby]

Why not jsr to it and have it exit with a "return"?

901088[/snapback]

 

An extra two bytes on the stack for no good reason.

901093[/snapback]

Yeah, but bB already reserves 6 bytes for the stack that are unused (or are supposed to be, I think) when drawscreen is called. So you have the bytes; why not use them?

[supercat]

Yeah, but bB already reserves 6 bytes for the stack that are unused (or are supposed to be, I think) when drawscreen is called.  So you have the bytes; why not use them?

901104[/snapback]

 

If bB uses them, then that would limit the user's program to two-deep subroutine nesting within the vbl routine instead of three-deep. While two-deep nesting would suffice for most programs, why impose the restriction if there's no need to?

[vdub_bobby]

Yeah, but bB already reserves 6 bytes for the stack that are unused (or are supposed to be, I think) when drawscreen is called.  So you have the bytes; why not use them?

901104[/snapback]

 

If bB uses them, then that would limit the user's program to two-deep subroutine nesting within the vbl routine instead of three-deep. While two-deep nesting would suffice for most programs, why impose the restriction if there's no need to?

901127[/snapback]

Makes sense.

[appleo]

Can someone write a kernel with the following

 

* 8 sprites (for 4 creatures, 4 missiles)

 

* support for the 2600 keyboard controllers

 

Thanks

[vdub_bobby]

Can someone write a kernel with the following

 

* 8 sprites (for 4 creatures, 4 missiles)

 

* support for the 2600 keyboard controllers

 

Thanks

939409[/snapback]

You'll need to be a little more specific. Can the missile-sprites be dots/lines, or do they need to have more complex shapes?

 

What are the spatial relationships between the sprites? Specifically, do more than two of them need to be on the same scanline at the same time?

 

Finally, you already have this with the current bB kernel if you implement flicker.

Edited September 28, 2005 by vdub_bobby

[appleo]

The missile sprites can be dots or small squares.

The sprites/missiles can be one color but each needs their own color.

It is possible all 8 objects might be on the same scan line at the same time.

I am a complete newbie to 2600 coding - what is flicker?

I probably have some reading to do

 

Can someone write a kernel with the following

 

* 8 sprites (for 4 creatures, 4 missiles)

 

* support for the 2600 keyboard controllers

 

Thanks

939409[/snapback]

You'll need to be a little more specific. Can the missile-sprites be dots/lines, or do they need to have more complex shapes?

 

What are the spatial relationships between the sprites? Specifically, do more than two of them need to be on the same scanline at the same time?

 

Finally, you already have this with the current bB kernel if you implement flicker.

939431[/snapback]

[vdub_bobby]

The missile sprites can be dots or small squares.

The sprites/missiles can be one color but each needs their own color.

It is possible all 8 objects might be on the same scan line at the same time.

I am a complete newbie to 2600 coding - what is flicker?

I probably have some reading to do

Yeah, read the Stella Guide

[+batari]

The missile sprites can be dots or small squares.

The sprites/missiles can be one color but each needs their own color.

It is possible all 8 objects might be on the same scan line at the same time.

I am a complete newbie to 2600 coding - what is flicker?

I probably have some reading to do

 

Can someone write a kernel with the following

 

* 8 sprites (for 4 creatures, 4 missiles)

 

* support for the 2600 keyboard controllers

 

Thanks

939409[/snapback]

You'll need to be a little more specific. Can the missile-sprites be dots/lines, or do they need to have more complex shapes?

 

What are the spatial relationships between the sprites? Specifically, do more than two of them need to be on the same scanline at the same time?

 

Finally, you already have this with the current bB kernel if you implement flicker.

939431[/snapback]

939491[/snapback]

vdub_bobby's multisprite kernel might work when it's integrated into bB - it has 5 sprites and 3 missile-like objects. One of the sprites could be used as a missile if that's what you need. The only issue with this kernel is it doesn't allow more than two sprites on a particular scanline.

 

Two independently-moving sprites per scanline is a limitation of the 2600's hardware. Games that display more must display the sprites on alternate frames. In the future, I may implement Manuel's algorithm for "intelligent flicker" which will allow flicker to be done automatically instead of doing it explicitly like you must do now.

[appleo]

Some questions:

 

1) So displaying sprites on alternate frames is called "flicker" ? (I tried searching forums for a definition, but didn't find it) I assume it's called this because they literally flicker - how did they get multiple non-flickering objects then in games like Space Invaders, Galaxian, Combat?

 

2) I've heard the term "player/missile graphics" for a long time, what is the difference between a sprite and a missile object? I'm used to Commodore 64 where everything is just a sprite.

 

Thanks

 

The missile sprites can be dots or small squares.

The sprites/missiles can be one color but each needs their own color.

It is possible all 8 objects might be on the same scan line at the same time.

I am a complete newbie to 2600 coding - what is flicker?

I probably have some reading to do

 

Can someone write a kernel with the following

 

* 8 sprites (for 4 creatures, 4 missiles)

 

* support for the 2600 keyboard controllers

 

Thanks

939409[/snapback]

You'll need to be a little more specific. Can the missile-sprites be dots/lines, or do they need to have more complex shapes?

 

What are the spatial relationships between the sprites? Specifically, do more than two of them need to be on the same scanline at the same time?

 

Finally, you already have this with the current bB kernel if you implement flicker.

939431[/snapback]

939491[/snapback]

vdub_bobby's multisprite kernel might work when it's integrated into bB - it has 5 sprites and 3 missile-like objects. One of the sprites could be used as a missile if that's what you need. The only issue with this kernel is it doesn't allow more than two sprites on a particular scanline.

 

Two independently-moving sprites per scanline is a limitation of the 2600's hardware. Games that display more must display the sprites on alternate frames. In the future, I may implement Manuel's algorithm for "intelligent flicker" which will allow flicker to be done automatically instead of doing it explicitly like you must do now.

939621[/snapback]

[+batari]

Some questions:

 

1) So displaying sprites on alternate frames is called "flicker" ? (I tried searching forums for a definition, but didn't find it) I assume it's called this because they literally flicker - how did they get multiple non-flickering objects then in games like Space Invaders, Galaxian, Combat?

 

2) I've heard the term "player/missile graphics" for a long time, what is the difference between a sprite and a missile object? I'm used to Commodore 64 where everything is just a sprite.

939649[/snapback]

1- I made sure to qualify my statement to say two "independently moving" sprites. You can have more than one sprite per scanline if they are "dependently moving" meaning the 2600 can display two or three copies of each sprite natively at a fixed distance apart. Using programming tricks you can get more, like in Galaxian. But the point is, the objects move as a group.

 

This is not the complete story, however... There are other dirty tricks out there but it's unlikely that bB will be able to support all of them unless you do some kernel hacking.

 

2- a "sprite" is 8 bits wide, but a "missile" is one bit, meaning it's either on or off, and therefore missiles can only be in square or rectangular shapes.

[mos6507]

2- a "sprite" is 8 bits wide, but a "missile" is one bit, meaning it's either on or off, and therefore missiles can only be in square or rectangular shapes.

939673[/snapback]

 

Per scanline. Across the entire screen a missile or a ball can be any shape you can draw with one variable sized brushpoint, so to speak, assuming you have the CPU time to adjust its position, width, etc.... That's why missiles have been used for things like starfields, road borders on things like Pole Position, pseudo sprites in M-network games, etc...

 

I think the Death Derby kernel might make a good bBasic kernel because it gives you an 11x32 pseudo bitmap and 5 objects with no flicker. Only the ball has position limitations (has to be slotted between the tombstones) I could see other types of games that could be done with it.