[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.
User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

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

Post by Traace » May 3rd, 2017, 12:35 am

Hi Community, It started when I bought a SCPH-3000 from eBay. Because these Japanese Systems are not that common here in the EU.

I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.

There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.

And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.

(Click on the pic)
Image


PS1 is love :praise

2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.

I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know :)
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

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

Post by rama3 » May 3rd, 2017, 4:38 am

Oh, that's really nice of you. I suppose similar points will be present on the PU-8 series? Up until now, it was thought that those boards wouldn't support full stealth chips.

You didn't get this unit from "h-ecke" by chance? ;)

User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

Post by Traace » May 3rd, 2017, 4:47 am

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. ;)
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

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

Post by rama3 » May 3rd, 2017, 5:04 am

Awesome, thanks! :)

There's also many install pics around for the later PSX boards, where they tell you to grab a reset signal from all across the other side of the board. This is so silly, as the same signal is right there at the HC05, near Pin13.

User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

Post by Traace » May 3rd, 2017, 6:09 am

What you call Pin 13 on that 52pin HC05 is pin 20 on a 80pin HC05. :D

Yes that Pin 13 is connected to the reset lane. So a physical reset actually resets the drive controller too. One of the PS1 PCB reset lanes is like this: PSU-->Reset Signal-->?Diode?-->Resistor-->HC05(Drive controller)
So, in theory it should also be possible to take it straight from the PSU reset signal :) (As on mine PU-7)

I guess they took another point on newer PS1 because its easier to solder on, or they were lazy who knows :lol:
Last edited by Traace on May 3rd, 2017, 6:41 am, edited 1 time in total.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

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

Post by rama3 » May 3rd, 2017, 6:39 am

I honestly think they didn't have service manuals and were too lazy to ring out a better connection point :p

likeabaus
Extreme PSXDEV User
Extreme PSXDEV User
Posts: 133
Joined: Jul 27, 2016

Post by likeabaus » May 3rd, 2017, 11:29 am

Traace wrote:Hi Community, It started when I bought a SCPH-3000 from eBay. Because these Japanese Systems are not that common here in the EU.

I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.

There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.

And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.

(Click on the pic)
Image


PS1 is love :praise

2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.

I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know :)
Thats pretty neat that you were able to figure that out, nice work!

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

Post by nocash » May 3rd, 2017, 8:26 pm

No! I hate modchip diagrams! Can somebody explain why those modchip diagrams always consist of nothing but numbers and arrows? I understand that commercial modchip manufacturers don't want other people to figure out how modchips are working. But if you don't have that kind of commerical interests, and if you know that one of the pins is a Reset signal, why can't you annotate that as "Pin Y = Reset"?

Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.

Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?

User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

Post by Traace » May 4th, 2017, 2:13 am

nocash wrote:No! I hate modchip diagrams! Can somebody explain why those modchip diagrams always consist of nothing but numbers and arrows? I understand that commercial modchip manufacturers don't want other people to figure out how modchips are working. But if you don't have that kind of commerical interests, and if you know that one of the pins is a Reset signal, why can't you annotate that as "Pin Y = Reset"?
Well this one is made for a public release in mind therefore I didn't make it to "complicated". I understand your point and its a pretty good one. Normal People just don't care what signal comes to what pin/point, they don't care how this chip actually works. It might also to consider that most people just don't have the time to read a couple of ps1_specs pages(thanks for that btw) think about what they read there and apply their new knowledge afterwards.Sad but true. In my opinion we have to change the peoples mind first, so we don't confuse them with more advanced diagrams that nobody can apply.

nocash wrote: Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.
I just tested normal anti-modchip games(like The Legend of Dragoon US) in my SCPH-3000 tho, to get it running i had to patch the boot to JPN of course. You refer to them correct?

I hope that helps(80-pin QFP):

Code: Select all

