7 replies to this topic

[stephena]

So, I've been working on this issue on and off for a year or two. Basically, I need a way to reliably determine whether a ROM is NTSC or PAL format. I'll briefly outline what Stella currently does, and how the current approach isn't optimal:

• when the Console is first created, run the TIA for 60 frames
  
• each time a frame contains more than 285 scanlines, increment a counter
  
• at the end of 60 frames, if the count is at least 20 then the format is PAL, otherwise NTSC

There are several problems with this:

• I don't like magic numbers; that is, why '60', '285', '20', etc? What if a ROM had 284 scanlines most of the time? Should it be PAL or NTSC??
  
• auto-running the TIA makes other parts of the code more complicated. Specifically, 'smart' controllers like AtariVox and SaveKey have to know that they're not really being run; it's a test.
  
• What about ROMs that start out with a low scanline count, then switch to a higher one once the game starts? Currently it's detected as NTSC when it should probably be PAL.

I guess the real problem is that on a real system, the ROM isn't NTSC or PAL, the console is. The console has certain properties, and the ROM runs according to those properties. But in emulation it's the other way around; it's the ROM that determines what type of console you have. This is causing me all sorts of problems. For example, certain aspects of the emulation must be decided very soon. The maximum number of scanlines to produce (in the TIA) and the palette to use are two such aspects. Put another way, these things can't be dynamic. A decision needs to be made at the beginning of emulation, and the ROM must adhere to them from that point on. If they were dynamic, it would slow things down and give strange results. One scenario would be switching scanline counts constantly bouncing between NTSC and PAL palettes, but there are other similar issues.

Overall, the problem is that the console determines display format. That's the way a real system works, and it's the way the current code works (after the auto-detect has run for a short time). I'm at a loss how to work around this fact.

EDIT: I should add that any approach I use must still be automatic. Editing the ROM properties database to specifically indicate a ROM is PAL is out of the question. This is the way older versions of Stella worked, and it's a maintenance nightmare (not to mention it completely breaks any new homebrew PAL ROMs that are developed).

[goldenegg]

If there's nothing in the ROM to determine NTSC/PAL, why bother trying to auto detect at all? Why not just allow the user to set Stella to either NTSC or PAL mode and use that setting?

[trent]

I agree. Allow the user to select the mode and skip the detection.

[stephena]

There is a way to do this, and it's addressed in my "EDIT" point above. That's the way Stella worked in the past. If you try to load a PAL ROM on an NTSC 'machine' (where the machine is virtual here), you get weird behaviour (screen rolling/skipping, wrong palette, etc). And based on previous feedback, when that happens people say that Stella is crap, not that they didn't set the right setting. IOW, the responsibility falls back to me.

Besides, other emulators attempt similar autodetection, and removing it now would be a regression. It's so nice to start Stella, select a ROM and not have to care whether it's NTSC/PAL, uses left controller or right, etc. For the typical end user that doesn't care how it works (just that it does work), auto-detection is very nice. I'm just trying to improve its implementation.

I guess I may have to accept that what I'm trying to do is not completely reliable, and deal with corner cases as they pop up. I just thought there might be a nicer way of doing it. I guess it's my OCD popping up again

[Thomas Jentzsch]

Other options to check could be the timer values or the colors used. But those are even more unreliable.

For the scanlines, you have to use the middle between NTSC and PAL. But not the arithmetic middle, but where 312-n% = 262+n%. And that is ~285. So there you have your "why" part 1.

Not sure where the 20 comes from. Usually the first few frames are very unstable (initialization stuff happening there). So maybe e.g. the first 20 frames are ignored, and then it is >50% of the remaining 40 frames. But then it would be better to skip the first 20 frames completely. Maybe it would be better to wait until the scanlines are about stable (+/-1) and determine NTSC/PAL on this value.


BTW: I noticed a different Stella problem for BD: If you start it in NTSC mode and later switch to PAL, the screen goes crazy. But not when doing vice versa. So it should be somehow possible to switch the mode (and not only the palette) later on. Especially for developers. Probably that already exists and I just didn't find it...?

[stephena]

Thomas Jentzsch, on Tue Jan 17, 2012 8:30 AM, said:

Not sure where the 20 comes from. Usually the first few frames are very unstable (initialization stuff happening there). So maybe e.g. the first 20 frames are ignored, and then it is >50% of the remaining 40 frames. But then it would be better to skip the first 20 frames completely. Maybe it would be better to wait until the scanlines are about stable (+/-1) and determine NTSC/PAL on this value.

OK, some good info there; I'll look into it. Also, would looking at the starting scanline help at all? Maybe if it's 50 or greater then it's PAL??

Quote

BTW: I noticed a different Stella problem for BD: If you start it in NTSC mode and later switch to PAL, the screen goes crazy. But not when doing vice versa. So it should be somehow possible to switch the mode (and not only the palette) later on. Especially for developers. Probably that already exists and I just didn't find it...?

This is related to what I was saying above. Once Stella determines that the virtual console is NTSC, certain things are set in the TIA for NTSC mode (including the size of the window). Switching to PAL later probably causes the screen to roll, not unlike what would happen if you put a PAL cart in an NTSC console. So from that POV the emulation is correct.

However, I can see it being useful to dynamically switch between and NTSC and PAL consoles. Basically it would require a slight reworking of the TIA and Console classes, as currently once they're set up, they can't be changed.

[Thomas Jentzsch]

stephena, on Tue Jan 17, 2012 12:15 PM, said:

[OK, some good info there; I'll look into it. Also, would looking at the starting scanline help at all? Maybe if it's 50 or greater then it's PAL??

I would not rely on that too much (or not at all, unless you want to apply fuzzy logic). Also how to you determine the starting scanline? VBlank off? This can happen much, much earlier.

Quote

This is related to what I was saying above. Once Stella determines that the virtual console is NTSC, certain things are set in the TIA for NTSC mode (including the size of the window). Switching to PAL later probably causes the screen to roll, not unlike what would happen if you put a PAL cart in an NTSC console.

I wonder why it works vice versa then.

Quote

So from that POV the emulation is correct. However, I can see it being useful to dynamically switch between and NTSC and PAL consoles. Basically it would require a slight reworking of the TIA and Console classes, as currently once they're set up, they can't be changed.

That would be very helpful for development (or if autodetect fails).

[stephena]

Thomas Jentzsch, on Wed Jan 18, 2012 1:48 AM, said:

Quote

This is related to what I was saying above. Once Stella determines that the virtual console is NTSC, certain things are set in the TIA for NTSC mode (including the size of the window). Switching to PAL later probably causes the screen to roll, not unlike what would happen if you put a PAL cart in an NTSC console.

I wonder why it works vice versa then.

Because the TIA code sets some upper limits on # of scanlines once it is set as NTSC or PAL. PAL obviously contains more scanlines, so NTSC mode can 'fit' in its bounds. The same is not true of placing PAL in NTSC mode. I believe in NTSC mode, Stella sets the upper limit on scanlines to be 290. If you try to squeeze 312 scanlines into 290, then the result is screen roll.

As for forcing NTSC/PAL mode, I'll consider this for a future release.