Developing a better hardware region detection method

General Programming help in C, C++ or ASM, Compiling / Debugging, and R3000A Central Processing Unit (CPU) information
Post Reply
rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Developing a better hardware region detection method

Post by rama3 » July 27th, 2019, 2:50 am

I'm proposing to develop a change in how homebrew software detects and adjusts to the different PSX models.
Standard practice has been to look at a char in the kernel that marks a console as being NTSC-J (char: I), NTSC-U (char: A), or PAL (char: E).
The practice is then to initiate the GPU with 60Hz for NTSC-J and NTSC-U, and with 50Hz for PAL.

Code: Select all

// SCEx string address in the BIOS (we *must* do a !='E' check or else a Japanese PSX will treat it as PAL)
if (*(char *)0xBFC7FF52!='E')
{
    // NTSC
}
else
{
    // PAL
}
This classic method works with the assumption that:
- this is what the user actually wants
- this is an unmodified console

These days though, there are several problems with that.
- Many modern displays don't work well with 50Hz sources, especially when considering upscalers and line doublers.
- Modern displays are often built for a native 60Hz refresh rate, and using 50Hz can put them in a degenerate display mode where scrolling isn't smooth and the active video area is reduced
- Quite a few consoles have swapped BIOS chips, often making an NTSC-J system report to be PAL
- Quite a few setups are using RGB (and not CVBS or S-Video). These setups have a clear choice between 50Hz or 60Hz, as color decoding isn't needed.

If we look at classic CRT monitors, those in the PAL region typically supports 50Hz and 60Hz RGB.
And if the CRT was made after ~1990 or so, it typically also supports NTSC color decoding.

So given this, I want to propose developing a new method to detect the system hardware (specifically the GPU clock speed).
And, using this method, I want to propose making the decision more often to default to NTSC timings on supposed (and real) PAL consoles.

If that new system detection method is successful, it would be great to include it as a library call in homebrew SDKs such as psxsdk or PSn00bSDK.
Last edited by rama3 on July 27th, 2019, 3:10 am, edited 1 time in total.

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » July 27th, 2019, 3:00 am

One idea to try is to put the GPU into both (PAL, NTSC) modes, and measure the VBlank interval using a CPU timer.

This should work, since the important difference between the 2 main system types is the GPU oscillator frequency.
That oscillator is slightly faster on NTSC regions, slightly slower on PAL regions, while the CPU oscillator is always the same 66.7Mhz for all regions.

It should be possible to characterize these console types:
- true PAL console (correct PAL GPU speed, wrong NTSC GPU speed)
- true NTSC console (correct NTSC GPU speed, wrong PAL GPU speed)
- "dual oscillator" type console (Net Yaroze, modded console) (correct PAL and NTSC GPU speeds)

Rarely, an early NTSC system type console can lock up the GPU when switching to PAL mode.
A timeout for the detection routine should trigger then, and the result is that this is a true NTSC machine.
This happens on a few machines that shipped with a disconnected PAL oscillator clock pin.
The system's GPU will stall while the test runs, and resume operation when the timeout eventually triggers.

The VBlank check should have some slack to account for manufacturing differences, "old/new" type consoles (consoles using dedicated oscillators vs newer PLL based ones) and modded consoles with not perfectly accurate oscillators.

The result of the system check should only be used to make a better informed decision on the default display mode.
Of course developers can still offer manual PAL/NTSC switches or choose to ignore the new check's result and go with the old method.

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » July 27th, 2019, 3:15 am

Some sample choices a developer can make using the new method, if it works:

- console is true NTSC > always use NTSC mode, disregard the region char
- console is true PAL > no change, it's still probably best to choose PAL mode, disregard the region char
- console is multiformat > this is new: use NTSC mode, disregarding the region char

Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests