Coupla playfield questions.

[potatohead]

First the good news. The paddles work great. I love paddle games, so I'm having a good time with that part of things.

 

My question(s) are:

 

1. Is it possible to have the higher vertical resolution playfield, without it being a RAM playfield, and without resorting to super chip code, and still have the use of the paddle functions?

 

2. Is it possible to change kernels in a running game, without making a mess of the screen, ie: maybe go to RAM playfield and back?

[SeaGtGruff]

1. Is it possible to have the higher vertical resolution playfield, without it being a RAM playfield, and without resorting to super chip code, and still have the use of the paddle functions?

 

2. Is it possible to change kernels in a running game, without making a mess of the screen, ie: maybe go to RAM playfield and back?

You can have a higher-resolution playfield without the Superchip if you use a ROM playfield, as is done in the multisprite kernel. Of course, that means you can't actively change individual pixels on the playfield-- you'd have to define a whole new playfield in ROM. And I think you might need to create a custom kernel for it-- although that might not be too difficult, since the Superchip option uses absolute addresses for the playfield, so all you'd need to do is modify the kernel to compile as if it's using the Superchip option, without actually using the Superchip option, and then point the playfield pointers to your playfield ROM data.

 

Another possibility would be to modify the kernel to do away with the asymmetrical playfield, and just use a standard reflected playfield, which would let the RAM playfield have twice the normal resolution.

 

As for switching kernels mid-game, yes, you can do that, as long as both kernels are present in the code. If you have two or more kernels, you'll need different names for them, and you'll need to call the extra kernels with a gosub instead of with the drawscreen command (which is really just a special kind of gosub command, anyway, since it compiles to a JSR command that calls the kernel).

 

Michael

Edited July 27, 2009 by SeaGtGruff

[potatohead]

So let's say I do go ahead and code for superchip. Given the harmony deal, perhaps that won't end up being the negative it usually is.

 

I get the higher resolution RAM playfield anyway, right?

 

Is there a code template somewhere showing this?

 

And a follow on question then: When the playfield command is used, non superchip mode, is that a ROM playfield?

[CurtisP]

You can have a higher-resolution playfield without the Superchip if you use a ROM playfield, as is done in the multisprite kernel. Of course, that means you can't actively change individual pixels on the playfield-- you'd have to define a whole new playfield in ROM. And I think you might need to create a custom kernel for it-- although that might not be too difficult, since the Superchip option uses absolute addresses for the playfield, so all you'd need to do is modify the kernel to compile as if it's using the Superchip option, without actually using the Superchip option, and then point the playfield pointers to your playfield ROM data.

 

Actually, you shouldn't need to modify the kernel at all, just 2600basic.h. And instead of a playfield command create a data table names playfield. I will play with the code this week and see what I can come up with.

[+Random Terrain]

Actually, you shouldn't need to modify the kernel at all, just 2600basic.h. And instead of a playfield command create a data table names playfield. I will play with the code this week and see what I can come up with.

Cool. Can't wait to see what you come up with.

[RevEng]

Yeah, I tried that before. The ram is in page zero and your rom data isn't. The timing differences cause a corrupted display.

 

It needs a kernel change.

[SeaGtGruff]

Yeah, I tried that before. The ram is in page zero and your rom data isn't. The timing differences cause a corrupted display.

 

It needs a kernel change.

I'm not sure, because the Superchip RAM isn't in page zero, so using a ROM playfield shouldn't take any more cycles than using a Superchip playfield. However, you can't just point the playfield to ROM without specifying the Superchip option as well, because yes, the code (the addressing mode when reading the playfield data) would be different. But I haven't tried using a ROM playfield with the standard kernel, so I'm not sure what all would need to be changed-- whether it be modifying the kernel itself, or simply changing the bB header file, etc.

 

Michael

[RevEng]

Ah, see what you mean. Indeed, it looks like I didn't try with Superchip ram.

 

Carry on.

[SeaGtGruff]

Ah, see what you mean. Indeed, it looks like I didn't try with Superchip ram.

 

Carry on.

Actually, I think potatohead wanted to *not* use Superchip RAM, so that's why I'd originally suggested modifying the kernel to get it to compile "as if" for Superchip, but without having to actually use the Superchip. What I mean is, the standard kernel has all kinds of compiler directive statements in it, which cause the kernel to be compiled one way or another depending on which options have been selected. So I think all you should need to do is search for all the places where a compiler directive checks for the Superchip option to decide whether to compile the code having to do with the playfield one way or the other, and basically change it so it will always compile for a playfield that's in "upper memory" (i.e., non-page-zero memory), where absolute addresses are required. Then I think all you'd need to do for the rest of it is make sure the playfield variable is pointing to wherever the data is located-- whether it's in Superchip RAM, E7 RAM (used by the M-Network bankswitching method), CBS RAM, 4A50 RAM, or just plain old ROM. And of course you'd need to define your playfield data, too.

 

Michael

[potatohead]

That's the case.

 

However, it's not a big deal. Not worth serious hacking at this point. Really, I was just wondering whether or not there was an easy option to trade RAM for resolution in the standard kernel sans super chip. Thanks for the info.

[+batari]

That's the case.

 

However, it's not a big deal. Not worth serious hacking at this point. Really, I was just wondering whether or not there was an easy option to trade RAM for resolution in the standard kernel sans super chip. Thanks for the info.

There are at least three ways that I can think of that don't require too much effort.

 

If you don't mind a limited sort of playfield (reflected, mirrored, or only covering the middle 16 pixels) then I posted a hack that allows this.

 

Alternatively, if you move things around in 2600basic.h (place user variables just before playfield variables) and change pfres, it can use more standard RAM at the expense of variables. If you don't mind using 24 of the 26 variables, you can go as high as 18, though 16 would work better since it evenly divides 96 and would leave 10 variables to spare.

 

A third way is to use the modification by cd-w. He rewrote the kernel to use a larger gap between blocks in trade for a ROM playfield. Look in his blog for details.