Narrower display?

[jrok]

Is it possible to alternate the vblank to make a bB program's display narrower, ideally so that the area comprising PF0 isn't rendered at all? I'm trying to free up some cycles and create a black" border where playfield pixels can't be rendered (without resorting to PF0=255, since I'm using playfield color tables.) Could it be done with inline asm, or would it require a kernel mod? Can anyone point me in the right direction to some example code?

 

Thanks in advance,

Jarod.

[Impaler_26]

This could be what you're looking for:

 

http://www.atariage.com/forums/index.php?showtopic=139607

[jrok]

This could be what you're looking for:

 

http://www.atariage.com/forums/index.php?showtopic=139607

 

Thanks Impaler. But what I was thinking of was a display where the beam doesn't read *anything* in the extreme left and right portions of the screen (i.e. neither the background color nor the playfield color).

[jrok]

Actually, the more I research, I think this question is really for SeaGTGruff. I found the following on the stella list archives:

 

On the other hand, turning VBLANK on and off on each scan line to lengthen

the horizontal blanking interval and thereby create a narrower playfield

display has much more potential. Or maybe using VBLANK to draw a vertical bar down

the middle of the screen and divide it into two separate zones, something

like that. My real point is that there's potential to use VBLANK creatively to

do a lot more than just turning "off" the electron beams for vertical

blanking. In fact, I prefer to read the abbreviation "VBLANK" as "video blanking"

rather than as "vertical blanking," since there's no reason why it needs to be

used exclusively for vertical blanking, or even just vertical or horizontal

blanking-- it can be video blanking anywhere on the screen, even in the middle

of a scan line!

 

Increasing the horizontal blanking time might be useful for gaining extra

cycles to do certain things before objects are drawn on the screen, but there's

also a trade-off, because some of those cycles must be used to turn VBLANK on

and off at the desired times, hence you generally have to make the playfield

*much* narrower before you gain any useful number of cycles. But if you're

using a reflected playfield, and are covering up the PF0 pixels with VBLANK,

then you could possibly gain bytes by reducing the number of bytes needed to

define a playfield display. You could always just leave PF0 set to $00, but

covering up that portion of the left and right sides of the screen would also

cover up the background, in case you didn't want the background color

displayed there either.

 

This sounds like exactly what I am trying to do. I've tried to implement with inline asm, but I don't think I have the proper syntax. Michael if you get around to reading this, do you have any additional thoughts when it comes to a bB implementation?

 

Thanks!

Jarod.

[SeaGtGruff]

To make the screen narrower by turning VBLANK on and off, you have to do so at the appropriate times. You need at least 6 free cycles per line to do this-- ST? VBLANK takes 3 cycles, and you need to do it twice (once on, once off). You can use STA, STX, or STY, and if none of them already contain appropriate values, you'll also need to do a LD? #, which takes 2 more cycles-- so you'll possibly need up to 10 free cycles. Since the canned kernels already use up just about all possible cycles, and the timing is very exact, I don't think you could modify the canned kernels to do this. Your best bet would be to create a new kernel for it.

 

Michael

[MausGames]

So how many times can you use VBLANK on each scanline? Could it be used to create diagonal lines?

Edited March 16, 2009 by MausGames

[SeaGtGruff]

So how many times can you use VBLANK on each scanline? Could it be used to create diagonal lines?

You can use it as many times as you can squeeze into the scan line's timing. I once used VBLANK to "draw" a maze on the screen. The maze had blue walls and a black floor. The blue walls were defined by a blue background, and the black floor was created by turning VBLANK on and off. This was nothing more than a "stupid VCS-programmer's trick," because it had less than zero practical usefulness as part of a potential display kernel. I just wanted to "prove"-- on a purely theoretical level-- that VBLANK could conceivably be used to draw in a "fifth color" on the screen.

 

I think all conceivable tricks should be added to your tool kit-- never discard a technique because it's "stupid" or utterly impractical-- because one day hell may freeze over and you'll find a use for it! But generally speaking, "drawing" on the screen with VBLANK makes about as much sense as trying to pry a nail out of a board using a ripe strawberry. However, that doesn't exclude VBLANK from being potentially useful for making the screen narrower by increasing the widths of the left and right borders (i.e., the length of the horizontal blank), or perhaps even for making a blank zone in the middle of the scan line so the screen is divided into left and right portions.

 

Michael

[MausGames]

It sounds like it could also be used to make patterns or pits in floors, would that be impractical?

Edited March 17, 2009 by MausGames

[+Random Terrain]

I wish I could win a ton of money, then I could pay a few Atari 2600 wizards to make us a bunch of kernels for doing various jobs. Eventually the collection of kernels would be so large that any type of game you could think of would have an easy-to-use kernel for it.

[SeaGtGruff]

It sounds like it could also be used to make patterns or pits in floors, would that be impractical?

It would depend on the kernel. I would say patterns are out, but pits are a possibility. The thing to realize is that in order to draw with VBLANK, you need to turn on VBLANK at some desired spot on the scan line, then turn it off again at some other desired spot. And VBLANK isn't like the players, missiles, or ball, which maintain the same horizontal positions until you move them. Nor can you do fine-positioning with VBLANK. So you end up spending most of the scan line waiting for just the right moments to turn VBLANK on or off, on each and every scan line where you want to "draw" with it. That doesn't leave time for much of anything else. You could update the player graphics, but you probably wouldn't have time for drawing an asymmetric playfield, for example.

 

Michael

[supercat]

You could update the player graphics, but you probably wouldn't have time for drawing an asymmetric playfield, for example.

 

Probably not for drawing a full asymmetric playfield, but if one is using the 'copy' mode rather than 'mirror' mode, one could use VBLANK to hide places where the playfield really shouldn't be duplicated but is anyway. My Ruby Runner demo did that (it shows the middle 80 pixels of the screen).

[yuppicide]

Yep. That would be great. While you're at it you can help speed up development of Chimera.

 

I wish I could win a ton of money, then I could pay a few Atari 2600 wizards to make us a bunch of kernels for doing various jobs. Eventually the collection of kernels would be so large that any type of game you could think of would have an easy-to-use kernel for it.