How to determine console region and default video mode

I don't think you understood what I meant. By reading the Mechacon register one would get the specific magic gate region assigned for the console, which is accurate even in case of a console with a misplaced ROM chip.

I did experiments with swapping of ROM chips on PS2 consoles and that never affected the PS2 region in any way. The official software would still operate correctly with an (for example) US ROM and Japanese Mechacon.

I would be able to boot PSBBN on a JPN motherboard (JPN Mechacon) but with an USA ROM by just turning the console on with the HDD connected.


So my point is, this is accurate enough to get you a proper region for the DVD drive of the PS2 console even if it's ROM is not the right one. And it's the DVD drive, not the ROM which ultimately defines the console region.

Edit:
Also, both the EEPROM (NVM) and Real Time Clock chips are peripheral to the Mechacon so even if you would read the SCPH- code from the NVRAM/EEPROM you would be talking with the Mechacon anyway. These two devices are accessed through CDVDMAN functions due to that.

This isn't complex at all, it's just a matter of how to do it.

Quote:

---

Originally Posted by l_oliveira

I don't think you understood what I meant. By reading the Mechacon register one would get the specific magic gate region assigned for the console, which is accurate even in case of a console with a misplaced ROM chip.

---

Then I suppose it might fill the purpose we need, provided two things:

1: We must have a translation table for those magic gate region codes, so we can interpret what they really mean. Just having access to the codes without a means of interpreting them is useless. Personally I have no idea even what format such a magic gate region code would have...

2: Whatever method is used to extract that register from the mechacon must either be workable on every existing console model, without modification, or have some equivalent method on every existing console model plus some valid method of choosing the correct extraction method for each model. I strongly suspect at least two different methods will be required.

Quote:

---

I did experiments with swapping of ROM chips on PS2 consoles and that never affected the PS2 region in any way. The official software would still operate correctly with an (for example) US ROM and Japanese Mechacon.

---

This in itself does not prove much, as region identity is also stored in NVM for most models. And that too remains intact if you just swap ROMs.

Quote:

---

I would be able to boot PSBBN on a JPN motherboard (JPN Mechacon) but with an USA ROM by just turning the console on with the HDD connected.

---

I still don't see how that pinpoints the mechacon chip. I'm not saying it isn't so, but only that this example doesn't prove it.

Quote:

---

So my point is, this is accurate enough to get you a proper region for the DVD drive of the PS2 console even if it's ROM is not the right one. And it's the DVD drive, not the ROM which ultimately defines the console region.

---

Why is that region system, of the several differing ones implemented here, to be considered 'ultimate' relative to the others ? (We know for sure that both game DVD releases and movie DVD releases can work in more than one product code region.)

Quote:

---

Edit:
Also, both the EEPROM (NVM) and Real Time Clock chips are peripheral to the Mechacon so even if you would read the SCPH- code from the NVRAM/EEPROM you would be talking with the Mechacon anyway.

---

What of it ? I am not against the use of the Mechacon in any way.

I'm just arguing that one of the best codes for our purposes would be the product code as stored in the NVM, regardless of the method used to access that code, and regardless of whether it really is obtained from the NVM at all. I couldn't care less about where we get it from, as long as we can get it in a reliable manner.

Quote:

---

This isn't complex at all, it's just a matter of how to do it.

---

Good. But I still think that model differencies may make it a little more complex as we need something that will work on all models, without exceptions.

Best regards: dlanor

Quote:

---

I did experiments with swapping of ROM chips on PS2 consoles and that never affected the PS2 region in any way. The official software would still operate correctly with an (for example) US ROM and Japanese Mechacon

---

Regarding this, I did see something interesting (But it will not be if it's not valid):

I dismantled a SCPH-39001 (v7) PS2 some time ago, and found something like those region code jumpers that can be found in some consoles like some older models of the Sega Megadrive.

As I scrutinized the mainboard, I saw 5 "jumper points" (1 is bridged by what looks like a SMT jumper, the other 4 are open) near the CXD3098Q (CD/DVD DSP I think).

That area on the mainboard which I'm referring to is on the side without the EE and GS chips, and is between the hole in the mainboard and the CXD3098Q chip.

Near each those "jumper points" is 1 letter: Either J, U, E and 2 other letters I can't remember (And the photographs I have don't show those letters clearly, but only those 4 points).

