12 replies to this topic

[cruzer]

In other words, do I need to test the demo I'm working on on a real machine before releasing it? I'm planning to get one of course, but I'm not sure when.

For instance I have read that you should avoid setting the sprite motion registers in the first 24 cycles after an HMOVE. This can indeed cause trouble, but in some cases it seems to be working fine, on Stella at least. Can I be sure it will on a real Atari 2600 as well? And can I count on the colors to be correct, especially when it comes to luminances? This is relevant when mixing colors from different hues to create alternative gradients.

Any other Pitfalls^TM?

[GroovyBee]

From my experience of 7800 development its always good to test on the hardware as soon as you can. Then at least you know that you are on the right track.

[Tjoppen]

I can confirm that Stella's PAL colors differ from those of the real machine. Yes, different hues have markedly different intensities.
Stella gets sad if you start doing unusual stuff like foregoing VSYNC. Most importantly the audio starts stuttering - try running xSqueeker and you'll see.
There's also an alignment issue if you let sprites roll around the edges of the screen. Like if you have P0 and P1 in the same position and set HMP0 = $10 and HMP1 = $F0 and repeatedly do HMOVE they won't meet back up in the same place - on a real machine they do.
The above applies to Stella 3.4.1 - I don't know how the latest development version behaves.
MESS deals with the above much better.
Also beware that none of the emulators seem to deal with lack of VSYNC "properly", as in showing the screen rolling.

edit: The message here is that if you don't have a console + flash cart (like Harmony) you should get them or ask someone that does to test your prods before release.

Edited by Tjoppen, Thu Dec 1, 2011 6:24 AM.

[RevEng]

Agreed with the comments so far. One other comment, which is not even all Atari's are identical with regard to odd hmoves, close timing for 6-digit score, and more. Ditto for colors on real hardware, hence the old joke of NTSC meaning Never The Same Color.

[Andrew Davie]

cruzer, on Thu Dec 1, 2011 5:37 AM, said:

In other words, do I need to test the demo I'm working on on a real machine before releasing it? I'm planning to get one of course, but I'm not sure when.

There's a slight emulation error in the timing of the cosmic ark star effect (works fine in Stella, but the real thing refuses to cooperate)... but apart from that, it's solid gold.
Personally, I'm quite comfortable trusting Stella to provide very accurate emulation.

Cheers
A

[stephena]

There are a few edge cases in the TIA emulation in Stella. I know about all of them, and have a reasonably good idea what's happening, but I haven't had time to do more research and properly fix them. In general, Stella is extremely accurate in all the common cases, and sometimes falls down in the few edge cases:

• 'illegal' MOVES: still not emulated 100%, but much better than pre-3.0 versions (probably most noticeable in Kool Aid Man)
  
• changing NUSIZx while drawing is happening: works for most ROMs, but isn't correctly emulated completely (we cheat in the source code and use hard-coded values, most noticeable in Meltdown)
  
• lack of VSYNC doesn't cause rolling: this is one that I hope to fix sooner rather than later, in fact there's preliminary code in the TIA class already

Basically, if you don't do late HMOVEs, don't change NUSIZx while drawing with it, and don't forget to include VSYNC, then Stella is very accurate. If you want to do any of the previously mentioned things, I strongly advise also testing on real hardware.

Note that an error isn't always apparent. Sometimes Stella does things that real hardware wouldn't (ie, it is more lenient with programming errors, making your ROM look like it's working correctly when it isn't). Other times, there's nothing wrong with your code, and the output you get from Stella seems wrong (but is right on real hardware).

In everything but the edge cases, I'm fairly confident in trusting Stella output.

EDIT: As for the palette, I'm not sure this can ever be properly addressed. Even real hardware is inconsistent. You are able to create a custom palette file and have Stella use that instead, but I suspect that even if I were to include it in Stella, someone else would come along and say the colours are wrong. Never The Same Colour indeed

EDIT 2: I forgot to mention, I think the only emulation issues are in the TIA code, not elsewhere. One area of the TIA emulation that only Stella deals with (AFAIK) is the behaviour of 'floating' TIA pins. In this case, there's a commandline argument to introduce random data onto the bus which clearly shows if the ROM has been programmed correctly. Also, Stella is currently the only emulator that properly deals with inadvertent reads from the write port of cartridge RAM space. In most cases, if you do that you'll get back garbage data and overwrite what was in RAM at that point. That tends to lead to graphical garbage just as you'd see on a real system.

[disjaukifa]

I always test on real hardware, constantly. I use Harmony for that, when I'm just testing colors and slight graphic changes, ie the design of a sprite I'll do that through Stella, but when it comes to functionality and checking to see the actually flow of my games, I use Harmony and my 2600.

[Pioneer4x4]

I cannot imagine developing a game without the combination of Stella & Harmony. I could not have done anything without both of them and kept my sanity.
If it doesn't run on real hardware, it isn't an Atari game

[Sdw]

I'd recommend testing on real hardware, get a Harmony cart and a cheap 2600jr or something!
I've had a few instances where things looked fine in emulator but not on the real deal. Most recently I had some code that dropped from 312 to 311 lines sometimes, looked fine in emulator, but on real HW the frames with the dropped line turned the picture black-and-white for some reason!

Also, colours of course look different. One thing I've noticed is that some luma transitions gives a horizontal dark stripe, an artifact I've actually seen on the Atari 130XE as well.

If you need help testing before you get real HW, of course I'd be happy to help.

[stephena]

Sdw, on Fri Dec 2, 2011 5:59 AM, said:

I'd recommend testing on real hardware, get a Harmony cart and a cheap 2600jr or something!
I've had a few instances where things looked fine in emulator but not on the real deal. Most recently I had some code that dropped from 312 to 311 lines sometimes, looked fine in emulator, but on real HW the frames with the dropped line turned the picture black-and-white for some reason!

While I agree that you should of course test on real hardware, the error you noticed here could also have been detected in Stella. You just need to turn on PAL color-loss emulation. Basically, PAL ROMs that run at an odd number of scanlines causes the palette to switch to black&white. And Stella correctly deals with that if you tell it to.

[Sdw]

stephena, on Fri Dec 2, 2011 3:08 PM, said:

While I agree that you should of course test on real hardware, the error you noticed here could also have been detected in Stella. You just need to turn on PAL color-loss emulation. Basically, PAL ROMs that run at an odd number of scanlines causes the palette to switch to black&white. And Stella correctly deals with that if you tell it to.

Thanks, wasn't aware of that. Found the option now and turned it on!

[SpiceWare]

stephena, on Fri Dec 2, 2011 3:08 PM, said:

Basically, PAL ROMs that run at an odd number of scanlines causes the palette to switch to black&white. And Stella correctly deals with that if you tell it to.

Hmm - is there a reason that's not the default setting?

[stephena]

SpiceWare, on Fri Dec 2, 2011 10:31 PM, said:

stephena, on Fri Dec 2, 2011 3:08 PM, said:

Basically, PAL ROMs that run at an odd number of scanlines causes the palette to switch to black&white. And Stella correctly deals with that if you tell it to.

Hmm - is there a reason that's not the default setting?

Probably to cater to the user that just wants to fire up Stella and play a game. From a developers POV, it should definitely be on by default. I will make it the default for the next release, but it still won't reset itself for people that already have Stella installed.