25 replies to this topic

[jrok]

I'm curious which emulator is more accurate to physical cartridge performance? Both have a variety of settings that seem to "fix" certain performance issues but is there a particular platform and/or settings that reliably emulates the physical system? The reason I ask is because I'd like to someday put a game on cartridge, and I've already run into some major performance differences in a game I'm working on.

In particular, I'm using three for-next loops to test for collisions with a game map. Each for-next loop runs five iterations per game loop, with the first five on one side of the drawscreen and the other ten on the other side. Default z26 settings run this code silky smooth with no performance problems, but Stella's defaults chew on it like burnt steak. But if I switch Stella's settings from "Software" to "Open GL" or limit the number of for loops from 5 to 2 it's fine. Unfotunately, limiting the number of for-loops is too, well, "limiting" and I don't trust Open GL's hardware accuracy.

If anyone has any insight into the most accurate form of emulation, or even a good metric to test hardware accuracy I'd be much obliged. Thanks in advance.

Jarod.

Edited by jrok, Wed Oct 8, 2008 9:38 AM.

[stephena]

jrok, on Wed Oct 8, 2008 11:36 AM, said:

I'm curious which emulator is more accurate to physical cartridge performance? Both have a variety of settings that seem to "fix" certain performance issues but is there a particular platform and/or settings that reliably emulates the physical system? The reason I ask is because I'd like to someday put a game on cartridge, and I've already run into some major performance differences in a game I'm working on.

In particular, I'm using three for-next loops to test for collisions with a game map. Each for-next loop runs five iterations per game loop, with the first five on one side of the drawscreen and the other ten on the other side. Default z26 settings run this code silky smooth with no performance problems, but Stella's defaults chew on it like burnt steak.

I think you're confusing graphical performance with CPU emulation performance. Most systems today are so ridicuously fast that having the CPU emulation in C++ or assembly is pretty much the same thing. The number of for loops isn't the issue. Stella does have some problems with certain TIA emulation issues, but it's being worked on (and isn't related to your problem).

Quote

But if I switch Stella's settings from "Software" to "Open GL" or limit the number of for loops from 5 to 2 it's fine. Unfotunately, limiting the number of for-loops is too, well, "limiting" and I don't trust Open GL's hardware accuracy.

