News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - CUE

Pages: 1 2 3 [4] 5
61
Quote from: Auryn
If you are using a program somebody made for you, you should give him credits everytime you mention him.
This would be a good motive to not help you and show that you just reached this point by good luck.
Anyway, I believe the guy that made the program was Pleonex and because he is a good friend, take my help as a birthday present (was last wednesday).

Took me longer to make the screenshots as to find those pointers!
PS: I was wondering why you can't edit the graphics.
I'm the guy, not Pleonex.
I have the structure of the 5 files ('sysmes.dat' too), in spanish (see below). The "hard" part is updating the control bytes if you do not know how they are organized​. The rest is very simple and easy.

Quote from: mister seta 123
CUE: Okay, I'm  a idiot.  :( Take my virginity if you want.
Ok, I'll remember. Tonight, for example? ;D >:D ;D

I have no time now, you should wait until summer. I'm busy with some tools/translations (as you know, as always). I'm updatin RHDN with some of these old tools (and more soon).

File structure:
Spoiler:
--------------------------------------------------------------------------------
cabecera + datos + punteros + bytes de control

cabecera (4x4)
- SIR0
- offset1
- offset2
- 0

los datos van seguidos, con un 0-byte como terminador, sin alinear
el final del bloque se alinea a 4 bytes, rellenando con 0xAA

los punteros van seguidos, con un 0-int como terminador, sin alinear
el final del bloque se alinea a 16 bytes, rellenando con 0xAA

en offset2 están los datos de control, de la forma usual, dependiendo de cómo estén los datos anteriores
--------------------------------------------------------------------------------
camera.dat

en offset1, por cada entrada:
- offset a los datos, hasta que sea 0
- offset a los punteros
después del cero final:
- offset 1
--------------------------------------------------------------------------------
chara.dat

en offset1, por cada entrada:
- offset a los datos, hasta que sea 0
(si el offset es menor que el anterior es un ID)
después del cero final:
- offset 1
- 0
--------------------------------------------------------------------------------
file.dat

en offset 1:
- offset a "$nombre", hasta que sea 0
- offset a "dato"
- offset a "nombre"
- offset a los punteros
después del cero final:
- offset 1
--------------------------------------------------------------------------------
staff.dat

como camera.dat
--------------------------------------------------------------------------------
sysmes.dat

en offset 1:
- offset a "nombre", hasta que sea 0
- offset a ?1 ¿coordenadas de algo?
- offset a ?2
- offset a ?3
- offset a ?4
- offset a los punteros
después del cero final:
- offset 1
--------------------------------------------------------------------------------

62
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 27, 2012, 01:12:40 pm »
The text starts at an odd offset and Windhex needs an even offset to display correctly all. I think that's the problem.

63
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 24, 2012, 04:58:52 am »
Using my ASCII table, NOT THE UTF8 TABLE, 99% similar as other sjis tables, and using the same offset in the ISO (*) ---> no problems found:


(*) Bad idea. It's better to work with the extracted files.

64
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 23, 2012, 12:01:34 pm »
Please show your table. And post an offset with japanese texts.

ぁ=9F ---> or 829F?
あ=A0 ---> or 82A0?

Try with "cp932-ascii.tbl" from this package: http://www.fileden.com/files/2010/5/7/2851431/CUE.rar

The game font:
Code: [Select]
file .......... SYSTEM.DAT
offset ........ 0x00083C
tile width .... 8 (found in 0x000834, 2 bytes low endian)
tile heigth ... 14 (found in 0x000836, 2 bytes low endian)
bpp ........... 2
tiles ......... 1872
size .......... 0xCCC0 (found in 0x000838, 4 bytes low endian)
                (tiles * width * heigth * 8 / bpp)

65
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 23, 2012, 05:14:26 am »
Tha game uses Shift-JIS codes? Are you sure?
Find the font to know what characters are used.

66
But ECCRegen only recalculate the EDC/ECC, and not update the TOC when the modified file has a different number of sectors. It's the same problem with CD-Mage.

67
These games use MODE2/FORM2 tracks, same as PSX. I can't replace the files because I don't know how to assign values  to the byte CODING_INFO (sector byte 0x013) without check the MPEG/AUDIO file. The tool never checks the files, just replace.

68
No, sorry. I'm full with other projects.  :(

What system uses CD games with 2 data tracks?

69
CUE, did you get my PMs? I sent 2 but they're not showing up in my sent box.
Yes.

I'm working in a tool to replace files in a MODE0/MODE1 CD image, similar as PSX-MODE2:


MODE0 is finished. I think the next week will be totally finished.

March 17, 2012, 04:50:55 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Tool added: http://www.romhacking.net/utilities/852/

