Unofficial PS1 Hacking Topic

[Twili]

Boring topic so far. No screenshots yet.

 

-Documents-

 

filefrmt.pdf - I perform a Google search for you. No direct link. This is a document containing the specifications of common proprietary Playstation file formats. Google will say "Showing results for file format.pdf", so click "Search instead for filefrmt.pdf" below.

 

Unofficial wiki page on the TMD model format. Use in conjunction with filefrmt.pdf.

 

-Tools-

 

ECM Tools - For decrypting Playstation ISOs that end with .ecm. Extract the contents of the RAR to a folder and move your ECM there. Click and drag the ECM into unecm.exe.

You should move the CUE file to this folder as well. (assuming that the ISO is in BIN/CUE format, the BIN file will be .bin.ecm if encrypted)

 

Undisker - For extracting the filesystem of the ISO. File > Open... > on the dropdown menu "Files of type:" choose "BIN CD-ROM Image (BIN/CUE)", open the CUE file, not the BIN or it will not load!

 

If Undisker read the ISO correctly, there should be four files visible now.

 

-PSXDATA (folder)

-GAME.EXE

-SLUS_[number code for game]

-SYSTEM.CNF

 

You can right click a file and click Extract To... to extract only it, but I like to extract the entire filesystem. To do that, select Image > Extract To... from the top of the window, navigate to where you want every file extracted and click Extract.

 

 

And lastly, here are some notes that I have made on DTA files, which I know are used in the unreleased (officially, but leaked by the developers themselves ) Thrill Kill, at least, as containers for character models and animations:

 

Keep in mind that pointers in these files seem to be word-swapped and other data seems to be byte-swapped?

 

header

{

uint version; //offset 0x0, always 0x00000201?

uint trans; //offset 0x4, pointer to model part translations

uint anim; //offset 0x8, pointer to animation stuff

uint model; //offset 0xC, pointer to the TMD model

*the size of the next section of the header varies depending on the value of anim, contains (anim-0x14)/4 entries.

uint texture; //pointer to a color-indexed texture which has a header...

unint pad; //0x00000000

}

 

Note on model part translations: These are absolute translations, not relative to parents.

 

Note on TMD models: All pointers must have 0xC added to them.

 

I haven't even looked into the animation data yet.

 

Maybe xdaniel could write a viewer for DTA files?

[Arceny]

Hey! I tried hacking a PS1 game once; (Syphon Filter 2, I think...) I found sound files, but I couldn't extract them. This tool looks cool....

[xdaniel]

Maybe xdaniel could write a viewer for DTA files?

 

Once I have some DTA files to experiment with and wrote a TMD parser/renderer, I might try to Mega Man Legends doesn't use TMDs as such, so I can't just directly pilfer the code from that viewer, tho it does use (slightly non-standard?) raw GPU packets too, IIRC.

[Twili]

Here is a DTA file. TMDs I like to call essentially a binary version of OBJ, because...

 

 

And to make things easier, it seems that all of the models from this game use the same "PACKET LIST" from that wiki page, which is the one labeled "3 SIDED, TEXTURED, GOURAUD SHADING, NO PIGMENT".

[xdaniel]

Framebuffer simulation is bad, somehow textures end up getting overwritten. Still, not too bad for three or so hours with breaks. Gonna try and fix the textures, maybe take a look at animations, then make an actual GUI and put the whole thing, source and all, up here.

 

[Jason777]

Looks pretty sweet, I look foward to the release of the source.

[xdaniel]

Texture mapping might be not 100% correct, but it's close enough. Will look into animations next I guess, and depending on how that goes, I'll post the program either tomorrow or Friday/Saturday or so.

 

[Twili]

Remarkable progress. Thanks for taking your time to try this stuff. I look forward to the eventual release of this viewer.

 

Oh, by the way, would an OBJ Export function be a possibility? Then it would be easy to convert models to F3DEX2 and import them in Zelda.

[xdaniel]

I'm not sure about OBJ exporting, or at least about converting the resulting model for the N64... On the PSX, all textures and palettes are loaded to coordinates in the framebuffer, while the texture coordinates of a primitive are points on that framebuffer - think of everything on screen using a single big 1024x512 texture. A real world example:

 

 

...and how the viewer's simulated framebuffer looks:

 

 

