Jump to content
IGNORED

Emulator on monitor vs. real Atari 2600 on TV


Random Terrain

Recommended Posts

Although I'm a lowly batari Basic user who constantly deserves to be spit on, I still have the problem of going from emulator to real Atari 2600. For example, I'll make a sprite and think it doesn't look so bad using an emulator, but when I throw it into a Krok cart, stuff it into my Atari 2600, and look at it on a normal (non-HD) TV, the colors are darker, the edges are no longer crisp, dots for eyes are almost swollen shut (depending on the color), and you get that ghostly glow and that pesky slight lean to the right with most of the colors.

 

If I choose brighter colors, it's going to look like crap using an emulator and there's not enough room to make huge eyes and have thick edges. So here are two questions:

 

How do you make something that will look good using an emulator on a monitor and a real Atari 2600 on a TV?

 

Is the trick to just avoid a black background?

 

 

 

Thanks.

Edited by Random Terrain
Link to comment
Share on other sites

The Atari 2600 was produced when television sets would produce a blurry picture in response to even a perfect signal. Thus, there was no perceived need to include high quality video output and RF circuitry in the 2600. I'm not aware of any emulators that deliberately produce a blurry picture, but nor am I aware of any way to exploit the blurriness. I would expect that a game running on a black and white television could exploit the over-modulated chroma by having objects color cycle in such a way as to produce a "dot crawl" pattern that would move right or left or remain stationary. Never heard of that being done, though.

Link to comment
Share on other sites

How do you make something that will look good using an emulator on a monitor and a real Atari 2600 on a TV?

First, try to use a palette that's reasonably close to what you'll see on the TV. I generally prefer the z26 palette, although it isn't perfect.

 

Second, see if you can pick an emulator graphics mode with pixels having an aspect ratio that's reasonably close to what you'll see on the TV. I generally use the Stella emulator with the OpenGL Renderer (which, by the way, gives a somewhat fuzzy picture), and a GL Aspect of 83.

 

Aside from those suggestions, it can largely be a question of trying it out on a real TV to see how it looks, and using trial and error until you get something you're happy with. Also, you might consider having a switch in your program to let the user choose between two different sets of colors-- one set of colors for emulators, and another for TVs. But that shouldn't be necessary in the vast majority of cases, especially since you can adjust the settings on your TV or monitor if the colors are too bright or too dark, or if the tint needs to be nudged a bit.

 

Michael

Link to comment
Share on other sites

BTW, one thing I should have mentioned more clearly: on the 2600, pixels may appear to be shifted somewhat based upon their color. Further, certain colors (most notably those which are nearly opposite on the color wheel) will look bad when placed adjacent to each other.

Thanks.

Link to comment
Share on other sites

Have you thought about using emulation on a TV.

I don't have a modified Xbox or anything like that, so I don't think I can use an emulator on my TV. Best I can do is put the game on a Krok cart.

 

Glad I tested my game on a real Atari 2600. Before I did that, it seemed like I was getting a steady 262 in Stella, but letting the game play by itself on the Atari revealed a screen roll once in a while. That meant I needed to find a way to speed up my code. It made me do some rethinking and with tips from the bB forum, I found out how to trim some things down and do more with less and now the screen roll is gone. Emulators are great, but there's nothing like a real Atari 2600 for testing a game you're working on.

 

I can't wait to buy the Chimera cartridge so the process will be faster. My Krok cart is nice to have, but the Chimera cartridge will be even nicer. I plan to buy at least 3. Probably not all at once, though. I might have to buy one every other month.

Link to comment
Share on other sites

Yep, screen rolls aren't noticeable in Stella. What I do to check that in Stella is to enter the debugger and type in breakif { _scan==#263 } which causes the program to halt if it goes over 262 scanlines. However, this doesn't catch it if there's too few scanlines.

Link to comment
Share on other sites

Yep, screen rolls aren't noticeable in Stella. What I do to check that in Stella is to enter the debugger and type in breakif { _scan==#263 } which causes the program to halt if it goes over 262 scanlines. However, this doesn't catch it if there's too few scanlines.

That's a great tip. I see that Stella won't let you copy and paste, so you have to type it in every time.

Link to comment
Share on other sites

Yep, screen rolls aren't noticeable in Stella. What I do to check that in Stella is to enter the debugger and type in breakif { _scan==#263 } which causes the program to halt if it goes over 262 scanlines. However, this doesn't catch it if there's too few scanlines.

You don't have to test for equality only. You could also test for > 262 or < 262, or even != 262.

 

EDIT: Oops, now that I think about it, testing for < 262 won't work as you'd think. Since every frame will have scanlines less than 262 at some point, testing for that is pretty useless. I guess you'd need to test for _scan<262 and something else that indicates the end of a frame. That would pick up on frames that end with less than 262 scanlines.

Edited by stephena
Link to comment
Share on other sites

Yep, screen rolls aren't noticeable in Stella. What I do to check that in Stella is to enter the debugger and type in breakif { _scan==#263 } which causes the program to halt if it goes over 262 scanlines. However, this doesn't catch it if there's too few scanlines.

You don't have to test for equality only. You could also test for > 262 or < 262, or even != 262.

Another great tip. Is there a secret way to copy and paste in Stella? If not, can you add the ability to copy and paste?

Link to comment
Share on other sites

Yep, screen rolls aren't noticeable in Stella. What I do to check that in Stella is to enter the debugger and type in breakif { _scan==#263 } which causes the program to halt if it goes over 262 scanlines. However, this doesn't catch it if there's too few scanlines.

That's a great tip. I see that Stella won't let you copy and paste, so you have to type it in every time.

Copy and paste support is being worked on for a future release. However, you needn't type the command in every time, as you can save any commands you enter to a 'script' file using the 'save' command in the debugger. There are two possibilities:

 

1) Save the file named 'autoexec.stella', and place it in your 'base' directory (My Documents\Stella for Win32, $HOME/.stella for Linux and OSX)

 

2) Save the file named 'ROMNAME.stella' in the same place as the ROM itself.

 

Both of these files are parsed when the program starts. If they contain valid commands, they're automatically executed. Granted, it looks like the documentation doesn't mention this clearly (or at all), but the functionality is there, and it does work.

 

EDIT: These files can also be created outside Stella in a text editor. As long as they have the correct syntax, the correct name, and are placed in the right spot, they will load and execute just fine.

Edited by stephena
Link to comment
Share on other sites

Thanks. I looked at the Debugger page, but I'm not quite sure how save works. Would I type in "save autoexec.stella"?

Yes, but you then have to make sure it's in the 'base' folder as described above. You can do that outside Stella, using Windows Explorer or something. More work is needed in this area. BTW, 'autoexec.stella' will be run for every ROM you use, whereas the ROMNAME.stella will only be read for a particular ROM. Perhaps the latter is what you want?

Link to comment
Share on other sites

Thanks. I looked at the Debugger page, but I'm not quite sure how save works. Would I type in "save autoexec.stella"?

Yes, but you then have to make sure it's in the 'base' folder as described above. You can do that outside Stella, using Windows Explorer or something. More work is needed in this area. BTW, 'autoexec.stella' will be run for every ROM you use, whereas the ROMNAME.stella will only be read for a particular ROM. Perhaps the latter is what you want?

Thanks. I guess I can rename that file when I don't need it. I use save as often to make a new copy of the program I'm working on with the latest date and time like this:

 

puppynuggets_2008y_10m_30d_0610t.bin

 

So doing the ROM version would be as tedious as typing in breakif {_scan>#262} each time.

Link to comment
Share on other sites

I'm not aware of any emulators that deliberately produce a blurry picture...

:idea: MESS does.

Stella does as well, when using OpenGL mode and enabling the GL_NEAREST filtering. But what's really required is NTSC filter emulation (by Blargg), which I hope to add for a future release.

Link to comment
Share on other sites

For anybody reading this who is also a newbie, this is how I made an autoexec.stella file containing breakif {_scan>#262} on my Windows Vista computer.

  1. Opened Notepad and copied and pasted breakif {_scan>#262} in there.
    .
  2. Selected Save As under the File menu and located the Stella folder which is in the Documents folder (not the Stella folder in the Program Files folder).
    .
  3. Copied and pasted autoexec.stella into the file name box and selected All Files (*.*) from the Save as type drop down menu. (That fixed it so I didn't have to go back and remove ".txt" from the file name when I was finished.)

That was it. Now when I test a game I'm working on, all I have to do is run it in Stella, hit the key above Tab (`) for the debugger (which activates the code in the autoexec.stella file and hit the key above Tab (`) again to exit the debugger. From then on (until you close Stella) the debugger will automatically reopen if your program goes over 262. I thought I would have to rename the autoexec.stella file when I didn't need it, but it only activates when I open the debugger, so I can go ahead and leave it the way it is and play other games as long as I don't open the debugger.

Edited by Random Terrain
Link to comment
Share on other sites

I thought I would have to rename the autoexec.stella file when I didn't need it, but it only activates when I open the debugger, so I can go ahead and leave it the way it is and play other games as long as I don't open the debugger.

Yes, good catch on that one. I forgot that we only parse the file when the debugger is used for the first time (as an optimization thing). Looks like it serves another purpose as well; one can play games even if per-ROM debugger commands are defined, since they're never used until needed :)

Link to comment
Share on other sites

  • 2 weeks later...

Great thread! The autoexec.stella thing should also be added to the bB page, even though I can't get it to work. Now when I enter debugger and try to back out I can't. I have to CTRL-TAB to Windows, CTRL-ALT-DEL, and end task.

 

I should note I'm down for 1 or 2 Chimera carts once they're out.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...