A few questions... mostly techy stuff

[Bosola]

These are a few miscellaneous questions, without much practical purpose, but just for my own interest.

1. Where exactly *is* the executable on the PSOne disk? Is it split across files? Does the PSOne even read filenames?

2. How, exactly, do FF8/9 work? From what I've seen, you've just got these chunky BIN files on each disk. Why is this? What advantage is there to this? And how does the PSOne navigate them? By sector?

3. How much research has been done into the filetables and boot directories (if they exist) on the PSOne disk? I know we can't author our own disks, but is that because we don't know much about the ways in which these tables are coded?

4. Can anyone point me to information about the way the PSOne boots? I've seen that certain disks can 'hack' the PS logo that appears on startup, so I'm guessing there's some kind of bootstrap program on the disk itself. Google just gets me scores of spammy emulation sites.

5. What's the real reason EIDOS directly ported many of the files from PSX to PSOne? I've heard several theories: that it was unnecessary work, that the port was rushed, or even that Square didn't want to divulge certain information key to modifying and working on the files.

6. Do we actually know much about the executable on PSOne? Not that I'm thinking of modifying it! Can anyone point me to info on the PSOne architecture?

Thanks for reading my scrappy little thread.

 

[nfitc1]

I'm going to attempt to answer with some theories which I'm sure people will come by later and answer correctly.

These are a few miscellaneous questions, without much practical purpose, but just for my own interest.

1. Where exactly *is* the executable on the PSOne disk? Is it split across files? Does the PSOne even read filenames?

There's no "main executable" on any PSX disc. From what I understand, either somewhere on the disc tells the system where to begin processing or the system has a static sector to begin processing from. That said, I believe the first file read is something like init.bin

2. How, exactly, do FF8/9 work? From what I've seen, you've just got these chunky BIN files on each disk. Why is this? What advantage is there to this? And how does the PSOne navigate them? By sector?

Basically same deal as above. It's like the entire game had all its resources compiled into the code. This saves time when trying to look up files (because there aren't any). It's better for the code to say "access data at this address" rather than "access data at this address in this file". The second command takes longer because file seeking requires more accessing.

3. How much research has been done into the filetables and boot directories (if they exist) on the PSOne disk? I know we can't author our own disks, but is that because we don't know much about the ways in which these tables are coded?

Overall, I know that PD PSX roms can be made. I don't know how myself, just that they do exist.

4. Can anyone point me to information about the way the PSOne boots? I've seen that certain disks can 'hack' the PS logo that appears on startup, so I'm guessing there's some kind of bootstrap program on the disk itself. Google just gets me scores of spammy emulation sites.

That "PS logo hack" isn't anything more than a standard loading screen. Discs can provide overrides, but there's pre-processing going on in the background.

5. What's the real reason EIDOS directly ported many of the files from PSX to PSOne? I've heard several theories: that it was unnecessary work, that the port was rushed, or even that Square didn't want to divulge certain information key to modifying and working on the files.

It's a combination of both. Square was being pressured to expand its platforms (I don't know why it didn't with FFIX ) and they wanted it to be as much like the original as they could. Models had to be converted, but it makes sense that the battle data be identical to make sure that it all works the same.

6. Do we actually know much about the executable on PSOne? Not that I'm thinking of modifying it! Can anyone point me to info on the PSOne architecture?

I'm a little confused by this question. I'm not much of a ROM modder so I can't give specifics. Are you talking about the API or the OS? I don't know much personally.

 

[Bosola]

That was very helpful. As for the last question: the API. Surely, though, there's no real OS on the PSOne? I imagine maybe there's some level of hardware abstraction, but that would be about it.

Also, I remember certain pirated PSOne disks coming with cracks and memory managers. Where do these 'sit'? How do these work? What exactly do gamesharks and the like *interface* with? Obviously, they somehow force particular memory values. I can see how the older sort (those that plugged into parallel ports) would work, but later, GSs came as boot disks. Is there some, more privileged 'layer' to memory management, that can force the console to ignore writes to certain memory locations?

 

[nfitc1]

That was very helpful. As for the last question: the API. Surely, though, there's no real OS on the PSOne? I imagine maybe there's some level of hardware abstraction, but that would be about it.

Everything with hardware and software has an operating system in some form. Otherwise, all the discs would have to have hardware accessing functions built onto each of them, which we know is not the case.
API is the virtual layer between the discs and the operating system that the data on the discs is run from.

 

[Bosola]

Everything with hardware and software has an operating system in some form. Otherwise, all the discs would have to have hardware accessing functions built onto each of them, which we know is not the case.
API is the virtual layer between the discs and the operating system that the data on the discs is run from.

Yeah, I'm aware that most applications don't directly interface with the hardware, but with an "abstraction" layer in *some* sense. The alternative would be bulky and redundant, and maybe slow, too (assuming you can stick certain data on ROM). I just thought you were referring to something closer to the 'common' sense of an 'operating system', that includes libraries and what have you.

So, exactly which operations are managed by software on the disk itself? I assume disk and data management is sorted out by the API, where does this layer 'end', so to speak?

 

[halkun]

I'll answer this. I have some free time...

1. Where exactly *is* the executable on the PSOne disk? Is it split across files? Does the PSOne even read filenames?

The game's  executable is on the root of the disk. In the American version is SCUS_941.63. The PSX BOIS is hard coded to read SYSTEM.CNF (It's a text file)and then load and execute the refrenced in there. The "Main executable" is really small (ABout 300k) because all it does it lay out the memory, then decompresses and loads STARTUP/SCEAP.LZS (I think, that also may just be the splash screens ) Now it actually doesn't open it like a file but raw reads the data directly of the CD-ROM like it's memory. That is the "kernel" that managers all the modules of the game.

The PSX has no memory manager, so the game "executable" is actually split up in different modules and overwritten when a new module is needed. (Menu, battle, field, etc) Foe example. the .MNU files are actually PSX program fragments that just deal with that menu. When a new menu is needed, the old one is overwritten and the new one is executed.

So I guess there is no real "Main executable" there is "The Kernel" and "the modules.

Also don't confuse the kernel with kernel.bin. That is just supplementary data for the game.

2. How, exactly, do FF8/9 work? From what I've seen, you've just got these chunky BIN files on each disk. Why is this? What advantage is there to this? And how does the PSOne navigate them? By sector?

It actually works just like FF7 (Direct disk reads), but they did away with the file names to keep hackers out. They weren't needed anyway. I've seen some PSX games that make a huge data block and flag it as a folder in the directory. When you try and open the folder, the filesystem crashes. (Konami Toki Meki Memorial)

3. How much research has been done into the filetables and boot directories (if they exist) on the PSOne disk? I know we can't author our own disks, but is that because we don't know much about the ways in which these tables are coded?

Booting pretty straightforward on a PSX. SYSTEM.CNF is read, and the referenced file is loaded into memory and ran. The reason why we can't author our own FF7 disk is because the file locations were hard-coded... somewhere When they made the final burn, A disk image was made, the files were put down, and then the file locations were "filled in". We don't know where the reference table is. They did the same with FF8/9, but the file locations were recoded, the file names were wiped from the directory and replaced with a big bin blob.

4. Can anyone point me to information about the way the PSOne boots? I've seen that certain disks can 'hack' the PS logo that appears on startup, so I'm guessing there's some kind of bootstrap program on the disk itself. Google just gets me scores of spammy emulation sites.

The PS logo is in the BIOS, before anything is read off the disk. once again, the BIOS reads SYSTEM.CNF and then runs the executable in there.

5. What's the real reason EIDOS directly ported many of the files from PSX to PSOne? I've heard several theories: that it was unnecessary work, that the port was rushed, or even that Square didn't want to divulge certain information key to modifying and working on the files.

Read this

6. Do we actually know much about the executable on PSOne? Not that I'm thinking of modifying it! Can anyone point me to info on the PSOne architecture?

You are going to have a heck of a time modding the executable. It's native state, the kernel is compressed and you will have to work with the modules where they are. Altering their location or size will break the game.


As for you PSX questions.------
The PSX has a 512K program called a BIOS that is the layer between the software and the hardware. PSX games are not allowed to make direct hardware calls and were only allowed to go through the BIOS. Here you will find the load_file() function, which is used by the BIOS to load the initial  300k boot file. but square bypasses that function the much faster read_sector() which allows them to load data one sector at a time and not have the game "stall" while it does a file load. (The PSX BIOS can't multitask. It give it a function, and you must wait till it returns)

You can read my PSX doc for more info here You can load the SDW file in OpenOffice. (It's really old, and was originally written in StarOffice)

 

[Bosola]

The game's  executable is on the root of the disk. In the American version is SCUS_941.63. The PSX BOIS is hard coded to read SYSTEM.CNF (It's a text file)and then load and execute the refrenced in there.

Aha, so that's what those files are for.

Now it actually doesn't open it like a file but raw reads the data directly of the CD-ROM like it's memory. That is the "kernel" that managers all the modules of the game.

So, correct me if I'm wrong, but you're saying that, rather than open it like a 'file' to be worked on, it just treats the files on the CD-ROM as a part of its 'own' memory?

the .MNU files are actually PSX program fragments that just deal with that menu. When a new menu is needed, the old one is overwritten and the new one is executed.

So is a lot of the MNU just assembly code? If so, does that mean we could (in theory) alter the way the 'executable' works by modifying these modules... assuming, of course, we don't exceed the filesizes (easier said than done).

Read this

Much appreciated!

As for you PSX questions.------
The PSX has a 512K program called a BIOS that is the layer between the software and the hardware. PSX games are not allowed to make direct hardware calls and were only allowed to go through the BIOS. Here you will find the load_file() function, which is used by the BIOS to load the initial  300k boot file. but square bypasses that function the much faster read_sector() which allows them to load data one sector at a time and not have the game "stall" while it does a file load. (The PSX BIOS can't multitask. It give it a function, and you must wait till it returns)

You can read my PSX doc for more info here You can load the SDW file in OpenOffice. (It's really old, and was originally written in StarOffice)

Thanks!

As for gamesharks, do they just make commands to the BIOS, that can then veto changes to memory made by the game itself?

 

[halkun]

So, correct me if I'm wrong, but you're saying that, rather than open it like a 'file' to be worked on, it just treats the files on the CD-ROM as a part of its 'own' memory?

Kind of. Think of the CD-ROM as a huge "bank" of memory that is 650 megabytes, split into 2k "chunks". Each chunk is a sector. When FF7 needs to load data, go goes into the drive, reaches just that chunk and loads it into RAM, then it does something else. The next frame, it will read in the next chunk, then do something else. It repeats unti the file is loaded. It's very quick, and as you can see we don't need to know filenames, just were the chunks are located. Those are hard coded somewhere. It's the reason why most of the files actually have thier file length in the header, so the loader routine can blindly load chunks without going over. Many also have the memory address the data supposed to be loaded into.

 

[Chev]

To put it simply, you could say it treats the CD as one huge file.