VDD - pin 1 -> Mainbaord VDD
GP5/T1CKI/OSC1/CLKIN - pin 2 -> Unused for MM3
GP4/OSC2/CLKOUT - Pin 3 -> Connected to HC05 Pin 42 (This one has something to do with Stealth support)
GP3/MCLR/VPP - Pin 4 -> Mainboard Reset
VSS - pin 8 -> Mainboard VSS
GP0/CIN+/ICSPDAT - pin 7 -> ? I/O with GP1 ?
GP1/CIN-/ICSPCLK - pin 6 -> ? I/O with GP0 ? -> Connected to HC05 pin 32
GP2/TOCKI/INT/COUNT - pin5 -> Unknown
nocash wrote: Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?
Yes, it comes from a SCPH-3000 System
Last edited by Traace on May 4th, 2017, 7:37 pm, edited 1 time in total.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

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

Post by rama3 » May 4th, 2017, 6:45 am

I'm sure you/we/someone can add a small legend to your diagram, saying what point is what :)

Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p

Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee :)

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

Post by nocash » May 4th, 2017, 8:58 am

Thanks for the pin-outs & confirming that it's a SCPH-3000 board! I've added a note in the http://www.psxdev.net/forum/viewtopic.p ... 4284#p4284 thread, saying that the 424660 cdrom/firmware is also used on that board.
Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?

HC05 pin32/80 is PortB,bit1, ie. the SCEx signal transferred at 250 baud, connecting there makes sense for modchips.

HC05 pin40/80 is PortC.bit1, ie. the SPI-bus output, which should be unused in pre-SCPH-9000 consoles. That doesn't make sense to me.
HC05 pin39/80 is PortC.bit0, ie. the SPI-bus input, that would make more sense (to watch the SUBQ signal for knowing the position & when to output SCEx on which sectors).

The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » May 4th, 2017, 11:46 am

nocash wrote:Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?
I'll write a program to do it. Easy enough. Read the ROM into RAM, CRC32 it and then print the results on screen.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

Post by Traace » May 4th, 2017, 7:42 pm

rama3 wrote:I'm sure you/we/someone can add a small legend to your diagram, saying what point is what :)

Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p

Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee :)
Yes,true. thanks for the notice :)
It ain't goes to HC05 40 (my eyes lied:D ). The correct Pin is HC05 42 :) ( I edit the pinout above)
nocash wrote:The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).
Seems like that is the reason why we still need to patch the region of a US,EU Game to JPN in order to run them on Japanese systems.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

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

Post by rama3 » May 4th, 2017, 8:53 pm

Shadow, those tools already exist. There is a checker tool that displays the BIOS CRC and compares it to a known list.
Another tool can dump the BIOS to memory card or over SIOCONS.
http://forum.redump.org/topic/4991/new- ... l-cd-unit/
http://www.psxdev.net/forum/viewtopic.php?f=66&t=395

Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.

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

Post by nocash » May 4th, 2017, 11:33 pm

HC05 pin42/80 is PortC.bit3, ie. drive SPEED, the TOC/SCEX is read at single-speed, and other sectors are (normally) read at double speed, so that should actually work for sensing when to output the SCEX signal, but only if the games are really using double speed (which might apply for most or all games, but it would be very easy to produce a game that defeats that kind of modchips by using single speed for SCEX reading).

Ah, and, at double speed, the SCEX signal would be 500 baud instead of 250 baud, and the cdrom firmware won't recognize 500 baud signals at all. Ie. at double speed, the game can't really detect if there's a 500 baud SCEX string coming from the disc (instead, it can only detect if a modchip outputs a 250 baud SCEX signal despite of running in double speed mode).

The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).

User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

Post by Traace » May 5th, 2017, 1:53 am

rama3 wrote: Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.
Unfortunately I just bricked my old German "PS Hacker v2" yesterday (Hate those clones anyway :mrgreen: ), but yes it should work :)
nocash wrote:HC05 pin42/80 is PortC.bit3, ie. drive SPEED, the TOC/SCEX is read at single-speed, and other sectors are (normally) read at double speed, so that should actually work for sensing when to output the SCEX signal, but only if the games are really using double speed (which might apply for most or all games, but it would be very easy to produce a game that defeats that kind of modchips by using single speed for SCEX reading).
That's interesting, thanks
When I leave HC05 pin42/80 disconnect from the Modchip, Stealth is not given anymore, the rest (beside region patching) works.


Oh, the tool above is pretty nice.

