Author
|
Topic: [BM 00] The Virtual File System (Read 2 times)
|
KaioShin
Guest
|
 |
« on: December 12, 2006, 02:18:12 pm » |
|
According to our more experienced PSX hackers this is what we should deal with first and foremost. The game's files are packed into rather huge files. We'll need to find out how the files are made up so that we can extract the contents. Later we'll need to be able reconstruct them of course. I think that the several .DAT files are the packs. So, we'll need to get them unpacked. Klarth and Gemini will be able to tell you more about them, let's see what we can do  |
|
|
|
|
Klarth
Guest
|
|
« Reply #1 on: December 12, 2006, 03:27:15 pm » |
|
|
|
|
|
|
Gemini
Guest
|
|
« Reply #2 on: December 12, 2006, 09:34:54 pm » |
|
Briefly: all .DAT files are archives used in our VFS. There is an unsigned long (4 bytes each) value at the beginning of the archive which indicates the number of files contained /2, then there is another ulong, an unknown value, but it's always set to 0x0000000B, so who cares about it.  The last important part is... INDEXES! They are managed as unsigned shorts (2 bytes each). First ushort is the pointer (you have to multiply it for 2048 in order to obtain the actual pointer), next ushort is file size (multiply for 2048 here, too). Ok guys, now we need only a utility for dumping all that crap out of data files.  One is down, what's the next? |
|
|
|
|
Klarth
Guest
|
|
« Reply #3 on: December 12, 2006, 11:02:07 pm » |
|
Are you sure that your description of the pointers are accurate and it's not storing the size within the pointer too? Because multiplying the size by 2048 means that the number will be a multiple of 2048...ie, you can't get an exact file size, only the number of sectors used, which is a problem. So I think your analysis is a bit off there, but I don't have the game myself.
|
|
|
|
|
Gemini
Guest
|
|
« Reply #4 on: December 13, 2006, 05:10:58 am » |
|
Yes, it's accurate, there's no doubt about it. It's not necessary to specify an exact number of bytes since the Psx can read only sectors made of 2048 bytes (excluding control detection codes) for non XA data.
|
|
|
|
|
Klarth
Guest
|
|
« Reply #5 on: December 13, 2006, 07:56:27 am » |
|
I know, but all of the VFS's I've come across have a method to obtain the exact filesize, so the game doesn't have to waste bytes of RAM. It only copies so many bytes from the last CD sector read. Welp, we'll see.
|
|
|
|
|
Aerdan
Guest
|
|
« Reply #6 on: December 13, 2006, 08:25:51 am » |
|
I don't mean to be rude or anything, but can we please stop calling it a 'virtual' filesystem? The term's being incorrectly applied; a virtual filesystem is one that is an overlay over real ones, useful for providing a filesysetm-agnostic way to access files.
|
|
|
|
|
Gemini
Guest
|
|
« Reply #7 on: December 13, 2006, 09:17:26 am » |
|
I know, but all of the VFS's I've come across have a method to obtain the exact filesize, so the game doesn't have to waste bytes of RAM. I got your point, but you should know that having to deal with different games means learning different way to use the console. If you don't trust what I wrote, just open DAT files in a hexeditor or disassemble the asm code and you'll find out the answer by yourself. a virtual filesystem is one that is an overlay over real ones, useful for providing a filesysetm-agnostic way to access files. Infact that's what it does. The only files relying completely on the actual file system are two: those used for booting the game. |
|
|
|
|
Klarth
Guest
|
|
« Reply #8 on: December 13, 2006, 09:27:53 am » |
|
The term's both been used for "An abstraction API sitting between the kernel's file i/o functions and the actual filesystem code/driver" as you claim it can only be. And it ALSO applies to a generic filesystem sitting above a real filesystem, because it's an abstraction of the real FS. The term's been used in the gaming industry, or at least hobby game development. Virtual File System, File Subsystem, Resource file, etc.
|
|
|
|
|
disroyal
Guest
|
|
« Reply #9 on: December 13, 2006, 01:43:01 pm » |
|
I just saw this and got kinda interested, so I made a program to read the files from the dats. I'm kinda drunk right now so I don't know if it works as it should  Instructions: vfsdump filename.DAT Oh and it uses filestreams, so it's slow as hell :'( I'll rewrite it to us buffers tomorrow though. [attachment deleted by admin] |
|
|
|
|
Gemini
Guest
|
|
« Reply #10 on: December 13, 2006, 02:14:59 pm » |
|
It's not working at all. I guess your extraction method is wrong somewhere. Anyway I'm coding already the same program with a gui. Shouldn't take too much time. PS: Talking about next things to do, I guess I've figured out how the proprietary graphics format works. Next time I'll post the specifics and the dumper for DAT files. |
|
|
|
|
disroyal
Guest
|
|
« Reply #11 on: December 13, 2006, 08:52:00 pm » |
|
Hehe, so much for coding when you're drunk |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #12 on: December 14, 2006, 08:48:17 am » |
|
Just a heads up, you guys should probably find somewhere to host the tools besides board attachments. As usual, space is low. You fill it up, you have none. I'm not interested in allocating anymore space to it and I'm leaving in less than 24 hours.
|
|
|
|
|
MegaManJuno
Guest
|
|
« Reply #13 on: December 14, 2006, 01:54:13 pm » |
|
Hmm... I do have an FTP server set up at home that I might be willing offer space on... It's normally up pretty much 24/7, although I would require user accounts (I have anonymous access disabled) so I can:
A) Have some idea of who's accessing my system.
b) Limit usage somewhat, so everyone and their brother isn't eating up my bandwidth.
Some sort of online repository would be much better in the long run, but if need be, I could offer some space for this project to at least serve as a mirror of sorts for the files in case the primary source was unavailable.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #14 on: December 14, 2006, 05:54:58 pm » |
|
You could also host them on a site like Fileden. |
|
|
|
|
|
