nesdev.org

Maybe run a cycle counter routine to tell whether it's running on NTSC or PAL (or even Dendy).

Dwedit wrote:Maybe run a cycle counter routine to tell whether it's running on NTSC or PAL (or even Dendy).

Sounds intriguing - is there example code of this technique available?

The total number of clock cycles per frame on various systems:
29780 NTSC
33247 PAL
35464 Dendy

Run this code for a frame. Look at the value of counter afterwards. I'll assume all variables are in the zeropage, and the last beq does not cross pages.
Total cycles per iteration: 22

So afterwards, you look at the value of counter.

up to 1354: NTSC
up to 1512: PAL
up to 1612: Dendy (has NTSC-like sound pitch, and PAL-like 50 FPS)

Michel did this in Years Behind. The source is linked in this post: http://nesdev.com/bbs/viewtopic.php?p=50455#50455

You'll have to ask him if you want to use it though.

EDIT: There should be a law against posting at the same time as me.

neilbaldwin wrote:Sounds intriguing - is there example code of this technique available?

The simplest way I know of to detect NTSC vs PAL is having your NMI wait, say, 22 scanlines (NTSC Vblank has 20 scanlines, PAL has way more) as soon as it fires, and then check $2002. If the Vblank flag is set, it's a PAL console.

How long is Dendy's VBlank? Well, I don't think it's possible to detect a third system with this technique anyway, since the VBlank flag is cleared when you read it.

tokumaru wrote:the VBlank flag is cleared when you read it

The vblank signaling in the NES PPU has a race condition bug. If you try to read vblank status out of PPUSTATUS ($2002), you'll miss even more vblanks than you would with an NMI handler. I think that's why Dwedit used 'giveup' instead of PPUSTATUS in his code sample.

Now as I understand it, timings are like this:

Famicom, PlayChoice, NTSC NES, Brazil NES: 262 lines per frame, vblank NMI fires at 241, 3 dots per CPU cycle
PAL NES: 312 lines per frame, vblank NMI fires at 241, 3.2 dots per CPU cycle
Dendy: 312 lines per frame(?), vblank NMI fires at 291, 3 dots per CPU cycle

The Dendy NMI fires later so as to be more compatible with cycle-timed NMI handlers (e.g. Balloon Fight and Battletoads) and cycle counting mappers (e.g. VRC series).

tepples wrote:The vblank signaling in the NES PPU has a race condition bug.

And what does that have to do with the method I posted? The NMI fires, you wait a little more than 20 scanlines, read the PPU status and the VBlank flag will tell you if the system is PAL or NTSC (according to what you said about the Dendy, it would be detected as NTSC, which is nice). As far as I can tell, the racing condition doesn't affect anything in this case.

Are there emulators with a "Dendy mode"? I thought that the game I'm working on would fail on a Dendy, but if it's indeed like you described it will run just fine.

I was confused when I read about your method.

But if you want to measure a lot of frame timings to calibrate your engine, that's what a copyright notice screen is for.[1] You get at least 120 chances to measure frame timing while it is displayed. Besides, you can find the end of vertical blanking by waiting for the sprite 0 flag to turn off.


[1] That and decompressing the title screen tiles.

tepples wrote:But if you want to measure a lot of frame timings to calibrate your engine, that's what a copyright notice screen is for.

Why would anyone want that? I check it every frame just because my VBlank code is timed anyway, and it's cool to have the program adapt to the other system on the fly, without resetting.

Besides, you can find the end of vertical blanking by waiting for the sprite 0 flag to turn off.

Yeah, but the goal is not to find out how long the vertical blank is, the goal is to check the VBlank flag past the known duration of the NTSC vertical blank so that you get the answer (is the console NTSC or PAL) from a simple flag, without having to use a counter and check its value afterward. I find it simpler, but it will not detect a Dendy.

What is a dendy ?

Bregalad wrote:What is a dendy ?

Russia's unlicensed version of the Famicom. Apparently it has some unique hardware differences.

tokumaru wrote:Why would anyone want that? I check it every frame just because my VBlank code is timed anyway, and it's cool to have the program adapt to the other system on the fly, without resetting.

Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o

BMF54123 wrote:Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o

You're right that it isn't possible on the NES, but it is on the Super NES. Apparently there's some sort of "50/60 switch".

In fact it could be possible if you soldered 2 PPUs one on the top of the other and connect all their output pins to a multiplexer. (I don't know what you'd do with the video out pins tough).

But there would be issues with frequencies, as the main crystal freq isn't the same for PAL and NTSC so that's much inapplicable.

BMF54123 wrote:Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o

My game just supports this because in my case there is absolutely no extra cost in doing so, and it's cool to see a timing-sensitive program not breaking on emulators when the region is changed.

What's a Dendy?

Russia's unlicensed version of the Famicom. Apparently it has some unique hardware differences.

Generally speaking, it's the Asian PAL-Famiclones based on the 6527P/6538 chips (Dendy, Microgenius, Pegasus, etc.)
Oscilloscope tests HERE:
http://nesdev.com/bbs/viewtopic.php?t=5070
Vblank, NMI, scanlines, PPU etc.

Can someone fix nestopia's "dendy-mode" according these tests?