• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
March 28, 2024, 07:18:45 pm

News:

Use of ePSXe before 2.0 is highly discouraged. Mednafen, RetroArch, and Duckstation are recommended for playing/testing, pSX is recommended for debugging.


How do you build a PS1 disc image from a collection of files?

Started by nitwit, June 17, 2016, 06:39:49 pm

nitwit

Also what are the various ways that PS1 games load files into memory?  Is there are built-in function that does that automagically or does it need to know which sector a file is in?

If I move files around in a disc image, will the game still work?

If this is true, then the best way to deal with most games would be to dissect the disc image into files, modify those files, and then reassemble the files into a disc image.

Xifanie

That's not how it works. A PSX CD doesn't need any file. The information is stored in the CD's sectors; an indexed file is 100% irrelevant to the PSX. For example, to load what we call BATTLE.BIN, the game loads data from sector 1000 for a length of 683 sectors to memory address 0x80067000. If you move the indexed file or delete it, the PSX won't care, it will still load the data from sector 1000. You have to change the sector number inside the game's code/files.

Indexed files are just convenience for us hackers; that's all they are.
  • Modding version: PSX
Love what you're seeing? https://supportus.ffhacktics.com/ 💜 it's really appreciated

Anything is possible as long as it is within the hardware's limits. (ie. disc space, RAM, Video RAM, processor, etc.)
<R999> My target market is not FFT mod players
<Raijinili> remember that? it was awful

nitwit

Quote from: Xifanie on June 17, 2016, 08:17:32 pm
That's not how it works. A PSX CD doesn't need any file. The information is stored in the CD's sectors; an indexed file is 100% irrelevant to the PSX. For example, to load what we call BATTLE.BIN, the game loads data from sector 1000 for a length of 683 sectors to memory address 0x80067000. If you move the indexed file or delete it, the PSX won't care, it will still load the data from sector 1000. You have to change the sector number inside the game's code/files.

Indexed files are just convenience for us hackers; that's all they are.

Does this apply for games other than FFT?

Also how would you iterate through a disc image and write to specific locations in a sector?

How do you deal with files that are in a place where if they become too large stuff gets messed up because there isn't enough room?  Or loading an uncompressed version of a file?

Xifanie

Yes all PSX games. Like I said, the console doesn't read the file index, it reads sectors.

You just export/import files and stuff. The file index links files to sectors. Like I said, it's a convenience for hackers. But it also doesn't mean that because there is no file for some sectors, that there is no data there. (You can see all FFT's free sectors here: http://ffhacktics.com/wiki/CD_Index)

...What?
  • Modding version: PSX
Love what you're seeing? https://supportus.ffhacktics.com/ 💜 it's really appreciated

Anything is possible as long as it is within the hardware's limits. (ie. disc space, RAM, Video RAM, processor, etc.)
<R999> My target market is not FFT mod players
<Raijinili> remember that? it was awful

nitwit

Quote from: Xifanie on June 19, 2016, 06:27:02 am
Yes all PSX games. Like I said, the console doesn't read the file index, it reads sectors.

What should I read to learn more about this?

Quote from: Xifanie on June 19, 2016, 06:27:02 am
You just export/import files and stuff. The file index links files to sectors. Like I said, it's a convenience for hackers. But it also doesn't mean that because there is no file for some sectors, that there is no data there. (You can see all FFT's free sectors here: http://ffhacktics.com/wiki/CD_Index)

How did you determine which sectors are free?

Quote from: Xifanie on June 19, 2016, 06:27:02 am
...What?

I'm working on a PS1 game.  This game has a file which is compressed.  Immediately after that file - and I do mean immediately, as in the next sector - another file begins.  If I decompress that file, edit it, and then recompress it, it is often too large to reinsert back in the location it was previously in.

Fortunately for me the makers of this game also included a uncompressed version of that file, but for unknown reasons they made the game load the compressed version and the uncompressed version just sits there, doing nothing but taking up space.

This file contains most of the battle and post-battle routines, all of which are reasonably well documented.  I can edit them, but I can't actually apply my changes.  I must either find a way to move files around so that I have room after the compressed file to insert it when it is larger than normal, or I need a way to make the game load the uncompressed version of that file.

I guess I'm asking for a tutorial on how to understand everything about CD-ROM XA Mode 2.
https://en.wikipedia.org/wiki/CD-ROM#XA

I printed 3 specifications (ECMA 119, ECMA 130, and the Phillips CDI spec), but they are dense and difficult to understand.  I don't know what much of the terminology means and it would take me months to read and comprehend everything in them.

Xifanie

http://forums.afterdawn.com/threads/bin-cue-iso-frequently-asked-questions-read1st.258815/
I guess

FFT just happens to only use sectors that the file index shows. It should be the case with most games, tbh. But I'm pretty sure I've heard of some games with either one big-ass file, or just the PSX EXE, and the other "files" only being stored in sectors, and not actually have files from the file index linked to those sectors.

I really don't know the circumstances, so I can't help much. But you're VERY likely going to have to find the sector in the game's code, and its length. The length in FFT is stored as the # of bytes loaded; so 1 sector = 2048 bytes. It could also be the number of sectors loaded in your case. Granted, that is only relevant if the game can even allow a bigger filesize to be loaded.
Let's say you have a file loaded at 0x80004000 for 0x8000 bytes (16 sectors); i.e. 0x80004000 to 0x8000BFFF if you have another file normally loaded at the same time at 0x8000C000, well, guess what, you're screwed.

You would also have to move the file somewhere else. cdprog makes this easier by allowing you to create files and link them to sectors. You still have to edit the game's code though.

I'm just guessing the compressed file is decompressed on the file, for only parts of it at a time. Otherwise it would be pretty fucking stupid to spend processing time decompressing a file that shouldn't be compressed in the first place.
  • Modding version: PSX
Love what you're seeing? https://supportus.ffhacktics.com/ 💜 it's really appreciated

Anything is possible as long as it is within the hardware's limits. (ie. disc space, RAM, Video RAM, processor, etc.)
<R999> My target market is not FFT mod players
<Raijinili> remember that? it was awful

nitwit

Looking at fft.bin, addres 0xca17, the beginning of a sector that is some kind of directory index.  What does all this mean?  Where does each entry begin and end?  What are the properties of each byte or bit in each entry?  How do you tell the difference between a entry to a file and an entry to another directory?

https://i.sli.mg/NRumkM.png


EDIT

http://alumnus.caltech.edu/~pje/iso9660.html

Maybe it was right in front of my face the entire time.