Jump to content
IGNORED

Question about Playfield width/height


rcoltrane

Recommended Posts

I'm a newbie here but I've compiled my own games with Visual Batari Basic, so I've read a lot of documents, but I couldn't find an answer for my doubt.

 

Why I can't reach Atari 2600 full screen resolution to make my playfields larger and thinner screen rows? For example, I've taken the Breakout sample code from Batari source and I've included a wall of bricks as a playfield. But when I compile it, the wall height is too large and it doesn't reach both left/right sides of the screen. Why does that happen? Is it possible to fix or it requires a kernel tweaking?

Link to comment
Share on other sites

the wall height is too large and it doesn't reach both left/right sides of the screen. Why does that happen? Is it possible to fix or it requires a kernel tweaking?

The 2600 doesn't have screen memory per se-- in essence, the graphics registers hold only one line's worth of data, so that data will be repeated on subsequent lines unless the programmer manually updates the graphics registers between one line and the next.

 

Furthermore, the playfield graphics registers cover only the left half of the screen, so that data will be repeated on the right half of the screen-- or reflected, depending on the playfield control register-- unless the programmer manually updates the playfield graphics registers between the left side of the screen and the right side.

 

The standard batari Basic kernel uses the 2600's built-in RIOT chip RAM to create screen memory for the playfield. But since there's only 128 bytes of RAM, which must be used for other things as well (the game's "user" variables, plus batari Basic's "system" variables so to speak, not to mention the stack), some compromises had to be made-- namely, there are only 12 playfield rows. However, the last row is actually "hidden" behind the score row, so you can't see it unless you scroll the playfield.

 

Also, there's only so much time to update all of the graphics registers, so additional compromises had to be made-- namely, the sprite graphics use a 2-line kernel, and the playfield graphics memory doesn't include data for the PF0 register. Since the standard batari Basic kernel uses a reflected playfield (PF0, PF1, PF2, PF2, PF1, and PF0), and the PF0 register has only 4 bits, this means the central 32 playfield pixels are mapped to screen memory, but the leftmost 4 playfield pixels and the rightmost 4 playfield pixels are not. You can still write to PF0 to define its 4-pixel pattern, but the left and right sides of the screen will be mirror images of each other, and the pattern will extend from the top of the screen to the bottom of the screen.

 

The standard kernel lets you define the heights of the playfield rows, but you're still limited to 12 rows (11 visible rows and 1 "hidden" row).

 

If you use the multisprite kernel, the playfield data is read from ROM instead of mapped to RAM, so you can define as many rows as you want-- although the playfield will either be repeated or reflected (i.e., you can't draw an asymmetrical playfield as in the standard kernel).

 

If you use the standard kernel with Superchip bankswitching, the playfield screen memory is moved to the Superchip RAM, which allows you to define more playfield rows, hence the playfield rows can be thinner.

 

And if you use the DPC+ kernel, you can do all sorts of neat things. I'm embarrassed to say that I haven't experimented with the DPC+ capabilities yet, so I'm not sure of everything it can do-- but IIRC, you can define different row heights for each of the different playfield registers, and I think you can use all 40 playfield pixels instead of being limited to just the central 32 playfield pixels.

 

Edit: Of course, you can also write your own custom assembly kernels for batari Basic, so you could create a non-DPC+, non-Superchip kernel that lets you change all 40 playfield pixels on every line by reading the playfield data from ROM-- but then you'd have to give up some things, like maybe doing without the ball, or one of the missiles, etc. And there are also other old and new bankswitching schemes that add more RAM, such as CBS RAM+, or M-Network bankswitching, and so on.

Edited by SeaGtGruff
  • Like 1
Link to comment
Share on other sites

If you use the multisprite kernel, the playfield data is read from ROM instead of mapped to RAM, so you can define as many rows as you want-- although the playfield will either be repeated or reflected (i.e., you can't draw an asymmetrical playfield as in the standard kernel). If you use the standard kernel with Superchip bankswitching, the playfield screen memory is moved to the Superchip RAM, which allows you to define more playfield rows, hence the playfield rows can be thinner. And if you use the DPC+ kernel, you can do all sorts of neat things. I'm embarrassed to say that I haven't experimented with the DPC+ capabilities yet, so I'm not sure of everything it can do-- but IIRC, you can define different row heights for each of the different playfield registers, and I think you can use all 40 playfield pixels instead of being limited to just the central 32 playfield pixels.
WOW! Thanks for the very detailed explanation!!! Kudos to you :D I'm using multisprite kernel indeed, but how can I manually define how many rows I want on the screen at visual batari basic code? I'm just trying to achieve a 'Breakout' clone here, with the same number of rows, same block sizes and same colors from the original game. And since it's a simetrical game, I'd like to use the whole screen, as you said it's possible by repetition or reflection of the playfield (in this case, the wall of bricks). Could you give an example on how to do such thing? And again, thank you for your kind support. Cheers, Roger Edited by rcoltrane
Link to comment
Share on other sites

Atari's Breakout maps the 2 edge bricks to PF0 and uses an asymmetrical display method...writing to PF0, PF1, and PF2 twice on every scanline as it's being displayed (the "missiles" are used for the side walls - which is why the color of the lower area of them is the same as whatever paddles are on the screen).

 

Ever thought of just hacking Breakout directly? It's not a very complex game (and the display code is already written for it). There's even some leftover RAM memory the original game didn't use.

Link to comment
Share on other sites

Atari's Breakout maps the 2 edge bricks to PF0 and uses an asymmetrical display method...writing to PF0, PF1, and PF2 twice on every scanline as it's being displayed (the "missiles" are used for the side walls - which is why the color of the lower area of them is the same as whatever paddles are on the screen).

 

Ever thought of just hacking Breakout directly? It's not a very complex game (and the display code is already written for it). There's even some leftover RAM memory the original game didn't use.

 

Could you help me out with that please?? I'd love to see the original Breakout code and compile it myself. How can I hack the original .bin ? Is there a special tool?

Link to comment
Share on other sites

  • 3 years later...

+Bump

 

 

..How can I hack a .bin an see the code?

 

Did you click on the link I posted in another thread?

 

stella.sourceforge.net/docs/debugger.html

 

See the link above? Click on it. Read info. You run a game using Stella, press the button above TAB and to the left of the 1 key, then you can mess with the code.

 

If you have no clue what to do then, the next step is to learn assembly language:

 

randomterrain.com/atari-2600-memories.html#assembly_language

Link to comment
Share on other sites

Yeah I saw that Random, thank you. So far so good.

 

The only thing I can't figure out right now is how to get a missile to keep flying across the screen after I've stopped pressing fire.

 

Or to not have the first missile disappear as soon as I hit the fire button again. I want the missile to keep traveling until it collides with the edge of the screen. Is this possible? I can't find any good missile tutorials. They are all very basic. No pun intended.

Link to comment
Share on other sites

I want the missile to keep traveling until it collides with the edge of the screen. Is this possible? I can't find any good missile tutorials. They are all very basic. No pun intended.

Are you talking about doing that with batari Basic or when hacking a classic game? If you are talking about using batari Basic, this example program has a missile that does what you are talking about:

 

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

Link to comment
Share on other sites

  • 1 year later...

I understand redundant, seemingly simple questions from noobs get annoying. Please bare with me. I can find many mentions of it, but no tutorials..

 

 

What is the simplest code I can use, starting with a completely blank .bin, to set the playfield blocks to their smallest size? Please tell me, what kernel if any this requires, how to implement it, and what lines of code to write. I cannot find a sample code anywhere.

Edited by freshbrood
Link to comment
Share on other sites

You can get 88 rows that are 2 scanlines high using the DPC+ kernel:

 

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

 

This example program shows the most common resolutions when you press the select switch multiple times:

 

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

Link to comment
Share on other sites

WOW! Thanks for the very detailed explanation!!! Kudos to you icon_mrgreen.gifI'm using multisprite kernel indeed, but how can I manually define how many rows I want on the screen at visual batari basic code? I'm just trying to achieve a 'Breakout' clone here, with the same number of rows, same block sizes and same colors from the original game. And since it's a simetrical game, I'd like to use the whole screen, as you said it's possible by repetition or reflection of the playfield (in this case, the wall of bricks). Could you give an example on how to do such thing? And again, thank you for your kind support. Cheers, Roger

 

The multi sprite kernel draws the playfield from ROM. That means you couldn't do things like use the play-field for breakable bricks.

 

You can play around with two settings:

 

const screenheight=84
and
pfheight=1
Various combinations of those two settings will make the playfield rows smaller or larger. Also, you can get a weird effect where the top of the screen is clear or garbled playfield data in some variations.
But even after you figure out what they do and what values work it's horribly fiddly. I'd use anything but the multi-sprite kernel for this kind of game :)
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...