determining NTSC/PAL/SECAM from code examination

[AdamWozniak]

is there any way to tell what display type was intended (NTSC/PAL/SECAM) by examining disassembly or emulation?

 

at first i thought just "count WSYNC between VBLANKS" but then it occurred to me that, through careful cycle counting, it was possible to "skip" some WSYNCs and still wind up with a valid frame.

Edited May 10 by AdamWozniak

[Ben_Larson]

Right.  You can't count WSYNCs.  That would not be reliable for any game that uses cycle counting.

 

In general I think emulators just keep track of how many scanlines are being drawn on the screen and deduce based on that whether to use NTSC or PAL colors.

[JetSetIlly]

10 hours ago, AdamWozniak said:

is there any way to tell what display type was intended (NTSC/PAL/SECAM) by examining disassembly or emulation?

 

Not in the general sense. However, determining whether the ROM is NTSC or PAL covers perhaps 80% of cases and that is possible to an extent. The real complications come when you encounter SECAM, PAL60 and PAL-M. As far as I know there's no good way of automatically differentiating those.

 

 

For the emulator I've been working on, I have a couple of basic rules with regard to automatically detecting whether the ROM is NTSC or PAL:

 

(1) Start with the assumption the ROM is NTSC

(2) Once the TV screen is "valid", if the number of scanlines exceeds a "threshold" switch to the PAL specification.

(3) Consider the decision to be final once the TV screen is "stable"

 

* Working with a "valid" TV screen is important because the first few frames produced by the console have probably not be VSYNCed correctly and counting scanlines to determine the specification during this time will lead to mistakes. For practical purposes, I never consider the first frame to be valid for specification purposes.

 

* The PAL "threshold" is an arbitrary number that lies beyond what is possible for an NTSC TV. I've decided on 302 scanlines. ie. if the number of scanlines reaches 302 then the ROM is PAL rather than NTSC

 

* Finally, we need to be careful about "misbehaving" ROMs that output "bad" frames every now and again. These ROMs generally work fine but produce a "bad" TV signal every now and again. To defend against this, I say that the TV is "stable" (even if the ROM isn't) after the first six frames.

 

 

There are other things to consider when it comes to TV emulation, such as how the TV image is "framed". But with regard to automatically detecting the TV spec, the above rules are the best I could come up with.

 

I'd be interested in hearing if anyone has any other ideas. This is definitely an area I'd love to improve upon.

[+Gemintronic]

Disclaimer: This is a clueless, useless bit of conjecture.

 

I've heard there are small differences between US 2600s and other countries.  I think one is other countries got mono sound?  Could be very wrong on this.

 

I wonder if hardware differences like that could be detected.  Or, at least see if such differences were used or avoided in code.

[Thomas Jentzsch]

Stella has two options which try to detect PAL-60 and NTSC-50 games based on the color codes used. It uses some statistical data of PAL and NTSC games. But the hit rates are not very impressive, therefore the options are disabled by default.

[Thomas Jentzsch]

58 minutes ago, Gemintronic said:

I've heard there are small differences between US 2600s and other countries.  I think one is other countries got mono sound?  Could be very wrong on this.

IIRC PAL consoles got mono output, but that's something the CPU cannot see.

58 minutes ago, Gemintronic said:

I wonder if hardware differences like that could be detected.  Or, at least see if such differences were used or avoided in code.

There is a slight difference in CPU clock speed. This is used by some ARM games to detect PAL consoles (developed by @SpiceWare). But this only works because there is a 2nd clock in the ARM, which can be used to compare to the 6507 CPU speed. Besides that, I don't think there is anything usable.

[JetSetIlly]

Just now, Thomas Jentzsch said:

Stella has two options which try to detect PAL-60 and NTSC-50 games based on the color codes used. It uses some statistical data of PAL and NTSC games. But the hit rates are not very impressive, therefore the options are disabled by default.

Oh that's an interesting approach. Do you think the results for this could be improved with better statistical data, or is it a dead end?

 

* Can you give an example of an NTSC-50 ROM. I don't think I've come across one of those before.

[Thomas Jentzsch]

56 minutes ago, JetSetIlly said:

Oh that's an interesting approach. Do you think the results for this could be improved with better statistical data, or is it a dead end?

Maybe someone can find a better pattern than I did. But I doubt that sufficient improvements are possible.

56 minutes ago, JetSetIlly said:

* Can you give an example of an NTSC-50 ROM. I don't think I've come across one of those before.

Air Raid is above Stella's threshold for PAL games. I have attached a few other examples.

Commando (1984) (AKA Front Line) (Edu Games - Edu Juegos) (PAL).bin Barnstorming (Unknown) (PAL).bin River Raid I (AKA River Raid) (Edu Games - Edu Juegos) (PAL).bin Enduro (Edu Games - Edu Juegos) (PAL).bin

[+SpiceWare]

5 hours ago, Thomas Jentzsch said:

This is used by some ARM games to detect PAL consoles (developed by @SpiceWare). But this only works because there is a 2nd clock in the ARM, which can be used to compare to the 6507 CPU speed.

 

For those interested you can learn more about it in the Harmony/Melody Club entry found below. The routine can detect if the 2600 is NTSC, PAL, as well as SECAM.

 

It also covers 2600 / 7800 detection, which does not require an ARM. This is useful for implementing a pause feature that works via the 2600's TV Type Switch as well as the 7800's PAUSE button. Note: the 2600 / 7800 detect routine shown does use the CDFJ driver, you'll want to refer to @batari's original routine for pure 6502 games.

 

 

[AdamWozniak]

On 5/11/2024 at 3:08 AM, Gemintronic said:

Disclaimer: This is a clueless, useless bit of conjecture.

 

I've heard there are small differences between US 2600s and other countries.  I think one is other countries got mono sound?  Could be very wrong on this.

 

I wonder if hardware differences like that could be detected.  Or, at least see if such differences were used or avoided in code.

NTSC 2600s combine the two TIA sound channels to produce a mono signal.  this is done OUTSIDE the TIA.  from what i can tell of PAL schematics, the PAL TIA does this INSIDE the TIA.  the net effect is the same; mono audio.

[AdamWozniak]

On 5/11/2024 at 10:04 AM, SpiceWare said:

 

For those interested you can learn more about it in the Harmony/Melody Club entry found below. The routine can detect if the 2600 is NTSC, PAL, as well as SECAM.

 

It also covers 2600 / 7800 detection, which does not require an ARM. This is useful for implementing a pause feature that works via the 2600's TV Type Switch as well as the 7800's PAUSE button. Note: the 2600 / 7800 detect routine shown does use the CDFJ driver, you'll want to refer to @batari's original routine for pure 6502 games.

 

 

your problem is the mirror image of mine, which is also interesting, how can a cart determine what kind of 2600 it is running on?

 

i was mostly coming at this from the other direction though.  if i'm an emulator, how can i tell from the code in the cart what speed to run at?

 

 

[JetSetIlly]

4 hours ago, AdamWozniak said:

i was mostly coming at this from the other direction though.  if i'm an emulator, how can i tell from the code in the cart what speed to run at?

You can't tell from just looking at the code. You have to run it in order to find out about the TV image being generated. From that you can infer what TV specification is being targeted. The information about the TV image then implies the clock speed of the 2600 that is generating the TV image.