[Diagram]SCPH-1000/3000 PU-7 MM3 Stealth Install

General information to do with the PlayStation 1 Hardware. Including modchips, pinouts, rare or obscure development equipment, etc.
rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » May 5th, 2017, 5:42 pm

Trimesh, do you know how how it gates the original SCEX string from an original disc on PU-20+ boards?

Also, I hooked up a scope to "point 6" (http://www.mod-chip.net/images/pu23l.jpg) and found that it constantly seems to mirror the test signal from "point 5" there. Isn't that confusing the tracking error circuit?

User avatar
TriMesh
Verified
PSX Aptitude
PSX Aptitude
Posts: 225
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » May 5th, 2017, 8:32 pm

PU-20 is the same as PU7/8/18 - it's just NRZ data fed into a pin on the MCU and another signal (commonly called 'gate') that pulls down the comparator input to prevent the original signal from getting through.

On the PU22/PU23/PM41 boards, this signal no longer exists because it's been embedded into the subcode data stream by the CD processor chip (presumably in an attempt to block modchips) so the modchip signal in instead injected into the tracking error processing chain. The problem with this is that if you just grounded down the signal for a whole bit cell then the tracking would drift off and the drive would lose the signal.

So they take one of the timing signals from the CD DSP (WFCK) and use that to chop up the drive signal so it's floating 50% of the time - this lets you inject the simulated error signal into the signal chain without excessive interference with the tracking servo. The choice of WFCK seems pretty much arbitrary - you can chop up the output signal with a software timer and it still works OK. I suspect it was done that way at least as much because it makes it easy to work out what sort of board the chip is installed in (by detecting if the clock is present) than anything else.

The important thing is that the chopping frequency has to be well outside the bandwidth of the filter in the tracking servo since then all the switching frequency stuff is filtered out and all that you end up with is an about 3dB reduction in the effective tracking servo filter gain.

Yes, this does cause some negative effects to the performance of the tracking servo, but it generally has more than enough gain margin to handle it. If the gain is very marginal, then it can mess things up (these are the consoles that stop working even with a correctly installed modchip).

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

Post by rama3 » May 6th, 2017, 1:00 am

This is a great explanation of what's going on. Many thanks!

So I'm left wondering about one thing:
Why does the chip continue interfering with the tracking circuit, long after the SCEX injections are done?
Is the bandwith filter so effective that the people designing this just didn't bother turning the interference off after a while?

Anyway, I think with this information, we can do better :)

User avatar
TriMesh
Verified
PSX Aptitude
PSX Aptitude
Posts: 225
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » May 6th, 2017, 10:09 pm

rama3 wrote:This is a great explanation of what's going on. Many thanks!

So I'm left wondering about one thing:
Why does the chip continue interfering with the tracking circuit, long after the SCEX injections are done?
Is the bandwith filter so effective that the people designing this just didn't bother turning the interference off after a while?

Anyway, I think with this information, we can do better :)
It's been a while since I looked at the code, but from what I can remember the output was left floating after the strings have all been transmitted. It's possible that what you are seeing is just coupling rather than an intentional data transfer.

The way that SCEx signal was injected on the newer units also changed with time. The first implementation used 3 wires and a link - the link coupled WFCK into the tracking servo and the data line just dragged it down. As a result, this signal was injected at all times. This worked OK on most units, although some had problems with it.

Later, a 5 wire approach was used, which effectively replaced the link with a software controlled link that could be turned off when not needed. Finally, the approach used in MM3/Mayumi was devised, which put both the clock output and the data output on the same pin.

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

Post by rama3 » May 7th, 2017, 12:14 am

So much insight, awesome! :)

I'll check again what's going on with the coupling that I saw. The signal was strong so I just assumed it was being actively driven.

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

Post by rama3 » May 11th, 2017, 7:22 am

Installed a PSNee chip using this diagram. Works perfectly :)

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » May 11th, 2017, 10:38 pm

TriMesh wrote:Basically the logic is...
Wow. Thanks for all that insights! I didn't knew how/why that WFCLK "sync" connection worked for booting unlicensed discs.
Yeah, using the SPEED signal with delays looks a bit hacky, and might run into troubles with some games/bioses/expansion roms.

