Make A NES Rom PAL Only

[Me_Dave]

I don't know if this is really romhacking related, but awhile back I found a really old program made by this cool old school programmer from Poland that just changes the PAL/NTSC bit of the iNES header of a Rom.

However that doesn't seem to really do anything. So How do you really switch the region of a NES Rom? "so that it only works in PAL Mode"

Is there a way to do it with a Hex Editor? or do you have to program your own game for it to work?

Also is there a way to really test it in a NES Emulator?

I have tried switching modes in several but most roms still work like normal except on the rare occasion when I find a Rom that Really is PAL Only and it reports that it can not be run in NTSC Mode. Then some emulators also have a Dendy Mode as a Region but I think Dendy Roms also use NTSC Mode. 


https://sourceforge.net/projects/mines-editor/
Mines has some other uses too and there is an older Windows Version that works the same as the Dos Version but it's still a Command line tool although both have a GUI. "You have to run it from a Batch File"

He also made a really cool Game Boy Emulator https://zboy.sourceforge.net/







     

[SMB2J-2Q]

I see your point.

For example, the very first PAL releases of Super Mario Bros. released in 1987 were exactly the same as the standard NTSC releases and so, consequently, run slower with the PAL NES consoles. A true PAL version of the SMB cart was released in 1990, also with numerous bug fixes included, but not everything was 100 percent optimized (for example, the soundtrack sounded faster due to limitations associated with pitch adjustment/note durations in the conversion from NTSC to PAL).

~Ben

[FAST6191]

Given the ines header is a user created concept rather than anything baked into the ROM/hardware itself I am not surprised little notes it/respects it.

Not sure how such things are done in those games, or generally. A casual scan on the nesdev wiki did not reveal much in the way of magic bits like some other systems have, nor anything in the seldom used Nintendo header, so whether you do some kind of cycle timing https://www.nesdev.org/wiki/Cycle_reference_chart or there is something more subtle during boot I don't know.
I can see a path to something automated -- combine some mapper detection and subvert the first instructions to be a standalone program if necessary you insert into some free space.

[SMB2J-2Q]

Given the ines header is a user created concept rather than anything baked into the ROM/hardware itself I am not surprised little notes it/respects it.

Not sure how such things are done in those games, or generally. A casual scan on the nesdev wiki did not reveal much in the way of magic bits like some other systems have, nor anything in the seldom used Nintendo header, so whether you do some kind of cycle timing https://www.nesdev.org/wiki/Cycle_reference_chart or there is something more subtle during boot I don't know.
I can see a path to something automated -- combine some mapper detection and subvert the first instructions to be a standalone program if necessary you insert into some free space.

He should also refer to these links:
https://www.nesdev.org/wiki/Detect_TV_system
https://retrocomputing.stackexchange.com/questions/20045/did-the-pal-version-of-super-mario-bros-on-the-nes-really-have-faster-music-an

~Ben

[shanem]

Since PAL runs at 50FPS, you basically have to edit a bunch of timing (through code) and things like SFX data. There are no specific bits to magically convert a game from 60FPS to 50FPS on NES to make it a true, PAL-only title. Developers across regions just edited and recoded their proprietary ASM files for their specific region according to their hardware.

Make sense?

[Me_Dave]

I see your point.

For example, the very first PAL releases of Super Mario Bros. released in 1987 were exactly the same as the standard NTSC releases and so, consequently, run slower with the PAL NES consoles. A true PAL version of the SMB cart was released in 1990, also with numerous bug fixes included, but not everything was 100 percent optimized (for example, the soundtrack sounded faster due to limitations associated with pitch adjustment/note durations in the conversion from NTSC to PAL).

~Ben

He should also refer to these links:
https://www.nesdev.org/wiki/Detect_TV_system
https://retrocomputing.stackexchange.com/questions/20045/did-the-pal-version-of-super-mario-bros-on-the-nes-really-have-faster-music-an

~Ben

Thank you, that really explains a lot as I really thought Dendy games had the same timing as NTSC, and I didn't know there even was a PAL version of Super Mario Bros..

I do have a suspected Dendy Rom that was dumped from my own cart but I am not really sure about it's origin as it could be from the Pegasus, cause there exist 2 known Cartridges of it and the second one was found in Argentina. Maybe I should test it on my Everdrive and see if there is any difference in the timing I don't really have anything to compare it too except the original cart maybe that could work.. It is AFAIK dumped as NTSC so it could be running at a different speed.       

https://familygameenargentina.blogspot.com/2015/10/1991-4-in-1-pacman.html
My cart is the same but is green except that the label on it makes it look like it could been a reproduction so that guy Probably has the only real Original Undumped Cart.

Given the ines header is a user created concept rather than anything baked into the ROM/hardware itself I am not surprised little notes it/respects it.

Not sure how such things are done in those games, or generally. A casual scan on the nesdev wiki did not reveal much in the way of magic bits like some other systems have, nor anything in the seldom used Nintendo header, so whether you do some kind of cycle timing https://www.nesdev.org/wiki/Cycle_reference_chart or there is something more subtle during boot I don't know.
I can see a path to something automated -- combine some mapper detection and subvert the first instructions to be a standalone program if necessary you insert into some free space.

Thank you, those clock rates can help me to determine what speed my many consoles are actually using depending on what chips they are built with. 

Since PAL runs at 50FPS, you basically have to edit a bunch of timing (through code) and things like SFX data. There are no specific bits to magically convert a game from 60FPS to 50FPS on NES to make it a true, PAL-only title. Developers across regions just edited and recoded their proprietary ASM files for their specific region according to their hardware.

Make sense?

Yes it does, as I figured you probably had program it yourself as the only real PAL ONLY Roms I have encountered are Homebrew Demo's that were built as PAL Only and don't work in NTSC Mode.
       

[Bavi_H]

Terminology note: In this post I use the word "region" to indicate NTSC, PAL, or Dendy because that is what my emulators' menus call it, but it might be more accurate to call it something else like "TV system". Be aware that the different lockout chips the NES uses are a different "region" concept that don't directly correspond to NTSC/PAL/Dendy.


Getting the emulator to run as a different region

Some emulators do not use the region flag in the NES file header to change the region at all. If that's the case, when you want to try another region you may have to add a filename tag or change the selected region in the menu, see below.

Your emulator might ignore the region flag in the NES file header if it thinks it knows better. Because NES files often have incorrect headers, emulators often calculate a checksum of the NES file without the header, then refer to an internal list of checksums of common games to determine the correct header settings to use. In Mesen 0.9.9 you can see if this happened as follows: After you open a game, go to the Tools menu and choose the Log Window command. At the bottom of the Log Window look for the line "[DB] Database info will be used instead of file header."

Filename tag: Some emulators will look for a (E) or (U) or (J) in the filename to indicate what region to use. If it sees (E) for Europe it will use PAL, if it sees (U) for USA or (J) for Japan it will use NTSC.

Menu setting: Your emulator probably has a menu item to run the emulator as a specific region. You can change the setting and reset the game to see how the current game would run on another region. This would be like plugging a US cartridge into a European NES with its lockout chip disabled, for example.

In FCEUX 2.6.4, go to the Config menu, Region submenu, then select NTSC, PAL, or Dendy.
In Mesen 0.9.9, go to the Options menu, Region submenu, then select Auto, NTSC, PAL, or Dendy.

When you change this setting, the emulator will probably switch the region immediately. Some modern games will detect what system is being used during start up and adjust itself, so after changing the region setting you might want to reset the game and see if it behaves differently.


Developing a game for a different region

The different region consoles have both a different CPU clock rate and a different video frame rate. In the NESdev Wiki page Cycle reference chart, look at the rows for "CPU clock speed" and "Frame rate (vertical scan rate)".

On the NESdev Wiki page "Detect TV system", there's a section at the bottom called What to change that provides an overview of timing values a developer should consider adjusting for a different region. These various time-based values are based on either the CPU clock rate or on the video frame rate, such as:

value	based on
music pitches	CPU clocks
music note durations	video frames
object velocities	video frames (for example, velocity values in subpixels per frame)

Adjusting these time-based values for a different region console usually involves compromises. For example, because of precision and rounding when doing conversions, the object velocities and accelerations will probably feel slightly different on NTSC and PAL versions of a game, no matter how much work the developer puts into converting them.

[Me_Dave]

Terminology note: In this post I use the word "region" to indicate NTSC, PAL, or Dendy because that is what my emulators' menus call it, but it might be more accurate to call it something else like "TV system". Be aware that the different lockout chips the NES uses are a different "region" concept that don't directly correspond to NTSC/PAL/Dendy.


Getting the emulator to run as a different region

Some emulators do not use the region flag in the NES file header to change the region at all. If that's the case, when you want to try another region you may have to add a filename tag or change the selected region in the menu, see below.

Your emulator might ignore the region flag in the NES file header if it thinks it knows better. Because NES files often have incorrect headers, emulators often calculate a checksum of the NES file without the header, then refer to an internal list of checksums of common games to determine the correct header settings to use. In Mesen 0.9.9 you can see if this happened as follows: After you open a game, go to the Tools menu and choose the Log Window command. At the bottom of the Log Window look for the line "[DB] Database info will be used instead of file header."

Filename tag: Some emulators will look for a (E) or (U) or (J) in the filename to indicate what region to use. If it sees (E) for Europe it will use PAL, if it sees (U) for USA or (J) for Japan it will use NTSC.

Menu setting: Your emulator probably has a menu item to run the emulator as a specific region. You can change the setting and reset the game to see how the current game would run on another region. This would be like plugging a US cartridge into a European NES with its lockout chip disabled, for example.

In FCEUX 2.6.4, go to the Config menu, Region submenu, then select NTSC, PAL, or Dendy.
In Mesen 0.9.9, go to the Options menu, Region submenu, then select Auto, NTSC, PAL, or Dendy.

When you change this setting, the emulator will probably switch the region immediately. Some modern games will detect what system is being used during start up and adjust itself, so after changing the region setting you might want to reset the game and see if it behaves differently.


Developing a game for a different region

The different region consoles have both a different CPU clock rate and a different video frame rate. In the NESdev Wiki page Cycle reference chart, look at the rows for "CPU clock speed" and "Frame rate (vertical scan rate)".

On the NESdev Wiki page "Detect TV system", there's a section at the bottom called What to change that provides an overview of timing values a developer should consider adjusting for a different region. These various time-based values are based on either the CPU clock rate or on the video frame rate, such as:

value	based on
music pitches	CPU clocks
music note durations	video frames
object velocities	video frames (for example, velocity values in subpixels per frame)

Adjusting these time-based values for a different region console usually involves compromises. For example, because of precision and rounding when doing conversions, the object velocities and accelerations will probably feel slightly different on NTSC and PAL versions of a game, no matter how much work the developer puts into converting them.

Thank you, That explains a lot.

However I have Messen Set in Preferences Advance to Disable Built-In Game Database "I hate when a emulator relies entirely on a Game Database" and I mostly use NintendolatorNRS that doesn't use a Game Database.

I did find that Mines is not even needed as you can set a NES ROMs Region "TV System" Bit in a Hex Editor or using a iNES 2.0 Header like with Nintendolator. Although that doesn't really do anything except when if you do encounter a Pal Only Rom that display's on the screen that it can't be run in NTSC Mode or that you need to switch to Pal or Dendy Mode. You can set the iNES 2.0 Header of that Rom to Dendy and it will load the game in NTSC Mode but only in a Emulator that relies like you said on reading the iNES Header and isn't using a Game Database or some other method to determine what TV System is being Used.

It works with Messen if the game database is disabled and it works with NintendolatorNRS. "At least it did work for the one rom I tested it with so far"