CRC "3539DEF6"
Romstatus "Dumped"
"Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
System Rom "1.1 01/22/1995"

Edit: Both SCPH-3000 were tested now. Same result.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

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

Post by nocash » May 5th, 2017, 2:38 am

Traace wrote:CRC "3539DEF6" ...Romstatus "Dumped" ..."Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
Okay, thanks. The extra-info that I was after is the part number (the whole text on the ROM chip), the package (40pin?), and the board name and mechacon part number (ie. PU-7, 1-655-322-15 and 42660 (unless the other SCPH-3000 board is different)).
Just check here to see how the whole info should look like: http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065
Or, if you could make a photo of the PCB front side would be nice, too. Currently you've only the back side.

User avatar
Traace
Curious PSXDEV User
Curious PSXDEV User
Posts: 12
Joined: Mar 07, 2016

Post by Traace » May 5th, 2017, 2:55 am

nocash wrote:
Traace wrote:CRC "3539DEF6" ...Romstatus "Dumped" ..."Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
Okay, thanks. The extra-info that I was after is the part number (the whole text on the ROM chip), the package (40pin?), and the board name and mechacon part number (ie. PU-7, 1-655-322-15 and 42660 (unless the other SCPH-3000 board is different)).
Just check here to see how the whole info should look like: http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065
Or, if you could make a photo of the PCB front side would be nice, too. Currently you've only the back side.
Ahh I see, It shouldn't be a problem to look that up. You can expect that information this weekend :)



Update: http://www.psxdev.net/forum/viewtopic.p ... 290#p12290
Last edited by Traace on May 8th, 2017, 12:55 am, edited 1 time in total.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW

User avatar
Shendo
Verified
C Programming Expert
C Programming Expert
Posts: 250
Joined: Mar 21, 2012
I am a: Programmer
Motto: Never settle
PlayStation Model: SCPH-7502
Discord: ShendoXT
Location: Croatia, EU

Post by Shendo » May 5th, 2017, 6:26 am

nocash wrote:The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).
Oh, first I actually only published dumper in the .exe form but I got a bunch of people PMimg me
for instruction on burning a working CD. So instead I published a bin/cue image.

I attached exe in the dumper release thread.

Dumper also shows CRC32 but I haven't included a "already dumped check".
If anyone wants to improve upon it I released the source.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

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, 2:09 pm

nocash wrote: Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.
It's pretty much a hack. Mayumi (and MM3, since it appears to have been largely copied from Mayumi) there are two different operating modes depending on which sort of board the chip is installed in.

On PU-7 / PU-8 / PU-18 / PU-20, the code attempts to work out where in the boot sequence the console is by monitoring the X1/X2 speed control line. It's not as simple as just switching the data on and off - there are a series of delays for each part of the boot, and the speed line is basically used just as a hint to know exactly where the boot is right now. You can't just gate the data using the speed line because the anti-modchip test is carried out using CD-Audio play mode, and that's X1 too.

Basically the logic is:

After reset or door close, delay for a bit (two different delays for reset or door close) then start looking for the speed to switch to X1 (first protection check) - after this is detected, wait for the speed to switch back to X2 and start another timer. Then wait for the speed line to go back to X1 again (second protection check - this is also why it screws up on the very early boot ROM, since that doesn't have this check). At this point, it just waits for the door switch and then the whole cycle repeats.
That's the basic process - the code also has some code to detect the situation where you are booting using something like Caetla rather than the boot ROM, since that changes the timing and using the same timing as the original boot ROM would make the console fail the second protection check.

On PU-22/PU-23, it's a lot simpler. This is a special mode that's enabled when the chip is installed in a newer console (what used to be the modchip gate line is connected to WFCLK on the newer boards, and the code looks for a clock on this pin and if found enables PU22/PU-23 mode). In this mode, the chip monitors the XLAT line between the control MCU and the servo amp chip and cuts of the SCEx strings when it detects a pulse on it. There is also an initial delay so that it isn't triggered by the setup phase when the chipset is reset. It's basically relying on the fact that the MCU doesn't talk to the servo amp during the read TOC phase, but does as soon as it's finished. Despite (or maybe because of) it's simplicity, this mode works really well.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests