[PS2] POPS stuff & POPStarter

Teh LULz. Apparently, POPS does not care if your MODE2 XA image is bigass.
I took a Blitter Boy EXE, renamed it in PSX.EXE, put it at LBA 600.000 and vomited a 1.31 GB VCD (Leadout @ MSF 133:31:55 trololol). POPS could run it no problem xD.

The Blitter Boy VCD I've tested: http://aybabtu.chez.com/PS2/POPS_SHIT/BLITTER_BOY_TEST.RAR
The modified CUE2POPS binary which was used for making it : http://aybabtu.chez.com/PS2/POPS_SHIT/CUE2POPS_21_B1.EXE

This modified CUE2POPS build doesn't make better things I guess. It's based off the latest public build (v2.0) and aims to write a MMMM:SS:FF formatted lead out (instead of MM:SS:FF) in the VCD header. Just a small mod so. I don't even know if POPS supports that definition.

Don't try to put CD-DA tracks after 99:59:75, that won't work for two reasons :
- The cue sheet parser of CUE2POPS is poorly coded, and it accepts MM:SS:FF formatted entries ONLY.
- The VCD header itself does not have a byte where you could add MMs in the tracks descriptors.


I did not try with retail games yet. Perhaps they'd fail at seeking to high LBAs when trying to read the game resource files...
Oh, and how can we premaster STR/XA properly when violating the PS-X rules anyway ?

 

Yep yep yep. I took my two Megal Gear Solid discs, reassembled their contents in a 1240 MB disc image, craX0red the four contextual disc checks and tested the big VCD at disc swap spots. Works very fine.
Cool thing. Thanks for letting us know about it.

 

You might be better off adding support for loading game patches that can apply to the exe at run time and call into POPS to change CD's.
Some PSX games hard code the layout in the EXE and having to patch those would likely be harder.

 

Patches and subroutines loading is implemented in the private POPStarter build I use for my researches, as you can see in this bootup sequence. It handles up to 10 patches/subroutines per specific game (and up to 10 "global" patches/subroutines which are always enabled regardless of the game I run).
Patches can be used for patching data in the POPS emulator core before it's executed. It's as basic as "copy the said data (the data and its length are user defined) to the said address (destination address is user defined)".
Subroutines (called "TROJAN" in the POPStarter file hierarchy) are pieces of ASM codes that can be hooked to anything in the EE RAM (except to the kernel LOL). Can be LibCrypt breakers, savestate function, trainers... For my MGS hackeries, I've hooked this subroutine to IGR. See ? It's just a simple read values / write values proggie that can be easily ported to ps2rd codes xD . When I trigger IGR, the subroutine is called. It patches some values in the virtual PS-X RAM according to the values it reads and what it has to do, and it goes like this.

Coding some function that tells the fileXio server to mount another VCD (disc 2 for example), resets the CD-ROM emulator thread and cleans out the CD-ROM drive registers would be something very difficult to do .

 

i have 2 questions

1. is there a way that this can be recoded so there is 1 bios folder so that we only need to put the files in once
i.e.
__common/POPS/BIOS.BIN

and not
__common/POPS/GAME PARTITION_NAME/BIOS.BIN

this would make things easyer

2. is there a way to do multi disk games thats easy a fast??

 

If it was easy then everyone would be doing it

I assume at the moment you just patch in code assembler.
We could do with an open source reimplementation, like opl vs hdl.

 

I guess POPS isn't a very good emulator, because a real PS1 will fail to read past 99:59:74. The PS1 CD controller doesn't understand the weird BCD A0:00:00 to represent 100:00:00.

I know this because 99:59:74 is as far into a GD-ROM that a (modded or debug) PS1 will let you read, even though GD-ROMs go to 122 minutes or so.

 

A PS1 reading GD-ROMS?
Interesting.. tell me more

 

It's not, the compatibility is quite good though considering sony only released it to run one game.

