Should this work?

[yuppicide]

I'm using 8kSC and the following:

 

set kernel_options no_blank_lines background

 

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

[Primordial Ooze]

The order of the options doesn't matter, but there are limitations as to which options can be used alone and/or together:

 

 

 

Acceptable singles:

player1colors

no_blank_lines

pfcolors

pfheights

 

Invalid singles:

playercolors

readpaddle

background

 

Acceptable combinations:

pfcolors pfheights

pfcolors pfheights background

pfcolors no_blank_lines

pfcolors no_blank_lines background

player1colors no_blank_lines

player1colors pfcolors

player1colors pfheights

player1colors pfcolors pfheights

player1colors pfcolors background

player1colors pfheights background

player1colors pfcolors pfheights background

player1colors no_blank_lines readpaddle

player1colors no_blank_lines pfcolors

player1colors no_blank_lines pfcolors background

playercolors player1colors pfcolors

playercolors player1colors pfheights

playercolors player1colors pfcolors pfheights

playercolors player1colors pfcolors background

playercolors player1colors pfheights background

playercolors player1colors pfcolors pfheights background

no_blank_lines readpaddle

 

Yes it should.

[jrok]

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

 

Same here. I'm not really sure what is meant by "Change background color instead of playfield color." How do you define background lines? And since it says "instead of playfield color", how is it possible to that some valid kernel options contain both pfcolors and background?

[yuppicide]

Same here. I'm not really sure what is meant by "Change background color instead of playfield color." How do you define background lines? And since it says "instead of playfield color", how is it possible to that some valid kernel options contain both pfcolors and background?

 

Well, you don't define background lines it's just one color. But, you are right.. how is it possible you can do PFCOLORS and BACKGROUND as valid options, but yet it says I can only do one or the other.

 

Either way I can't get it to compile using background and when I try to change background color it's all screwed up. Blue comes out as a bright sea green color for me if I try to change background color without the kernel background option.

 

I have a game where you control a little fish, so I needed the water blue, but wanted my playfield a "coral" like color.. purple, green, light brown, something other than black.

Edited October 20, 2008 by yuppicide

[+Random Terrain]

I never understood what the purpose of background is. Maybe I'm confused, but I thought COLUBK did the same thing? Does COLUBK not work with Superchip RAM?

[Robert M]

I'm using 8kSC and the following:

 

set kernel_options no_blank_lines background

 

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

 

 

You must include the pfcolors kernel option with the background kernel option. Then you must use the pfcolors: construct to make a table of 11 colors (assuming you are using the standard 11 high resolution. Like this:

 

  pfcolors:
 $f5
 $f5
 $f5
 $43
 $f5
 $f5
 $f5
 $f5
 $f5
 $f5
 $f5
end

 

Normally with the pfcolors kernel option set, the table of pfcolors would be applied to the COLUPF register on each row change. With the additional background option set, however, the kernel writes to the COLUBK register instead of COLUPF.

 

So with pfcolors you can have a new PF pixel color each row with a solid background. If you throw in the background option, then you get rows of color in the background PF, and the PF pixels are all the same color.

 

Cheers!

[Robert M]

double post

Edited October 21, 2008 by Robert M

[+Random Terrain]

OK, now I get it. It forces the pfcolors data into the background:

 

http://www.atariage.com/forums/index.php?s...t&p=1356367

[yuppicide]

On the bB page, when it says "INSIDE GAME LOOP" that means it must be inside the game loop, but for example COLUBK doesn't say anything, so can that be outside the loop OR inside as well?

[+Random Terrain]

On the bB page, when it says "INSIDE GAME LOOP" that means it must be inside the game loop, but for example COLUBK doesn't say anything, so can that be outside the loop OR inside as well?

This should answer your question:

 

http://www.randomterrain.com/atari-2600-me....html#ephvarreg

[SeaGtGruff]

The ability to change both playfield *AND* background colors isn't part of the standard options-- it's something somebody added with a customized include file IIRC. There's a thread about it somewhere.

 

Michael

[yuppicide]

I figured out why my colors were screwed up.. well I shouldn't say I figured it out, though.

 

In my one game I'm doing COLUBK = 132 (blue) but it comes out as PAL purple. When I set it to 212, PAL blue, it looks like I wanted.

 

So somehow even though I specify set tv ntsc it's still doing PAL. Maybe something in my code is taking too long and making the emulator think PAL?

[+Random Terrain]

Maybe something in my code is taking too long and making the emulator think PAL?

Using Stella, did you hit the button above Tab (`) for the debugger, stare at Scanline:, then hold down Alt + f to see if Scanline: changes from frame to frame. If it stays at 262, everything is great:

 

http://www.atariage.com/forums/index.php?s...t&p=1600284

[yuppicide]

Everything looks okay. It's always at 262 unless you die, in that case the program looks for a collision between you and the playfield and does REBOOT. When that happens it shoots up to 800 something.

 

I am just looking at my code for the skulltitle and when the screen changes yellow and the lightning sound occurs the scanline changes.

 

EDIT: I originally asked what ALT-F did.. I figured it out. Sweet.

 

Using Stella, did you hit the button above Tab (`) for the debugger, stare at Scanline:, then hold down Alt + f to see if Scanline: changes from frame to frame. If it stays at 262, everything is great:

 

http://www.atariage.com/forums/index.php?s...t&p=1600284

Edited October 22, 2008 by yuppicide

[+Random Terrain]

In case anyone wants to know, I added that info to my version of the bB page under Timing:

 

http://www.randomterrain.com/atari-2600-me...nds.html#timing

[yuppicide]

Great! How about adding the updated bAtari Basic files to your page as well?

 

In case anyone wants to know, I added that info to my version of the bB page under Timing:

 

http://www.randomterrain.com/atari-2600-me...nds.html#timing