I am wondering about the minimal requirement for the "gate" and "sync" signals.

For older boards with "gate", the "Old Crow" modchip code outputs "gate=highz" for a short moment after power-up, and it does then switch "gate=low" permanently. I don't understand what that's good for. It would seem easier to wire the pin to GND permanently, or are there any problems when doing that?

For newer boards with "sync",
TriMesh wrote:Finally, the approach used in MM3/Mayumi was devised, which put both the clock output and the data output on the same pin.
That sounds nice. So there are two wires on one modchip pin, one for "data" and one for "sync"?
And how would that signal look like? Could one just output the Raw SCEX signal, or would it be required to mix it with some WFCLK-style pulsing for the low-levels (or high-levels)? Something like...

Code: Select all

    _________________________                           _
  _|                         |_________________________|   Raw SCEX

    _________________________   _   _   _   _   _   _   _
  _|                         |_| |_| |_| |_| |_| |_| |_|   Low-pulsing?

    _   _   _   _   _   _   _                           _
  _| |_| |_| |_| |_| |_| |_| |_________________________|   High-pulsing?

User avatar
TriMesh
Verified
PSX Aptitude
PSX Aptitude
Posts: 225
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » May 16th, 2017, 12:26 pm

When outputting a '1', the pin is simply pulled low
When outputting a '0', the pin emits the WFCK signal (same phase as the reference)

Unlike the modes used on the older boards, the output pin is low-Z for the entire message.

Also note that I'm using '1' to mean a high bit in the SCEx message - I.E. the state that corresponds to the DATA pin being pulled low on the older modchips.

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

Post by rama3 » May 16th, 2017, 5:35 pm

Thanks, I can use that information right now :)

User avatar
toadhall
Interested PSXDEV User
Interested PSXDEV User
Posts: 5
Joined: Jun 25, 2017

Post by toadhall » July 9th, 2017, 5:46 pm

Traace wrote:Here you go, full stealth is also possible on PU-8, you're right. However, the diagram below is not mine. So i didn't test it yet. But it should just work!

Image
(All credits go to an unknown guy from EurAsia forums)

Please Ignore that strange looking chip on the left top of the board, its for some kinda color correction he said.
Only the Numbers are for the Modchip install.


I will do a proper PU-8 diagram in the future, but these boards are pretty expense here.


Edit: Oh and yes "h-ecke" sold them to me. ;)
Hi everyone! Figured it would be best to ask my specific question here as it's related to the topic.

I have a nice Japanese SCPH-5000 with a PU8 board and I'm attempting to install a MM3 chip on it but so far it doesn't seem to work. I followed the diagram from the quote above but all I get is the cd/memory card menu. The MM3 chip is a Japanese one from Eurasia.

Here's my attempt:
Image

I've doublechecked (and triple and quadruple) my work but can't seem to figure out what's wrong. Any ideas, guys?

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

Post by rama3 » July 10th, 2017, 1:15 am

Is your test game NTSC-J? Even if the modchip unlocks the drive, Japanese consoles will only start Japan licensed disks.
Your install looks correct. Modchip Pin 7 probably is drive door. Modchip Pin 3 is interesting.. Is it connected to HC-05 Pin 26? (SQCK)

Oh by the way, this PU-8 subrevision never came to Europe, as far as I know. I recently found one of these as well and it's a very late design. Kinda cool!

User avatar
toadhall
Interested PSXDEV User
Interested PSXDEV User
Posts: 5
Joined: Jun 25, 2017

Post by toadhall » July 10th, 2017, 2:46 am

Huh. Didn't think of testing an NTSC-J backup. Popped one in and it booted right up. Thank you for the help!

