[PS2] POPS stuff...

Thanx, gonna mess with it tomorrow

 

Thanks, that's great news.

Okay. Did you manage to run a game with LAUNCHER.ELF+EXECUTE.ELF and POPSTARTER_REV9.ELF or it still freezes in a BSOD ?


I'm trying to fix the VMC directory bug in EXECUTE.KELF and a container vulnerability... The release of a bugfixed package should take a while, because I'm too lazy to reverse the MG hashes for today:witless:.

 

Nope didn't work I gave up...

I tried the old way just to test;

1. created a partition PP.POPS-00001.
2. added the popsheader data to the game.
3. copied all to the PP.POPS-00001 partition, so inside that i have:
- disc0 folder with disc0 inside
- EXECUTE.ELF
- MYDUMP.BIN
Started EXECUTE.ELF with uLaunch, result; black screen, but L1+SELECT+START worked and vmc's where created.

Replaced EXECUTE.ELF with the region free POPS 6.60 and tried one more time...
It worked.
That's nice

But now i want it to work the way you intend it to be...

Edit:

I think it's a region issue, what region console are you running this?

Gave it another try;
1. converted game to .VCD image.
2. in __common folder created POPS folder and inside it disc0.
3. created partition PP.SLPS-02034 with SLPS-2034.VCD and EXECUTE.ELF (POPS 6.60 version).
4. hex-edited LAUNCHER.ELF with partition name PP.SLPS-02034.

Started EXECUTE.ELF with uLaunch, result; it works! Also L1+SELECT+START worked and vmc's where created

Edit2:

Bad, it didn't worked, i had the previous setup still on my hdd with the PP.POPS-00001 partition and somehow the LAUNCHER.ELF starts the game but if i delete MYDUMP.BIN from the POPS partition i get the BSOD again
And the vmc's where already there from the first run with MYDUMP.BIN.

 

Dont you miss that step?

 

Thanx
My misstake ..^.. gonna fix that right now, see what happens...

Edit:

No, still BSOD
Also i can't use L1+SELECT and START to go back

When converting a game how much data is added to the new .VCD?

 

PAL (European) unit. But none of the file is region locked. Should work in your console, unless your console is a Jap V0.

POC2 files (your step 3) with disc0 in the __common partition (your step 2) cannot work, as the POC2 mounts disc0 in the virtual CD-ROM drive from PP.GAME_PARTITION/disc/disc0, not from __common/POPS/disc0.

The file hierarchy of the POC2 is :
PP.POPS-00001/disc/disc0 [the original Bishi Bashi image]
PP.POPS-00001/EXECUTE.ELF [POPS in it's container]
PP.POPS-00001/MYDUMP.BIN [Your game image]
__common/ps1emu/card0.bak [temp VMC image, slot 1, created by the emu]
__common/ps1emu/card1.bak [temp VMC image, slot 2, created by the emu]
__common/ps1emu/card0 [used VMC image, slot 1, created by the emu]
__common/ps1emu/card1 [used VMC image, slot 2, created by the emu]

The file hierarchy of POPStarter is :
__common/POPS/disc0 [the original Bishi Bashi image]
PP.GAME_NAME/EXECUTE.ELF [POPS in it's container]
PP.GAME_NAME/IMAGE0.VCD [Your game image]
__common/POPS/GAME_NAME/SLOT0.OLD [temp VMC image, slot 1, created by the emu]
__common/POPS/GAME_NAME/SLOT1.OLD [temp VMC image, slot 2, created by the emu]
__common/POPS/GAME_NAME/SLOT0.VMC [used VMC image, slot 1, created by the emu]
__common/POPS/GAME_NAME/SLOT1.VMC [used VMC image, slot 2, created by the emu]

Partitions in blue, folders in green, files in red.

Differences between POC2 and POPStarter :
In the POC2, your game image must be named "MYDUMP.BIN"; in POPStarter it must be named "IMAGE0.VCD"
In the POC2, the Bishi Bashi image must be in the game partition, folder "disc"; in POPStarter it must be in the __common partition, folder "POPS"
In the POC2, the VMC folder ("ps1emu") is created by the emulator. In POPStarter, users have to create the parent folder "POPS" (and put disc0 in it), then the emulator creates a subfolder that has the name of your partition.
In the POC2, EXECUTE.ELF can be executed directly (as long as the partition name is hard-coded). In POPStarter, EXECUTE.ELF is run by LAUNCHER.ELF and cannot be run directly...

A few more things :
CUE2POPS can also convert your games for use in POC2. The TOC specs didn't change. Just rename the output file as "MYDUMP.BIN" instead of "IMAGE0.VCD" and put it in your PP.POPS-00001 partition:encouragement:.
POPStarter may freeze/crash/reboot/shutdown the user console if a certain HDD OSD dump that comes from a certain forum is installed in the HDD (no joke).
POPStarter may freeze/crash/reboot/shutdown the user console if anything else than the partition name was hexedited.
POPStarter may freeze/crash/reboot/shutdown the user console if the GUID/NIC/HDD microcode is internally denied/blocked/blacklisted/banned.


@AKuHAK, did you manage to make it work ?

 

Yeah ive got it to work ))) The error was in pfs-shell. Pfs-shell incorrectly copied disc0 into POPS folder. Mortal Kombat Trilogy works fine - and CD tracks are good.

