Author Topic: CHRONO CROSS FILE EXPLORATION THREAD  (Read 64724 times)

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #285 on: December 18, 2007, 11:06:47 pm »
Ah, thanks again M. I'll say this, if the value 0xFFE0 points to the previous poly's third non-UV byte pair/pointer, I'd be very happy. It just so happens that two quads for Serge's belt buckle could fall into such a situation; they share a specific vertex I've been focusing on, but only one of the quads has a working pointer for that vertex. The other quad, which follows in the data, has the value 0xFFE0 for the corresponding pointer. You can see an illustration of this occurrence in the following pic:
http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

So poly #1's third byte pair, 68 09 or 0x0968, behaves very nicely as a pointer and the corresponding pointer on the next quad listed is 0xFFE0. Everything checks out as if 0xFFE0 does exactly what you say, and I'm going to do some tests to prove it 100%. I'll also look for the run of triangles; should be pretty easy to find. But I like your explanation, since it accounts for both a.) the need for a system with one byte pair per UV map coordinate; and b.) why there's so many ..FF byte pairs.

Every value that begins FF.. is negative when a byte pair is interpreted as a signed integer, correct? So the 0xFF58's I've been seeing could possibly point backward 168/8 = 21 positions within the non-UV data?

This is turning out to be the exact thing Sora had suggested earlier. Pointers to intermediate pointers that point into Section 1-3. We'll have to worry later about values that should behave as positive pointers yet don't seem to, but we'll get these special codes/backward pointers nailed down first. Thanks again MDenham! Boy, am I glad you walked in here!
« Last Edit: December 18, 2007, 11:08:44 pm by FaustWolf »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #286 on: December 18, 2007, 11:57:32 pm »
Ah, thanks again M. I'll say this, if the value 0xFFE0 points to the previous poly's third non-UV byte pair/pointer, I'd be very happy. It just so happens that two quads for Serge's belt buckle could fall into such a situation; they share a specific vertex I've been focusing on, but only one of the quads has a working pointer for that vertex. The other quad, which follows in the data, has the value 0xFFE0 for the corresponding pointer. You can see an illustration of this occurrence in the following pic:
http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

So poly #1's third byte pair, 68 09 or 0x0968, behaves very nicely as a pointer and the corresponding pointer on the next quad listed is 0xFFE0. Everything checks out as if 0xFFE0 does exactly what you say, and I'm going to do some tests to prove it 100%. I'll also look for the run of triangles; should be pretty easy to find. But I like your explanation, since it accounts for both a.) the need for a system with one byte pair per UV map coordinate; and b.) why there's so many ..FF byte pairs.

Not only that, but note the 0xFFC8 (-56) for poly 2, vertex 4, which happens to be (surprise, surprise) identical to poly 1, vertex 1...  seven entries earlier.  Aside from the bad habit Square seems to have had of making ridiculously long chains of 0xFFD0 on occasion (why not just make it a single pointer back?) it's looking like this may finally be what's going on with the negative values.

Quote
Every value that begins FF.. is negative when a byte pair is interpreted as a signed integer, correct? So the 0xFF58's I've been seeing could possibly point backward 168/8 = 21 positions within the non-UV data?
It's not just values that start with FF (I've seen an 0xFED0 in one of your hex dumps recently, for example) - it's any number 0x8000 or "larger".  What with the observation, if memory serves, that the largest-in-magnitude negative number for Serge is -496 (62 entries) I'd be amazed if we see anything of the form 0xFC??, though if any of the characters have a sufficiently complicated model, there might be some rare 0xFCF8s and such.

Incidentally, this is why 0xFFF8 doesn't seem to occur at all - this points to the preceding entry, and so it'd only appear as the first pointer of a polygon.  However, due to whatever orientation rule Square decided on for the polygons, they seem to have avoided sharing the first vertex of a polygon with the last vertex of the preceding one.

And yes, 0xFF58 is probably pointing backwards 21 positions - which happens to close the loop from, for example, your polygons 1, 2, 3, 4, 5, and B (B's 4th vertex is saying "use the vertex 21 earlier", which happens to be 1's 3rd vertex).

So here's an idea for what to do as a test on this:

For poly B (I would have said to change poly A; however, tracing its chain leads off the top of that hex dump :(), change its non-UV data to A0 08 60 08 B0 08 88 08.  Assuming things are working the way they seem to be, there should be no change in the appearance of the model.  However, if there's something else at work here, then something will change with poly B (possibly fairly dramatic).

Now to figure out what's going on with the "too large, but positive" pointers...

---

Edit: Thank god for Wikipedia as far as helping (somewhat) with my hunch as far as the "gobbledygook".  Can you check for all of the characters' models to see if any of them have this value larger than 0x04C11DB7 (which happens to be a pretty standard divisor for CRCs)?  I see that changing things doesn't end up crashing things without fail, which means that it may not be getting checked against, but it'd be nice to be able to pin down whether or not this is, in fact, a checksum.
« Last Edit: December 19, 2007, 12:10:09 am by MDenham »

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #287 on: December 19, 2007, 12:37:25 am »
M, you are correct with regards to the value 0xFFE0, which means you are correct about everything else as well, no doubt! Congrats on figuring this out!  :lee:

Here's irrefutable proof as to the nature of the negative pointers. It's a big pic though, so 56kers click at own risk.
http://img178.imageshack.us/img178/7420/ffe0provendq0.gif

Here's the rundown: I changed the 3D coordinates of the vertices beginning at addresses 0x28E8 and 0x3188 to make their locations obvious, then pointed the non-UV data for the shared coordinate of two belt buckle polygons to both vertices (i.e., the third byte pair for quad "1" in previous belt buckle pics was directed at 0x3188 and the third byte pair for quad "2" was directed at 0x28E8). Thus, two "prongs" stuck out from Serge's belt buckle in different directions. When I changed the third byte pair for quad "2" back to E0 FF (or 0xFFE0), only one prong stuck out from Serge's belt buckle toward the vertex controlled at address 0x28E8. Arrgh, the experimental design is difficult to communicate, but suffice it to say that M's right. :P

Yeah, Luminaire posted that -496 is the "largest" negative number for Serge's non-UV data. So I'd look for 0xFE10, correct? If we find that value works the same way, then we can assume that all negative pointers beteween 0xFE10 and 0xFFF0 work the same. We're getting there!

As for the "gobbledegook" data, I can tell you right off the bat that Kid's "gobbledegook" value is 0x040701D9, and Guile's is 0x049A034B -- but I'm cheating by looking at the wiki entry. I'll take a look at some of the other models later and see what they've got.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #288 on: December 19, 2007, 02:31:24 am »
Okay M, here's something we need to figure out. First, a range of hex code from Serge's Section 1-2:



I'm looking at the value 0xFE10 @ address 0x1832. Its value as a signed integer is -496, which means it should point back 62 spaces according to the scheme formulated earlier. That points it to address 0x1736 (if I counted right), which in turn points to address 0x1724. Problem is, the pointer at address 0x1724 does not refer to the same coordinate on the UV map as the non-UV data at 0x1832.

The UV texture coordinate referenced for address 0x1832 is (59, 8A). The UV texture coordinate referenced for both 0x1736 and 0x1724 is (7D, 9A) so those check out okay. But how to handle 0xFE10, I dunno. I can say that it is NOT a negative pointer into the vertex pool because that would point it to address 0x4058, which controls a vertex that has nothing to do with the texture being mapped to the polygon described by 0x1832.

Interestingly, address 0x1832 (pointer 0xFE10) shares the UV coordinate (59, 8A) with address 0x1820 (pointer 0xFE40). And in addition, the only other addresses that share (59, 8A) are waaay back in the 0x600 ~ 0x690 address range in Section 1-2, in with the triangle UV data! I'm starting to wonder if 0xFE10 points backward from the boundary between quads and triangles, which would be incredibly messy to tangle with.

It's becoming clear that we must tread lightly and carefully from this point forward with the pointers in Section 1-2. I'll try out your other suggestions tomorrow as a brief test to make sure other negative pointer values check out okay. Weird!
« Last Edit: December 19, 2007, 02:33:13 am by FaustWolf »

halkun

  • Architect of Kajar
  • Earthbound (+15)
  • *
  • Posts: 50
  • Ayumi Hamasaki Fanboy
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #289 on: December 19, 2007, 05:28:59 am »
I'm going to throw a lesson about polygon packing here. You may find this helpful.

I'm going to introduce you guys to a concept called "triangle strips" and "triangle fans". Now this might have nothing to do with the model, but clues indicate this might help you out. The reason why I think this might confuse matters is because triangle strips and fans were not supported under the PS1 GPU. (They were, however, supported under the PS2). That being said, triangle fans and strips can be managed in software to, and you still get some benefits out of it.

Triangle strips
When the PSX GPU draws a quad, it is actually drawing two triangles with shared corner vertexes. When the GPU goes into "quad drawing mode" it will allow both triangles be drawn in one pass, as opposed to "kicking" two separate GPU triangle commands down the pipeline. Now, the idea of a triangle strip is that you don't have to stop with two sets of triangles. All you have to do is add one more point and you have another triangle. If you add another point, you can make another triangle. It makes "packing" easier because you only have to define a single point past a quad to create another three-sided polygon.

Here's an example of a triangle strip.

Here, you define v0, v1, and v2 to make a triangle. Adding one more vertex, v3, makes a quad. What makes strips very efficient is all you have to do is add one more vertex, v4, and you have another triangle without having to define another three points! Do you need another triangle? All you have to do is add v4 and you have another object from a single point definition. Now, like I said, the PSX GPU doesn't do triangle strips, but this looks like some of your data descriptions. (Then again, I might be wrong.) Keep in mind, many 3D modeling applications with create triangle strips for you as a matter of convenience. Square might be taking advantage of this.

Triangle fans
Triangle fans follow the same idea, but one vertex works as a "center" and the other vertexes orbit about this center, creating a fan shape.

In this example, v0 is the center, with v1 and v2 creating the first triangle. In this mode, v4 uses v0 to create a new triangle. Now if you want to make a new polygon, just add a single vertex.

These lookup tables look "stripish" in their construction. I might be wrong, but at least you guys learned something....
« Last Edit: December 19, 2007, 05:35:15 am by halkun »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #290 on: December 19, 2007, 09:53:02 am »
These lookup tables look "stripish" in their construction. I might be wrong, but at least you guys learned something....
They don't just look it - they are, though the idea of a "quad strip" is still a little awkward to handle (more in the whole sense of "yeesh, that's a lot of looking things up" than anything :D).

---

Okay M, here's something we need to figure out. First, a range of hex code from Serge's Section 1-2:



I'm looking at the value 0xFE10 @ address 0x1832. Its value as a signed integer is -496, which means it should point back 62 spaces according to the scheme formulated earlier. That points it to address 0x1736 (if I counted right), which in turn points to address 0x1724. Problem is, the pointer at address 0x1724 does not refer to the same coordinate on the UV map as the non-UV data at 0x1832.

The UV texture coordinate referenced for address 0x1832 is (59, 8A). The UV texture coordinate referenced for both 0x1736 and 0x1724 is (7D, 9A) so those check out okay. But how to handle 0xFE10, I dunno. I can say that it is NOT a negative pointer into the vertex pool because that would point it to address 0x4058, which controls a vertex that has nothing to do with the texture being mapped to the polygon described by 0x1832.

Interestingly, address 0x1832 (pointer 0xFE10) shares the UV coordinate (59, 8A) with address 0x1820 (pointer 0xFE40). And in addition, the only other addresses that share (59, 8A) are waaay back in the 0x600 ~ 0x690 address range in Section 1-2, in with the triangle UV data! I'm starting to wonder if 0xFE10 points backward from the boundary between quads and triangles, which would be incredibly messy to tangle with.
Also, 0x1820 ends up pointing back to 0x1740...  which is wanting the vertex at 0x1200 into the pool (0x3AE8, I believe?).  I don't think this is right either, so it wouldn't surprise me if one of the "unknown" values in the header controls where the transition between "check backwards in the quads table" and "check in some direction in the triangles table" is.

However, just because it doesn't refer to the same point in the UV map doesn't mean that the current model isn't still correct.  While most of the texture is contiguous for specific portions of the model, there are still spots where you go from, say, the top of the foot into his pants, and those are in two different parts of the texture.  Keep that in mind here and check that just in case, because I suspect that it probably is a transition between "sections" of Serge (as far as his texture goes).

Anyway, I've gotta run for work here.  I'll be back to check in on any new developments in about ten hours. :D

Sora

  • Chronopolitan (+300)
  • *
  • Posts: 362
  • The Terror Of Death
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #291 on: December 19, 2007, 01:18:43 pm »
glad to see we're winning again ^.^
DR.Faust always knows whats going down.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #292 on: December 19, 2007, 02:00:36 pm »
Yeah, we're really kicking ass, but it's all thanks to the knowledge everyone's bringing to the table here. If we can get these pointers nailed down and find the bone information, I think that may be all we need to do some rudimentary viewing of the models. I would assume the models exist in a frozen battle pose in their "natural" state, without animation data being applied to them -- I think that's how FF7 worked anyway, judging from the FF7 models I've seen with Mirex's viewing tools.

Halkun, major thanks for taking the time out to illustrate the triangle strips and fans. It certainly seems we've found quad strips, and I imagine if I mapped out some triangles on Serge's texture according to the data they'd be arranged the same way, or similarly. If the PSX GPU doesn't do such things, the model editing program the Squeenies used certainly did -- I wonder how much it would help if we knew which model editing program these were created in?

The next step is figuring out what these pointers are pointing to, exactly. And MDenham, I don't have a pic on hand at the moment, but there certainly is a texture boundary being crossed in the data I posted above. The pointer at address 0x1832 is referring to a vertex on the side of Serge's shoe from what I can tell, and the ones at addresess 0x1724 and 0x1736 refer to Serge's leg. The value 0x07E8 at address 0x1724 definitely works as a positive pointer into the vertex pool, because changing the coordinates of the vertex it's pointing to causes a texture spike from the area being mapped on the texture.

- - - - -

Okay, this evening's first experimental results are in. I did a test MDenham suggested earlier -- going back to the almighty "shoe" and changing Quad B's pointers (which are the negative kind we've been examining recently) to the values we believe they would point to based on the scheme M developed. The results are 50% successful, with some oddities hindering our full understanding of the pointers.

First, the code that's applicable here:


We're focusing on the data for Quad B. Its original pointer byte pairs are thus: D0FF  B0FE  E8FF  58FF

Let's trace where they go (or where they should go) one by one...

0xFFD0 = -48, /8 = 6 positions back in the non-UV data. That brings us to address 0x1934, which in turn leads us an additional three positions back to address  0x1926.

0xFEB0 = -336, /8 = 42 positions back. That leads us to...address 0x18A6 if I'm counting right.

0xFFE8 = -24, /8 = an easy 3 positions backward to address 0x1946.

0xFF58 = -168, /8 = 21 positions backward to address 0x1904.

Thus, reading by our current scheme, Quad B's pointer byte pairs should be equivalent to: A008 6008 B008 8808

If we're reading the pointers correctly, then changing Quad B's pointers to these byte pairs should have no effect on the model -- those values should be the actual pointers into the vertex pool.

Now let's try altering the last two byte pairs so Quad B's non-UV data becomes D0FF B0FE B008 8808. So far, so good -- no change:
http://img263.imageshack.us/img263/4103/lasttwopterschangedwu2.gif

That means we're reading the byte pairs E8 FF and 58 FF correctly.

Now let's try the first two byte pairs as well, so that Quad B's non-UV data is A008 6008 B008 8808:
http://img263.imageshack.us/img263/1993/allpterschangedvi1.gif

If you look closely, there's a bit of a graphical hiccup, a very thin texture stretch from Serge's sock. That means we're just slightly off. At first I thought something weird might be up with the value 0xFEB0, so I switched the second byte pair back to B0FE. But now things are even worse:
http://img263.imageshack.us/img263/8769/firstpterchangedox2.gif

This means that the first pointer value, 0xD0FF, isn't being read correctly, since it's the only one that could be causing a problem if the second byte pair is switched to its original state. So I figure, "okay, the problem is with the first pointer value." Yet switching only the second pointer is still problematic:
http://img263.imageshack.us/img263/7586/secondpterchangedyy6.gif

So I believe we're interpreting the values 0xFFE8 and 0xFF58 correctly, but something weird's up with our interpretation of 0xFEB0 and 0xFFD0. I wish it were my counting that was off -- let me know if that's the case, anybody, and I'll be a happier camper than I am right now. But as things stand, the interpretation of these as negative integers with division by 8 giving us the number of positions backward doesn't capture the full picture.

Discuss.


« Last Edit: December 19, 2007, 10:10:15 pm by FaustWolf »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #293 on: December 19, 2007, 10:42:18 pm »
So I believe we're interpreting the values 0xFFE8 and 0xFF58 correctly, but something weird's up with our interpretation of 0xFEB0 and 0xFFD0. I wish it were my counting that was off -- let me know if that's the case, anybody, and I'll be a happier camper than I am right now. But as things stand, the interpretation of these as negative integers with division by 8 giving us the number of positions backward doesn't capture the full picture.

Discuss.
That is bizarre.  Near as I can tell, the only real assumption that can be made is that negative pointers that end in 8 ("odd" pointers) are correct, while negative "pointers" ending in 0 ("even" pointers) have something else entirely going on with them, although I'm not sure what.  (I do notice that the first and second vertices of every poly, when they have a reference, are 0x???0 invariably, while the third and fourth vertices, as references, are 0x???8.)

B's first two vertices should be pointing at the last two vertices of the poly at 0x18E8, by the way.  I was going to chalk that up to these being divided by 16 instead of 8, but this puts both of B's first two vertices as the fourth vertex of 0x18E8, in addition to other weirdness with other vertices, so it's not that simple.  It is, at least, obvious that for references, that last digit controls the behavior of how it looks up the reference.

On a related note with strange values, I'm thinking there's a limit of 1024 vertices per model, which means anything between 0x2000 and 0x7FFF needs to have the top two bits separated out.  (Not sure what purpose, if any, those two serve, but it's something to check at this point.)  Confirmation for this requires either finding a vertex pointer of, say, 0x2??? and changing it to 0x0???, and seeing what effect, if any, results.

Finally, is there any chance that someone has a complete disassembly (the original source is a bit much to hope for, :D - I'll make do with semi-cryptic opcodes and no real names for procedures and variables) of the program itself for Chrono Cross?  I'd like to try and pin down where the battle model loader is and see what all we're missing as far as odd behavior (such as why "even"/"odd" references are treated differently; what, if any, purpose bits 13 and 14 serve for vertex addresses; and how it determines where to change between triangles and quads).

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #294 on: December 19, 2007, 11:07:44 pm »
Well, I can say that 0xFFE0 has been interpreted correctly under your scheme as well, M. The experiment conducted in this post lends credence to the division-by-eight rule, I believe:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg85654.html#msg85654

But I'm going to take another look at my latest experiment based on what you've just said. It might lead to something.

Do you have a hex editor and disassembler handy at all, M? There's some ASCII signatures in Cross' executable that may be of some interest to you. PS2Dis seems to work fairly well as a disassembler even for PS1 executables (I assume the program itself is for PS2 though). I think PS2Dis might even preserve the ASCII signatures that correspond to loaders, so maybe a hex editor wouldn't even be necessary. If you're interested, I can post some screenies of the executable in PS2Dis and my hex editor so you can see if the info shown in these might help. PS2Dis should be available freely for download somewhere -- I'll check up on where they're hosted and post those addresses here if you'd like.

- - - - -

Here's an example of what PS2Dis shows. Looks like it recognizes some basic commands:
http://img255.imageshack.us/img255/7156/ps2disxm0.gif

Anyone know what PutDrawEnv and the like are, exactly? Could these help in any way?
« Last Edit: December 19, 2007, 11:20:55 pm by FaustWolf »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #295 on: December 19, 2007, 11:27:20 pm »
Do you have a hex editor and disassembler handy at all, M? There's some ASCII signatures in Cross' executable that may be of some interest to you. PS2Dis seems to work fairly well as a disassembler even for PS1 executables (I assume the program itself is for PS2 though). I think PS2Dis might even preserve the ASCII signatures that correspond to loaders, so maybe a hex editor wouldn't even be necessary. If you're interested, I can post some screenies of the executable in PS2Dis and my hex editor so you can see if the info shown in these might help. PS2Dis should be available freely for download somewhere -- I'll check up on where they're hosted and post those addresses here if you'd like.
As far as a hex editor, just grabbed a copy of XVI32 to use, so that's one major shortcoming in my toolkit addressed. :D  Also found PS2Dis's homepage, so I'm taking a crack at things.  The executable is SLUS_010.41, right?

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #296 on: December 19, 2007, 11:31:40 pm »
Yup, that's what I'm looking at. I know absolutely zip when it comes to assembly language (I think it has something to do with shifting bits  :lol:), so I'm very interested in what you'd find. I'm not sure if it comes in the default install, but make sure you get the PS1 Linker Address Map, because I think it's required to do an "Invoke Analyzer." Not sure about that, though.

ZeaLitY

  • Entity
  • End of Timer (+10000)
  • *
  • Posts: 10795
  • Spring Breeze Dancin'
    • View Profile
    • My Compendium Staff Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #297 on: December 19, 2007, 11:47:45 pm »
Just in case, the Chrono Cross demo's executable is out in plain sight. I imagine the basic rendering engine was done by then, so in case analyzing it can help:

http://chronofan.com/Black/Cross/KID.EXE

That might be the total opposite of what you're looking for, though.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #298 on: December 19, 2007, 11:53:33 pm »
Hmm, it's way bigger than the SLUS executable of the final version. I'll toss it into PS2Dis just for the heck of it and see what's in KID.exe...

Zeality, was Cross the only playable demo on the disc you ripped this from? Judging by the name, it should only apply to the Cross demo if there was more than one. Thanks for providing it again!

BTW M, everything looks like it works out fine if I interpret 0xFFD0 and 0xFEB0 as being divisible by 16 and not 8. What's the best rule of thumb to use, do you think? Because 0xFFE0 works best when interpreted as being divisible by 8...

- - - -

PS2Dis is telling me things like "Bad sjis code" and "Bad hankaku code" as I scroll through KID.exe. SJIS refers to Japanese script, is that right? Anyone know what Hankaku means by any chance? If there's any clues in KID.exe, looks like they might all be in Japanese.

- - - - -

Nah, I see OTag references in KID.exe too, just like in the SLUS executable. Interesting. M, what Zeality posted is probably worth a look too, from what I can tell. I wonder why KID.exe is so much larger than the final SLUS?
« Last Edit: December 20, 2007, 12:01:29 am by FaustWolf »

ZeaLitY

  • Entity
  • End of Timer (+10000)
  • *
  • Posts: 10795
  • Spring Breeze Dancin'
    • View Profile
    • My Compendium Staff Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #299 on: December 20, 2007, 12:05:49 am »
The other demos / trailers were kept in different folders. Cross had one all to its own, with KID.EXE, CRONO.HED, END.DAT, CROCRO.IMG (the actual game data; 101 MB), and TITLE.XAM, BLOOD.XAM, and TIDAL.XAM. For whatever reason, the last three refuse to copy off the disc onto my hard drive. "Invalid MS-DOS function."