WORKSHOP CODING INTROS & DEMOS for Play Station 1

[Z3R0X]

This is one of the best threads ever, thank you lightforce for all your knowledge. I learned a lot form you and PSXDev.
The only suggestions I can think of it is to divide/struct the code into smaller files with typical C project struct like the include, lib, src folders. Because if everything is in one file MAIN.C can be difficult to read for the newbies.

[alexfree]

This isn't the only way to make a cracktro/preloader, but it may in fact be superior to what me and MottZilla have done. With the https://alex-free.github.io/tocperfect patcher instead of modifying the PS-EXE itself you can simply append another separate EXE as the last file in the data track (to not mess with any LBAs) and then either add a SYSTEM.CNF file to the image (also at the end) if it is an early Japanese PSX.EXE game like Ridge Racer Japan that doesn't have one, or edit the BOOT line on the existing SYSTEM.CNF (which also doesn't change the amount of sectors it takes up).

Something else I've thought about, is how 'correct' does the disc image really need to be at the beginning sectors for it to still boot on the PSX? SCPH-1000, all USA consoles, and all PAL consoles up to 102 don't even need a valid license sector, so in theory sectors 0-15 could have data for a file in them. Sector 16 needs to be the directory, but that is 30720 bytes for free without appending any files on the end of the disc (but still needing a SYSTEM.CNF to point to it). If we take needing a valid sector 4 into account, we still have 20480 bytes for free if we start at sector 5-15.

I'm still not exactly sure how cracktros work. Are you modifying the PS-EXE (using the header zero bytes somehow) to jump lower then user ram 80100000 to unused kernel RAM that then contains the cracktro? Or are you modifying the entire exe to load higher or lower then 80100000 (or whatever start address the executable is linked for) and then @8010000 is the actual cracktro? Something else?

I need to see the downloads available already to figure that out (hopefully there is source code). It would be nice to automate this into a CLI on Linux as well so I don't need to use wine. If source is available that should be pretty easy.

Anyways, excellent thread, really cool to meet someone from the scene here at psxdev. I wonder what you think of https://alex-free.github.io/aprip ? The anti-piracy patch (not the libcrypt ones) in that while only working on stock consoles without a modchip, has worked with every titles I've tried it with and it's something I discovered only last year. I figured that out when I realized that the original Japanese launch consoles can never trip anti-piracy detection (not the libcrypt protection) since they lack the readtoc command in the CDROM controller C0A/C0B versions and games had to ensure those consoles would function normally. So with a correct TOC and no modchip every game (including spyro YOTD USA) works without any patching on those early consoles. That behavior is easily emulated on other consoles which do contain the readtoc command in their newer CDROM controller firmwares with gameshark codes (100% success rate not including Spyro YOTD USA because of memory scanning) and depending on weather or not the game obfuscated it, the ISO itself sometimes.

[alexfree]

So I tried the idea, can you fit a cracktro/pre-loader in the sectors before the volume descriptor (16)? The answer is surprisingly yes, but this isn't as great as it might seem.

Sectors 0, 1, 2, 3 are zero-filled so they are fine to use.

4 is the license data, which depending on what console it is has to match the region. Some consoles must have this matching so it can't be used for additional data.

5-11 are the logo data, which is the real issue. By having some of the PS-EXE data where the logo data is, the console never gets past the white sony screen (tested on SCPH-1000 and SCPH-5501, both don't care about sector 4 data so this is the actual issue.

12, 13, 14, 15 are 'reserved' zero-filled sectors as well. Besides sector 12 being abused for EDC-based detection in some of the late Japanese games, these are fine as well to use.

So how do I know this technically works? I'm using sectors 0-13 to fit a PS-EXE and it does actually work just fine with a soft-mod (Tonyhax International with SCPH-1000).

adding-file.png

cdmage.png

So realistically, if your executable is 2048*4=8192 (0x2000) bytes or lower you can put it at LBA 0-3 and it completely works.

Possible fixes:

1) If you can somehow place an unsigned char array of sector 4-11 user data at 0x2001 to whatever in the middle of the executable and have it end up in the exact sectors 4-11 that need that data, you might be able to continue to use sectors 12-15 for the rest of the exe?

2) If you did 2 files, stage 1 is 0-3 and stage 2 is 12-15.

Again the problem is nothing but issues after sector 4, because even if you do one of the above solutions those EDC protected games will not work correctly because they lock up the game if sector 12 EDC checksum is non-zero (which it would be after writing the PS-EXE, and if it's not, then it would corrupt the user data of the sector by trying to 'fix' the user data it thinks is corrupted).

An idea with this would maybe be even to put a small bit of assembly at sectors 0-3 which just reads a PS-EXE too large for just 4 sectors off of a memory card and runs that as a stage 2. Again you do have 0x2000 bytes to work with that causes zero issues.

Don't mean to clutter up this thread but I've never seen anyone try anything similar. This is a 3rd possible way to do a cracktro that is somewhat realistic.

[Z3R0X]

@Alexfree Very interesting idea, thanks for sharing your knowledge!

[inc^lightforce]

Don't mean to clutter up this thread but I've never seen anyone try anything similar. This is a 3rd possible way to do a cracktro that is somewhat realistic.

No need to do that. We worked it out in 1997 and until its Consoles end, it worked each and everytime.

Shouts