To change the cuesheet file:
- get the file LBA (file "CDDA1" in Grandia Digital Museum)
- convert to minutes/seconds/fractions
- change the values in the file (".cue" extension)

Example:
Code: [Select]
CDDA1 LBA = 193769
min = lba / (60 * 75) = 43;  // integer division
mod = lba % (60 * 75) = 269; // remainder division
sec = mod / 75 = 3;          // integer division
fra = mod % 75 = 44;         // remainder division

Edit the cuesheet file and change INDEX 01 with the new min/sec/fra values ("isoname" is the cd image name):
Code: [Select]
FILE "isoname" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 01 43:03:44

70
Hmmmm, I have the game in ISO/MP3 format (ISO for the data track, MP3 for the music track) and  I expanded FIELD\TEXT2.BIN from 26192 bytes (0x6650) to 26624 bytes (0x6800) to fill the latest sector with random data. I replaced the file into the ISO and the game run fine in SSF Ver0.12 beta R3. Now I need finish the tool to allow replace a file with other of any size.

The EDC (Error Detection Code) is a sector CRC checksum to check if the sector data is corrupt. The ECC( Error Correction Code) is used to correct the corrupt data.

71
Quote from: MrFwibbles
How do you conclude that KERNEL.BIN is the next file? ...
YAMADA.BIN - Start at sector 614, size=80 -> 80 / 2048 = 0.04 -> rounded = 1 sector -> 614 + 1 = 615 is the next sector (LBA)
WINDOW.BIN - Start at sector 615, size=13900 -> 13900/2048=6.78 -> rounded = 7 sectors -> 615 + 7 = 622 is the next sector (LBA)
...

Max filesize in the same "space": round(SIZE/2048) * 2048 ('2048' is the sector size, 0x800):
- for YAMAHA.BIN -> round(80//2048) * 2048 = 1 * 2048 = 2048 bytes
- for WINDOW.BIN -> round(13900//2048) * 2048 = 7 * 2048 = 14336 bytes

Quote from: MrFwibbles
...After saving, recompiling and mounting the ISO, ...
How do you do?
All others files are in the same position (LBA)? Check the file "CDDA1" in the root, a CD DA file pointing to the music track. The game can crash if this LBA is modified.

Can you convert your MODE1 ISO in a MODE0 ISO with the music track in another file (MP3/WAV format)? I have a tool to modify a MODE0 image with modified files, even changing the number of sectors occupied.


~~~ ADDED ~~~
- for E800.MDT -> round(0x7B000/2048) * 2048 = 246 * 2048 = 0x7B000 bytes, the file has the max space allowed, you can't add more bytes !!!

72
ROM Hacking Discussion / Re: Densetsu no Stafi - Font Question
« on: March 08, 2012, 07:45:02 am »
I used an old (and unfinished) tool to convert a binary file into a graphic file (only 1-2-4-8 bpp) with a monochrome palette.

73
ROM Hacking Discussion / Re: Densetsu no Stafi - Font Question
« on: March 07, 2012, 10:29:39 pm »
The font isn't compressed:
- rom offset = 0x0032A2FC
- total tiles = 0x100
- tile width = 0x0C (*)
- tile height = 0x10
- resolution = 2bpp reverse

(*) This is the 'problem': most of the graphic tools only work with tile width multiple of 8bits

The font extracted (with 16 tiles/row, but really is 1 tile/row):


The font extracted with borders:


Code: [Select]
1 row -> 12 bits @ 2bpp reversed -> 24 bits reversed =-> 3 bytes reversed
2bpp -> 1 row = 3 bytes, b1-b2-b3

for (tile = 0; tile < 0x100; tile++) {
  for (height = 0; height < 0x10; height++) {
    get 3 bytes
      a1, a2, a3
    reverse each byte (bits 76543210 -> bits 54761032)
      n = ((n & 0xC0) >> 6) | ((n & 0x30) >> 2) | ((n & 0x0C) << 2) | ((n & 0x03) << 6)
    each 2 bits is a pixel (3 bytes = 24 bits -> 24/2 = 12 pixels width)
  }
}

74
Newcomer's Board / Re: What are these PS2 .DAT files ?
« on: February 26, 2012, 02:07:37 pm »
Files are compressed and packed (same structure in PSG1 and PSG2).

The compression is a LZ Renau.

Code: [Select]
/*------------------------------------------------------------------------------
 DAT file structure:
 - header
   + 4 bytes: number of files, low endian
   + for each file
     - 4 bytes: LBA, low endian
   + fill
     - aligned to 0x800 bytes, padded with 0x00
 - data
   + X bytes: encoded data
   + fill
     - aligned to 0x800 bytes, padded with 0x00
------------------------------------------------------------------------------*/

Code: [Select]
/*------------------------------------------------------------------------------
 LZR file structure:
 - header
   + 2 bytes: signature, always "CM"
   + 4 bytes: decoded length, low endian
   + 4 bytes: encoded data length, low endian
 - data
   + X bytes: encoded data
   + Y bytes: flags
 - fill
   + aligned to 0x800 bytes, padded with 0x00

 'flag' data, 8 bits, right to left:
 - 0: uncompressed data, copy 1 byte to 'target'
 - 1: compressed data, copy 'length+3' bytes from 'target-offset-1' to 'target'
      + 12-bits offset, bits 0-11
      + 4-bits length, bits 12-15
------------------------------------------------------------------------------*/

75
Programming / Re: Any idea what this SLZ algorithm is?
« on: February 05, 2012, 03:19:19 am »
Are you unpacking the PSX or PS2 games?

76
Programming / Re: Any idea what this SLZ algorithm is?
« on: February 04, 2012, 01:00:58 pm »
Is normal, you can use different offsets.

An example:

To encode "00-00-00", with previous data = "00-00-00-01-00-00-00-02-$" (the current position is '$'), you can use:
- get 3 bytes from $-8
- get 3 bytes from $-4

The 2-bytes chunk that indicate the compression of these data are different.

77
Newcomer's Board / Re: Unpacking an NDS .pak archive?
« on: January 23, 2012, 04:50:24 am »
Header:
- 4 bytes <- number of files
For each entry:
- 4 bytes <- unknown, maybe a checksum or hash
- 4 bytes <- file offset (aligned to 4 bytes)
- 4 bytes <- file length unpacked/uncompressed
- 4 bytes <- number of file parts

Each file has a header with offsets to each part (the last offset is the offset to the next file) and the data packed or compressed (no idea).

78
ROM Hacking Discussion / Re: Phantasy Star Generation 2 tryout.
« on: January 23, 2012, 02:46:25 pm »
I had not seen this post. I have some tools for Phantasy Star Generation 1 & 2 PS2, some unfinished.

Quote from: RedSun
1)Is there any way to expand/reconstruct iso to insert uncompressed(~1.5 bigger than original compressed) text ?
Why? You can replace the original compressed files with the new compressed files.

Quote from: RedSun
2)Is there any way to make the game read half-width letters ? (shows "-" instead)
Yes. All you need is modify the original font file to add the missing characters ('J', 'Q', 'Y', 'j', 'q', 'w', 'x', 'z').



