PS2 Test Clone

[l_oliveira]

It is hard-coded on the drive mechanics controller (mechacon), the BIOS has nothing to do with the drive region. There is no known way for any software running on the EE or IOP to change the drive region, or even to get any sectors off a disk from a wrong region.

That's true for all units manufacturated before 2006. Since the 7700x series Sony started to ship a single version of bios and mechanics controller which contains all regions. The region is then set at factory by writing a value on the mechacon chip EEPROM (which is internal to the said chip and has tight security). This is also why around that time most modchips stoped working with the newer PS2s and needed their CPLD microcodes to be updated.

The mechacon contains its own microcontroller and firmware (in an internal PROM), and it controls access to the drive. That is why modchips need some wires to the mechacon, instead of just the BIOS chip; they overwrite the disk authentication information (which is sent between the mechacon and drive DSP over a private bus), so the mechacon never "sees" the real region of the inserted disk.

Or if there's any, even (DVD-R/CD-R). I couldn't have it explained better :)

I don't know exactly when and why the boot sequence can fail, but there seem to be situations in which the drive controller is partially initialized, but the BIOS hangs in an infinite loop waiting for some response that will never happen.

Like I said on the previous post, faulty EE RAM can (and will on most cases) cause the RDRAM init to fail or even if the PS2 get to boot, cause random crashes, garbage on the screen and bad sound.
In the case of PS2 units that can't init the GS chip (TV stays on it's blue screen) or black screen with no boot the only diagnosis one can do is hook the EE SIO cable and set up it properly then wait for the DECI2 error messages. If RDRAM is faulty you will see something like this:

# Initialize memory (rev:3.17, ctm:393Mhz, cpuclk:295Mhz )
# RDRAM INIT returned error: -1
The error code varies depending on the kind of error... And sadly I don't know what each value means. And the unit hangs at that.

I think something like this causes the behaviour you are experiencing: upon boot, the BIOS send the initialization command to the mechacon (4 bytes, calculated off some other bytes from rom0:ROMVER), which succeeds. From this point onwards, the mechacon assumes the BIOS to be valid, and happily verifies each inserted disk. Therefore, it spins it up and searches for the region signature. If it matches, the disk is okay and the mechacon waits for normal software to read it (which won't happen, as the system failed to boot), so it keeps spinning. However, if the region doesn't match, the mechacon stops the disk and remembers the error status, ready to send it back to any application trying to read the disk (which, obviously, won't happen as well).

On early units (pre 7700x), because the Mechacon is completely independent from the IOP, it will work even if the ROM bios chip is removed, which prevents the IOP from booting for obvious reasons. I don't know how it is for the current production batches though.

For the IOP, the mechacon is seen as part of the DVD drive DSP registers as it's the DVD DSP chip that interfaces with the IOP. If the DVD drive hardware was faulty, you would get a normal boot log on EE SIO but still a black screen and the disc would not spin, I believe.

Hardware vs software behavior is such a wonderful topic for discussion, isn't it ? :thumbsup:

[Dr.Wily]

Hum. interesting !

The mechacon contains its own microcontroller and firmware (in an internal PROM), and it controls access to the drive. That is why modchips need some wires to the mechacon, instead of just the BIOS chip; they overwrite the disk authentication information (which is sent between the mechacon and drive DSP over a private bus), so the mechacon never "sees" the real region of the inserted disk.

OK, but this PROM can programed one time or many times ? This microcontroler is programed before or after being mounted on controler board ? Or other way, each microcontroler it specific to a zone ?

Industrially, it's more cheaper to have one controler board for all PS2 than a specific one for each zone. I mean, if this is the same board, that means that has a soft to program (or reprogram...) the PROM. That means also it has a pinout somewhere on the board to plug some programers or something.

The question is :

TEST PS2 has a diferent microcontroler or just diferent firmware in PROM ?

[l_oliveira]

Different microcontroller (they're all MASK-ROM based).

To illustrate what I mean I will mention a GH-006 motherboard I have here:

BIOS: (C) 2000 SCEI / B 10 020
DVD Driver ROM: (C)2000 SCEI / D 110 020 16M
Mechacon: (C)1999 SCEI CXP 102064 -102R (-102R is the firmware signature)


If it was a Japanese mechacon it would be -002R or -302R for a Europe PAL mechacon, -202R for an Australia mechacon... etc ...

Something for you to think about:


CXP102064-001R,-002R <- T10000
CXP102064-003R,-751R <- T10000H
CXP101064-605R <- SCPH-10000
CXP101064-602R <- DTL-H10000
CXP103049-403GG
CXP103049-003GG
CXP103049-501GG
CXP103049-002GG
CXP103049-303GG
CXP103049-203GG
CXP103049-103GG
CXP103049-401GG-TL
CXP103049-202GG-TL
CXP103049-102GG-TL
CXP103049-001GG-TL
CXP103049-301GG
CXP103049-201GG
CXP103049-101GG
CXP102064-202R <- SCPH-30002
CXP102064-102R <- SCPH-30001
CXP102064-101R <- SCPH-30001
CXP102064-007R <- SCPH-30000
CXP102064-005R <- SCPH-10000

[SilverBull]

Hardware vs software behavior is such a wonderful topic for discussion, isn't it ? :thumbsup:

Indeed :nod:. I love discussing these things, although I really come from the software side of things.

TEST PS2 has a diferent microcontroler or just diferent firmware in PROM ?

PROM = MPROM = Mask-Programmable ROM. This one is inside of the mechacon chip and written as part of the production process. It cannot be changed afterwards.
As l_oliveira wrote, 7700x and later units use a rewritable (internal ?) memory, so they can be reprogrammed for other regions, at least in theory.

Maybe this is a dumb question, but how is a changed mechacon region (in comparison to the console region) being handled when reprogramming the later chips? Is the private key for the MagicGate system (e.g., the one to decrypt KELFs) being written as well, or do all these chips have all private keys stored in PROM, and the rewritable ROM just tells the firmware which key to use?

Something for you to think about:

Interesting, thank you :thumbsup:.

[l_oliveira]

Maybe this is a dumb question, but how is a changed mechacon region (in comparison to the console region) being handled when reprogramming the later chips? Is the private key for the MagicGate system (e.g., the one to decrypt KELFs) being written as well, or do all these chips have all private keys stored in PROM, and the rewritable ROM just tells the firmware which key to use?

The new mechacon just contains enough firmware to cover all existing regions. All they have to do to change the region is overwrite certain settings on the internal mechacon eeprom (1024 bytes) and the mechacon will behave as desired. The new bios detects which region is the mechacon set as and then acts accordingly.

Interesting, thank you :thumbsup:.

You're welcome...

By the way, the mechacon codes list I posted above was extracted from you know what and is indeed official. The CXP-103049-xxx chips are used on the 30000R-39000 range, that was made from late 2001 to early 2003. Because we don't know of TEST PS2s using such mechacons, I left them blank.

From SCPH-50000 forward they switched for the "Dragon" series of mechacon (CXR706080) which contains the internal eeprom and real time clock chips as well as the syscon (System controller).

You see, fascinating stuff ... lol :dance:

[Dr.Wily]

I don't know if mechacon is pinout compatible between test\debug PS2 and retail ps2. But simple question, can I use a test\debug mechacon on retail PS2 ? (same revision)

[SilverBull]

I don't know if mechacon is pinout compatible between test\debug PS2 and retail ps2. But simple question, can I use a test\debug mechacon on retail PS2 ? (same revision)

No, you can't. At least not without swapping the BIOS chip as well.

The BIOS sends some authentication data to the mechacon on startup in order to unlock the drive (at least on the 3000x series; I don't know about the newer versions). This data includes both the console region and type (consumer vs. developer/test), and the mechacon won't operate if used with the "wrong" kind of BIOS.

[l_oliveira]

No, you can't. At least not without swapping the BIOS chip as well.

The BIOS sends some authentication data to the mechacon on startup in order to unlock the drive (at least on the 3000x series; I don't know about the newer versions). This data includes both the console region and type (consumer vs. developer/test), and the mechacon won't operate if used with the "wrong" kind of BIOS.

The newer versions have actually nastier initializations.
People saw it and had issues with it on 50000 or newer consoles while the FreeMC boot software were being developed. Because the OSDSYS loads the updater KELF file early on boot, drive init isn't done yet at that point so FMCBoot has to do it by it's own. It was quite troublesome for them back then.

[Christer-swe]

Tests will NOT play backups and they will NOT play DVDs.

I know they can't play movie DVD's (they can read DVD's with games on them :110:) but I'm fairly certain I have played a backup on one of mine... Do all versions lack this feature? :shrug:

[l_oliveira]

I know they can't play movie DVD's (they can read DVD's with games on them :110:) but I'm fairly certain I have played a backup on one of mine... Do all versions lack this feature? :shrug:

Because the early ones lack the Magic Gate feature (DVD player on ROM is Magic Gate encrypted) they don't have. As the newer ones came with Magic Gate enabled, there were no reason to make the consoles play DVD video. Like the DEV PS3s that don't play BD-Video.

The bottom line is that the console hardware can read DVD Video discs but it lacks software to do so.

[Christer-swe]

Yeah, but the question was about being able to play backups.

I'm sure I have played a backup on one of mine, but it might have been a patched disc...

[hl718]

I know they can't play movie DVD's (they can read DVD's with games on them :110:) but I'm fairly certain I have played a backup on one of mine... Do all versions lack this feature? :shrug:

TESTs will only play Master Discs.

If you have a true beta or have patched a backup to master, it'll work.

If you just burn a dupe, it'll fail to boot on a TEST whereas it'll work on a modded retail.

As far as DVD the main reason TESTs lack DVD-Video playback and PS3 TESTs lack BD-Video playback is licensing. If they don't playback movies then that's one less fee per unit Sony has to pay.

-hl718

[l_oliveira]

A simple test you can do is put a DVD video disc on a TEST and try to listen if it stops the disc. If it does stop the disc, DVD Video patched backups won't work....

But wait ... The TEST ROM is probably different enough to make ESR not work in the TEST. I think patching the discs for master disc is better than patch for ESR... lol