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.

Topics - Griever

Pages: [1]
ROM Hacking Discussion / Golden Sun text compression
« on: October 28, 2014, 02:39:15 pm »
Hello, I'm digging into different text compressions and found one in Golden Sun for GBA is quite interesting.
Sure, I know about Labmaster's doc and tool, but unpacking routine was just rewrited atop on asm code, and I'm trying to get the idea of compression.
Here's graph of 1 character decode. That's all pretty complicated but the part I don't understand is this one.
Hard to explain, but I'll try.
The function receives previously decoded char code. Each of this chars has some kind of path in recursive tree (which I wanted to discuss here), so actual source text bitstream just decides either to parse tree one round or emit char.
Before each tree there's codes of characters, which can be put after this previously decoded char. So one tree parse returns offset-back to appropriate character. Source text bitstream just decides if you need to parse one more time and increase this offset-back.
Now for path in tree: if you go right (1), you get out of parsing, if you get left(0), you go into recursive tree, so you'll have to meet more 1s to get out of parsing and so on. At the end of parsing you have to count how much 1's did you get  and that will be offset-back.
Source bitstream can also skip some bits from the beginning of this tree path, so you can set a root in any place of this path, thus changing result offset-back.

For me all this path in recursive tree storage is overcomplicated and unoptimal (not saying, I don't understand it at all). But I'm sure there should be some simple explanation how this scheme works.
Maybe it's modification of well known algorithms or someone has seen this kind of tree in previous?

Personal Projects / VBA-SDL-H bugfix
« on: September 25, 2014, 07:05:56 am »
So I was summing up information for GBA debugging emulators and found, that VBA-SDL-H is the only opensource and free option for honest romhackers. Please correct me if I'm wrong.
Looks like Labmaster doesn't care about it anymore, in fact sources are hard to find nowadays. There's also a VBA-SDL-H2 available at poke community, which has some additional functions.
Anyhow, there's a bug in 'dsave' command: both address and size are read from the same command argument.
Code: [Select]
void debuggerDumpSave(int n, char** args)
  u32 address;
  u32 size;
  char *file;
  FILE *f;

  if (n==4){
    if (!dexp_eval(args[2], &address)){
      printf("Invalid expression in address.\n");
    if (!dexp_eval(args[2], &size)){//should be args[3]
      printf("Invalid expression in size");

      printf("Error opening file.\n");

    for(u32 i = 0; i < size; i++) {
      fputc(debuggerReadByte(address), f);

  } else
The same bug passed to VBA-SDL-H2.
I wanted to update VBA-SDL-H2 code, compile emulator and release it at github and here, but I'm quite new at community policies and regulations. Is this appropriate? Won't that offense rights of Labmaster, poke-community or VBA programmers?

For me Kruptar - is the best utility for text. Not only because it's like Atlas/Cartographer in nice GUI pack. It's just more flexible, powerfull and user-extendible.
Still it's strangely not so popular here, so I've made a small document for those, who interested, which explains in short what is Kruptar, how it works and how to write fully functional plugins for that tool, using C and MinGW.
Questions and recommendations on improvement are very welcome.
Added code for Langrisser scheme: string starts with 3 ID bytes, which should be passed to script at editable form and each line should have odd length, so plugin also must make alignment of string.

ROM Hacking Discussion / [psx] Einhander Virtual File System
« on: January 24, 2011, 12:18:30 pm »
Good day, everyone!
I can't figure out Einhander's virtual file system. The game has one BININDEX.BIN and a few BINPACK0.BIN, BINPACK1.BIN, BINPACK2.BIN etc. BINPACKs have raw data in them and sector aligned.
Sure it looks like BININDEX is a header file with offsets of end files in it, but here, what I've learned:
1) BININDEX is sector aligned and has a few sections inside itself. There are no filenames in it - guess it's ok for some PSX games
2) Offset 0x2C in BININDEX is an end_file offset in sectors from the beginning of BINPACK0.BIN (offset is equal to 0x01BF). 0x2C is loaded from executable itself and there are no continuum data in the neighbourhood in sys.exe
3) I've corrupted data 0-0x20 in BININDEX and it didn't affect the game, also they are not readed. So all these meaning bytes are actually not used!
My guess is that this game does not have any VFS: just a file BININDEX with offsets, which are placed in random pattern and they are loaded in each time by appropriate code.
Can it be right, or I'd mistaken somewhere?

Pages: [1]