And while your game, unlike Mega Man Legends above, does load every single texture to the framebuffer separately (MML uses sheets of IIRC 256x256 pixels with multiple textures on them) and each of them can ex. be dumped to PNG separately, the texture coordinates for each primitive would need to be recalculated to no longer point to framebuffer coordinates but coordinates on each texture, which in turn would need to be identified first. Also, which is a smaller problem, the textures would need to be padded to N64-compatible sizes (60x22 to 64x32, 18x48 to 32x64, etc).

 

All that should be doable, but I'm not sure if I'd want to try it, to be honest...

 

(Hope the explanation makes sense, it's rather late here)

[Twili]

It makes perfect sense. Here are some things that I have on the animation data, using DEMON1.DTA.

 

At the offset specified by the third pointer in the DTA header is this header for the animations chunk:

 

10 00 00 00 90 CA 00 00 01 00 00 00

 

The first word is a relative pointer from this header to the animation table.

The second word is a relative pointer from this header to the animation name table.

The third word is always 00 00 00 01?

 

The animation count is not specified and the animation and animation name tables are null-terminated.

 

These two tables also contain pointers relative to the starts of them. This is all of the data for the last animation, divided up into patterns that I saw, as I have no good way of explaining it and it's up to you to decide what it means:

 

06 00 0F 00 00 00 00 00 04 00 00 00

 

00 00 00 00

 

FA 3B 70 01 00 2C 47 7E 5B 64 11 3F 00 00 40 08

E4 0F 5F 00 EC E7 B0 35 00 00 20 0E 2E 34 90 04

F1 37 20 3C 74 54 50 03 00 C0 02 00 34 48 AF 3E

51 B7 01 08 00 12 0C 20 EB 37 40 00 22 B8 7F 06

 

04 00 00 00

 

E3 17 D1 01 FA 33 A7 78 82 A8 EF 3E 00 00 B0 06

DF 9B 9F 05 C2 93 50 39 00 00 50 0C 52 14 10 04

F9 37 BF 3B 76 2C 30 00 00 E8 02 00 3A 10 BF 3E

4D BF 11 0A 00 4C 0C 00 F2 27 60 3F 0A 90 8F 06

 

09 00 00 00

 

00 00 61 01 14 24 C7 6E 4D D4 EF 3D 00 00 50 09

D2 CF 8F 01 7F B3 C0 38 00 00 60 09 14 74 60 0C

DD 83 1F 3D 7D 24 60 00 00 94 02 00 36 D4 EF 3D

55 93 01 09 00 A4 0C 00 F2 5B 90 3F 18 A4 EF 05

 

0E 00 00 00

 

00 00 60 01 01 24 E7 65 4E D0 71 3F 00 00 A0 08

E3 EF CE 3E F8 EF C0 34 00 00 90 0E 25 3C B0 04

EF 77 40 3C 73 5C 10 04 00 B4 02 00 32 58 AF 3E

51 B3 81 07 00 2A 0C 20 E9 3B 80 00 28 C4 7F 06

[xdaniel]

Got as far as reading out the name table, as well as the animation data as you divided it up, although I haven't had any success with that 0x40 long block of data yet. I assume it's some kinda translation/rotation information - well, duh, I guess -, but I don't have any clue yet as of in what format it is, if it's per TMD object (doesn't seem likely?), or per whatever else, etc., etc. I'll give it another shot later today (meaning Friday, and during daytime that is) and release the viewer with source, regardless of animation support, on Saturday or Sunday.

 

I also, uh, acquired the game myself and can confirm that the other "*1.DTA" character models also work properly, that is to the same extend DEMON1.DTA does.

[Twili]

It's alright if animations aren't doable. I mainly wanted just to see the models themselves in their textured glory. I understand how frustrating it is when there's a feature that you want to implement that's just beyond your grasp. Looking forward to testing it myself. All of the DTA files have model data. The other numbers are alternate costumes.

[xdaniel]

Alright, I'll get to uploading the program and source later on today then. I'm guessing - because to me nothing else appears to make sense - our animation data is in, or is related to, the PSX's MIME animation system/method/format, which apparently modifies vertex coordinates instead of(?) having a skeletal hierarchy. I read about it in the SDK documentation last night, but don't fully understand it, or at least not yet. Still, no idea if I'll be able to implement that - if the data even is MIME format data - so I'll just release the whole thing as is, as mentioned.

[xdaniel]

http://magicstone.de/dzd/random/DTAViewer.rar - C#, uses OpenTK, archive contains binaries (use binReleaseDTAViewer.exe) and source. Neither GUI nor code itself are particularly clean, but what's there should at least work correctly.

 

[Twili]