Method to make installed DISC games boot from from the hard drive in a PSX...

Looks like this on the PSX:







Additionally it looks like this on PSBBN:







This method takes advantage of a feature the HDD OSD (and PSX/PSBBN) has called "child partition".
The problem this work around resolves is that both the PSX and PSBBN do not use graphical resources which are contained within the partition information section (PATINFO) instead they want to look inside of the partition (it assumes PFS automatically) for a directory called /res (resources). Inside that icons and text description is placed in a format specific to PSBBN/PSX.

The partition naming scheme goes like this:

PC.GAME-12345.MAGIC.anythingyouwanthere
PP.GAME-12345.MAGIC.doesntmatterwhatishere

As long the "GAME ID" (GAME-12345) and "MAGIC" (any arbitrary text/numbers string) match, the OSD will consider both partitions to be part of the same item and the PP (Parent Partition) will be aways referenced to when display resources are needed.

The games displayed on the screen for the screenshots is named like this:

PSBBN:
PC.SLPM-55222.HDL.PREMIUM (4352MB)
PP.SLPM-55222.HDL.PREMIUM (128MB)

PSX:
PC.SLPM-55221.HDL.EMPRESS (4224MB)
PP.SLPM-55221.HDL.EMPRESS (128MB)


Since the games are using a specially modified version of MINIOPL (diskload) they have been made bootable.

This also works with the original PS2 HDDOSD but in it we will have the usual 3D icons and text being displayed. All you will notice of different is that the game is bigger by 128MB.

 

Ou god you are a wizard! D: Im still figuring out how to create bootable FMCB MC for PSX. I got desr-5700 model in perfect condition and desr-7000 which one im ready to use for some testings. Would replacing the HDD work if i got Maxtor HDD ( exactly same as in desr-7000) with FMCB and update disc? Or does it have to be one of those official Sony HDDs?

 

The HDD unit must have the Sony custom firmware (like with the SCPH-20401), so no... replacing the disk with a generic ATA disk will not do.

Just FYI, Maxtor disks are not the only ones used in the PSX. My DESR-5100 has a Seagate HDD.

As for installing FMCB for the PSX, you have two choices: either perform the installation with the PS3MCA tools (Using the script meant for the PSX) or using your PSX itself (start the installer with Swapmagic).

 

Thanks for the HDD info! Is there a tutorial of any kind about using PS3MCA tools to install FMCB for PSX? I have your "install_for_PSX installation script", but dont have an idea what to do with it. :/

 

I wonder if a pass through device could be made that tricks it.

 

I've been trying to find people interested in developing such a device. We already learned *WHAT* the PS2 get out from the harddrive, Where it is stored and how the PS2 get it out from the drive...

Man it's just a 512 bytes data structure hidden inside of the drive firmware overlay. The extra commands which the drive support are there to provide the console with the data.

And because the PSX derives the disk encryption key from adding that with it's own onboard unique information, disk encryption is unique per motherboard + HDD combination. Such a device would need a small storage to hold the security sector extracted from the harddrive.

 

Discussion supprimée. Désolé pour le dérangement occasionné...

 

Either this, which is l_Oliveira's idea. Or we could find somebody who can work with Fujitsu MCUs to modify the DVRP's firmware.

 

Great stuff. So how do we (end users) convert our "PP" partitions to "PC" for retail PS2 PSBBN?

• Modified whitelist uLaunch (Shows "PC" + "PP" partitions for editing)?... probably to kludgy..
• Modified loader e.g. SP193's HDLInstaller (Choose "PP" or...."PC + PP" install )?

Also, are the files in the "res" folder editable? I'm guessing jkt01.png is as it seems, but what about the description file..

 

Modifying a drive would be cheaper & there are so few PSX's out there. The problem with modifying a drive is that each type has to be done separately, hacking a cheap ide to sd card adapter might make more sense.

 

One cannot convert the partition. It isn't in a different format. It's just the game partition with a different name, and with a new partition that is created specifically for containing only the resource files and title information for the dashboard (e.g. the XMB or PSBBN Navigator).

The obvious way to make a proper game installation would be to create a modified version of HDLGameInstaller for this purpose, but then I haven't decided on whether it is going to be possible to allow the user to select the resource files to be used.

The whole format is documented in the Sony SDK's documents.

The problem is, we cannot modify a drive's firmware easily. The tools for replacing a drive's firmware are usually not available, and so is the firmware itself.

The DVRP's firmware is flashable via software. Modifying it is basically just the creation of a Custom FirmWare (CFW) that lacks the stupid DRM functionality. The entire process will be probably reversible too, since it's just a matter of restoring the original firmware (which can also be extracted from the update discs).

One strong reason why I support this is because the user will not need to buy any extra hardware. Especially since this adaptor, if one is created, is probably not going to be very cheap because it won't be really mass produced.

Even if it's possible to modify some IDE adaptors to support a few additional commands, that would be also as bad as modifying the firmware of every drive that the user is going to use. Such a modification would be device-specific and strongly depends on whether the device's firmware can even be replaced. And if this was done, why not just modify the DVRP's firmware? The requirements are about the same (the firmware has to be understood, modified and reflashed). But it's only ONE, common firmware that needs to be modified for all consoles.

 

I misread DVRP Yeah that does sound interesting. If there was an emulator for the PSX that ran that code then it would be trivial to patch and test it, having to go through a firmware upgrade to test it sounds like it could be a hassle.

 

Thanks for explaining it clearly SP193. As you mentioned, could a modified version of your HDLGameInstaller have the option to do a standard install, with the game being installed in a PP partition as normal, and then a PSBBN/PSX install that places the game in a PC partition while creating a 128mb PP partition named like l_oliveira's examples above? Users could then add the .png and text data easily with uLaunch..

 

For the PSX you can use SP193's installer (it will install the partition using the original SONY naming scheme out of the bat) then rename the partition in uLE.

It installs automatically with this naming syntax:

PP.GAME-12345.HDL.WHATERVER_YOU_NAMED_IT_HERE

So just rename it as:

PC.GAME-12345.HDL.WHATERVER_YOU_NAMED_IT_HERE

And make another partition where "PP.GAME-12345.HDL." part of the name matches.... The last portion of the name doesn't matter, can be different.

It's best that both PP and PC partitions have OSD icons so they don't show up as corrupted data. Because Open PS2 Loader scans the HDD for partition type, not name it can still find the games even if they're installed in this new format.

 

very nice! never thought about using the child partition for that stuff xD. always bugged me that the HDL games didnt had a icon in PS-BBN.

 

man you never cease to amaze me....

i've tried to do this with PSBBN a long set of years ago, abusing the HDLoader's installer to get the PP.xxx partitions and after repeatedly going through the tech docs and whatnot things for ages and whatnot i eventually gave up after having PSBBN recognize my games and so on, but always ending up in a black screen at boot.

to date i have no idea what went wrong, until you mentioned the PC.xxx partition.
the ones i made were always PP (...sigh)

keep up the good work with the stuff
even though my development and research interest has majorly shifter over to psp and my pair of TOOLS is now at their quiet rest, it never stops being as interesting to follow as it was when i started

edit:

do tell me more about the boot though, i vaguely remember investing some time looking into the secondary boot parameters of the cfg file that is present on every disk, as the tech docs for HDD usage describe the secondary boot parameter which would direct the game to the HDD, and only booting if off the disk (i wonder if it was something like "MAIN_APP" (pointing to the elf on the disk and the remaining data to pfs0:/) or something of the sorts.... it's been a while.)

was this not needed at the end of the day ?

 

Is there a set of bat files already made that allows install on a PSX for PS3MCA for Free Mc Boot 1.93?

 

http://psx-scene.com/forums/f153/[t...c-ps3-memory-card-adaptor-120793/#post1116507

 

That stuff only makes sense on the context of something specific such as dnasload.elf which parses the "dnasboot =" parameter (or at least pretends to)... On this stuff it's exactly as you said: "this was needed at the end of the day" and I add: "at all" ...

Currently, the loader which is added to the PP partition parses the partition name from the boot up arguments passed by the OSD then use it to extract the path for the boot partition. After that it tries to detect the partition, checking if it's a HDL game or a APA partition. If it's a HDL game it proceed booting. If not, it adjusts the second letter of the name to "C" then retry booting. If both attempts fail it then exit to the OSD with "booterror" as argument passed to OSD.. (just like SONY software does)

 

DNASBOOT2, HDDLOAD, PFLSLOAD... a bit off-topic

Yep, I vaguely remember that the NoKey version gets the bound package name from the partition name which is retrieved in argv[0], and does not care about the DNASBOOT2 param. Have you tried changing the partition name when you've installed Bishi Bashi Champ in your PSX ? This should work... ...as long as the third char of the partition name is a dot (because of a syntax check or another arg juju which is performed by the SLBB ELF itself).

By the way, I wanted to upgrade my PS2 MBR this morning, from uLE HDD Edition WIP6 to WIP7 and the crap did no go. I first thought that the doormat tool was bogus before I figured that the biggest KELF we can put in the darn __mbr is 883200 bytes / 1725 sectors long. Since the PSX's flash loader deals with "MBR compliant" KELFs, I wonder if the Crab did apply such an annoying bootfile length restriction to xfrom too... Anyway, osdmain.dat eats so much space that the bootfile has to be paxored for the user's extra stuff to fit in the poor flash.
Sorry for replying off topic, Gentlemen.