SeaGtGruff

The reason it comes into play only while the game isn't being actively played is so it doesn't interfere with playing the game. I've also heard people say that it's because the graphics are changing (moving) while the game is being played-- although that doesn't sound very convincing to me, since a lot of games have background/playfield graphics that don't move. In any case, the color cycling kicks in pretty quickly-- in a matter of only a few minutes-- if the game is left inactive. And color cycling was included in the very first Atari 2600 games, and was specifically mentioned in Atari's game design guidelines; it was even built into the OS of the Atari 8-bit computers so that it happened automatically and didn't have to be coded and managed by the programmer. So Atari obviously felt that it was important. As far as whether other companies used color cycling-- I don't know, since we only ever had Atari consoles. But my guess is that the reason Atari felt it was important is because they'd gotten complaints from people who'd bought their Pong system and had experienced an issue with it. Whether the problem was actually that bad or was overblown by hysterical fear mongers, I don't know. And if it was that bad, I don't know what the reasons were. Maybe the signal was too intense-- i.e., in terms of the amount of contrast between the white objects and the black background. Or maybe TV manufacturers were building crappier TVs back then, and once a lot of people started to use video game consoles and home computers with their TV sets the TV manufacturers realized that they needed to start building better TVs. Anyway, I was probably wrong to say that Pong "ruined" our TV, because I don't remember whether we actually had to get a new TV because of Pong-- after all, it was 40 years ago, so my memory of those days is a bit hazy now-- but I do remember that the issue of screen burn was discussed in our house, and that my parents got rid of Pong because of that issue.

I don't know how long it's supposed to take for permanent screen burn to occur on a CRT TV. Have there been actual laboratory studies? Does the brand and model of TV make a difference, or are all CRT TVs built to exactly the same standards and specs? Keep in mind, we're talking about TVs from about 40-to-50 years ago (I'm not certain when the Pong game came out for the home market, but the TV set could have been bought several years before that). Also, the screen burn might not have been permanent-- it may have just been a persistence of image that eventually faded away. But when you're playing Pong for an hour or two, then you switch over to a TV station to watch a show and you can still see a ghost image of the Pong game screen, it tends to upset the people who wanted to watch the show, even if the ghost image eventually disappears after a while. I'm pretty sure there was a reason Atari instituted color-cycling in their games, and I seriously doubt it was because people had been leaving the Pong game on their TV screen nonstop for a year or two.

Our first "console" was Atari Pong, and it did ruin our TV. Oddly enough, it was my father who bought it, because I don't think any of us kids had ever heard of Atari Pong. That didn't stop us from getting an Atari VCS for Christmas one year, complete with half a dozen games like Space Invaders, Missile Command, Air-Sea Battle, and a couple of others I'm not sure about (Canyon Bomber? Sky Diver? Adventure? Superman?)-- and, of course, Combat. It's hard to remember which games we got along with the console and which were bought later. I don't think any of us had asked for an Atari VCS, so it was probably my father's idea (again). Later on, when we bought Pac-Man, he played it nearly as much as I did-- and he still plays a web version of Pac-Man on his computer.

Read his user name out loud and that should answer the question for you.

I don't know if anyone else mentioned it yet, but in some cases it might come down to collision detection. Try not to flicker two objects such that they're only ever displayed on alternate frames/fields if you need to be able to detect collisions between them, otherwise you'll need to compare their positions to see if they might be colliding.

Yellow Orange Red Purple Blue Green Brown White Black

ORG sets the actual address, whereas RORG is used to relocate the code to some other logical address. For example, if you're going to create a 16K ROM image then you can set ORG to $C000 at the beginning of the code, which would give you room for 16K from $C000 to $FFFF. But each 4K ROM bank needs to be at an address which reduces to $1000 after you strip off the three highest bits, which can't be "seen" by the address bus since it has 13 bits instead of 16. So you could use RORG $9000 for the first 4K of the ROM image, then RORG $B000 for the second 4K, then RORG $D000 for the third 4K, and RORG $F000 for the last 4K. The assembler will use each bank's RORG address for any instructions that reference memory addresses within that bank. If you don't give a RORG address, the ORG address will be used. There are a few things to note: If you're using RORG addresses for everything in the ROM image then the ORG address doesn't matter-- it could be $0000, $1000, $2000, etc. I'm not sure if it matters whether the ORG addresses overlap the addresses for the TIA, RAM, and RIOT, since they aren't part of the actual ROM image. If you are using RORG, the addresses for each bank don't need to be in order and don't need to be different. For example, you could use RORG $F000, RORG $F000, RORG $F000, RORG $F000 if you wanted, although giving each bank a unique address range makes it easier to keep track of which bank is which when you're looking at an assembly listing. Or you could use RORG $F000 for the first bank, RORG $D000 for the second bank, RORG $B000 for the third bank, and $9000 for the fourth bank. The RORG addresses don't determine what bank is the first one, which is second, etc.-- rather, the ORG addresses do that, because the bank numbers depend on what order the banks are in the ROM image, not what their logical addresses are. You should put some sort of data at the bankswitching hotspots, even though it's just "dummy" data, because you can't leave any "holes" inside the ROM image-- so you put dummy filler bytes at those addresses to plug the holes. EDIT: You can leave memory "undefined" in your code, but when the assembler assembles your code into a ROM image, it will fill those holes with default values. So you don't necessarily have to put data at the bankswitching hotspots, but whether you do or not the assembler will put something there anyway.

I'm not sure I understand what "software mode" means in this case. The 8-bit Atari's graphics were designed to allow changing graphics mode from row to row, as well as the ability to use interrupts from row to row for changing the colors, so it isn't as though using those abilities is somehow "tricking" the Atari into doing cartwheels that it was neveer designed or intended to do. Similarly, the Atari 2600 doesn't even have graphics modes-- you must manually update the graphics components (playfield pixels, player pixels, player positions, colors, etc.) from line to line or else you'll just get a series of colored bars that extend vertically across the screen. So it could be argued that it's impossible to draw the parrot at all on the Atari 2600 if "software modes" aren't permitted. If we were talking about "hacking" the computer's screen display by POKEing locations in ways that "trick" the computer into displaying things in a way its designers had never considered or intended, then I could see the point. But is that really the case with that image?

That picture of the old Royal reminded me of something I've always wondered, too-- When did the dollar sign go from two lines through it to only one line through it?

You can't make them smaller horizontally, only vertically. In batari Basic I think it's pfres or something like that-- it's been a while.

My Windows 8 computer isn't set up to compile batari Basic. Can you post a BIN to go with the BAS? Also, it seems like you could simplify those IFs, and I'm not following how N is being used.

Your original sprite was 24 bits (pixels) wide, so you'd need to use 3 sprites side by side, 8 bits each. To do that you'd need to use both player0 and player1, either as p0-p1-p0 (2 copies of player0, close together, with 1 copy of player1 between them) or as p1-p0-p1 (vice versa). You'd also need to use assembly instead of batari Basic, or else create a custom kernel for batari Basic. On the other hand, if this is supposed to be part of a static screen (no other objects and no movement), you could use the titlescreen kernel to do it. As an alternative, one thing you might try-- just to see how it looks-- is to use 1 double-wide player, and alternate the sprite's image between 2 frames with the horizontal position changing by 1 pixel position, to try to emulate the appearance of a 17-pixel-wide sprite. In places where the pixels overlap between frames, the player color will be solid; but in other places the player pixels will flicker with the background, so it should give you an apparent 17-pixel resolution but with some flicker. Or you could just position 1 copy of player0 beside 1 copy of player1 to get a 16-pixel sprite.

I'm looking forward to the new BIN. I think it's neat when people can recreate a classic Atari 2600 game using batari Basic.

I was thinking that if the delay for quad-width players were different than for double-width players, it might be +8 clocks, as follows: - strobe ends - 4 clocks for "start" signal (which isn't generated for "copy 0" until 228 clocks later) - 1 extra clock ("phantom pixel") for single-width player, then 8 pixels begin (1 clock each) OR - 2 extra clocks ("phantom pixel") for double-width player, then 8 pixels begin (2 clocks each) OR - 4 extra clocks ("phantom pixel") for quad-width player, then 8 pixels begin (4 clocks each) So: 4 + 1 = 5-clock delay for single-width players 4 + 2 = 6-clock delay for double-width players 4 + 4 = 8-clock delay for quad-width players But the extra 1 or 2 clocks aren't due to "phantom pixels" as I've suggested above, but are presumably due to some extra gates that must be processed before drawing the players can begin, which aren't needed for the missiles and ball. I haven't tried to decipher that particular part of the TIA schematics, so I'm not sure what the extra logic is. That parrot looks great! I wasn't asking for myself, so I don't know how much the restricted width would be a problem. A week or two ago someone asked whether playfield pixels could be 2 colors rather than just 1, because he was working on a "Snake" game and was wondering if he could make it a 2-player game. That got me to thinking about the possibility of using quad-sized players. Now I'm thinking the only feasible solution to that would be to alternate the playfield color between scan lines, and draw the blocks of each player's snake on the even scan lines for the first player and on the odd scan lines for the second player (or vice versa)-- with or without flicker to help remove the "blank" lines within each block.

I thought there might be a difference, but I wasn't sure. I gather that the difference is the same for double-width and quad-width, +6 clocks? My idea was to see if I could cover the screen with quad-sized players, lined up to the playfield pixel positions, so that each 40x192 position could be set to the background, playfield, or player colors. Unfortunately there isn't time enough to change sizes, strobe, load/store the graphics data, strobe again, and resize again.

Thanks, Thomas. I know that at one time Stella was positioning them 6 clocks after the strobe instead of 5, but I never tested it on actual hardware to see what the correct behavior is. I guess it doesn't matter, anyway, since I figured out that my idea won't work.

I'm well aware that when you strobe RESPx, the player's "coarse" position will be 5 color clocks after the strobe. But is this affected by the player's width? That is, will the player be positioned 5 color clocks after the strobe even if the player is set to double-width or quadruple-width? I would do a little experiment to answer the question myself, but my Windows 8 computers aren't set up for Atari programming, and my Atari 2600 and programmable carts are currently unavailable anyway.

^^^ This. I agree that sometimes large pictures are desirable, and other times they're overkill, but I think the amount of server space they take up is more important than how annoying slower load times or the need to scroll the browser window is for us. Since this issue is more likely to pop up with photos taken by high-resolution cameras, perhaps a few good rules of thumb might be to (1) always scale photos down to reasonable dimensions before attaching them; (2) always use JPG, PNG, GIF, or some other compressed format (personally, I hate JPG artifacting, as well as GIF dithering, so I vote for using PNG); and (3) consider cropping photos so they include only the relevant portions. Of course, the problem with rules of thumbs is that there are always exceptions, so the final rule of thumb should be "follow all of the preceding rules of thumb as appropriate, and break them as needed."

I think the "def" line must be fine as it is, because it seems to be interpreted correctly in the "complex statement detected" section. If the problem didn't start to occur until switching to a 64-bit OS, I'm thinking the cause might be related to the number of bits in a word-- i.e., 32 bits versus 64 bits. If I remember correctly, word size has created some issues in DASM before-- i.e., 16 bits versus 32 bits-- but I can't recall the specifics of when those issues occurred and what had to be done to either fix or work around them. I've been out of the Atari programming loop for well over a year now-- as it happens, ever since I got a 64-bit Windows 8 computer, retired my old 32-bit Windows XP computer, and ran into issues when I tried to get DASM, batari Basic, Crimson Editor, and Visual batari Basic installed and running smoothly. Consequently, I'm out of touch with the current states of DASM, batari Basic, Crimson Editor, and Visual batari Basic (although I am aware that work on DASM was revived recently). It might be necessary to create 64-bit versions of DASM, batari Basic's various executables, and Visual batari Basic, if any of those things haven't been "converted" yet. In the meantime, splitting the "if ... then" is a good idea, but you might want to split "b{1}=1:VelX=0.01" into two lines as well. Then make sure you're creating an assembly listing when you compile, and when (or if) compilation fails you should open up the assembly listing and look for the specific statement where the assembler threw up an error. Once you're able to identify the specific place where the error occurs, it might be possible to figure out some kind of workaround. EDIT: PS-- I noticed a misaligned "rem" in one of the pictures you posted. I can't tell whether that "rem" line is indented or not, since I don't know whether the other lines are indented by only 1 space or more than 1 space. Furthermore, if indeed that line is not indented, it might not cause a problem anyway, since the "rem" will simply be treated as a line label and the apostrophe after the "rem" will be interpreted as a "rem." On the other hand, I recommend that you scrutinize your code for any such misaligned lines and correct them as need be, because they can (and generally do) cause problems. Even if it turns out that there's only one other line which isn't aligned properly, and it just so happens to be another "rem" statement, the other "rem" might not be followed by an apostrophe, and having two line labels which are the same ("rem" and "rem") might cause problems. I always like to indent program code lines by at least 3 spaces so the difference between the program code lines and the line labels is much more obvious. EDIT #2: Also, it's been my experience that whenever you get "Unresolved Symbol List" errors yet the listed symbols are defined, it's usually some other symbol that was unresolved, hence the need to look carefully at the assembly listing to determine the precise statement that caused the batari Basic compiler and/or the DASM assembler to upchuck. And after finding where the error occurred during assembly, you might need to look at the assembly code generated by the batari Basic compiler, since the compiler may have (and probably did) generate some flaky assembly code from your batari Basic code. That's why you can often find the problem by going straight to the compiler-generated assembly code, but I prefer to look at the assembly listing first-- unless the compile process didn't even get that far. Additionally, I notice that "mul8" is one of the symbols that was listed. If I remember correctly, there were times when I needed to specifically declare the "divmul.asm" (or whatever) include file in my batari Basic programs, even though it wasn't supposed to be necessary to do so (i.e., due to the specific multiplications and divisions I was doing in my program). Determine which include file the "mul8" routine is defined in, then try specifically including that include file at the beginning of your batari Basic program.

Have you ever successfully compiled anything before with this setup, or is it your first attempt? If it's your first attempt with this setup, I'm thinking it could be problems with spaces-- i.e., in a directory name or file name. If that's the case, you can get around it by adding quotation marks in certain places in your Crimson Editor settings and/or batari Basic batch file.

I don't see how it could be either the cart or the Atari itself. If you count the bars there appear to be about 70 of them visible-- 35 green and 35 red. The Synthcart cycles the background color and uses 2 pfpixels of PF0 to mask the left and right edges of the screen (to cover up the HMOVE bars on the left), so that leaves 36 "empty" pfpixels for the background. When I run the Synthcart ROM in Stella using PAL60 mode, the background cycles between brown, purple, and red. So I'm guessing the alternating green-and-red stripes in the photo might be from the brown background color, since brown is red plus green. Then again, the stripes in the bottom half of the photo are phase-shifted a bit from the stripes in the top half, so they don't necessarily correlate to the brown background color. Anyway, it seems like it must be something to do with the mod, something to do with the TV (an obscure setting, perhaps?), or a combination of the two. It's like the background color is somehow being separated into red and green components, but phase-shifted depending on the actual color that's supposed to be displayed. It's almost like a weird sort of artifacting.

The problem is, different people have different senses of humor. *I* thought it was funny-- but people don't usually laugh at my jokes, either!

https://www.youtube.com/watch?v=1KRqeDEQcYk

Yes, it's normal with NTSC television signals. Look up "artifacts" or "artifacting" for an explanation.

I always used to display all 16 hues and luminances onscreen at once (in GTIA mode on an Atari XE computer) and then adjusted the brightness, contrast, color, and tint on the TV until hue 1 was yellow, hue 15 was brown, and I could easily distinguish between all 16 luminances. The color pot was unknown to me back then, and even if I'd known about it I probably wouldn't have messed with it.