Oh that mean that we really need some debug messages appearing at screen ^^

 

Thanx for explaining that

Another thing, when using cue2pops i get an error (see picture).
It does create the vcd, and it only happens when i use this command:

CUE2POPS.EXE "D:\cue2pops_v1\SLPS-02034.CUE" "D:\cue2pops_v1\IMAGE0.VCD"

when i use this:

CUE2POPS.EXE "D:\cue2pops_v1\SLPS-02034.CUE"

No error.

The output size from both methods is the same.

 

I just try to see if I get it, and yes, it happens to me too - tho IMAGE0.VCD is created. Other commands works without that error - I did not try yet if it works in real, on console.

 

I didn't put debug messages or coloured screens because it is one of the first things that a reverse engineer could use to mess up the container (along with syscalls):witless:, + it's room consuming.
Since the payload interacts with packed data that interacts with scrambled container segments that interact with the POPS core, with memory reallocations and a tracker that follows the whole thing till the emulator is launched, I prefered to keep my code as small as possible. All that security crap is the reason why I was affraid of an incompatibility with GSM.
Anyway, I'll trash the crypto and integrity checks in my next revisions (if I build any). There's no need of such a viril protection; it's just the result of me vomiting my frustration all over the source code hahaha.

Strange error... CUE2POPS is very poorly coded, but for EXE+CUE+OUTPUT and EXE+CUE, the code is the same.

After "A POPS virtual CD-ROM image was saved to", the program simply does this (in the main function) :

I don't know why that error pops up...
BTW, I've just noticed that dumpaddr is freed twice, first time before the file output operations and once again after "A POPS virtual CD-ROM image was saved to", stupid me.

Guys do not hesitate to modify, fully rewrite or port CUE2POPS if you want to.
EDIT : If the athor of PSX2PS2 GUI is reading the thread, an update would be certainly appreciated too.

 

I'm not trying to get into the middle of all the drama that has surrounded this emulator so far. I just have a question.

I've been hearing rumblings that this released version may do more than "freeze/crash/reboot/shutdown" the console in those noted situations? Is that true? If I had a drive and wrote that one particular HDD image to it (you probably know what I mean), if I were to use this on that HDD, what exactly would happen?

 

It will just kick you back to the HDD/MC browser instead of loading and executing POPS. Since the said HDD image was thrown to the masses by someone who told that's a way to run POPS in LBA48 HDDs, I thought I had to deny the execution, so the user doesn't risk a HDD screwage.
Crash and shutdown normally happen if a malicious person tries to bypass the security measures by hacking binaries or using cheat engines, depending to where and how the integrity of executable segments was compromised.

EDIT : Oh, OK, now I see what you're talking about. No, I didn't implement stuff that damage the console, the HDD or anything:congratulatory:. Just things that forbid the execution.

EDIT2 : Since the emu can halt on a BSOD and kick to the browser, I'm thinking of invoking TESTMODE for all container related errors, in order to avoid confusion.

 