There are no 100% accurate emulators for anything.

 

The PS1 CD controller, unlike most drives, doesn't care if you issue requests to read sectors beyond what the Table of Contents says the size of the disk is. To read a GD-ROM, just do a continuous sector read starting at 10:02:00. If the GD-ROM has no audio tracks (some like Chu Chu Rocket do), the PS1 drive will succeed at reading until around 99:59:74, when the 100th minute begins.

The Q subcodes on a CD say where you currently are on a disk. This is how a drive knows it's reading the correct place. The Q subcodes store the MSF (minutes:seconds:frames) counters as BCD rather than raw bytes. GD-ROMs are really just multisession CDs with the second session's lead-in/TOC starting at 9 minutes or so. The main data area of a GD-ROM I believe starts at 10:02:00 and ends at 122:01:74, or 110 minutes of space. The Q subcodes after 99 minutes are encoded as a modified BCD, where the high nibble can exceed 9. After 0x99 0x59 0x74 (99:59:74) comes 0xA0 0x00 0x00 (100:00:00). The last sector's Q codes are therefore 0xC2 0x01 0x74. The PS1 CD controller gets confused by the weird fake-BCD values of A0+, so it will fail the reading attempts.

You have to start reading at 10 minutes and maintain it continuously - you can't directly seek to later sectors. This is because GD-ROMs' second session is about twice the density of a normal CD. To seek, the CD controller has to calculate how far it needs to move the laser sled to get near where it wants to go, and this calculation will be wrong when the data is twice as dense. At 10 minutes, however, the GD-ROM's second session hasn't been long enough yet to cause a large enough difference from ordinary CDs (because before the second lead-in, a GD-ROM is recorded at CD density). This means that the laser will be placed close enough to find the sectors at 10 minutes. Once the laser is tracking the groove and streaming, it won't lose track despite the density difference. This varies by drive, of course, but PS1 accepts it.

That the PS1 CD controller couldn't read past 99 minutes is what made me give up the attempt.

I might be wrong on the 99 minute thing; it might actually be 89 minutes. If that's the case, the reason the controller would get confused past 89 minutes is that the CD specification defines MSFs of 90 minutes and higher to be negative, such that 99:59:74 is sector -151 (sector LBA 0 is 00:02:00 so 00:00:00 is LBA -150). I do remember the PS1 failing at either 90 or 100 minutes.

 

You're awesome in sharing this cool info with us, even though most of what you just said is above me. It was an interesting read and gave me somewhat of an idea of the prinicpals.

 

Any word on a revision 13 release?

 

Revision 13 was compiled on 2014/03/25 and that build will probably be released if I don't find incompatibilities with other launchers or softwares like GSM. For now it lacks a documentation. I'm busy repacking some PS2 Utility Discs at the moment so I can't write one. I think I'll release it this month...