The "U" point is closed (Leaving the points J, E and those 2 others that have letters which I can't remember open), and this console is a NTSC-U console.

Maybe I'm just jumping the gun, but I do think that those 4 points do look like they have something to do with a console's region code.

I did take a few photographs of the mainboard, but none of them clearly show the letters next to those points.

I don't have that console anymore, as I had returned it as it's laser unit was failing (So I can't check to see what those 2 remaining points were labeled as).

@SP193:
Whatever those jumpers really mean, they can only be useful to us if the jumpered state is somehow readable by one of the CPUs in the console. Otherwise they are useless to us, no matter how profound effect they may have on the hardware. We need to access their state in software, in order to make our homebrews adapt to them.

Best regards: dlanor

SP193,

These jumpers are used at the factory by the assembly robot to choose which version of ROM/Mechacon combo it has to install on the board.

The earliest motherboard I saw with those jumpers was the US V1. And they're not populated on them. Also if you look carefully you will notice they're not connected to anything.

dlanor,

The only way to fully change the region of a PS2 console is replace it's Mechacon (and it's ROM as if you don't DVD playback will fail due to incompatible DVD elf being present on the mismatched EROM).

The Mechacon chip has a register where it outputs it's internal ROM version and that's what I'm talking about.

Checking it should be something simple just like how jimmi check the DEV9 chip version register to figure out if the console is of PCMCIA DEV9 or SSBUS DEV9 type to then choose if OPL picks cdvdman_pcmcia or not.

And considering that I have access to a good number of different versions and regions of consoles this could be interesting if we make some kind of test application to make this a PoC. (this "Proof of Concept" thing surely been famous recently with all that hacking, eh ? lol)


And working on this don't need to be anything done in a rush as currently nobody has actively complained about their console not working right.

I'm sure on certain cases, like Katananja's 90006 console he would obviously prefer NTSC over PAL (which is what the 90006 defaults to as video system) so it would be odd for him if some day he downloads an updated uLE elf which determines that his console is PAL regardless of it being of J game region and has to run on 50hz. :lol:

You see, people see "NTSC-J" on the SCPH-9006 but when you turn it on it outputs PAL video. But then the "NTSC-J" marking on the sticker means it runs "NTSC-J" discs, not that it's of NTSC video system.
http://media.photobucket.com/image/S...1/DSC02662.jpg (SCPH-90006 Ceramic White sticker)

Confusing, not ? :crazy:

What I wanted to say is that I wasn't able to read the NVM on the emulated v12 at all. Someone with a v12 already complained that the region detection is not working in kernelloader. I think I used the correct offsets within the NVM for region detection. I found a NVM dump of a v12 console that proves that my offsets are correct. There must be a way to dump the NVM of a v12 model.

The problem is simply the fact that SONY tightened the security on the DRAGON version of the Mechacon chip (that chip equips all consoles made after the 5000x and it contains the mechacon, syscon, eeprom and real time clock on a single part) because people were abusing DNAS with those tools to modify the EEPROM and get around DNAS bans on Socom and other online games.

You won't be able to directly read the EEPROM on anything newer than V7.

Quote:

---

The Mechacon chip has a register where it outputs it's internal ROM version and that's what I'm talking about.

---

What about the "sceCdMV" function that supposingly reads the Mechacon's "version"? I haven't seen what kind of numbers/string it returns, but perhaps it's worth looking into?

The CDVDMAN modules in the BIOS contains several "interesting" functions that return information related to the system. And many of those functions are not present in newer modules, especially on those bundled with games.

I think that there was also a function to read a console's NVRAM (But which one? The Mechacon's?).

Even CDVDFSV (EE RPC server on the IOP side) provides access to them from the EE.

Anyways, it's true that many parts are linked to the Mechacon, even if it seems dumb (E.g. the Mechacon is responsible for powering-off the console, the system clock is read from the Mechacon...).

Quote:

---

These jumpers are used at the factory by the assembly robot to choose which version of ROM/Mechacon combo it has to install on the board.

---

Thanks for enlightening me on that one.
I think that I saw that they were really not connected, but thought that I was mistaken. :lol:

Quote:

---

Originally Posted by l_oliveira

The only way to fully change the region of a PS2 console is replace it's Mechacon (and it's ROM as if you don't DVD playback will fail due to incompatible DVD elf being present on the mismatched EROM).

---

Yes, I know. The PS2 is a complex system, and several of its parts must match each other in order for things to work right.

Quote:

---

The Mechacon chip has a register where it outputs it's internal ROM version and that's what I'm talking about.

---

I got that part. But what I don't know is how such a version code relates to the specific region of the console (or the product code of the console).

Quote:

---

Checking it should be something simple just like how jimmi check the DEV9 chip version register to figure out if the console is of PCMCIA DEV9 or SSBUS DEV9 type to then choose if OPL picks cdvdman_pcmcia or not.

---

Accessing the register is probably easy, once we find out how it should be done, but we also need to know how to interpret its contents, which I do not know at present.

Quote:

---

And considering that I have access to a good number of different versions and regions of consoles this could be interesting if we make some kind of test application to make this a PoC.

---

Sure, we can do that. But even if we get consistent results for the consoles we try it with,, we still can't be sure that these codes are equally valid everywhere. Only an official spec can prove that, and that is something we only have for the official product codes of the consoles. That is one of the reasons why I've kept returning to these codes as the ideal choice.

Quote:

---

And working on this don't need to be anything done in a rush as currently nobody has actively complained about their console not working right.

---

Well, homebrews only choose between PAL and NTSC, so even in a fully random scenario the odds would be 50% for a happy user. But with all normal US, European and japanese consoles the result is always correct (except for homebrews using the old absolute address method to check ROMVER).

So it is only for consoles outside of these 'normal' regions that the possibility of error exists, and here we still have 50% chance of correct choice at random, plus the strong factor that modern TV sets in PAL regions always support NTSC syncing, and if the cable is not composite the user will probably not even notice if he gets NTSC instead of PAL.

So many users never can get this problem, and of those who do, many will not see it as a problem, or even notice it at all. But there are some who will, and it is for their sake that this thread is meaningful.

Quote:

---

I'm sure on certain cases, like Katananja's 90006 console he would obviously prefer NTSC over PAL (which is what the 90006 defaults to as video system) so it would be odd for him if some day he downloads an updated uLE elf which determines that his console is PAL regardless of it being of J game region and has to run on 50hz. :lol:

---

I don't really see the problem here. Why would PAL be used in any case ?

Both you and I agree that the xxx06 product code is for consoles needing NTSC-J, and I never suggested anything different. And whether the ROMVER string contains an 'H' or a 'J' in that 5th character position doesn't really matter, since they are both different from 'E' and therefore will cause NTSC to be used with the present method of uLE, just as would also be the case if basing the choice on an extracted xxx06 product code.

Both methods lead to correct results, since that is one of the regions for which no dubious factors apply.

The regions to expect odd results for are those where the ROMVER usage conflicts with the homebrew convention, such as for continental china using the letter 'C' (like you said), even though their TV system uses a variation of the PAL standard.

And that is where an improved homebrew method could help, based on the console product code (if available) or some other region specific code of similar reliability.

Quote:

---

Originally Posted by Mega Man

What I wanted to say is that I wasn't able to read the NVM on the emulated v12 at all. Someone with a v12 already complained that the region detection is not working in kernelloader. I think I used the correct offsets within the NVM for region detection. I found a NVM dump of a v12 console that proves that my offsets are correct. There must be a way to dump the NVM of a v12 model.

---

I don't know about the v12 specifically, as I've never had access to that model.

But I have used various bios dumper programs (for the needs of various PCSX2 versions), and some of these have successfully dumped NVM contents of all my consoles. This includes both v15 and v18, where any security concepts of v12 should also be present. Perhaps parts of the source code of those bios dumpers could be useful for NVM extraction for our purposes too.

Quote:

---

Originally Posted by l_oliveira

The problem is simply the fact that SONY tightened the security on the DRAGON version of the Mechacon chip (that chip equips all consoles made after the 5000x and it contains the mechacon, syscon, eeprom and real time clock on a single part) because people were abusing DNAS with those tools to modify the EEPROM and get around DNAS bans on Socom and other online games.

You won't be able to directly read the EEPROM on anything newer than V7.

---

But if so, then how did the bios dumpers produce NVM files for my v15 and v18 consoles ?

I suppose they might just generate values of their own invention (defaults) for some console types, but I doubt that anyone would bother to code it that way. It would be easier to just supply a dummy file for people to use with consoles where NVM extraction doesn't work. I suspect that those bios dumpers may well hold the solution to this.

Best regards: dlanor

Well I meant that the SCPH-90006 is a PAL console at the video output. But it read Japanese region coded discs.
Once the games boot they change the video back to NTSC.
I never saw a original Chinese game but I suppose it set up the video output as PAL even being marked as NTSC-J.


Now, regarding the mechacon stuff, I think the dumpers work because they only read and they do that through the proper SCE functions which do all the obscure "juju" needed to unlock the chip for reading. Obviously the intent of the tightened security is block hacker tools from working, in the same way as the USB port changes made on the IOP. SONY aways been a company which believed that obscurity is a valid way of making things secure... :crazy:

You probably know that better than me...

Now back to the subject at hand, the mechacon region checking is an absolute method because each DVD player region requires the mechacon to contain different encryption keys and therefore different firmware ROMs.

If we're able to compile a table with the MG regions and the respective read back values we will have a solid method to determine the console region and along with another table have an reasonable set of default settings.

I'll check and try to figure out the details regarding the registers later on today.