The reason I was asking was indeed because someone claimed that their HDD was wiped (or otherwise corrupted), and they "lost 200GB of ISOs". That definitely points to an issue with LBA48, especially if the __common partition was above 137GB. Is there general issue with writing to partitions below 137GB with a non-LBA48 aware program on the PS2?

I especially don't want misinformation floating around that says you were corrupting people's HDD if they were using that HDD image if you're not doing so.

 

Yeah definately. POPS writes to __common to create VMCs. If the __common partition is above the LBA48 limit, it would ruin the APA table. I think that WinHIIP should be able to rebuild the APA table and fix broken checksums.
Everything that's made by $ony fail at gathering the HDD specs, at reading data above 137GB and certainly f*ck up the HDD on write-access. Not all HDD users know it. It would have been preferable that I mention it in the readme, my silliness...

A well known PS2 developer is studying the HDD module set and the interface.
The dirty hack that consists of replacing $ony's ATA device driver with a homebrew one would only be performed by kamikazes for the purpose of testing. This is does not offer a decent high capacity HDD support, since other HDD modules remain untouched and could still behave badly. It's hacky and risky, hence why I've been kinda pissed off when vash32 did spread a bootleg of the test dump, as a so called 48-bit solution and including a hexhacked POPS POC2 that pushed former project maintainers to cancel their work.
A high capacity HDD fix for $ony licensed softwares/games would come from devs, not from the copy/paste of a PS2SDK IRX.

The ban against that HDD image is not an act of vengeance but a measure to prevent hdd corruption, so no, I had no reason to deliberately waste the user's HDD. The container does not have destructive function. Even hardware bans aren't destructive and God knows I could massacre HDDs and MCs of lamers that are responsible of the project cancellation. I didn't. Teh scene does not need such junkware and drama. All I want is to make my amateur container as reliable as possible and then have some damn vacation:rolleyes-new:. As for advanced features that could be implemented in the container (by "advanced", I mean things that I haven't the intelligence to code, LOL), decrypted POPS binaries have been online for years. Devs can write their own container, it's up to anyone who's motivated to do it.

 

