Jump to content
IGNORED

A few novice questions about batari.


Gorf

Recommended Posts

Here is a sample of me being just plain silly.

 

silly.bin

 

Since Invaders was a vertical, I thought I'd be a knumbskull and try

something silly after studying some of the features of the 2600.

 

Im guessing this is not practical to do but I thought it would

be fun to do anyway. Who knows maybe one of you 2600 master

coders will derive something useful from it. No fancy kernal

features...player0 is you and player1 is them. You can shoot,

however no collision(would not even know where to start there.)

 

again....silly. :D

 

Asking all 2600 /batari brainiacs the following....

 

a ) I know we can vblank, but can we hblank somehow?

 

b ) Would batari be able to handle an 8 sprite row? 3 such rows?

 

c ) I've seen a few assembly versions of these items so can

batari do it using the inline assembler, or would the batari

kernal conflict with some of the mentioned techniques?

 

d ) Can you place a playfield in RAM instead of ROM,

and if so can the playfield be higher in (vertical) resolution?

 

e ) Is there a document on 2600 coding for the novice at 2600

coding but with plenty of assembly and coding background like

myself?

 

Hope you like my silliness!

 

Im wide open to suggestions , critique, possibilities and all that.

 

Thanks!

 

:)

Edited by Gorf
Link to comment
Share on other sites

 

 

 

Most interesting indeed. Will have to look at that code too. But this is to do a vertical and no flicker.

Why I want to know if an hblank is possible is to do one row of three..change the verticle position

than a nother 3 ...8 times. I assume if done with an Hblank you can still avoid flicker and then I can

easily handle the rest of the game for a vertical invaders. In not shooting for arcade perfect, but

simple function only. Is there anyway to make the copies closer together? I set it to the close copies

according to the manual. the batari manual that is...

Edited by Gorf
Link to comment
Share on other sites

Nice looking demo, Gorf. I've been kicking around some thoughts about "vertical" arcade games ported to horizontal home TV systems. I've discussed it in this 7800 thread, and also this one in the 2600 Forum. It's nice to see someone experimenting with writing the actual code. It may turn out that the 90 degree rotation of these games is just too disorienting to retain the "feel" of the original game. But I think the only way to find out is to try it.

Link to comment
Share on other sites

a ) I know we can vblank, but can we hblank somehow?

I'm not sure I know what you mean, so my answer might not fit your question. :)

 

VBLANK stands for "vertical blanking," but I prefer to think of it as "video blanking," because you can turn VBLANK on and off anywhere on the screen (although it isn't a good idea to turn it off during the vertical sync, since the active video signal can interfere with the vertical sync signal). I've actually used VBLANK to draw (erase?) a simple maze on the screen, as well as a circle. However, it isn't very practical to use VBLANK for *drawing* purposes in a game.

 

The Atari 2600 performs its HBLANK automatically, and you can't decrease the HBLANK time-- but you can *increase* the HBLANK time by turning VBLANK on before the end of a scan line, and then turning VBLANK off again after the next scan line would normally have started to display.

 

However, batari Basic's canned kernels control the VBLANK themselves, and don't let you change it (although you *might* be able to if you stick a "VBLANK = 0" right after "drawscreen," draw some scan lines on your own, and then do "VBLANK = 2" before continuing your post-drawscreen stuff, and also by sticking a "VBLANK = 0" in a "vblank" routine and then drawing some scan lines on your own; I'll have to try that sometime :ponder:). And since batari Basic is handling everything while the screen is being drawn, it doesn't let you insert VBLANK commands within the screen area that it's drawing automatically.

 

What you may be referring to is the ability to perform code during the VBLANK with the "vblank" option. And as I just said in the previous paragraph, batari Basic is handling everything for you while it's drawing the screen, so it doesn't let you perform your own "horizontal blank interrupts" with some kind of "hblank" option-- and it's already using up all of the HBLANK time, anyway.

 

On the other hand, if you create your own display kernel, you can do just about anything. I actually wrote a simple display kernel with batari Basic commands (*not* inline assembly code, although that would have been better) to display all 128 colors at once on the screen, using only the background color, by changing the background color 9 times on each scan line (8 luminances of a given hue, plus black or gray), and then switching to a different hue every so many scan lines.

 

So the short answer is "no," not with any of the canned kernels-- but "yes," if you write your own display kernel.

 

b ) Would batari be able to handle an 8 sprite row? 3 such rows?

That depends. You can display five sprites on any row-- player0, player1, missile0, missile1, and the ball-- but three are 1-pixel sprites, and if you use them for "blob sprites," then you can't use them for projectiles. If you display three copies of the players and missiles, then you can get 13 sprites on any row (three player0s, three player1s, three missile0s, three missile1s, and the ball), but the three copies of each sprite will move together-- which is actually what you want for a "Space Invaders" type of game, anyway, although (as implied above) you'd really want to save the missiles and ball for drawing any projectiles.

 

So that leaves you with six sprites per row. With the multisprite kernel, you can get six independent sprites per row, but five of them will be drawn with player1, so they'll flicker like crazy. However, if you want to get eight sprites on a row (and want to save the missiles and ball for projectiles), then you could use three copies of player0, three copies of player1, and two copies of "player2." You'd get flickering, but it will be two-frame flicker (30Hz on a 262-line screen, or 25Hz on a 312-line screen), so it might not be too bad.

 

However, the bigger problem will be getting multiple rows of these sprites, and being able to destroy any sprite from any row. For the moment, let's stick with six sprites on one row-- three copies of player0, and three copies of player1. If one of them gets destroyed, you can eliminate it by changing the number of copies of the player it was drawn with, including any necessary adjustments to the spacing of the copies and the horizontal position of the first copy. So six sprites on one row is easy.

 

Six sprites on two rows is a different story-- at least, with batari Basic's canned kernels. To get two rows of sprites, you can make the sprites taller, with two copies of the sprites' graphics separated by rows of blank pixels. To remove one of the copies from one of the rows, you change the graphics for that player so it contains only one copy of the sprite, and adjust its vertical position as needed. That works great if you're displaying only one copy of that sprite per row, but not if you're displaying two or three copies per row, because if you change the graphics to get only one vertical copy, it will also affect the other copies of that sprite, making it impossible to remove just one copy on one row.

 

That's probably why you asked about the possibility of an "hblank" option, because if you could change the NUSIZx of a player on each row of sprites, then your problem would be solved. To do that, you'll need to create a custom kernel.

 

The other possibility is to use the multisprite kernel and make do with the flickering.

 

However, I'm helping someone with a batari Basic game that bears a partial resemblance to "Space Invaders," except there are only four sprites on each row, and only two rows of sprites (unless he decides on more rows). And last night I worked out how to get two rows of four sprites (or actually up to five rows of four sprites) and remove any one of them, without flicker. It was so easy I don't know why I didn't figure it out immediately. You display one copy of player0 on each row, with up to five copies vertically, which lets you remove any of those vertical copies at will. Then you display three copies of player1 on one row, three copies of player2 on the next row, three copies of player3 on the next row, etc., and change their number of copies, spacing, and positioning as needed to remove any one of the copies from any row. Assuming that player5 is reserved for the hero, that gives you up to four rows of four sprites, without flicker-- or five rows if you don't use player5 for the hero (although there's really nothing else that you could use for the hero, since with the multisprite kernel the playfield pixels are in ROM, and the missiles and ball have fixed heights of 1 line).

 

c ) I've seen a few assembly versions of these items so can

batari do it using the inline assembler, or would the batari

kernal conflict with some of the mentioned techniques?

When you use inline assembly code with one of the canned kernels, your code is being performed in the so-called "overscan" period, and (if you're using the "vblank" option) in the so-called "vblank" period (they're both part of the "vertical blank interval," and "overscan" is actually something else-- the part of the screen that's displayed beyond the physical boundaries of the display-- but for some reason Atari programmers have always used those terms). You can't perform inline assembly code during the actual "drawscreen" process. So the only way to get "horizontal blank interrupts" is to write your own display kernel, and use it instead of one of the canned kernels.

 

d ) Can you place a playfield in RAM instead of ROM,

and if so can the playfield be higher in (vertical) resolution?

With the standard kernel, the playfield is *already* in RAM, but it has such a small amount of RAM allocated to it (so there's room for other variables) that the vertical resolution is so poor. If you use the Superchip option with the standard kernel, you can get a much better vertical resolution for the playfield-- I think it's as small as 3 lines per pixel, or 32 rows of pixels, but I may be mistaken (I'm too lazy to look it up right now :D).

 

On the other hand, with the multisprite kernel the playfield *always* resides in ROM-- at least for the time being, although it should be possible to use the Superchip to move the playfield into RAM, so that may come in a future release. And I think you should be able to do that right now on your own, by tinkering with the playfield pointers. However, the multisprite kernel uses a reflected symmetrical playfield, rather than an asymmetrical playfield, and arranges the byte tables for PF1 and PF2 in a different manner than the standard kernel does, so you'd need to take that into account. On the other hand, the multisprite kernel's ROM playfield can have up to 88 rows of pixels-- really 96, but the last eight rows are covered up by the score display. And even though you can't (officially) use playfield scrolling with the multisprite kernel, it's easy to make a vertically-scrolling ROM playfield by tinkering with the playfield pointers and having a repeating pattern of playfield rows (up to 128 rows before the pattern repeats, because you need to pad the bottom of the playfield with one less than the number of rows in the repeating pattern, and 128+127=255, and the byte tables for the playfield registers mustn't cross a page boundary).

 

e ) Is there a document on 2600 coding for the novice at 2600

coding but with plenty of assembly and coding background like

myself?

The standard reference for programming the Atari 2600 is the "Stella Programmer's Guide," which can be found in several places on the internet (there's even an HTML version of it somewhere). But that document really focuses on the TIA (or "Stella" chip), so you'll also want to get a reference for the 6502 assembly opcodes, and possibly a reference for the 2600's RIOT chip (which is covered somewhat in the "Stella Programmer's Guide," although you might find some additional obscure programming information buried in the RIOT datasheet). Aside from those, there are tutorials on programming the 2600, such as Andrew Davie's series (which has been assembled into a nice PDF document somewhere), and a few others. And if you're going to do your own assembly coding for the 2600, and want to use bankswitching, don't overlook the documents about bankswitching. You can find a lot of information by Googling with a few choice search parameters-- start with broad search words (like +2600 +programming), then add more parameters to whittle down the results. :)

 

Michael

Edited by SeaGtGruff
Link to comment
Share on other sites

Wow! That is a lot of info..thanks a lot...

 

What I would like to do is draw

 

player1 on vertical line (n)

 

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

 

all in the same frame.

 

Can this be done in batari?

 

Or...is there any sample kernels out there that

would do the above? I do know 6502...well from

the old days but it should not be hard to pick it

up again.

Link to comment
Share on other sites

Wow! That is a lot of info..thanks a lot...

 

What I would like to do is draw

 

player1 on vertical line (n)

 

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

draw it again on n+= (sprite height + 1)

 

all in the same frame.

 

Can this be done in batari?

 

Or...is there any sample kernels out there that

would do the above? I do know 6502...well from

the old days but it should not be hard to pick it

up again.

I posted a reply earlier, but it got lost. Anyway, I'll try to work up a demo and post it later.

 

Michael

Link to comment
Share on other sites

@Micheal

 

"That's probably why you asked about the possibility of an "hblank" option, because if you could change the NUSIZx of a player on each row of sprites, then your problem would be solved. To do that, you'll need to create a custom kernel."

 

Yes, that is why I asked about this. Can I get 8 sprites vertically

without flicker? One column is all I need and I'll mess with the multiple copies settings.

 

And how hard is it to make a custom kernel that would do this?

 

Also, can I tell the TIA to make the copies of the srpites closer

than they are? So when I set player1 to three copies, Im stuck

with the distance the hardware gives me or is there a way to

make them closer together?

Link to comment
Share on other sites

Nice looking demo, Gorf. I've been kicking around some thoughts about "vertical" arcade games ported to horizontal home TV systems. I've discussed it in this 7800 thread, and also this one in the 2600 Forum. It's nice to see someone experimenting with writing the actual code. It may turn out that the 90 degree rotation of these games is just too disorienting to retain the "feel" of the original game. But I think the only way to find out is to try it.

 

Why no one tends to utilize the vertical nature of the players it quite suprising....I bet is more

of you advanced 2600 coders thought vertically, you would come up with a whole slew of stuff.

 

I have always wondered....but being the novice, I will rely on the rest of you Guru's around here.

Link to comment
Share on other sites

So...is there any hope of my plan?

Sorry, I didn't have time to do anything much last night, and tonight is shot now, too. I don't know about tomorrow night, either-- there's a possibility that I may be going out to dinner after work, in which case I don't know when I'd get home (plus Wednesday night is "Lost" night).

 

One thing I did try last night was to create a customized version of the multisprite kernel. The idea I'm working on is to draw only the left copy of PF1, and then draw blanks (zero bits) for the two copies of PF2 and the right copy of PF1, so the left copy of PF1 could be used to draw the player's ship while the multisprites (player0 through player5) are used on the right side of the screen for the columns of invaders-- without the player's ship being reflected on the right side of the screen. I got it partly working, but I still have a few kinks to work out:

 

post-7456-1176870615_thumb.png

 

Michael

Link to comment
Share on other sites

So...is there any hope of my plan?

Sorry, I didn't have time to do anything much last night, and tonight is shot now, too. I don't know about tomorrow night, either-- there's a possibility that I may be going out to dinner after work, in which case I don't know when I'd get home (plus Wednesday night is "Lost" night).

 

One thing I did try last night was to create a customized version of the multisprite kernel. The idea I'm working on is to draw only the left copy of PF1, and then draw blanks (zero bits) for the two copies of PF2 and the right copy of PF1, so the left copy of PF1 could be used to draw the player's ship while the multisprites (player0 through player5) are used on the right side of the screen for the columns of invaders-- without the player's ship being reflected on the right side of the screen. I got it partly working, but I still have a few kinks to work out:

 

post-7456-1176870615_thumb.png

 

Michael

FWIW, I found 6 free cycles in the MSK recently. This might be helpful if you need a few more cycles.

 

The extra cycles are located near one of the expletives I put in the code so I'd remember where I was but I forgot to take them out

msk6.zip

Link to comment
Share on other sites

FWIW, I found 6 free cycles in the MSK recently. This might be helpful if you need a few more cycles.

Thanks, I'll check it out tomorrow night. :) And when I get everything working, I'm going to post my customized includes and demo code ("Vertically-Spaced_Invaders"). It isn't going to be a sideways Space Invaders per se, just a sideways shooter, but hopefully the demo will help Gorf in his project.

 

One of the things I'm doing is scrolling the ROM-resident playfield in the multisprite kernel, which is actually pretty simple to do. Here's a demo of that, from a project I'm helping someone else with.

 

Michael

Scrolling_ROM_Playfield.bas

Scrolling_ROM_Playfield.bas.bin

Link to comment
Share on other sites

FWIW, I found 6 free cycles in the MSK recently. This might be helpful if you need a few more cycles.

Thanks, I'll check it out tomorrow night. :) And when I get everything working, I'm going to post my customized includes and demo code ("Vertically-Spaced_Invaders"). It isn't going to be a sideways Space Invaders per se, just a sideways shooter, but hopefully the demo will help Gorf in his project.

 

One of the things I'm doing is scrolling the ROM-resident playfield in the multisprite kernel, which is actually pretty simple to do. Here's a demo of that, from a project I'm helping someone else with.

 

Michael

I'll check that out. Vertical scrolling has been on the agenda for a while, I just haven't gotten around to it.

Link to comment
Share on other sites

I'll check that out. Vertical scrolling has been on the agenda for a while, I just haven't gotten around to it.

Well, my technique relies on a looping playfield, and the bottom of the playfield is padded with extra rows so the playfield can begin at any point in the pattern. And since each PF ROM table is limited to 256 bytes, that means the longest playfield pattern would be 128 pixels, since the extra padding has to be 1 row less than the full pattern.

 

So for example, if you have a pattern of 12 rows that repeat, and the playfield has 44 rows in all (or 48, but the bottom 4 are hidden by the score), then you'd have

 

12 = 12 rows

+12 = 24 rows

+12 = 36 rows

+12 = 48 rows... last 4 hidden

+7 = 55 rows needed

 

So that's 44+11 = 55, not 48+11. Anyway, save the original PF pointerlo values, then define an offset, and set the PF pointerlo vaues to the original values plus the desired offset (in this case the offset would be from 0 to 10) to start the playfield at a particular row. And you could even scroll PF1 in one direction, but scroll PF2 in the other direction, or scroll them at different speeds (if you used two offsets, one for PF1 and the other for PF2), or have different numbers of rows in their patterns, such as scrolling PF1 through a repeating pattern of 12 rows, but scrolling PF2 through a repeating pattern of 24 rows, etc.

 

Michael

Link to comment
Share on other sites

Well, my technique relies on a looping playfield

D'oh, I don't know what I was thinking... you don't have to have a looping playfield, if the scrolling stops when it reaches the "top" or "bottom" of the playfield strip. And you should be able to have more than 256 rows if you jump to another ROM table (on another page) to continue scrolling, but then the next pageful of rows would have to "overlap" with the old pageful, by which I mean some of the rows would have to be repeated on the next pageful (for continuity). And of course you'd have to modify pointerhi as well when jumping to the new pageful of rows.

 

Michael

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...