12 replies to this topic

[Killer-Duck]

How do I create a constant value in DASM? (e.g. in C you can use macro definitions or the 'const' keyword)

[GroovyBee]

Use either of the following :-

SomeValue equ $24   ; Or ...
SomeOtherValue=99

    lda #SomeValue
    ldx #SomeOtherValue

[SeaGtGruff]

GroovyBee, on Tue Oct 5, 2010 12:02 PM, said:

SomeOtherValue=99

Don't you need spaces around the equal sign?

Michael

[GroovyBee]

SeaGtGruff, on Tue Oct 5, 2010 7:45 PM, said:

Don't you need spaces around the equal sign?

My mistake. I don't use DASM very often as all my latest projects are done using the assembler in CC65.

[Killer-Duck]

Ok, thanks guys!

[Killer-Duck]

(srry for double-post)

When should I turn on/off VBLANK?

[Nukey Shay]

http://www.atariage....r-first-kernel/

[eshu]

Killer-Duck, on Fri Oct 15, 2010 3:28 PM, said:

(srry for double-post)

When should I turn on/off VBLANK?

From "Stella Programmer's Guide"

A typical frame will consists of 3 vertical sync (VSYNC) lines*, 37 vertical blank (VBLANK) lines, 192 TV picture lines, and 30 overscan lines.

Edit: There's a few versions of that guide, the one I linked to is just the first one that came up on google - I prefer this one

Edited by eshu, Fri Oct 15, 2010 3:46 PM.

[SeaGtGruff]

Killer-Duck, on Fri Oct 15, 2010 3:28 PM, said:

When should I turn on/off VBLANK?

After you finish drawing the last line of your game screen, turn on VBLANK during the next horizontal blank, and leave it on. Then draw your "overscan" lines, vertical sync lines, and "vertical blank" lines. After you finish drawing the last line of the vertical blank, turn off VBLANK during the next horizontal blank, and leave it off. Then draw your game screen. Loop back and keep repeating.

Michael

[Killer-Duck]

SeaGtGruff, on Fri Oct 15, 2010 10:49 PM, said:

Killer-Duck, on Fri Oct 15, 2010 3:28 PM, said:

When should I turn on/off VBLANK?

After you finish drawing the last line of your game screen, turn on VBLANK during the next horizontal blank, and leave it on. Then draw your "overscan" lines, vertical sync lines, and "vertical blank" lines. After you finish drawing the last line of the vertical blank, turn off VBLANK during the next horizontal blank, and leave it off. Then draw your game screen. Loop back and keep repeating.

Michael

Thank you! So when we turn on VBLANK we "turn off" the electron gun so it doesn't display anything while it repositions itself to the top-left corner(vertical blank), then we turn on the electron gun again when we want to draw to the screen?

[SeaGtGruff]

Killer-Duck, on Sat Oct 16, 2010 3:21 PM, said:

Thank you! So when we turn on VBLANK we "turn off" the electron gun so it doesn't display anything while it repositions itself to the top-left corner(vertical blank), then we turn on the electron gun again when we want to draw to the screen?

Yes, exactly. Well, technically the three electron guns (one each for the R, G, and B phosphors) are still on, but during blanking they're set to a level that prevents the phosphors from being excited enough to light up. Of course, it's simpler to think of them as being "turned off." But yes, VBLANK is turned on after the game screen's been drawn, and is kept on throughout what the "Stella Programmer's Guide" calls the "overscan" and "vertical blank." Then VBLANK is turned off again when it's time to start drawing the game screen on the next frame:

(1) Turn on VBLANK; draw the "overscan" lines.
(2) Turn on VSYNC; draw the vertical sync lines.
(3) Turn off VSYNC; draw the "vertical blank" lines.
(4) Turn off VBLANK; draw the game screen lines.
(5) Loop back to (1) and keep repeating.

The number of lines drawn is somewhat flexible, although you should keep the total number constant, and the number of lines between vertical syncs should also be constant from frame to frame. Also, PAL requires an even number of lines for the colors to display properly.

The Atari 2600's TV signal isn't as complicated as a normal TV signal, because normal TV signals have 4 types of lines, but the 2600 has only 3 types of lines:

TV signal:
- equalizing lines (pre-equalizing and post-equalizing)
- vertical sync lines
- normal vertical blanking lines
- active lines

Atari 2600:
- vertical sync lines
- vertical blanking lines
- active lines

The equalizing lines (or really half-lines) are vertical blank lines, but have two wide equalizing pulses per line (or one pulse per half-line). The Atari doesn't have equalizing lines; it just uses normal blanking lines.

In a normal NTSC/60 signal, there are
3 pre-equalizing lines (or 6 pre-equalizing pulses)
3 vertical sync lines
3 post-equalizing lines (or 6 post-equalizing pulses)
12 normal vertical blanking lines
241.3 active lines

These numbers are somewhat iffy, because some documents show only 9 normal blanking lines after the post-equalizing pulses. However, closed-captioning data is sent on line 21, which implies that there should be 12 normal blanking lines.