I must also say that I think I was mistaken - the person I was speaking to mentioned "I hate this fucking launcher" and in the context of POPS I was erroneously thinking he meant LAUNCHER.ELF. Instead I think he merely mistakenly formatted his drive using uLE, thinking that the format option would format a single partition as opposed to the whole drive. I should have picked up on that when he mentioned that he was unable to recover any of his ISO partitions with WinHIIP, as I doubt a POPS corruption would have damaged the whole drive, as WinHIIP (as far as I'm aware) scans each 128MB block looking for HDL partitions and so would likely recover many, if not all, of the ISOs on such a corrupted drive (and not sure, but maybe even PFS partitions)

 

In this case, THIS LAUNCHER = uLE
And the guy were trying POPS-00001, not POPStarter
So POPStarter is not guilty here, only the user is - Im
not saying you claimed it, I just want to help to clarify the situation.

Edit : ahah, LocalH, you were quicker than me. :tears_of_joy: Well, glad to see there is no misunderstanding anymore.

 

I want to clarify the situation. If I had, for example, 500Gb Hard Drive - can I use it such a way: all "official" sony stuffs goes below 137Gb limit, but HD loader games is installed over 137Gb limit? Is this possible or no? As for me - I cannot test it because I have twenty 40Gb hard drives :concern:

And by the way what was the purpose of PSone logo removal? I read that it was "shitty" :tongue: But what that mean technically

BIOS in the PSP POPS isn't the same - its a little bit more modified, removed region lock, optimized code parts...

 

And how do you suppose that we impose a limit on it? The stupid APA partitioning scheme has this weakness: It doesn't have any boundaries, and there is no concept of partitioning only part of the disk.

The APA driver will happily loop through the entire disk until its hits the end (or at least, it thinks that it hit the end!), hence why it takes so hideously long to list every game/software installation you have on a really large disk (and also why it's called Aligned Partitioning).

The PSX (As in, those DESR units) does something like that (limiting the visible size of the disk to 40GB), but I believe that it uses emulation of the PS2's "aged" ATA interface in hardware (The DVRP seems to be the mastermind behind all that).

Sony had a 48-bit LBA version of the APA and PFS drivers for the PSX... but the APA driver is unfortunately embedded within the DVRP's firmware and I have absolutely no idea how to even take a peek at how it works. D:

The 48-bit LBA version of the PFS module can be ripped from the PSX's files since it's a regular IRX module, although I can't remember whether it's bound to the DVRP's interfaces or not (probably not).

But beware that they're most likely having a different format from the original PFS and APA standards, so don't expect any of the old Sony PS2 software to recognize the data on your disk if you use these 48-bit LBA modules (assuming that you somehow get them running on a retail PS2 unit).

If I were to ever hack (Yes, hack, since I can't get its source code...) a piece of Sony software, I would limit the reported size of the disk to 1TB from within the replacement ATAD module, by getting ATAD to report the installed disk's size as 1TB if the disk is actually larger than 1TB. (Or maybe 750GB, depending on other factors like how the Sony software calculates free space)

 

We're in the situation that project maintainters didn't want to deal with. That was expectable.
- A release that's isn't end user friendly (installation, file hierarchy, partition name hard-coding)
- Tons of files and packages that are derivated from the POC2 (what I call POC2 is POPS-00001, original release, that followed conan14's release) and confusion about which file is which version
- Misinformation in some tutorials that are floating around
- A HDD OSD image that messes up HDDs, published in a highly frequented w@rez forum
Lesson learnt. We can get over it; "never give up":sneakiness:.


@LocalH, DaSA, LocalH.
Ah OK, thanks for the clarification.
Mmm, I've been able to recover my game partitions with WinHIIP after a uLe format many times. The first non-system partition was unrecoverable because the HDD OSD was installed with the HDD Utility Disc (doesn't create the __boot partition) and uLe creates a __boot partition (which overwrites 512 Mb).
POPS-00001, as I released it, has got $ONY ATAD. I don't know what's in TheISOzone ELFs.
POPStarter... contains a homebrew ATAD. Don't get me wrong, I won't encourage users to create partitions over the 137Gb limit (and that's why I didn't tell it in the readme and in this thread). The homebrew ATAD was put there for one reason : SAFETY... but since I've learned the lesson, I know I'll soon regret my confession...

I don't know. Perhaps by allocating the space that is dedicated to $ony stuff with one or more huge partition up to the LBA28 limit, then installing HDL games till you reach the disc end, and delete partitions you've created below 137Gb.
Keep in mind that the HDD OSD will still freeze regardless to how you've set up your partitions, due to it's incapability to get the correct HDD size.

Ahahah, sorry for the lack of details in my statement. English is not my mother tongue so my word choices are quite limited, and my grammar is "shitty":biggrin-new:. I hope to not receive a ban for bad wordings and abusive use of the F word. Normally "sh*t", "crap", "thing", and "stuff" are understood worldwide, I use'm the most. Yeah I've to admit that it's not enough for telling something constructive and comprehensive but it makes sense : if it's shitty, it's crap, so in definitive it f-ing sucks:wink-new:.
A better question would be what is the purpose of the PS logo. The removal allows some ("some" I use it very often too) "incompatible" games to run games.
Did you notice that when you run the emu with a CONSOLE BIOS the SCE logo is shown and the PS logo is skipped ? I believe the emu does some voodoo with the PS OSD.

I've found a PSP POPS BIOS. It's CRC is 5660F34F. Kernels are identical, the OSD code differs... Looks like the OSD executable segment is packed, like in 750x and higher. Will unpack and disasm this shit tomorrow.

 

I joined to say thanks for your hard work and keep up the good work

Now for some info I would go with bios by S 4.01 it can read sub and multi tracks anything above that S removed the code for it

If I convert a game that has cdd cue sub img only 4.01 and bellow to 3.71 reads it correctly not sure if it was a bios change or emu the problem

BTW just in case you are wondering I did not lose anything testing this but Tales of Phantasia (J) [SLPS-01770] still has problems when converted
no proper start stop of voice overs once started it continues until all of the VO is done then stops working :rolleyes-new: