question

[question]

To get rid of the blanking at the top of the Dragonstomper screen, set YSTART to 39.

 

However, it appears you can't reduce the number of lines-- if you change it from 210 to (say) 200, it looks like you still get 210 lines in NTSC games?

 

As for Alt-M, that doesn't work the way I thought I remembered. I thought there used to be an option to decrease the width of the screen in games that do HMOVE on every line, such that the display starts at clock 76 (68 plus 8 ) instead of at clock 68?

 

So in the long run, it's probably best to leave the game properties alone and let Stella emulate the game screen more or less as it would appear on a TV-- i.e., with some blanking visible at the top and bottom of the screen.

[question]

Stella lets you specify which scan line the screen display will begin on, as well as the number of scan lines that will be displayed. You can use these two options to crop off any blanked lines from the top of the display and the bottom of the display (set the top line first, then the screen height). To access these options, press the TAB key while the game is running and select GAME PROPERTIES, then go to the last tab. IIRC the display doesn't update as soon as you change the settings-- after you apply them, you have to press the BACKSLASH key and select the option to restart the ROM. Once you've changed these two settings for a given game, Stella should remember them for the next time you play that game.

 

Edit: As for the extra blanking on the left, there's an option to remove that, too-- I forget the exact description and location of the option, but it's the option to hide or show HMOVE.

 

Edit #2: Probably the reason for the difference between Stella 2.2 and Stella 3.8.1 is (I'm guessing, so stephena can correct me if necessary) because the game properties for all the old games used to be stored in a file, whereas (I think) now Stella determines most game properties automatically if possible-- although you can still set the game properties yourself for a given game and save them.

[A2600 Music]

Here is a music example using DPC+ with three voices coming out of one sound channel.

Thank you for posting that! I think I like the square waves' sound the best.

[A2600 Music]

You mean CANT? Than Im totally fine

Oh, you're right-- I misread what you'd written! Sorry, and thanks for the correction.

[A2600 Music]

But you can do pretty decent stuff using the different polynomial counters by themselves and changing them frame-to-frame.

If you mean changing the control registers (waveforms) from one frame to the next, I haven't tried alternating between different waveforms yet-- just alternating between different frequencies to try to get "better" notes (i.e., more in tune as judged by equal temperament). I'll have to try "flickering" the waveforms, too.

 

I would still bet that the vast majority of music on 2600 updates once per frame.

Oh, no doubt about it! The Harmony and DPC+ is a definite game-changer, but it will take many, many years and many, many homebrew programmers churning out hundreds of new DPC+ games before once-per-line music comes anywhere close to matching the numbers of once-per-frame music on the 2600.

[A2600 Music]

"Many games probably don't have enough free time during each scan line to allow for updating the volume even once per scan line..."

 

Woah. Stop. Don't think like that!

Games are here and coming with music (Chetiry) and speech (Frantic) during gameplay. (Sample speech, not AtariVox+ speech). Hold on to your seats.

Not arguing, just saying different way of making music.

Here is using bB and Built-in notes:

It's like anything else-- if you really want it in your game, you'll do whatever it takes to squeeze it into the scan lines loop of your kernel.

 

I just meant that it's fairly common in a game for the programmer to run out of cycles and end up having to look for ways to shave off a cycle here or there wherever possible to make things fit, including unrolling the loop if necessary.

 

I should probably point out that I'm referring mainly to non-DPC+ games that don't have the benefit of data queues and computations that get performed in the background by the ARM co-processor-- you know, "classic-style" Atari 2600 games. In cases like that, the sounds and music would most likely be updated only once per frame, definitely not once or more per line.

 

But if you're using the Harmony and DPC+, you can squeeze more things into the scan lines anyway, so of course you'll probably have plenty of time to update one of the volume registers at least once on each line-- and then likely update the other volume register once per frame for the percussion or noises that use the TIA's built-in sounds.

 

As for sampled speech-- enthusi already pointed out that it can be done using once-per-frame updating.

[A2600 Music]

THIS is NOT the way people generate nice tunes in demos etc.

How do they do it in demos? Obviously not with the ARM co-processor (unless it's a Harmony demo). The TIA can make some decent music by itself-- maybe not "in tune" in terms of equal temperament and A4=440Hz, but certainly "in tune" in terms of just intonation. As for PWM-- how would you do that if not by changing the volume manually?

[A2600 Music]

Well volume-adjustments to mimic (in principle) any instrument (aka sampling) is not at all feasable for games though since this requires multiple updates per frame.

A 60Hz sample just doesnt sound right

 

Well, afaik Boulderdash does this during the Title-screen

The TIA updates the audio output twice each scan line-- well, in theory at least, since each of the two audio clocks are generated twice during each scan line, although the selected frequency setting lets through only certain clock pulses (i.e., every pulse, or every other pulse, or every third pulse, or every fourth pulse, etc.). If you're controlling the audio by varying the volume-- whether doing the wave or frequency computations yourself or letting the ARM co-processor do them for you-- then it's best to update the volume at least once per scan line, otherwise you can't produce the higher notes. The NTSC TIA's line rate is about 15699.89Hz, so updating the volume once per line will let you produce frequencies up to about 7849.945Hz (approximately B8, higher than the highest note on a piano, but less than the full range of MIDI notes). If you update the volume twice per line you can go up to 15699.89Hz (approximately B9, a little more than the highest MIDI note-- assuming the MIDI note values haven't been transposed up an octave or more).

 

Many games probably don't have enough free time during each scan line to allow for updating the volume even once per scan line, at least not during game play. But most title screens probably do have enough free time for this, especially if the ARM co-processor or the DPC chip is being used. If you're doing the frequency computations yourself, there's barely enough time left for updating the VBLANK and VSYNC registers during each frame, let alone drawing a screen display.

[A2600 Music]

Even without a Harmony cart-- i.e., using just the built-in waveforms and frequencies-- you can play different notes as fast as you can change them, or several times per scan line. However, that obviously has practical limitations, since a given note may have a frequency that requires the wave to play for at least several scan lines in order for a single cycle of the note's wave to play. So yes, you can certainly alternate between different notes at 30Hz. However, the result is a series of notes that rapidly alternate between each other, as opposed to a true chord sound.

 

On the other hand, you can create some chords using harmonics, by defining a waveform that combines multiple harmonics. The resulting notes will be slightly "out of tune" as judged by equal temperament tuning, but they'll actually be more pleasing because of the harmonic resonance or consonance. For example, a major chord consists of P1, M3, and P5-- perfect unity or the base note of the chord, the note that's up a major third from the base note, and the note that's up a perfect fifth from the base note. The just intervals for those are 1:1 (P1), 5:4 (M3), and 3:2 (P5). If you go up a couple of octaves and start with the P5 note-- equivalent to playing G4-C5-E5 instead of C4-E4-G4-- the harmonics are 3, 4, and 5. So if you pre-define a waveform that combines the 3rd, 4th, and 5th harmonics, and play it at the frequency of C3, you'll get a chord that sounds like G4-C5-E5. Or if you play the wave at the frequency of D4, you'll get the chord A5-D6-F#6. Then you don't need to compute the next value of a complex wave, you just have to play the pre-defined wave at whatever frequency is needed to get a particular major chord-- or rather, the second inversion of that major chord.

 

The catch is that you don't get the equal temperament notes, and more importantly you're limited to a specific type of chord for each pre-defined waveform. But you could define a set of waves that mix certain harmonics together at different amplitudes to emulate the drawbars of an organ, or something like that.

[A gentleman never asks and a lady never tells]

I'm only #$36, but sometimes I feel like I'm #%110110.

[A2600 Music]

What I don't understand is, how can the A2600 "emulate" 3,4,5 Instruments at the same time, when the A2600 only got 2 Channels?

Is that something like: this music works only on the Emulator, but not on real hardware?

It's the same as a pair of speakers that can "emulate" an entire orchestra performing in stereophonic sound, or even a one-speaker monophonic system playing back a musical recording. The sound waves for the sounds are added together to create a complex wave.

 

To do this on the Atari 2600 you use the "always on" wave, then vary the volume (amplitude) to create complex waves. The catch is that each of the 2600's audio channels can play only 4-bit sound waves, or amplitudes from 0 to 15. So if you want a single channel to play multiple notes at the same time, the sum of their amplitudes can't exceed 15. For example, you can have three sounds, each with an amplitude of 5 (0 to 5), so their sum will never exceeed 15 (0 to 15). The other catch is that it takes a lot of processor time to compute the next value for a complex wave. The Harmony "cheats" by letting the ARM co-processor do the calculations in the background.

[Customer keeps asking for tracking number... what to do?]

You know how people post pictures of their restaurant receipts on the web and get the restaurants in trouble for waiters who put comments like "Lady Chinky Eyes" on their receipts? Well, maybe someone needs to post pictures of their email exchanges with troublesome buyers who repeatedly demand a tracking number when one was clearly provided again and again, and who then leave negative feedback. Shame them publicly!

 

[Third-Stage Guild Navigator]"I did not say this. I am not here."[/Third-Stage Guild Navigator]

[Actual television resolution.]

Nice illustration! If I had to choose I'd much rather watch movies in widescreen format on PAL than NTSC - the vertical resolution is so low extra scanlines really make a big difference.

I'd much rather watch widescreen movies on a widescreen HD TV! And I hate when I pull out an old "widescreen" DVD of a movie that's really just a letterboxed 480-line film-- I have to change the settings on my HD TV and Blu-Ray player so the picture fills up the screen the way it's supposed to. Oh, well, eventually they'll be re-released in a proper widescreen format-- I hope.

 

With the games the programmer has a lot more CPU time to play with, your model frees up even more

 

What happens with PAL 262 mode normally, does this correct for aspect ratio or stretch out the image?

If you make a PAL/50 game that draws only 192 active lines (the yellow area in my illustration), you do get a lot more CPU time during the vertical blanking. And even if you draw 230 active lines so the picture more closely resembles an NTSC/60 game (the yellow and gray areas in my illustration), you still get more CPU time, since you've got 82 lines of vertical blanking (as opposed to only 70 lines of vertical blanking with NTSC)-- but not as much extra CPU time as with only 192 active lines.

 

If you make a PAL/60 game, the picture should match that of an NTSC/60 game (except for the difference in the color palettes), since the lines should be spaced a little further apart such that the pixel aspect ratio is the same as an NTSC/60 game. In contrast, using 230 lines in a PAL/50 game should give you an active area that's about the same height as 192 lines in an NTSC/60 or PAL/60 game, but the pixels will be flatter/wider because of the lines being closer together-- so you get a higher vertical resolution, but that means it will be harder to make the graphics match those of the NTSC/60 or PAL/60 version. For example, a sprite that's 12 lines tall will look shorter or squatter in PAL/50-- you'd have to draw the sprite 14 or 15 lines tall (12 * 1.2 = 14.4) to make it look like it's the same height as a 12-line-tall sprite in an NTSC/60 or PAL/60 game.

[Actual television resolution.]

How many scanlines do we have if we make sure to only use half of them?

 

I was amazed when widescreen became popular because the format effectively deinterlaced the image.

If you've got something scanlines, but you make sure to use only half of them, then you have some scanlines. Now, you might have thought you'd have some scanlines plus half of the t, but if we include half of the t then we'd be interlacing, so we have to throw away the half of the t since we aren't interlacing. So we keep the some and throw away the thing.

 

As for PAL, the reference I was looking at said PAL pixels have an aspect ratio of 59:54, but another page says that a pixel aspect ratio of 12:11 is actually used, which makes more sense. That still gives a Stella scaling factor of 109% for PAL games.

 

I made a picture to try to (approximately) illustrate how a PAL 2600 and NTSC 2600 screen compares to the full TV picture. The full canvas represents a 4:3 screen. The black area represents the part that corresponds to the border on an Atari 800 (NTSC). The yellow plus the gray portion represents the picture area on a standard NTSC 2600 screen (192 lines, each with 160 active color clocks). The yellow portion by itself represents 192 lines on a PAL 2600 screen, with the gray portion representing the extra blanked lines above and below the active lines. If you want the PAL 2600 screen to have the same size and aspect ratio as the NTSC 2600, you should draw about 230 active lines (288/240=1.2, and 192*1.2=230.4).

 

[Actual television resolution.]

This is partially off-topic from the specific question about scan lines, but I believe the resolution for NTSC 240p is given as 352x240. For an Atari 800 Graphics 0 display, this corresponds to 44x30 characters, so the border area is 2 characters wide on the left, 2 characters wide on the right, 3 rows tall at the top, and 3 rows tall at the bottom:

 

352 x 240 = 352/8 x 240/8 = 44 x 30 = (2+40+2) x (3+24+3)

 

The Atari 2600 doesn't have a border area like the Atari 800, since the border area on the 800 is part of the active video (hence you can set the border color), whereas the border on the 2600 is part of the horizontal blanking and vertical blanking.

 

Anyway, I believe the pixel aspect ratio for NTSC video is given as 10:11. That applies to both 704x480 and 352x240, since 352x240 = (704/2)x(480/2). But since the 2600 has 160 active pixels per line, its pixel aspect ratio is 20:11, or about 1.82 (1.81 repeating 81). That's close to the default 2x1 pixel size used by most of the emulators; but if you want to tweak Stella's resolution to get 1.82, you would set the scaling factor to 91% (100% = 2.0, so 1.82/2.0 = 91%).

 

I'm not sure about the PAL 2600, but I think the pixel aspect ratio is 59:27, or about 2.19 (2.185 repeating 185). So I guess you'd set Stella's scaling factor to 109% for PAL?

[Learn Assembly in 8 hours with bB and the ASDK]

_{I prefer DOS edit because it has line numbers, lets you split the screen and has a fun retro feel.}

I started out in Atari 2600 programming with the old "2600 SDK" programming IDE (called "adev.exe"), which was rather similar to DOS Edit except it had menu options for assembling your 6502 code and running the resulting ROM files in an Atari 2600 emulator. It used to be available on the old DASM web pages, but disappeared many years ago-- although I do still have it on my Windows XP computer.

[A few Harmony questions...]

The BD ROM cannot be released to public anyway.

True, but I got the impression he might have been referring to the one-level "demo" ROM that Andrew had posted shortly before the full game was green-lighted for release, since Andrew had commented that BD wouldn't work on a Harmony cart. Except now that I think about it, did that comment apply to the "demo," or only to the full game? I assume the compatibility issue is related to the number of banks used by the game, versus the number of banks that Harmony supports for the 3F and 3E bankswitching schemes-- in which case that "demo" ROM should work on Harmony, right?

[A few Harmony questions...]

I believe I read somewhere that that Boulderdash game for example cannot be played on it.

Actually, I think Boulder Dash was/is sold on a *modified* version of the Harmony cart. But AFAIK you can't play the ROM on a *standard* Harmony.

[Charge!]

when flickering, objects are half as bright, so increasing their brightness evens out similar objects not flickering overall.

Not necessarily-- it depends on the two colors involved. If you're flickering an object (playfield, ball, player, or missile) against a black background, then yes-- the object's perceived color will be about half as bright as normal. But if you're flickering that same object against a *white* background, it will be *brighter* than normal.

 

However, the suggestion of increasing the brightness is a good one, although it should be phrased in terms of adjusting the object's hue and luminance as needed to try to maintain a more consistent appearance (color) for the object whether it's flickering or not flickering. For example, if the unflickered object is orange, and is displayed against a red backdrop, then you might want to change its color to yellow when you're flickering it, so the result will be orange (yellow plus red).

 

Generally speaking, flickering can give inconsistent results depending on the display device (as pointed out by theloon), and some people are more sensitive to it than others ("Aaaahhh! My eyes! My eyes!"), which makes it tricky to use in a game. But getting back to what I'd intended to say in my first post, tweaking the hues and/or luminances of the colors that are being flickered together (whether it's changing the color of a sprite between frames, or alternating between the sprite's color and the background color between frames) could significantly reduce the amount of flashing or "strobing" that's perceived by the viewer.

 

Another consideration is what the intent is-- using flicker to create the appearance of more colors, or more sprites. If you're trying to get more sprites, then you might want to keep the hues closer to each other on the YIQ/YUV color wheel, as hues that are directly opposite each other will create a shade of gray when flickered together. But if you're trying to get more colors, then it doesn't really matter where on the color wheel the two hues are in relation to each other-- in fact, you might even *want* them to create a shade of gray. And even if you're going for more sprites, you still might want the two colors to make gray. For example, I was designing a hi-res 96-pixel bitmapped title screen for a Christmas-themed game that I may or may not ever make, and I wanted the text to be white on red-- so I used red (or really more of a dark pink) for the background and light green for the letters (players), which produced text that was as close to white as I could get it.

[Charge!]

I played around with that kind of flicker

It's the only kind of flicker there is! Whether you're flickering to get extra colors, or flickering to get extra sprites, you're still alternating between two colors.

[Charge!]

By "flickered at 30hz," you mean that they swap every other frame, since hz is just another way to say the frames per second, right?

 

I've tried flickering something between two positions every other frame and it makes for a very noticeable flickering effect, especially without phosphor effect enabled, while yours is almost unnoticeable, even without phosphor. How did you manage to make them so stable with bB?

Flickering is greatly influenced by the amount of contrast between the two colors being flickered-- the degree of difference between their hues and their luminances.

[A slow year]

I don't think so. When I get a chance, I'll take a look, but I doubt it.

It would be great if the CD does have the ROM on it, so it could be loaded to a programmable cart (Harmony, Krokodile, or Cuttle) and played on an actual 2600.

 

But if it doesn't, I can certainly understand why Prof. Bogost might not want to make the ROM available so that unscrupulous people could potentially use it to make and sell carts.

 

The $8.95 price is very reasonable for a paperback book and CD.

 

As for the sold-out limited edition version, its price was more than my budget would have allowed for a 2600 game, but judging from the description I'd say the cost probably had more to do with the book-- "Leather casebound, foil embossed... with color details..."

[Asm Masters: Can switching pfcolors+pfheights be hacked in?]

I'll check the old test program-- it uses some special include files that don't exist in the current version of bB unless you copy them from that old thread into your includes folder. It seems they're missing the "RETURN" routine, so evidently they need to be brought up to date for the current version.

 

The problem with using pfcolors and pfheights together in the standard kernel is that the data must be loaded using LDY ABS,X due to timing considerations. The method I used in that old thread was to modify the standard kernel so it looks for the data in RAM. The combined pfcolors and pfheights table uses 40 bytes, so there isn't enough room in page zero unless the playfield is relocated to Superchip RAM.

 

I'll re-examine this issue to see if I can come up with any alternate solutions.

[48 pixel sprite positioning and optimisations]

The problem opcode is "sbx", and the clone is the Flashback2. It also can't run carts with SC RAM or DPC+, so those should be avoided if you're aiming for 100% compatibility.

This sounds like the kind of information that needs to be added to that page which describes the many different variations of the TIA and its clones, and what (if any) compatibility issues exist between them-- even though this is probably more of a CPU compatibility thing than a TIA compatibility thing.

["jmp (abs)" across page border ?]

I am a little unsure about what to do...manually adjust the vectors' location I suppose, but that seems cheesy. Any more general suggestion for handling this would be valued.

As flashjazzcat said, simply aligning the vectors would be the normal approach-- pretty much like it's standard to align data to avoid page-crossings. If you don't want to waste a byte, trying rearranging your subroutines, data, and vectors so you don't get this problem with the vectors.