In Japanese, this is like taking the key words, like nouns and verbs, out of a sentence and leaving only structure and grammar. This made the text half-readable: the kana was accurate but the kanji was wildly incorrect. It seems that while the single-byte definitions (the hiragana, katakana, numbers, symbols and some substrings) were the same across all versions, the double-byte definitions (kanji) had changed drastically. Unpointed A 0x3cacfe-0x3CAF12 (Std table)Īs previously mentioned, the text for most of the unpointed blocks was broken. Unpointed A 0x3bde36-0x3bde48 (Zeroes see notes) Unpointed C 0x3B254F-0x3B25F0 (Std table) Unpointed A 0x3B23DA-0x3B2314 (Std table) With our new definition of 'block' and the fact that the unpointed blocks are further divided by version, here's a proper layout of the text inside the Pre-release ROM: As newer revisions were shortened, the tail ends of previous versions remained on the development chips. The unpointed blocks of text work the same way. Lucca is waiting at the Fair.u at the Millennial Fair.nial Fair. In an effort to save space, the text is reduced even more in the next version, so the data looks like this now: The tail end of the previous version still remains. This new text is a bit shorter, so when it's written to the chip, the actual data is:Ĭrono, Lucca is waiting for you at the Millennial Fair.nial Fair. (using as the marker for the end of the string) The text goes through some revisions, and the next version, the line is changed to:Ĭrono, Lucca is waiting for you at the Millennial Fair. Let's say in our first version, we have a line reading:Ĭrono, you should go see your friend Lucca at the Millennial Fair. Let's use an imaginary line of text as an example. Each 'layer' of excess data is an artifact from a previous build written to the cartridge that, at one time, had a pointer table referencing down into what is now leftover data. When this process happens a few times and as the work-in-progress data changes, the excess data may form into 'layers,' like sediment, with the oldest version existing at the end, and newer (shorter) versions appearing before it. The data on the chips was overwritten and not wiped first, meaning if the new data was shorter than the previous data, the excess data remained. The developers would have used one or two test cartridges containing EEPROM chips that allowed the team to easily write the game code to the cartridge for testing on actual hardware. The reason for this leftover text still exists at all is due to the nature of how games were made during that era. Thus, unpointed data cannot be normally accessed by the code, as it has no way of being 'found.' It is essentially orphaned data. The game software uses the pointer table to find the memory address where the specified text string is stored. Unpointed text, part 1Īs its description implies, unpointed text is text that is not referenced by a pointer table. Since we are defining the offsets for the pointed data, this aligns with the layout of the unpointed data as well. If we define a block as a range of data beginning with a pointer table immediately followed by the text data it references, we can identify 7 blocks (laid out below). I'm not sure of the reasoning behind the 19 block layout of the Compendium text, but it too seems arbitrarily defined.Ī more logical system is to group blocks by the pointer tables that the game uses to reference each string of text. My offset ranges were chosen arbitrarily, looking for chunks of 0's and other anomalies in the hex view to delineate sections. However, the actual definition of a block is nebulous in both cases. My original research split this up into 23 blocks the more-accurate Pre-release translation on the Compendium breaks it up into 19 blocks. The dialogue spans offset 0x3B0242 to 0x3B1F3F. Defining a Blockīefore examining the leftover text, we need to better define what a 'block' of text is. That broken text has never been given a thorough examination, until recently when, on a whim, I picked up the project again and documented what I found. Unfortunately, the text was broken: the hiragana and katakana were readable but the kanji was wildly incorrect. While identifying the text blocks and dumping them, we found early on that there was leftover dialogue data from previous versions of the game. I never finished the translation or comparison, but thankfully the Chrono Compendium completed that project fantastically. I wanted to do a full translation and hoped to find exciting differences in the story. I was making it a project to dump all of the dialogue from this Demo version for comparison to the final. Eight years ago (!), we were starting to really dig into the Chrono Trigger Pre-release Demo ROM.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |