rcoltrane Posted April 4, 2012 Share Posted April 4, 2012 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? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 5, 2012 Share Posted April 5, 2012 (edited) 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 April 5, 2012 by SeaGtGruff 1 Quote Link to comment Share on other sites More sharing options...
rcoltrane Posted April 5, 2012 Author Share Posted April 5, 2012 (edited) 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 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 April 5, 2012 by rcoltrane Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 5, 2012 Share Posted April 5, 2012 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. Quote Link to comment Share on other sites More sharing options...
rcoltrane Posted April 5, 2012 Author Share Posted April 5, 2012 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? Quote Link to comment Share on other sites More sharing options...
freshbrood Posted October 1, 2015 Share Posted October 1, 2015 +Bump ..How can I hack a .bin an see the code? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 1, 2015 Share Posted October 1, 2015 +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 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted October 1, 2015 Share Posted October 1, 2015 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 1, 2015 Share Posted October 1, 2015 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 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted October 2, 2015 Share Posted October 2, 2015 (edited) . Edited April 16, 2017 by freshbrood Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 16, 2017 Share Posted April 16, 2017 (edited) 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 April 16, 2017 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 17, 2017 Share Posted April 17, 2017 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 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted April 17, 2017 Share Posted April 17, 2017 WOW! Thanks for the very detailed explanation!!! Kudos to you 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 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. See info here: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#pfheight 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 http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#pfheight Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.