bB Vertical Resolution

[Peter G]

I've been looking over the code for the maze game on the bB guide hosted by Random Terrain. There's one that's 23 blocks tall, and one that is 11 blocks tall. The site says bB defaults to 11 blocks tall (12 counting the bottom invisible row). How do I change that to the 23? And does that cost anything (number of sprites, certain pixels repeated, etc.)?

[+Random Terrain]

I used Superchip RAM:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#superchipram

 

 

But once I get done fixing up the DPC+ section, I'll probably make a version of that maze thing using the DPC+ kernel:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpcplus

 

The DPC+ kernel will probably be the main kernel that everyone will be using.

[Peter G]

I used Superchip RAM:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#superchipram

 

 

But once I get done fixing up the DPC+ section, I'll probably make a version of that maze thing using the DPC+ kernel:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpcplus

 

The DPC+ kernel will probably be the main kernel that everyone will be using.

 

So, for the basic default display that can just be tossed on a cart by anyone, the 11 high is it, with the possibility of adjusting the height of the blocks to help fill in more of the screen. Any programs using the DPC+ kernel would have to be manufactured with a Melody/Harmony board. No scrolling, but my idea is for a single boarder anyway (and that's just scrolling, I can still "move" between boards like Adventure, right?).

 

DPC+ supports multiple sprites. What about default? Is it possible to have, say, three sprites, one PLAYER0 and two PLAYER1's on seperate horizontal lines, or is it just the two sprites and that's it?

[+Random Terrain]

 

So, for the basic default display that can just be tossed on a cart by anyone, the 11 high is it, with the possibility of adjusting the height of the blocks to help fill in more of the screen. Any programs using the DPC+ kernel would have to be manufactured with a Melody/Harmony board. No scrolling, but my idea is for a single boarder anyway (and that's just scrolling, I can still "move" between boards like Adventure, right?).

 

DPC+ supports multiple sprites. What about default? Is it possible to have, say, three sprites, one PLAYER0 and two PLAYER1's on seperate horizontal lines, or is it just the two sprites and that's it?

 

The standard kernel has 2 sprites, 2 missiles, and one ball. If you use any kernel options, you can lose a missile or two. Superchip RAM gives you more variables and it can give you a higher resolution playfield. The Multisprite Kernel gives you 6 sprites, but there are a bunch of limitations (such as a mirrored playfield).

[+atari2600land]

Well, actually it would be player0, player1 and player2, not two player1s. I don't know how many sprites DPC+ uses (I haven't played with it much), but it can handle more than 3.

[+Random Terrain]

I don't know how many sprites DPC+ uses . . .

 

You can learn that by clicking on the link below:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpcplus

[SeaGtGruff]

So, for the basic default display that can just be tossed on a cart by anyone, the 11 high is it, with the possibility of adjusting the height of the blocks to help fill in more of the screen.

 

With the basic default display you can use the "pfheights" kernel option to adjust the heights of the individual playfield rows. As long as all of the row heights add up to 88, the playfield will still take up the same amount of the screen vertically. This could be useful if you want to make some of the playfield rows taller for some reason-- such as to make it easier for a tall sprite to move around in a maze:

   rem * Playfield example using pfheights
   set kernel_options pfheights
   dim p0x = a
   dim p0y = b
   pfheights:
   8
   12
   4
   12
   4
   12
   4
   12
   4
   12
   4
end
   pfscroll upup
   playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   X..............X...............X
   X..XXXX..XXXX..XXXXXXXX..XXXX..X
   X..X..................X..X.....X
   X..XXXXXXXXXX..XXXXX..X..X..XXXX
   X...........X......X.....X..X..X
   X..X..XXXX..X..XXXXXXXXXXX..X..X
   X..X.....X..X...............X..X
   X..XXXX..X..XXXXX..X..XXXXXXX..X
   X........X.........X...........X
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end
   COLUPF = $94
   player0:
   %01101100
   %00101000
   %00101000
   %00101000
   %10111010
   %10111010
   %10111010
   %01111100
   %00010000
   %00111000
   %00111000
end
   player0x = 80
   player0y = 50
loop
   if collision(player0,playfield) then gosub knock_back
   p0x = 0 : p0y = 0
   if joy0left then p0x = -1
   if joy0right then p0x = 1
   if joy0up then p0y = -1
   if joy0down then p0y = 1
   player0x = player0x + p0x
   player0y = player0y + p0y
   COLUP0 = $3A
   drawscreen
   goto loop
knock_back
   player0x = player0x - p0x
   player0y = player0y - p0y
   return

pfheights_example.bas

pfheights_example.bas.bin

[Peter G]

 

The standard kernel has 2 sprites, 2 missiles, and one ball. If you use any kernel options, you can lose a missile or two. Superchip RAM gives you more variables and it can give you a higher resolution playfield. The Multisprite Kernel gives you 6 sprites, but there are a bunch of limitations (such as a mirrored playfield).

 

Would using Superchip RAM kernel mean that, if I want a cart made, it has to have the actual Superchip RAM on the cart to work? I guess I'm just wondering if using that means the resulting program would only be practical on an emulator instead of an actual "play it on your TV" cart.

[+Random Terrain]

Would using Superchip RAM kernel mean that, if I want a cart made, it has to have the actual Superchip RAM on the cart to work? I guess I'm just wondering if using that means the resulting program would only be practical on an emulator instead of an actual "play it on your TV" cart.

 

When CPUWIZ put my game on carts, he had to use special ones:

 

http://atariage.com/forums/topic/191569-wanted-atari-2600-superchip-sara-carts/

[+Gemintronic]

Using SuperChip memory sometimes means the price goes up. It also sometimes means the cart maker will ask you to salvage your own carts for his use. Honestly, the last bit is the reason I avoid using extra RAM.

[SeaGtGruff]

I thought Melody carts can do Superchip bank switching without having to use actual Sara chips?

[+Gemintronic]

I thought Melody carts can do Superchip bank switching without having to use actual Sara chips?

 

Of course. But, if Melody boards are not available you might have to consider other sources.

[SeaGtGruff]

 

Of course. But, if Melody boards are not available you might have to consider other sources.

 

Melody boards might not be available?!?

 

Actually, I assume (or hope) that you mean someone might want to make carts themselves, or have them produced elsewhere, instead of using AtariAge/Albert. On the other hand, I guess it's possible that Albert might not have any Melody boards available.

[+Random Terrain]

Actually, I assume (or hope) that you mean someone might want to make carts themselves, or have them produced elsewhere, instead of using AtariAge/Albert. On the other hand, I guess it's possible that Albert might not have any Melody boards available.

 

Here's a related post:

 

http://atariage.com/forums/topic/211981-melody-boards/?p=2748317

 

I removed the Melody Upgrade Option from the store because there are several games (and several upcoming) that require the Melody board, and supply is an issue. Perhaps at some point in the future I can make that option available again, but for now I'm going to use the Melody boards for games that require them. For upcoming games, this includes Space Rocks, Seaweed Assault, Star Castle, two holiday-themed games, and others in the pipeline. And presently in the store there's Chetiry and Epic Adventure, as well as a few others (like Cave-In and Defender Arcade).

 

..Al

[Albert]

Melody boards might not be available?!?

 

Actually, I assume (or hope) that you mean someone might want to make carts themselves, or have them produced elsewhere, instead of using AtariAge/Albert. On the other hand, I guess it's possible that Albert might not have any Melody boards available.

This is only a temporary issue. We are working on solutions to make the Melody boards more plentiful.

 

..Al

[Peter G]

 

When CPUWIZ put my game on carts, he had to use special ones:

 

http://atariage.com/forums/topic/191569-wanted-atari-2600-superchip-sara-carts/

 

Okay, so even if I don't use any procedures that would call the SuperRAM chip, it won't work without it.

 

Just trying to understand what I can and cannot do, and what I can explore further. "A man's got to know his limitations." (So says a guy who, last week, was wondering if he could somehow make a Spleef game for the Atari until he started really thinking about it.... )

[Peter G]

 

 

With the basic default display you can use the "pfheights" kernel option to adjust the heights of the individual playfield rows. As long as all of the row heights add up to 88, the playfield will still take up the same amount of the screen vertically. This could be useful if you want to make some of the playfield rows taller for some reason-- such as to make it easier for a tall sprite to move around in a maze:

   rem * Playfield example using pfheights
   set kernel_options pfheights
   pfheights:
   8
   12
   4
   12
   4
   12
   4
   12
   4
   12
   4
end

 

Am I correct in assuming that each of those numbers corresponds to each line of vertical resolution (first number is first line, etc.)?

[SeaGtGruff]

 

Am I correct in assuming that each of those numbers corresponds to each line of vertical resolution (first number is first line, etc.)?

 

Yes, that's correct-- each number indicates the height (number of double-lines) for a given playfield row. (The bB kernel uses double-line resolution, meaning each "line" is actually *two* scan lines, or what [iIRC] is commonly called a two-line kernel.) And for some reason the first playfield row has to be 8, or bB gets messed up.