Sword of Moonlight Forum
Sword of Moonlight => Tools => Topic started by: TheStolenBattenberg on October 27, 2014, 11:38:04 am
-
Hey,
It's been a while, I've been busy with multiple project, same stuff as always.
I don't come without something though, even though it's a very small percentage of what I still have to do.
(http://i.imgur.com/uvb6ANm.png)
This is a very small utility for looking into the .T files on early FromSoftware games. Currently it will only display FSTim, but that's soon to change.
Now I'm not gonna actually say what I'll be providing in the eventual version, because that's normally where I go wrong. I'll promise awesome stuff, but won't deliver on everything.
But, what it currently supports is this:
- (partial) reading of .T archives.
- Reading and display of .FSTim with optional zooming. (4BPP only.)
- Exporting of .FSTim to .PNG
- Easy to use UI
Here's a download for this version. It should make it a little easier to get the files you want, rather than extracting the whole .T archives.
Download (1.87MB): Mediafire (http://www.mediafire.com/download/5n2a1f83icraxc2/FSTim+View.exe),
Now that's over, I figured I should probably say that this might be the last post I make related to King's Field tools here. I always felt kinda crappy posting KF in the Sword of Moonlight forums, but honestly, there's no where else to post about King's Field. Agetec boards maybe?.. If I have the time, and get the money, I'll probably make a website dedicated to the hacking of King's Field (though that's unlikely).
Report any bugs with the application to me, and I'll fix them. I fixed as many as I could, but there's always one that gets through. :)
- TSB
-
Is there anything other than images in the .T files?
As far as I'm concerned, your tools are welcome on this site. Todd, the site owner is a game creation enthusiast, and I suspect any tool dealing with game creation or any of the sub-disciplines (music composing, 2D graphics, story telling, installer archiving etc) is welcome here.
I think the Agetec forums are dead. Actually, I think Agetec went out of business. Their old office is empty and up for rent and they haven't produced a game for years (as far as I know).
Can I move this to the tools section?
-
Sure thing. There's actually loads more in the .T archives, but the file format is awkward to read, and very confusing. I also still consider myself an absolute noob when it comes to figuring out file formats.
I've currently found that they contain these files:
.Seq (Playstation Sequence Data), like a midi file for Playstation.
.Vab (Playstation Sound Bank), a set of sounds for Seq to reference. Like the driver in .PSF
.Tmd (Playstation Model Data), 3d data.
.Tim (Playstation Image Data)
.FSTim (FromSoftware Image Data)
Currently it'll handle .FSTim and .Tim. I wanna try and find out how King's Field handled Animations. From what I've heard, they're stored in .TOD files...
More on the .T Format, here's the information so far.
struct header {2048}
{
//The .T file header.
short {1} T_HeaderEntries; //This is the number of entries that are used in the ToC for the file.
//The 2 byte number (short) following this, appears always to be of '0100' in value. This is supposedly because the first sector begins at an offset of 0x800.
//Sectors beginning at 0x800 are confirmed in every file .T file on KF1 (US).
short {T_HeaderEntries }
//Following this, everything is just 00 until files start at 0x800.
//All files are followed by a 4 byte checksum.
byte {*} //File
int {1} //Checksum.
}
-
Interesting. I just looked at the .T header and I thinks it's a classic table structured for CD storage. The first 2 bytes are the number of files in the archive just like you said.
The rest of the header looks like a table of contents (ToC) listing the number of CD sectors to where the given file begins in the archive. i.e. There are 0x800 bytes of usable data in each PS1 CD sector, so its the ToC number times 0x800. The first entry is always "0100" because the first file always starts at 0x800 Unless the ToC happens to be longer than 0x800- which probably never happens.
At the end of every file I looked at, there is a 4 byte value. Those appear to be Fromsoft's tamper-proofing checksums. I knew the existed on text graphics, but they may also be used on 3D models etc. If so, they'll make the game freeze if anything is edited. That tool I posted awhile back to "enable editing" should fix some/all freezes. :drool:
-
I'll have to mark that 4 byte value you mention in the file, for more investigation.
Do you have any more information of table structure for CDs? It's not something I've looked at. T archives are something I find interesting, because of how irritating they are.
Maybe .T does stand for table or something of the sorts? I agree with the ToC idea, but I think the first 2 byte number isn't how many files there is, but actually how many entries are inside the table. For instance, in 'RTIM.T' on the KF1 (US) disk, the first number is 0x4B. This is 75 in decimal, how ever there is way over 600 files in RTIM.T, as can be proved with both your extractor and this viewer I constructed.
There is however, exactly 75 entries in the table. How would one know how many files are in each sector though? Could the first number be the position, and the second number be the sector? I guess not, because that would mean the sectors are larger than.
After looking in RTMD.T, and running multiple .TMD extractors, and searching the program with the latest version of FSTim view... I can say that it doesn't contain any .TMD data. In fact, I think this may be the file that contains the level data which everyone (well, maybe not everyone) wants. I come to this conclusion because everything else contains a Sony formats, or a slightly modified one. Maybe cross-referencing it with files from King's Field Japan would help, but figuring out .T archives 100% would be even better.
I updated the top post's document with this information.
-
Do you have any more information of table structure for CDs?
I haven't looked at the KF game specifically, but the process for loading data from the CD into RAM is usually fed three values: the data's starting sector (aka LBA) on the CD, it's destination address in RAM, and how many bytes to transfer.
To calculate the data's LBA location, the game loads a base LBA (which is the start location of the .T file), and then adds to that the value from the pertinent header entry. That makes the total equal the LBA location of the data the game wants to load. That LBA location is then fed to the function which loads the data to RAM.
I agree with the ToC idea, but I think the first 2 byte number isn't how many files there is, but actually how many entries are inside the table.
Yes, you're right. There could be many sub-tables inside the main .T 'archive' so it could contain many more files than are shown in the main ToC. If you go to the first location listed in RTMD.T's main ToC (ie 0x800), you'll see what looks to be another table (ie a sub- table) with 4 byte locations stored at patterned intervals. The sub-tables locations would most likely be relative to the beginning of the sub-file (ie 0x800 + 0x1A80 etc).
-
Unfortunately, having a table at 0x800 is inconsistent with the other .T files. This is most clear with VAB.T, which has pbaV at that offset, that's the header tag for a Vab playstation sound driver file.
-
I don't think the table at 0x800 belongs to the .T, it belongs to the file stored in the .T
A 'look up table' is a really common thing to have at the beginning of PS1 files.
-
Wouldn't it corrupt the files to have a look up table inside them though?
-
Not at all. The .T file's table would be used to look up a chunk of data stored in the .T file and load that chunk in RAM. Once the chunk is in RAM, the chunk's table header is used to look up data inside the chunk.
A real example from Brigandine is text. When you go into battle (i.e. game switches to the battle map), it loads a data chunk which contains battle text from the CD into RAM. It finds that chunk's location in the file by reading a 'look up table' at the file's top. Other chunks in the file contain creature sprites, map tiles etc. The text chunk also has it's own 'look up table' at the top. Once it's in RAM, that table is used to find a specific sentence of text inside the text chunk.
-
It's been near enough a year since I last worked on this tool, but I've come forward with a lot of new breakthroughs during this time, which will excite any King's Field fan
The .T archive file format has been fully reversed, and I've created a few small tests to see what it can find, and oh boy did I learn a lot more about how King's Field works.
1) There is no custom .Tim format, as was thought.
By creating a utility to scan through the .T files and find anything that looked like it was a texture, a lot of information was missed out on, primarily the fact that King's Field loaded all the textures for a level in one big clump, near-direct to video memory. This explains one big thing which I noticed when extracting files, which was that there were duplicates all over the place.
2) More files uncovered.
By excluding common PlayStation file types, I've found a lot more priority file formats inside the archives. I haven't had a chance to reverse them yet, but it could mean the discovery of the level data, which would be really cool for many reasons.
--
I'll try and keep this updated a lot more often, as I'm sure I've probably pissed people off here in the past by working on things then never releasing them... Sorry about that, life sure gets hectic the older you get, huh?
Edit:
From my notes, I've got this to show:
These Archives have no support:
- MO.T (Models. Weird sub-tables, can't extract it.)
- RTMD.T (Level data. Don't know the fileformat, can't extract it.)
These Archives have partial support:
- VAB.T (Can extract, but don't know all the files.)
- FDAT.T (Can extract, but don't know all the files.)
These archives have full support:
- TALK0.T (.Tim)
- TALK1.T (.Tim)
- TALK2.T (.Tim)
- ITEM1.T (.Tmd, .Tim)
- ITEM2.T (.Tmd, .Tim)
- RTIM.T (.FSTim)
It pretty much explains its self, although FDAT.T is bordering 'not supported' at the moment. Only an amazing 1 file is found in that, and it's a VRAM sheet
- TSB