An overview of what's new in this version :
- POPStarter is no longer a container but a separate launcher. Its binaries don't contain the emulator itself nor $ony copyrighted stuff.
- Bugfixes bugfixes bugfixes. Its code was rewritten and compiled with an updated PS2SDK.
- 2 new VCD launch methods : 1) VCDs can be stored in one big partition named "__.POPS". If the VCD can't be found in "__.POPS", POPStarter searches it in partitions named "__.POPS0", "__.POPS1","__.POPS2"... up to "__.POPS9". The old launch method (PP.GAME_NAME/IMAGE0.VCD) is still supported as well. 2) VCDs can be read from a USB mass storage device. That feature is powered by Delcro's PFS Wrapper. The PFS wrapper is not embedded in POPStarter, but POPStarter can handle and load it.
- Up to 10 users can use separate VMCs. VMCs are numerically prefixed depending to the user ID (0_SLOT0.VMC & 0_SLOT1.VMC, 1_SLOT0.VMC & 1_SLOT1.VMC...)
[*]
- The user's BIOS is handled from __common/POPS/BIOS.BIN (affects ALL games) and __common/POPS/VMC_DIRECTORY/BIOS.BIN (affects the chosen game, overrides __common/POPS/BIOS.BIN).
- Up to 10 patches can be loaded from __common/POPS/ and __common/POPS/VMC_DIRECTORY/
- Up to 10 subroutines can be loaded from __common/POPS/ and __common/POPS/VMC_DIRECTORY/
- The in-game reset feature of POPS was modified so it no longer crashes when the HDD does not have a proper MBR or a software which doesn't reset the IOP is in the MBR.
- The disc0 loader and its integrity checks were disabled. disc0 is no longer required to execute POPS.
- POPStarter can now run in the PSX (at least, it works in my DESR-7000 and should work in other models).
- By default, the POPS exception breakpoints are automatically disabled. This should allow the user to reset/poweroff the PS2 after the emulation has crashed.
- The debug texts of POPStarter can be enabled/disabled and their display time can be set by the user
[*]
- Almost all the patches that are applied to POPS by POPStarter can be enabled/disabled by the user
[*]
- POPStarter handles and loads texture files for the POPS in-game reset menu (I didn't test that thing, kind of useless)
- The user can load up to 10 modules after the IOP was reset with the POPS IOPRP (not tried either. I'm pretty sure that feature is br0ken. Will be deactivated by default in the released binaries).

Features with
[*] require the user to patch the POPStarter binaries or use a GUI.
That build was not yet tested with GSM and ps2rdGUI. Only POPStarter's internal functions were tested...

 

Hello krHACKen

Hello. I love your work. "J'attend vos news" ...Papy fait de la résistance ... for the PS1 and PS2. I'm "a...l" ... You're the Best ... Regards ...

 

Wouldn't this block LibCrypt games from working?

My apologies if my context is completely wrong.

 

The way libcrypt uses the breakpoint registers is purely to make sure they aren't being used, as long as the registers themselves work you don't need to emulate the behaviour (and most emulators don't). But I was under the impression that the "POPS exception breakpoints" was something different on the PS2 side.

 

Nope, I meant the exception breakpoints of the emulator itself, not breakpoint registers of the PS1 or the PS1 kernel. When POPS encounters a critical emulation fuckup, it deliberately breaks the emulator execution, causing the PS2 to not respond at all.
For example, when an exception breakpoint is triggered, the pad no longer responds and you can't open the in-game reset menu. And since the execution is broken, POPS cannot handle poweroff requests when you press the Power/Reset button.
Disabling them allows the user to reset or turn the PS2 off.


LibCrypt protected games would still have to be patched, with a scene patch against the disc image or a live patch with the subroutine handler of POPStarter.
The subroutine handler will need some in-depth documentation about how to make and use the "TROJAN" files, cuz that feature was originally implemented in closed betas of POPStarter and it's not enduser friendly. Below are a few "TROJAN" files, if you wanna see what they look like :
http://aybabtu.chez.com/PS2/POPS_SHIT/example_of_trojan_files.zip
Basically, they're made of a header which contains the hook address, the load address, and the hook type (jump instruction or jump and link instruction); and the code to be loaded and called. These files will have to be copied in the VMC directory of the games they are designed for...

 

Oh, that's right; I'm remembering how I used to break it. LibCrypt set the breakpoint address and mask to çaetla's address space so your debugger would crash, yes...

LibCrypt was funny because you could break most games without needing the original game. Most games would encrypt data with bunches of 0000's and FFFF's in it, making it easy to figure out the 16-bit XOR key.

 

It's a pity it can't cope with cd images with subcode's or you wouldn't need to patch the games.

 

bsnes/higan runs every SNES game with no known glitches related to emulation. There also was an emulator of the NES at the bus cycle level, but I don't know what happened to it or whether it was ever finished.

What was this PS1 emulator for PS2 used for?