Though I didn't realize Japanese consoles wouldn't allow region free with MM3. That's disappointing. I assume this is a limitation of the early PS1 models? Is there any way around this? I have an NTSC-J PSone, modded as well but not by me, and that model plays other regions.
rama3 wrote:Your install looks correct. Modchip Pin 7 probably is drive door. Modchip Pin 3 is interesting.. Is it connected to HC-05 Pin 26? (SQCK)
Pin 27 I think.
rama3 wrote:Oh by the way, this PU-8 subrevision never came to Europe, as far as I know. I recently found one of these as well and it's a very late design. Kinda cool!
I think so too! Very unique and hard to find outside of Japan.
Last edited by toadhall on July 10th, 2017, 12:45 pm, edited 1 time in total.

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

Post by rama3 » July 10th, 2017, 3:10 am

Workarounds are a replacement boot rom chip, patching the games / bootdisk or booting from expansion ROM.

User avatar
toadhall
Interested PSXDEV User
Interested PSXDEV User
Posts: 5
Joined: Jun 25, 2017

Post by toadhall » July 10th, 2017, 3:29 am

Heh. None of them easy options. Thanks for answering!

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

Post by rama3 » July 10th, 2017, 5:24 am

No problem, I'm just sharing the headache xD

Fixes might be found some day. We know the BIOS region lock could be circumvented on PSOne units, by patching one bit of the BIOS code on the fly. This bit makes it so that the PAL console runs in NTSC(-U) mode and that mode doesn't verify the region of the disk.
It would be great if more BIOS versions supported this hack but I haven't looked yet.

User avatar
K4DoS
Curious PSXDEV User
Curious PSXDEV User
Posts: 15
Joined: Jan 28, 2014
PlayStation Model: SCPH-9002
Location: Bacau, Romania

Post by K4DoS » July 21st, 2017, 5:45 am

toadhall wrote: Though I didn't realize Japanese consoles wouldn't allow region free with MM3. That's disappointing. I assume this is a limitation of the early PS1 models? Is there any way around this? I have an NTSC-J PSone, modded as well but not by me, and that model plays other regions.
Apparently the NTSC-J PSone (slim) uses the NTSC bootrom for SCPH-103. If yours is a 100, then maybe it uses the NTSC boot rom too. (at least I looked over a SCPH-100 BIOS using pSX and it was in English.)

User avatar
toadhall
Interested PSXDEV User
Interested PSXDEV User
Posts: 5
Joined: Jun 25, 2017

Post by toadhall » July 22nd, 2017, 3:24 am

Interesting! My PSone is indeed SCPH-103. Does this make it an Asian model instead of a Japanese one?

User avatar
TriMesh
Verified
PSX Aptitude
PSX Aptitude
Posts: 225
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » July 22nd, 2017, 3:44 am

toadhall wrote:Interesting! My PSone is indeed SCPH-103. Does this make it an Asian model instead of a Japanese one?
Yes. The only practical difference is that it doesn't have the region lockout in the boot ROM because it uses the same boot ROM as the US model but with a mechacon chip that's coded for Japan.

The other difference is that the SCPH-xxx3 models use the same 7.5IRE black level that NTSC:U/C consoles do, rather than the 0IRE level used in Japan. This is presumably because they were sold in Taiwan, which used standard US style NTSC rather than the Japanese variant.

User avatar
toadhall
Interested PSXDEV User
Interested PSXDEV User
Posts: 5
Joined: Jun 25, 2017

Post by toadhall » July 23rd, 2017, 5:15 pm

That's a pretty neat thing to know! Thanks. SCPH-103 is pretty common here in Malaysia. I see them quite often on secondhand sales sites here and even the one I bought brand new back in the day is a 103 (sadly dead now).

User avatar
TheShadowRunner
Verified
Active PSXDEV User
Active PSXDEV User
Posts: 64
Joined: Mar 02, 2015
I am a: Enthusiast
PlayStation Model: DTL-H1000

Post by TheShadowRunner » July 29th, 2017, 10:17 am

TriMesh wrote:The other difference is that the SCPH-xxx3 models use the same 7.5IRE black level that NTSC:U/C consoles do, rather than the 0IRE level used in Japan.
I never understood the impact of the different IRE levels when it comes to consoles. For instance if a JPN system and US system were connected to the same monitor via RGB, JPN would have a darker image? Or does it only affect the composite signal?

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests