News:

11 March 2016 - Forum Rules

Main Menu

Question: resizing a PSX disc image?

Started by ffvd_games, July 13, 2022, 03:16:55 PM

Previous topic - Next topic

ffvd_games

Hello, RHDN.

First, some background. I'm part of the SaGa Frontier ROM hacking community, and we've gotten to a point where we understand the game enough to start making patches that add onto the game instead of just changing some values or moving some bytes around. One patch in particular that's going to be released soon has hit a point where not much else can be done with it with the current layout of the disc image.

Now here's the question. Is it possible to, for example, take an existing PSX game, make some file 50 bytes larger, and recompile the file system into a working game ROM (assuming pointers magically work themselves out)? I know lameguy has a tool that can extract and rebuild PSX ROMs, but when I attempted to use it with SaGa Frontier, the game crashed right as it loaded in psxfin. No clue if I did something wrong, if there's some weird pointer thing specific to SaGa Frontier, or if there's some other underlying puzzle that we don't understand about existing PSX disc images.

Any and all help is much appreciated.

EDIT: forgot to mention what files we specifically want to start expanding. We're looking into expanding EVENT.BIN and EVENT2.BIN, which are script files for in-battle events. More specifically, we want to port over some new script files that were created for SaGa Frontier Remastered into the original game.

FAST6191

By and large PS1 games are ISO9660 with whatever file name length/sector setting/... restrictions it has that don't tend to trouble ROM hacking in any notable way other than needing the relevant tool to respect them/set your program up accordingly. Some, usually Square (Enix), stuff colours outside the lines a bit with raw reads of the disc usually for audio and maybe anti piracy (more on that shortly).

Not sure what is causing your issues with this. I assume you tried unpack and repack of whole ISO but files unchanged to confirm whatever tool you were using is working as a baseline.
The times I bother to fiddle with PS1 stuff I usually grab whatever ISO handling tool is good (PS1 not really having any standards so if I stick with old Scene dumps then 1000 different file formats in play)
Those that actually do it regularly
Dumping: https://github.com/Lameguy64/isodump
Rebuilding: https://github.com/Lameguy64/mkpsxiso
Or maybe
https://www.romhacking.net/utilities/1417 https://www.romhacking.net/utilities/1574/

Anti piracy can be a thing, though checking a vintage console hacking site (shocked it is still up after all these years) I only see such patches for Saga Frontier 2 (has a bunch for region changes for the original) so going to presume not in this case.

Sizes can also be a thing if the game accounts for file size in whatever compiler was used for it and raising sizes knocks you over limits it might have assigned for memory ( http://problemkaputt.de/psx-spx.htm#memorymap ) but for many things like this I would have expected continuous fetching as you are limited in memory (consider it 2 megs and that has to house the binary, active files and any scratch space it needs for calculations, decompressions and such like).
Internal pointers may be used to mitigate this at some level and fluffing those up can cause issues on this (or any console that uses as a similar approach, which is basically anything with a file system and a few things besides).
To that end internal pointers might be a thing you need to take care of -- many such files will include internal size values that you might do well to change (or not, sometimes they are there because the devs were doing coding being good boys). If the unpack-repack with whatever tool you like becomes successful then you can try adding a bunch of 00 to the end of the file and seeing if that makes a difference.

MysticLord

#2
Some other Square games from that era use a different file addressing scheme, which I don't pretend to understand. I think the Vagrant Story guy answered some questions on it, let's see if I can find them.

Valendian's reply this this thread seems relevant, but the thread itself is gone for some reason.
https://www.romhacking.net/forum/index.php?topic=18596

How to do system logging on a specific PS1 emulator (does Duckstation do this?).
https://www.romhacking.net/forum/index.php?topic=25677

CD seek and read questions.
https://www.romhacking.net/forum/index.php?topic=30707

Using MIPS syscall and disc read.
https://www.romhacking.net/forum/index.php?topic=26795

I agree with Fast6191 that you need to first attempt to rebuild the original unmodified disc image with the existing tools to verify that they work. If it works, after that you should see if you can rearrange files on the disc image without altering them and get it to work.

If it doesn't work, then I'm guessing it uses those custom LBA tables Valendian talked about. If that's the case, good luck - you're already beyond my skills. Try hassling Valendian on Twitter, I guess, and be honest about your abilities.

From my very limited understanding, the issue isn't that custom LBA tables are hard to modify, but that they're hard to find. Every thread I've seen on the subject quickly dives into technical information far above my skill level, and basic clarifying questions (about definitions, mostly) go unanswered.

It seems there's a skill level you have to meet to merit a response from the people who actually know how this works, and until then you will get zero help beyond "figure it out".