PAL timing and other questions.

[bastetfurry]

(Yay, first post )

 

Hello Forum!

 

Comming from the Breadbin i want to play a bit with the 2600, tryed bBasic but thats too limiting. (Plus it wont compile with GCC4.4 *sigh*)

So i am on my way to code me a kernel and have some questions.

 

1. How many cycles do i have per line on a PAL machine? Still 76? (I am going after the info from here)

2. Is there a PAL-Centric diagram/documentation somewhere?

3. Is there some way to detect on what machine my game is running?

4. When does the TIA set its registers in stone? At draw or some time before that? (Changing COLUBK in the middle of a line and stuff. )

5. When i issue STA WSYNC, where is the TIA giving back control to the CPU? At the start of next HBlank or the start of the next picture line? In essence, how many cycles till the TIA draws its first pixel/expects valid data.

[Rybags]

1. Cycle counts are the same per scanline.

 

2. With PAL you generally want to adjust the display, inserting blank lines before and after VSync. Generally you have 262 scanlines NTSC and 312 PAL, so that's 50 scanlines extra to play with.

 

3. I'm not 100% but I think that's a "No". Since the VSync is software initiated and everything else on the machine is based on fractions of the master clock, there's no sure way.

 

5. As far as I know, WSync on all the Atari incarnations returns control before HSync occurs. HBlank is a misused term and people often refer to anything outside the normal 160 colourclock display as HBlank but that's not really the case.

The entire display line is 228 colourclocks and you can see about 168 on most old TVs and even more than that on some modern sets.

[SeaGtGruff]

3. Is there some way to detect on what machine my game is running?

As far as I know, there's nothing your game can use internally to determine which variety of 2600 console it's running on. However, it is possible to determine whether it's running on a 2600 or a 7800, based on the initial values found in certain RAM locations-- although I should think this isn't 100% certain, because the 2600 powers up in a random state, so it isn't inconceivable that it could randomly power up with the values expected for a 7800.

 

The safest way would be to simply ask the player to specify which console is being used. And this assumes your game contains alternate code for the different consoles.

 

The simplest solution-- which was the one the game companies used, and that most homebrewers still use-- is to produce different versions of your game for the different consoles, or (if you can't afford to code and manufacture more than one version) to just specify up front that your game is intended to be played on a certain console.

 

If you're interested in a one-cartridge-works-on-all-consoles solution (which is a nice ideal to shoot for), you'll need whatever alternate code is required to compensate for the differences between the consoles. That means you need to know what all the differences are. I don't know if there's a definitive list anywhere-- it would be great if we could put one together-- but some of them are as follows:

 

The NTSC TIA has a blanking pin and an audio1 pin, but on the PAL TIA those pins are used for PAL-I and PAL-S connections. This generally has no impact on games, unless your game is designed to capitalize on an AV mod that sends the audio0 and audio1 outputs to different speakers for stereo sound.

 

PAL/SECAM 2600s have a slightly slower oscillator speed (3546894 Hz) than NTSC 2600s (3579575 Hz), which affects their audio frequencies, therefore you may want to use different frequency values in any music your game might have so it sounds as identical as possible on different consoles.

 

PAL/SECAM games normally have 312 scan lines per frame, but NTSC games normally have 262 scan lines per frame. This means the PAL/SECAM frame rate is about 50 Hz, whereas the NTSC frame rate is about 60 Hz. If your game updates a counter once per frame for keeping time or some similar purpose, you'll need to compensate or the game will run faster or slower depending on which console is being used.

 

The NTSC, PAL, and SECAM consoles have different color palettes, so your game will need to use different color values depending on the console.

 

The 2600's TV type switch flips up and down like the two difficulty switches, but the 7800's pause switch (which replaced the TV type switch) works like the game select and game reset switches-- you can press it down, but then it comes back up again. If your game uses the TV type or pause switches for anything, you'll need to program them differently to compensate for the way they work.

 

Some models of the 2600, or some clones, have slight timing differences in things like how soon changes to the graphical registers show up on the screen, so you might need to make adjustments in your kernel if you're drawing an asymmetrical playfield by updating the playfield registers as the scan lines are being drawn, or if the timing differences affect your score display, and so on.

 

Some consoles may differ in whether "illegal" opcodes will be executed as expected, so you might need to compensate for that-- or avoid using "illegal" opcodes at all.

 

Some cartridges don't fit easily into the cartridge slots of some consoles, so you might want to keep that in mind when choosing a cartridge housing for your game.

 

And while it isn't a difference related to consoles, some modern TVs drawn standard-definition displays (especially non-interlaced displays) differently. For example, my high-definition Samsung TV automatically converts a non-interlaced display to an interlaced display, which means flickered colors (and thus, flickered objects) are drawn as flicker-free interlaced colors. You could conceivably capitalize on this by letting the players choose between different kernel settings to get the best-looking display for their particular TV.

 

As far as asking players to select which console they're using, you could have an options menu that lists different choices for them to select from.

 

Another possibility is to use one or more of the console switches for selecting between different color palettes, number of scan lines, and so on. For example, you could program the difficulty switches to select the display type depending on whether they're up or down; or you could program the game select switch to cycle between each of the different display types.

 

Or if you want to be more creative, you could possibly include a sort of mini-game at startup, such as displaying blocks of color that will be different depending on which color palette the console uses, and asking the player to shoot the yellow block, or the red block, and so on, so you could tell which color palette is being used.

 

4. When does the TIA set its registers in stone? At draw or some time before that? (Changing COLUBK in the middle of a line and stuff. )

None of the register changes are instantaneous, at least not internally, since there's usually a slight lag between when a register receives its new value and when the change actually affects the output, as determined by whether or not a given line (such as a clock line) must go high or low first, or whether the signal from the register must pass through any inverters and other logic gates (or rather, how many it must pass through, since most everything goes through at least an inverter or two), how much delay is added by each gate, and things like that.

 

However, most of these internal delays are transparent to the programmer, because if most everything is delayed by the same amount (as controlled by the clock lines), then you have no way to tell that there's actually (say) a 1.5 color clock delay inside the TIA before a given 6507 instruction finishes executing, the new value is updated to the register, and the new value begins to affect the output. So as far as the programmer is concerned, most register changes appear to be instantaneous, except the ones that require more time than usual. Thus, changes to the color registers and player/missile graphics seem to take place as soon as the instructions have completed. There's a slight delay of (if I remember correctly) 2 or 3 color clocks before changes to the playfield graphics seem to take effect, depending on the console (most 2600s have the 2-clock delay, but some later and some clones may have the 3-clock delay). Changes to the VBLANK register take 1 extra color cycle. But the longest delays are probably with the audio registers. When you change the audio frequency, if the frequency counter has already passed the new value then it will continue counting up until it wraps around and finally hits the new value, which could take several scan lines. When you change the audio control register, the existing values in the polynomial counters need to keep shifting before their output bits begin to reflect the new control value.

 

So as far as the graphics are concerned, you can pretty much assume that any changes are instantaneous, except for the small lag with the playfield registers (which is normally irrelevant unless your kernel is updating the playfield while the line is being drawn), or the tiny lag with the VBLANK (which is also irrelevant unless your kernel is using VBLANK to blank portions of the active scan lines). And the audio register changes are usually irrelevant unless your kernel is making a series of rapid changes to the frequency registers to produce a sound effect, in which case the results you get from an actual console may differ dramatically from an emulator.

 

5. When i issue STA WSYNC, where is the TIA giving back control to the CPU? At the start of next HBlank or the start of the next picture line? In essence, how many cycles till the TIA draws its first pixel/expects valid data.

When you strobe WSYNC, the TIA stops the 6507 until the leading edge of the next horizontal blank, so you have the entire horizontal blank period (68 color clocks, or 22 and 2/3 machine cycles) before the active portion of the line begins.

[SeaGtGruff]

5. As far as I know, WSync on all the Atari incarnations returns control before HSync occurs. HBlank is a misused term and people often refer to anything outside the normal 160 colourclock display as HBlank but that's not really the case.

The entire display line is 228 colourclocks and you can see about 168 on most old TVs and even more than that on some modern sets.

If I understand you, the first part of your answer doesn't really apply to the 2600. The Atari computers have a shorter horizontal blank period than the 2600 does-- and a shorter vertical blank period, for that matter (assuming a standard 2600 screen display of 192 active lines)-- which of course is why you can change the color of the border that surrounds the playfield/background on the computers.

 

But the 2600 doesn't have a border like that-- it has 68 color clocks of horizontal blank, or 76 color clocks of horizontal blank when using a standard HMOVE (resulting in those infamous "black lines" at the left edge of the screen). The horizontal blank period can also be extended by setting and clearing VBLANK on each line, but increasing the horizontal blank at the right edge of the screen doesn't affect when the ready line goes low again, as it's timed by when the 6-bit horizontal sync counter triggers the start of the automatic horizontal blanking.

 

Hmm, so I guess my previous answer was slightly wrong, since it's the leading edge of the *HSC-triggered* horizontal blanking that releases the ready line, not the leading edge of horizontal blanking as it might be extended by the programmer using VBLANK.

 

Another possibility is to strobe RSYNC to reset the HSC, but that would make the scan lines shorter, so you'd actually be losing color clocks on each line-- the blanking would still be 68 clocks, but the active playfield area would be ended early by the reset of the HSC. And whenever I've tried using RSYNC to get a narrower playfield, it just scrambled the display on my TV, so I think the results will be heavily dependent on how tolerant the TV is of shorter-than-normal scan lines.

 

Anyway, increasing the horizontal blanking period by using HMOVE or VBLANK can give the programmer more cycles for making changes outside the active portion of the scan line, but since some of those cycles must be used to strobe HMOVE or set/clear VBLANK, the actual gain might not be enough to justify it. (Whereas on the Atari computers, you can just tell ANTIC to draw a narrow playfield, which lets you use all the extra time for making more changes during the horizontal blanking and border region.)

[bastetfurry]

Thanks for all the answers, i hope i can put them to great use.

 

The simplest solution-- which was the one the game companies used, and that most homebrewers still use-- is to produce different versions of your game for the different consoles, or (if you can't afford to code and manufacture more than one version) to just specify up front that your game is intended to be played on a certain console.

Hmm, you could use a bigger flash chip, "burn" the game in NTSC and PAL to it and use a jumper to decide which game to start.

When you strobe WSYNC, the TIA stops the 6507 until the leading edge of the next horizontal blank, so you have the entire horizontal blank period (68 color clocks, or 22 and 2/3 machine cycles) before the active portion of the line begins.

22 cycles... thats hard. Especialy as you cant directly place a sprite at one pos but have to "trigger" the position. Any nice trick to ease that? o.o

[SeaGtGruff]

Thanks for all the answers, i hope i can put them to great use.

 

The simplest solution-- which was the one the game companies used, and that most homebrewers still use-- is to produce different versions of your game for the different consoles, or (if you can't afford to code and manufacture more than one version) to just specify up front that your game is intended to be played on a certain console.

Hmm, you could use a bigger flash chip, "burn" the game in NTSC and PAL to it and use a jumper to decide which game to start.

That's true I guess. I'm not sure about the jumper part, as I'm not really a hardware person, but you could certainly have a bankswitched cartridge with a different version in each bank, and decide which bank to jump to after powerup based on a console switch setting.

 

However, that might be wasteful, since it doesn't usually take much to modify NTSC games to work on PAL consoles, or PAL games to work on NTSC consoles-- only a few parts of the code would probably need to be changed. You could read the appropriate color values, timing values, musical frequencies, etc., from ROM using a table indexed by the console type (like an offset of 0 for NTSC, 1 for PAL, 2 for PAL/60, and 3 for SECAM), and then store them in RAM if you need to be able to load them again more quickly later on. Or you might be able to just branch to different sections of code for the parts that need to be different.

 

Still, if the differences are more extensive, and timing is too critical to use indexed or zero-page addressing instead of immediate mode, then having a different version in each bank might be a good option if it didn't increase the cost of the cartridge too much.

 

When you strobe WSYNC, the TIA stops the 6507 until the leading edge of the next horizontal blank, so you have the entire horizontal blank period (68 color clocks, or 22 and 2/3 machine cycles) before the active portion of the line begins.

22 cycles... thats hard. Especialy as you cant directly place a sprite at one pos but have to "trigger" the position. Any nice trick to ease that? o.o

It depends on the game's needs. For example, if you aren't going to have different copies of a player on different scan lines, then you can set the player's position once during the vertical blank and not have to worry about it again for the rest of the frame-- just update its graphics and color as needed from line to line. And even if you reuse the same player on different lines, you can usually set its position on a line where it doesn't appear. If you look at a game like "Frogger," where one of the players is reused on different lines to draw the cars and trucks moving in different directions, you can see from the black lines at the left edge of the screen where they set the player's new position just above each section where it's going to be reused.

 

Also, you don't necessarily have to do everything during the horizontal blank period. For example, the playfield registers are drawn at specific times during the scan line, so you can update the players during the blanking and then update the playfield as the scan line is being drawn. It doesn't matter whether you update something during blanking or while the line is being drawn, as long as you can update it before it needs to be drawn. Or you can update it right after it's been drawn (for the next line, or for the right half of the screen, etc.). There's usually a lot of juggling going on while programming a game for the 2600, deciding at which points during the line you can update a particular object or color, and shuffling the order in which things are updated so you can update everything you want to in time for it to be displayed. That's what "racing the beam" is all about-- doing everything just in the nick of time while the line's being drawn.

 

Aside from that, it's true that some kernels need to make more changes than can be done in a single line, so a lot of games used 2-line kernels, where player0 is updated on one line and player1 is updated on the next line, then the VDEL registers are used to make the changes show up on the same line.

 

And now there's also the DPC+ bankswitching scheme, which lets you use immediate mode to load new values for the registers so you can make more changes per line.

 

And if all that isn't enough, you can resort to flicker if necessary. There's a lot of flickering going on in a game like "Millipede," but you're usually so busy trying to stay alive that you don't have time to gripe about the flickering!