What's new
By:

Making an English version of Typing of the Dead Arcade

So I guess this is where a roadblock forms and requires outside help.

The textures cannot be dropped in-between games as the order, size or something changes between them which results in the corrupted textures due to loading invalid data. A glance at them looks as if they're compressed with zlib and then in some format that I haven't seen as some PC textures aren't compressed. Looking at other projects (HotD2 uses the same exact files unsurprisingly) nobody seems to have figured out how to decompress/modify/inject textures into the game. I asked a friend of mine to take a look as he has a lot of experience doing translations but he has never focused on Dreamcast and the format eluded him as well.

This doesn't address the text box issue however I'm uncertain if it's the binary that sets this up or what, I can't find the original JP pc version to compare with the US as I assume it'll have the same problems.

So really about all that can be improved on the patch currently is swapping green for red blood unless there's someone capable of figuring out the texture format. I've confirmed that it's the same format used across Naomi, Dreamcast and the original PC version. Subsequent PC releases in Japan (i.e 2004) look to probably use it but have a new custom archiving format which I don't have the patience to deal with and doesn't help with the text box issue anyways.

Lastly pol are models, cam are the on-rails camera, mot I believe are movies and there are event tables missing from extraction on Naomi which based off the hex appear to reside within ic22.
 
If we could source the Japanese PC version would that help?
sammargh said:
The textures cannot be dropped in-between games as the order, size or something changes between them which results in the corrupted textures due to loading invalid data.
Click to expand...
Have you been able to identify a texture that is identical between the PC and the NAOMI version (something that doesn't need translation) and compared the files to see what's different?
 
Mostly I wanted to see what all differs between the two and it would allow using pc debugging tools to figure out the text box issue.

Yes, textures match from naomi to dc and pc (ranking.bin as an example has the same md5 sum across all releases)
 
sammargh said:
Mostly I wanted to see what all differs between the two and it would allow using pc debugging tools to figure out the text box issue.
Click to expand...
I'll see if I can find a copy.


sammargh said:
textures match from naomi to dc and pc (ranking.bin as an example has the same md5 sum across all releases)
Click to expand...
So the textures that are the same match exactly but when you swap in the ones that are different you end up with a glitchy mess?
 
twistedsymphony said:
sammargh said:
Mostly I wanted to see what all differs between the two and it would allow using pc debugging tools to figure out the text box issue.
Click to expand...
I'll see if I can find a copy.

sammargh said:
textures match from naomi to dc and pc (ranking.bin as an example has the same md5 sum across all releases)
Click to expand...
So the textures that are the same match exactly but when you swap in the ones that are different you end up with a glitchy mess?
Click to expand...
Correct, it's likely due to changes in size of the texture from one platform to another resulting in the texture becoming unreadable. I.e if the game is expecting a 128x128 bitmap for a texture and receives a 172x128 image it will end up looking really broken once applied to the object.
 
The demo should suffice. I was actually able to work with a friend who located the decryption routine on the textures but I haven't had time to implement it yet... and then there's the actual texture format to figure out.

Appears this demo also has the blank text with English dictionaries so it should suffice to debug.
 
As I had figured the blank text box is a result of the binary itself and not any of the model/event/texture boxes. I'm not sure I'm capable enough with SH4 assembly to fix this.
 
sammargh said:
As I had figured the blank text box is a result of the binary itself and not any of the model/event/texture boxes. I'm not sure I'm capable enough with SH4 assembly to fix this.
Click to expand...
Which blank text box? The one over top of the word(s) that you're supposed to type at a given time?

Or the blank questions for the multiple choice section?
 
They're one in the same. So I started screwing around with the game a bit more and the JP dictionaries are different from the US however I haven't bothered to figure out the full format. In the JP version there's a catalog at top that has the start and stop positions for the phrase in the bubble followed bysome 4 byte ? and repeating. When you get down to the phrases you find they're in Shift-JIS and following is a weird custom alphabet table used internally for the translation to keycodes. I was able to see that there's wide font support and that the trailing set of codes is necessary but rewriting all the dictionaries will be painful, and there's needing to fix the wide font.
4H6IStOl.jpg

Oops that's not right...
PFI2wqBl.jpg
 
At least for posterity sake in the event someone pokes at this game again a little on the dictionary as it turns out the US uses the same format:
MJEUqSy.png


The dictionary is compromised of 2 parts, the TOC and then the phrase. The TOC is split into 4 byte chunks with three parts:
## 00 00 00 First number in hex is some time gauge used for the rating. I'm not really sure how it translates to real-world time but it is a hex representation of something. I didn't look much further into this .
## 00 00 00 This can actually fill up the entire block but this is where the hex offset in the file the phrase begins. Endian is swapped as well so 104 is 0x04 0x01
## 00 00 00 Again this can fill up the entire block and this is the hex offset where the key codes start and endianess is swapped like phrases
FF FF FF FF EOF

A phrase is setup as such:
PHRASE 00 FF KEYMAP 00 FF FF PHRASE 00 FF KEYMAP 00 FF FF etc, etc only the phrase offset is needed and the keymap is read automatically to the 00. The last phrase does not need FF FF appended

And here is a json array of the 4 formats which should make automating translating the US dictionaries rather painless.
Code: 
{ 
"shiftjis": [ "０","１","２","３","４","５","６","７","８","９","Ａ","Ｂ","Ｃ","Ｄ","Ｅ","Ｆ","Ｇ","Ｈ","Ｉ","Ｊ","Ｋ","Ｌ","Ｍ","Ｎ","Ｏ","Ｐ","Ｑ","Ｒ","Ｓ","Ｔ","Ｕ","Ｖ","Ｗ","Ｘ","Ｙ","Ｚ","ａ","ｂ","ｃ","ｄ","ｅ","ｆ","ｇ","ｈ","ｉ","ｊ","ｋ","ｌ","ｍ","ｎ","ｏ","ｐ","ｑ","ｒ","ｓ","ｔ","ｕ","ｖ","ｗ","ｘ","ｙ","ｚ","￥","。","、","？","！","＿","「","」","?","[","％","　","’","＄","＃","＠","．","，","−" ],
"shiftjishex": [ "824F","8250","8251","8252","8253","8254","8255","8256","8257","8258","8260","8261","8262","8263","8264","8265","8266","8267","8268","8269","826A","826B","826C","826D","826E","826F","8270","8271","8272","8273","8274","8275","8276","8277","8278","8279","8280","8281","8282","8283","8284","8285","8286","8287","8288","8289","828A","828B","828C","828D","828E","828F","8290","8291","8292","8293","8294","8295","8296","8297","8298","8299","829A","818F","8142","8141","8148","8149","8151","8175","8176","815B","8193","8140","8166","8190","8194","8197","8144","8143","817C" ],
"ascii": [ "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z","a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z","","","","","!","_","","","?","","%"," ","'","$","#","@",".",",","-" ],
"keycodes": [ "A1","A2","A3","A4","A5","A6","A7","A8","A9","AA","AB","AC","AD","AE","AF","B0","B1","B2","B3","B4","B5","B6","B7","B8","B9","BA","BB","BC","BB","BD","BE","BF","C0","C1","C2","C3","C4","C5","C6","C7","C8","C9","CA","CB","CC","CD","CE","CF","D0","D1","D2","D3","D4","D5","D6","D7","D8","D9","DA","DB","DC","DD","DE","DF","E0","E1","E2","E3","E4","E5","E6","E7","E8","E9","EA","EB","EC","ED","EE","EF","F0" ] 
}
 
Last edited:
Well got some bad news. Started playing with the font after work today and this approach isn't going to work. Each glyph is 0xA0 bytes long in font.bin and fairly straight forward in how they're made. Problem is the game expects each glyph to be 0xA0 bytes and does not have any height/width characteristics as 0x90 bytes are used to draw the glyph and it's hard coded.

This means either way to get english to show on the top of the typing box as well as questions assembly changes are required and I do not have the resources or capability to look into doing that. There may be an event table or something that actually sets up the layout however I don't really have time for that either.

If someone were to pick it up a friend helped me find the compression used and it looks to be lzss in fashion. The first byte of the file is trimmed and the rest passed to a function as a1 and a2 appears to be a dictionary. Pseudo-code from ida of the function looks like so:
C: 
int __cdecl sub_44FE40(unsigned int *a1, int a2)
{
  unsigned int *v2; // esi@1
  int v3; // edi@1
  __int16 v4; // ax@1
  char v5; // dl@2
  char v6; // cf@5
  int v7; // ecx@11
  int v8; // ecx@13
  char v9; // bl@13
  unsigned int v10; // ebx@13
  int v11; // ecx@14
  int v12; // ebx@15
  char v13; // dl@16
  unsigned int v14; // ebx@18
  char v15; // cl@19
  unsigned int v16; // ecx@20

  v2 = a1;
  v3 = a2;
  v4 = 0;
  while ( 1 )
  {
    while ( 1 )
    {
      --HIBYTE(v4);
      if ( SHIBYTE(v4) < 0 )
      {
        LOBYTE(v4) = *(_BYTE *)v2;
        v2 = (unsigned int *)((char *)v2 + 1);
        HIBYTE(v4) = 7;
      }
      v6 = v4 & 1;
      LOBYTE(v4) = (unsigned __int8)v4 >> 1;
      if ( !v6 )
        break;
      v5 = *(_BYTE *)v2;
      v2 = (unsigned int *)((char *)v2 + 1);
      *(_BYTE *)v3++ = v5;
    }
    --HIBYTE(v4);
    if ( SHIBYTE(v4) < 0 )
    {
      LOBYTE(v4) = *(_BYTE *)v2;
      v2 = (unsigned int *)((char *)v2 + 1);
      HIBYTE(v4) = 7;
    }
    v6 = v4 & 1;
    LOBYTE(v4) = (unsigned __int8)v4 >> 1;
    if ( !v6 )
    {
      --HIBYTE(v4);
      if ( SHIBYTE(v4) < 0 )
      {
        LOBYTE(v4) = *(_BYTE *)v2;
        v2 = (unsigned int *)((char *)v2 + 1);
        HIBYTE(v4) = 7;
      }
      v6 = v4 & 1;
      LOBYTE(v4) = (unsigned __int8)v4 >> 1;
      v7 = __RCL__(0, v6);
      --HIBYTE(v4);
      if ( SHIBYTE(v4) < 0 )
      {
        LOBYTE(v4) = *(_BYTE *)v2;
        v2 = (unsigned int *)((char *)v2 + 1);
        HIBYTE(v4) = 7;
      }
      v6 = v4 & 1;
      LOBYTE(v4) = (unsigned __int8)v4 >> 1;
      v8 = __RCL__(v7, v6);
      v9 = *(_BYTE *)v2;
      v2 = (unsigned int *)((char *)v2 + 1);
      v10 = *(_DWORD *)&v9 | 0xFFFFFF00;
      goto LABEL_14;
    }
    v14 = *(_WORD *)v2;
    v2 = (unsigned int *)((char *)v2 + 2);
    if ( !(_WORD)v14 )
      return v3 - a2;
    v15 = v14;
    v10 = (v14 >> 3) | 0xFFFFE000;
    v8 = v15 & 7;
    if ( !v8 )
    {
      v16 = *(_BYTE *)v2;
      v2 = (unsigned int *)((char *)v2 + 1);
      v11 = v16 + 1;
      goto LABEL_15;
    }
LABEL_14:
    v11 = v8 + 2;
LABEL_15:
    v12 = v3 + v10;
    do
    {
      v13 = *(_BYTE *)v12++;
      *(_BYTE *)v3++ = v13;
      --v11;
    }
    while ( v11 );
  }
}
 
(Sorry to get anyone excited by seeing this bumped-- I'm just reading up on the latest and a thought occurred to me...)

For the boss battle trivia questions, it seems like a 'not terrible' hack-around might be to just patch the check for the correct answer-- always take the 'right' answer branch?
 
sammargh said:
Sorry to revive such an old topic... The skinny of it is you will search the bin of the rom you want to use for "CD001" as they use ISO9660 filesystem just like Dreamcast does. You'll end up finding something that looks like this (note this was me still poking everything so ignore that I'm in ic1 YOU MUST USE THE NETBOOT .BIN FILE TO DO THIS):
Click to expand...
Thanks for sharing this! I found to be useful for something else I was looking at.
werejag said:
ive been tryin to replicate this iso crreation and i have yet to get it to work on other netboot games. is there something im doing wrong


before the cd001 there is from two other isos just 33 bytes of 00
Click to expand...
I went ahead and made a script to just extract everything that looks like an ISO9660 file system from and save it to a file, then run iso info on it. There are several "iso"'s that don't seem to conform to normal format in most of the NetBoot images. This is written in Ruby FWIW. (I'm currently not parsing out the number of sectors in the track)

View attachment romex.rb.txt - https://github.com/ArcadeHustle/Naomi_ISO_Extract.git

sammargh said:
It really depends on the game, I've seen a bunch that do not follow iso9660 and have some custom filesystem. In these if you plug ic1 into a hex editor you'll be greeted with the files and would have to figure the format to parse them out.
Click to expand...
I noticed the same, if you extract them all, and run isoinfo on them all, you can see some of these differences. Some have Joliet, some have RockRidge, some have neither.

dev0 RomBINS # for each in `ls */*.iso`; do echo $each:; isoinfo -l -i $each > $each.txt; echo ------------------------------------------; done | less
...
------------------------------------------
Naomi1/StreetFighterZero3Upper.bin2.iso:
CD-ROM is in ISO 9660 format
System id: SEGA SEGAKATANA
Volume id: STREET_FIGHTER_ZERO3
Volume set id: STREET_FIGHTER_ZERO3
Publisher id: CAPCOM CO.,LTD.
Data preparer id: RCMBLD VER.1.00
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 78765
isoinfo: Unable to find Joliet SVD
------------------------------------------
Chihiro/OR2_1gb.bin1.iso:
CD-ROM is in ISO 9660 format
System id: CRI ROFS
Volume id: SAMPLE_GAME_TITLE
Volume set id: SAMPLE_GAME_TITLE
Publisher id: PUBLISHER_NAME
Data preparer id: PUBLISHER_NAME
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 105496
isoinfo: Unable to find Joliet SVD

------------------------------------------
Naomi2/InitialDexp.bin2.iso:
CD-ROM is in ISO 9660 format
System id: SGI
Volume id: CDROM
Volume set id:
Publisher id:
Data preparer id:
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 94107
Joliet with UCS level 3 found
NO Rock Ridge present

--------------------------------------------
Naomi1/WaveRunnerGP.bin5.iso:
CD-ROM is in ISO 9660 format
System id: SEGA SEGAKATANA
Volume id: SAMPLE_GAME_TITLE
Volume set id: SAMPLE_GAME_TITLE
Publisher id: SEGA ENTERPRISES,LTD.
Data preparer id: RCMBLD VER.1.00
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 45773
isoinfo: Unable to find Joliet SVD

--------------------------------------------
Naomi1/TriggerHeartExelica_v6.bin4.iso:
CD-ROM is NOT in ISO 9660 format

------------------------------------------
Naomi1/TheTypingOfTheDead.bin3.iso:
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: CDROM
Volume set id:
Publisher id:
Data preparer id:
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 18552
isoinfo: Unable to find Joliet SVD

I've attached the directory listing of all the Typing of the Dead iso images contained within the netboot image (as extracted by the attached script).

I've also attached all other directory listings, some appear to be scrambled / encrypted / incorrect.

Example directory listings for Initial D & WWF are shown in the image below.
Untitled.jpeg
 

Attachments

You must log in or register to reply here.
Back
Top