Then I suppose it might fill the purpose we need, provided two things:
Originally Posted by l_oliveira
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.
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.
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 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.
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.
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.)
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.
What of it ? I am not against the use of the Mechacon in any way.
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.
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.
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.
This isn't complex at all, it's just a matter of how to do it.
Best regards: dlanor