I think your real issue is that software rendering mode in Stella is slow on older computers with limited video cards, and switching to OpenGL mode 'fixes' this issue (because there's probably less onscreen changes). So your Stella options are to use OpenGL mode, or use software mode and switch to a smaller window. As for OpenGL hardware accuracy, I don't understand. OpenGL rendering in Stella should look exactly the same as software mode; it will just be a lot faster on systems that support it. Using OpenGL or software mode has no effect whatsoever on the emulation itself, only on how the graphics are sent to your video card (and screen).

Going forward (it's almost 2009), I will be concentrating on improving OpenGL performance and basically adding all new features to OpenGL mode (scalers and filters, etc).

EDIT: I just wanted to add that I'm willing to fix any software rendering issue you may be having, IF you send me a bug report and what type of hardware you're using. Also, any areas where Stella is deficient to z26 wrt the TIA will be addressed in a future release, and I'm eager to hear of any differences in behaviour, and where Stella isn't correctly emulating something.

Edited by stephena, Wed Oct 8, 2008 10:45 AM.

[jrok]

stephena, on Wed Oct 8, 2008 11:40 AM, said:

I think you're confusing graphical performance with CPU emulation performance. Most systems today are so ridicuously fast that having the CPU emulation in C++ or assembly is pretty much the same thing. The number of for loops isn't the issue. Stella does have some problems with certain TIA emulation issues, but it's being worked on (and isn't related to your problem)

Thanks so much for your speedy response, stephena. I've attached two binaries to help illustrate the issue, and see if you can reproduce it on your end. I'm pretty new to emu's so I'm not exactly sure whether what I'm seeing is an emulation bug or not. Basically, the rate of the game at which the graphics update seems to jump, almost as if the framerate itself is changing while the game is in progress. In other words the code still crunches correctly, but the rate at which the screen refreshes isn't constant the way it is in Z26 defaults.

The only reason I mentioned my for loops is that when I recompile with a lesser number of my for loops, Stella seems to handle the code fine no matter what the graphics transport mode is. Here's what I'm seeing on my end with these two binaries and Stella defaults:

Armageddon_Complex_5_loops.bin
- Entire graphics display shudders
- The refresh rate jumps every two seconds, almost like a "hiccup" effect (sorry for the bad analogy, but I'm not sure how else to describe it)

Armageddon_Complex_2_loops.bin
- No shuddering
- Constant screen refresh rate.

When I use Open GL on the "5_loops" version refresh rate is constant, but the display still shudders. Again, none of these problems occur on Stella when I shorten the total number of for loops per drawscreen. Default Z26 didn't seem to have any of these issues, no matter how many loops I included.

System Specs:
- Windows XP Pro
- Pentium D 2.80GHz
- 2.0G RAM
- RADEON X1300 Series graphics adapter

Thanks again for for taking the time to respond. I guess since I was seeing a definite difference in the way Stella and Z26 were handling the same code, I wanted to know which would be better suited to debug for EPROM, but in no way was I suggesting that Stella was inferior to Z26 in emulation. If anything, I assumed the issue was with my code, and wanted to figure out which standard to optimize towards. Please let me know if I've left out any info that might be helpful.

Jarod.

Attached Files

•  Armageddon_Complex_5_loops.bin   32K   49 downloads
•  Armageddon_Complex_2_loops.bin   32K   42 downloads

[Thomas Jentzsch]

jrok, on Wed Oct 8, 2008 7:22 PM, said:

Default Z26 didn't seem to have any of these issues, no matter how many loops I included.

Both binaries display a rapidly varying number of scanlines. Try z26 with option -n and see what I mean.

[jrok]

Thomas Jentzsch, on Wed Oct 8, 2008 1:57 PM, said:

jrok, on Wed Oct 8, 2008 7:22 PM, said:

Default Z26 didn't seem to have any of these issues, no matter how many loops I included.

Both binaries display a rapidly varying number of scanlines. Try z26 with option -n and see what I mean.

Yes, I noticed that too. But if z26 doesn't seem to have a problem with that, does that mean that the actual VCS hardware won't either?

[Thomas Jentzsch]

jrok, on Wed Oct 8, 2008 9:26 PM, said:

Yes, I noticed that too. But if z26 doesn't seem to have a problem with that, does that mean that the actual VCS hardware won't either?

Nope. Most likely the screen will roll on actual hardware.

Emulators are mainly written to emulate correctly written software. How they react on bugs, unless explicity implemented, is unpredictable.

[jrok]

Thomas Jentzsch, on Wed Oct 8, 2008 2:32 PM, said:

jrok, on Wed Oct 8, 2008 9:26 PM, said:

Yes, I noticed that too. But if z26 doesn't seem to have a problem with that, does that mean that the actual VCS hardware won't either?

Nope. Most likely the screen will roll on actual hardware.

Emulators are mainly written to emulate correctly written software. How they react on bugs, unless explicity implemented, is unpredictable.

Hmm... Well that's sort of helpful to know, but I suppose this brings me back to original nature of my question. After all, viewing the program on z26 doesn't show any obivous "bugs." So what I'm really asking is, does a baseline metric exist that programmers use to debug for cartridge? I mean, if emulators can't simulate true VCS performance via settings, is there a generally accepted list of benchmarks or guidelines on what to look for that may work in emulation but will be buggy on cartridge?

For instance, when I see wide trace variance in scanlines, what trace values I should aiming for (i.e 262)? Do benchmarks exist for framerate variance as well? Hope that makes sense.

Thanks,
Jarod.

Edited by jrok, Wed Oct 8, 2008 1:48 PM.

[Thomas Jentzsch]

jrok, on Wed Oct 8, 2008 9:44 PM, said:

Hmm... Well that's sort of helpful to know, but I suppose this brings me back to original nature of my question. After all, viewing the program on z26 doesn't show any obivous "bugs." So what I'm really asking is, does a baseline metric exist that programmers use to debug for cartridge? I mean, if emulators can't simulate true VCS performance via settings, is there a generally accepted list of benchmarks or guidelines on what to look for that may work in emulation but will be buggy on cartridge?

No special benchmarks. Just let someone make a final test on real hardware when you think you are done.

E.g. I developed Thrust almost solely with z26 and at the very end, Eckhard Stolberg tested the binary on his console.

Quote

For instance, when I see wide trace variance in scanlines, what trace values I should aiming for (i.e 262)? Do benchmarks exist for framerate variance as well? Hope that makes sense.

262 scanlines +-5% should be no problem. But they have to be constant.

[Nukey Shay]

What you are shooting for is a steady scanline count (first and foremost). Any deviation will cause problems on actual hardware whenever they occur. The guideline for counts is at 262 (NTSC) and 312 (PAL)...but those are secondary issues compared to an erratic count.

With all of that collision checking, you might have to break it up among multiple displays instead of checking all of them on a single frame (and/or optimize the code that exists within the loops).

[Random Terrain]

It will be nice when the Chimera cartridge is released since it will be even easier to use than the Krokodile Cartridge for testing our games on a real Atari 2600. I plan to buy a Chimera cartridge the second it becomes available.

[jrok]

Thomas Jentzsch, on Wed Oct 8, 2008 2:51 PM, said:

262 scanlines +-5% should be no problem. But they have to be constant.

Thanks, Thomas. This is extremely helpful, and it makes a lot of sense too. The funny thing is, I now know my suspicions about those "for-next" loops were correct. When I disable them all together, I maintain a constant 262 scan, and when I limit their iterations, the variance isn't nearly as large, which is probably why that 2_loop version worked okay in Stella.

Of course, that means I'll have to figure out a new way of testing those conditions, but it's incredibly helpful to know what sort of results to look for.

Cheers,
Jarod.

[Thomas Jentzsch]

Random Terrain, on Wed Oct 8, 2008 9:59 PM, said:

It will be nice when the Chimera cartridge is released since it will be even easier to use than the Krokodile Cartridge for testing our games on a real Atari 2600. I plan to buy a Chimera cartridge the second it becomes available.

I can't see how testing will become much easier with Chimera. With my Krokodile carts its just a matter of a few seconds.

So except of a wireless connection maybe (Bluetooth) I hardly can imagine any major improvement.

[jrok]

Nukey Shay, on Wed Oct 8, 2008 2:58 PM, said:

With all of that collision checking, you might have to break it up among multiple displays instead of checking all of them on a single frame (and/or optimize the code that exists within the loops).

Thanks, Nukey. I was just staring at my code a second ago and thinking the same thing (about breaking it across several frames.) What I'm doing now definitely isn't very elegant.

[Random Terrain]

Thomas Jentzsch, on Wed Oct 8, 2008 4:11 PM, said:

Random Terrain, on Wed Oct 8, 2008 9:59 PM, said:

It will be nice when the Chimera cartridge is released since it will be even easier to use than the Krokodile Cartridge for testing our games on a real Atari 2600. I plan to buy a Chimera cartridge the second it becomes available

I can't see how testing will become much easier with Chimera. With my Krokodile carts its just a matter of a few seconds.

So except of a wireless connection maybe (Bluetooth) I hardly can imagine any major improvement.

Maybe you need to upgrade your imagination. From what I've read, unless I'm mistaken, you'll be able to simply plop a game on a microSD card and take it over to the Chimera cartridge and get going. You won't have to play around with confusing menus and you won't have two cables constantly in the way that you'll have to plug into a cartridge every time. The Krokodile Cartridge is nice to have if you have nothing else, but it looks like the Chimera cartridge will be even faster and easier to use. I just want to get my game to the Atari 2600 with the fewest steps possible.

[Thomas Jentzsch]

Random Terrain, on Wed Oct 8, 2008 10:34 PM, said:

Maybe you need to upgrade your imagination.

Always a good idea.

Quote

From what I've read, unless I'm mistaken, you'll be able to simply plop a game on a microSD card and take it over to the Chimera cartridge and get going. You won't have to play around with confusing menus and you won't have two cables constantly in the way that you'll have to plug into a cartridge every time.

Well, I only use one cable which always stays inside the cart which always stays inside the console.

During developing I keep the Kroko Commander open. When I made a new binary, I simply press "Download" and switch the Atari off and on again. That's it, three steps: Compile, Transfer, Restart. I doubt Chimera can beat that.

So maybe you need to downgrade your imagination and upgrade your informations.

[Random Terrain]

Thomas Jentzsch, on Wed Oct 8, 2008 4:45 PM, said:

During developing I keep the Kroko Commander open. When I made a new binary, I simply press "Download" and switch the Atari off and on again. That's it, three steps: Compile, Transfer, Restart. I doubt Chimera can beat that.

So maybe you need to downgrade your imagination and upgrade your informations.

You're not supposed to have the power cord plugged in when it's in the Atari 2600, and you can only have the download cable constantly plugged into the Krokodile Cartridge if your Atari 2600 is close enough to your computer. I don't have room to have an Atari 2600 and a TV that close to my computer, so the Chimera cartridge wins. I just hope progress on it continues and I'll be able to buy one or two or three.

[Thomas Jentzsch]

Random Terrain, on Wed Oct 8, 2008 10:55 PM, said:

You're not supposed to have the power cord plugged in when it's in the Atari 2600...

It works, so... who cares?

Quote

...and you can only have the download cable constantly plugged into the Krokodile Cartridge if your Atari 2600 is close enough to your computer.

That's why I was wishing for a Bluetooth version.

Quote

I don't have room to have an Atari 2600 and a TV that close to my computer, so the Chimera cartridge wins. I just hope progress on it continues and I'll be able to buy one or two or three.

You can have mine.

[jrok]

Thomas Jentzsch, on Wed Oct 8, 2008 2:51 PM, said:

262 scanlines +-5% should be no problem. But they have to be constant.

Thanks again for your help with this. I revised my code somewhat to try to get scanlines under control, and I just wanted to make sure I understood what you meant by "constant."

I spread my code across three frames. Now, when I do a frame-by-frame trace in Stella, I get the following results:

Frame1: 262
Frame2: 276
Frame3: 273
(...)

It runs fine in Stella and z26 defaults, but the variance is less than 5% and it varies at a the same rate throughout the program. Is this what you mean by constant? Or do you mean that does every frame needs to have the exact same number of scanlines to prevent rolling (i.e. every frame has 276)?

Cheers,
Jarod.

Edited by jrok, Wed Oct 8, 2008 5:11 PM.

[s0c7]

jrok, on Wed Oct 8, 2008 5:50 PM, said:

Is this what you mean by constant?

Nope. If it is outputting at 262 scanlines, every frame needs to be 262. The swag he's talking about is although 262 is your baseline, some games output at 264 or something else close. But every frame needs to be the same or you'll get jitters or rolls.

[Random Terrain]

s0c7, on Wed Oct 8, 2008 7:05 PM, said:

jrok, on Wed Oct 8, 2008 5:50 PM, said:

Is this what you mean by constant?

Nope. If it is outputting at 262 scanlines, every frame needs to be 262. The swag he's talking about is although 262 is your baseline, some games output at 264 or something else close. But every frame needs to be the same or you'll get jitters or rolls.

When using Stella, I see that you can hit the "`" key above Tab to open the debugger, but how do you check the scanlines for many frames in a row? Do you have to repeatedly click on the Frame +1 button or can you make the debugger advance one frame every so many seconds until you stop it? I see that you can type in frame and a number, but that just skips ahead that many frames. It doesn't show you the scanline info for every frame up to that point.

[Nukey Shay]

Do you mean viewing the number of scanlines on-the-fly? The hotkey is alt L for Stella (shift cmd L in OSX).

[jrok]

s0c7, on Wed Oct 8, 2008 6:05 PM, said:

jrok, on Wed Oct 8, 2008 5:50 PM, said:

Is this what you mean by constant?

Nope. If it is outputting at 262 scanlines, every frame needs to be 262. The swag he's talking about is although 262 is your baseline, some games output at 264 or something else close. But every frame needs to be the same or you'll get jitters or rolls.

Sorry about the newbie questions, but I'm a newbie

I think I understand now. I went fishing for games that scanned over 262, and I noticed that "This Planet Sucks" weighed in at a constant 282 per frame. Out of curiousity, when you have frames that surpass 262, is there a standard method to even out the time? For instance, say I pared down my routines so that the maximum number scanlines in any given frame is 273. Would I (could I / should I) add garbage to the other frames until they also have 273 scanlines?

[Wickeycolumbus]

jrok, on Wed Oct 8, 2008 9:12 PM, said:

s0c7, on Wed Oct 8, 2008 6:05 PM, said:

jrok, on Wed Oct 8, 2008 5:50 PM, said:

Is this what you mean by constant?

Nope. If it is outputting at 262 scanlines, every frame needs to be 262. The swag he's talking about is although 262 is your baseline, some games output at 264 or something else close. But every frame needs to be the same or you'll get jitters or rolls.

Sorry about the newbie questions, but I'm a newbie

I think I understand now. I went fishing for games that scanned over 262, and I noticed that "This Planet Sucks" weighed in at a constant 282 per frame. Out of curiousity, when you have frames that surpass 262, is there a standard method to even out the time? For instance, say I pared down my routines so that the maximum number scanlines in any given frame is 273. Would I (could I / should I) add garbage to the other frames until they also have 273 scanlines?

All frames should be the same number of scanlines, or it will jitter(so yes, you should add/remove stuff to even out the scanline counts). Hope that answered your question

Edited by Wickeycolumbus, Wed Oct 8, 2008 7:37 PM.

[Nukey Shay]

All frames on an NTSC game should optimally be 262 frames. That is the highest "safe" amount. Having more than that increases the risk that the display will cause a television to roll. It's true that many games (including games made back in the 2600's heyday) surpass this number...just as it's equally true that some televisions have problems with them because of it. It's your choice.

BTW the latest build of This Planet Sucks! is a nice steady 262 in-game. AFAIK, it only deviates when game reset is pressed (dropping to 64). Since it's not during a game in progress, Greg probably figured that it wasn't important to fix.

Attached Files

•  This_Planet_Sucks__Fix___27_12_2002___Greg_Troutman_.bin   4K   40 downloads

[Random Terrain]

Nukey Shay, on Wed Oct 8, 2008 9:00 PM, said:

Do you mean viewing the number of scanlines on-the-fly? The hotkey is alt L for Stella (shift cmd L in OSX).

Thanks. That's cool, but that's not what I was looking for. I searched the debugger page for the words keyboard and shortcut and found nothing, but I forgot to search for alt. So thanks to you, I just did that and what I was looking for is Alt + f. I can hold down Alt + f and go frame by frame really fast and stare at Scanline: to see if it stays consistent.

**** This is a good thing to remember. Hit the button above Tab for the debugger, stare at Scanline:, then hold down Alt + f to see if Scanline: changes from frame to frame. If it stays at 262, I'm not screwed.