If we dispense with the extra half-line (since Atari 2600 screens normally aren't interlaced), we can draw the screen as follows:

3 vertical blanking lines
3 vertical sync lines
15 vertical blanking lines
241 active lines

However, most TV sets deliberately overscan the picture to prevent any blanking from being visible at the edges of the screen, whereas we want to be sure that everything on the game screen is visible. Therefore the Atari deliberately increases the length of the horizontal blanking (which is controlled automatically by the TIA chip), and the programmer deliberately increases the length of the vertical blanking, such that all of the game screen can be seen on most every TV, with a black border (the blanking) being visible around the four sides of the game screen. The following numbers are given by the "Stella Programmer's Guide":

30 vertical blanking lines (the "overscan")
3 vertical sync lines
37 vertical blanking lines (the "vertical blank")
192 active lines

Since the kernel is written in the form of a loop, we can enter the loop at any point that's convenient. Some programmers start the loop at the vertical sync lines, since those lines are at the top of the screen (or really between the bottom and top, since they trigger-- and occur during-- the vertical flyback of the electron guns). I prefer to start the loop at the so-called "overscan" lines, even though they're at the bottom of the screen, because it makes more sense to me that way, since that's when we turn on VBLANK, and we need to leave VBLANK turned on for the VSYNC lines and the so-called "vertical blank" lines. But it's just a matter of personal preference. For example, you could start your loop at the beginning of the active lines, and place the code for the overscan, VSYNC, and vertical blank lines at the end of your loop, then JMP back to the top to resume. However, the loop that draws the active lines generally needs to be kept as tight as possible, to maximize the amount of time you have for setting up the graphics on each line, so it's generally better to let the program just fall through from the vertical blank lines to the active lines without having to do a JMP to go from one to the other.

Since you're a beginner, I'll also point out that you need to learn about using the timer, because it's essential for letting you perform your between-frame game-keeping procedures (checking for and processing any collisions, reading the game controllers and console switches, updating the score, etc.). These procedures can take varying amounts of time, depending on which branches must be taken, so you want to set the timer at the beginning of the "overscan," then do your game-keeping stuff. When you're done with the game-keeping stuff, you fall into a little loop that checks the timer to wait until it runs out. Then you do the vertical sync lines, set the timer again for the "vertical blank," and do additional game-keeping stuff as needed. Then you fall into another little loop that checks the timer to wait until it runs out, after which you can turn off VBLANK and start drawing the active lines (game screen).

Michael

[Omegamatrix]

SeaGtGruff, on Sat Oct 16, 2010 4:42 PM, said:

Some programmers start the loop at the vertical sync lines, since those lines are at the top of the screen (or really between the bottom and top, since they trigger-- and occur during-- the vertical flyback of the electron guns).

I'm one of those guilty parties. I start my program with a clear loop for the RIOT ram and TIA registers, and then maybe do some one time initialization. After that I go straight into VSYNC. I like it because then I'm syncing up as fast as possible.


Some old era games enter the main program checking if INTIM has reached 0. However they do this before setting the timer. It might take them some extra frames until it reaches a stable point. I like to reach that stable point as soon as possible minimizing the initial start up garbage. That's just a preference though.

[SeaGtGruff]

Omegamatrix, on Sun Oct 17, 2010 4:15 PM, said:

Some old era games enter the main program checking if INTIM has reached 0. However they do this before setting the timer. It might take them some extra frames until it reaches a stable point. I like to reach that stable point as soon as possible minimizing the initial start up garbage. That's just a preference though.

I think if you're going to start the loop with the vertical sync, you might as well skip checking the timer first-- especially if you haven't even set the timer yet. But obviously it's okay the way they did it, since no 2600s or TVs were harmed by it! And what's a few extra frames when each frame is only 1/60th of a second. "Dang! I think there might be something wrong with my Atari! It took a 20th of a second longer than usual for the title screen to appear, and the TV picture rolled a few times before the title screen appeared!" I don't think that ever happened-- especially when half of us were jiggling the power switch to "fry" the game to see what interesting results might be discovered. Even when I wasn't "frying" a game, I pretty much expected that the screen might be blank and roll once or twice before things stabilized and the title screen came up.

As far as which is "better," starting with overscan or the vertical sync, I don't think it makes much difference, because unless there's a really long startup sequence, or the program is looping waiting for an unset timer to reach 0, the first sync should still occur before a full frame's worth of time has elapsed.

My only reason for starting with overscan is so I can set VBLANK on once and just leave it on until it's time to start drawing the game screen. If I remember correctly, some games that start with the vertical sync actually turn VBLANK on first, to ensure that blanking is on during the first vertical sync, which amounts to turning VBLANK on twice-- once at the start of the overscan, and then again just before the vertical sync. The next time through the loop, VBLANK will already be on, anyway. So it shouldn't hurt to leave out the VBLANK that's just before the vertical sync, because even though it might mean VBLANK will be off during the first vertical sync, things will stabilize by the second full frame, which should be soon enough.

To my way of thinking, the only "convincing" argument in favor of starting the loop with the vertical sync instead of with the overscan would be if the game-keeping routines are split up between the overscan and the vertical blank in such a way that the overscan routines process the stuff that happened while the game screen was being drawn-- the collisions and such-- whereas the vertical blank routines set everything up for the next frame. In that case, checking for collisions and such right off the bat is pointless if nothing's even been drawn on the screen yet, so it might seem more logical to put that stuff at the end of the loop, after the game screen has been drawn, and have the loop start with the routines that need to be done to set up the frame that's about to be drawn. Then again, if the game starts up with a title screen anyway, there should be no harm no foul with doing the overscan first, since the game isn't even in play yet.

So it's all just a matter of preference, and there's really no "right" way or "wrong" way to do it (as long as the chosen way *works*), which makes it a "non-issue." The only reason I mentioned it at all is because some beginners see one game do it one way, and another game do it another way, and they get confused and want to know which way is the "right" way, or which way is "better." If they know up front that there's different ways to do it, and it's largely a matter of preference (with a heavy dose of "This is the way I was taught to do it" thrown in), then hopefully they won't get confused if they see different games do it differently.

Michael