79
Newcomer's Board / Re: Metroid 2 text hack
« on: November 26, 2011, 05:22:14 am »
All you need to translate the game:

1-ASCII texts:
1B920: credits (in ASCII, F1=new line, F0=end)

2-Normal texts (you need a table, a=0x50, b=0x51, ..., space=0xFF, only lowercase chars):
03711: "game over"
03B24: "game saved"
03B94: "game cleared"

3-Normal texts (you need another table, a=0xC0, b=0xC1, ..., space=0xFF, only lowercase chars):
05912: "save.."
05922: "    plasma beam "
05932: "     ice beam   "
05942: "    wave beam   "
05952: "     spazer     "
05962: "       bomb     "
05972: "   screw attack "
05982: "     varia      "
05992: "high jump boots "
059A2: "    space jump  "
059B2: "   spider ball  "
059C2: "  spring ball   "
059D2: "   energy tank  "
059E2: "   missile tank "
059F2: "      energy    "
05A02: "     missiles   "
14105: "save.."

4-Special texts (you need use the table 3 too):
04095: "completed"
040BA: "presstart"
(you need get 1 character each 4 bytes, and the 4th byte is the horizontal position in pixels)

5-You need translate 3 graphics:
15F34: "RETURN OF SAMUS", "START", "CLEAR", font)
18300: some chars ("E", "L")
1F670: some chars ("P", "I", "W", "S")
("The End" graphic is not included)
(offsets used with Tile Molester)

Enjoy :)

80
SunnyGuy, you haven't chosen a good game to translate.

What do you need?
(1).- first to all, some tool to unpack/pack the ISO (GCRebuilder or GC-Tool, google is your friend)
(2).- now you can decompress the 4500+ files extracted from each ISO (all files named 'FILE_nnnnnnnn', where 'nnnnnnnn' is a hexadecimal number)
(3).- finally, it's time to check the files to search the fonts, graphics and scripts to translate

(1) & (3) are really easy, but there is no public tools to decompress the files (the compressions used are LZSS and Arithmetic).

"Baten Kaitos Origin" has the same file structure, with a single file with all the scripts and is the same file on each disk (there is a spanish translation in progress, and a french translation soon).

Pages: 1 2 3 [4] 5