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 - devdri

Pages: [1]
I remember once finding the text routine (in original non-dx), but I don't have it in my notes. Everything in the game runs on counters, that are incremented each frame. Then at say, 10th frame the counter is reset and the next character is copied to the spritesheet. It's probably not that hard to change once you find the right 'update' routine (I expect that text is just another type of object like enemies, but don't remember for sure). I could find the object id in debugger once I have a bit more free time. With the id just look up the address in a giant jump table and you get the right routine.

As for the Oracles - they have totally different engine, just reuse the graphics. There are some similarities in code 'style' (probably from the Nintendo SDK, although it's totally different from Pokemon 'style'), but it looks like Capcom didn't reuse any of the LA code.

Sorry for the waiting, this forum needs email alerts. It's very nice seeing that somebody actually checked out this project. I found that I had some uncommitted changes from long ago, mostly heuristic improvements for Ages. I remember also trying to make a proper GUI, but lost the prototype.

I committed everything to Github and resumed work. First I added a nice GUI in Tkinter for exporting the disassembly. The idea is to move away from the browser and make the program more user friendly. I'll soon include selecting the rom and running the server from GUI and later a main window with much more dynamic, realtime information than the browser based version. For example seeing the number of procedures grow live as more code gets discovered.

Anyway, here's a little teaser:

Personal Projects / Re: multiarch-emulator in C: ramulate
« on: January 16, 2014, 07:20:28 pm »
Hi, I'd be happy to help if you have any trouble with the GB. It's my fav platform.

Regarding interrupts: from what I've read, it is realized in hardware as follows:
When the interrupt is about to fire, on the next instruction fetch, the instruction register is filled with a fake opcode instead of the real one (which is still available on the 8bit bus, it's just the instruction register that is overridden to take the fake one instead). The fake opcode is some kind of call. After 4 clocks cpu reads the destination address from the bus (where the interrupt controller puts it) and the call is executed.
Fascinating document about this kind of stuff:
Anyway, when it comes to emulation, I'd realize it this way: just before fetching the next instruction, check if interrupt is pending. If so, just execute a fake call instead of the real instruction.

I looked a bit at your source. You might wanna use a script to generate the cpu switch if you don't do it yet. Writing all those cases by hand is hell. The way Z80 opcodes are structured is quite meaningful, I like this table:
Few years ago I have written an emulator in C and used a script that generated the switch from a similar table. It's a mess, but maybe it'll be useful:
I've been using this table approach for 2 more projects, so it's working nice.

I hope some of this stuff is actually useful for you. If you have some questions or want to compare implementation of some parts of the emu, or sth, just message me.

Pushed to Github and updated first post. Also, I put together a small readme to help you get started.

OK, so I'm finally getting some cool results, so I figured I'd post here.

I've always had this special nostalgia for the original Zelda Link's Awakening and after making an emulator few years ago, I wanted to go further.
So I started this project to automate ROM reverse engineering.

Here is a screenshot of the setup. Code at top of page is with all optimizations, code below is without most.
As you can see, loops are reconstructed and call parameters are annotated next to call instructions.
The rightmost image is the current state of Zelda analysis. Green means known code, blue is obvious data (text and sprites) and dark blue is 0xFF padding.

  • static decompilation (no emulation/tracing, all code paths treated equally)
  • expression reconstruction - sequences of instructions are replaced with c-style assignments.
    For example: LD A, 0x30; LD [0xFF00], A is replaced with [0xFF00] = 0x30. This also works across jump boundaries.
  • register lifetime analysis - this enables two things: unneeded flag calculations are stripped away and also I get all ins and outs of a procedure, which helps analysis at global scope.
  • bank switching analysis - direct consequence of the above. I treat rombank as just another register and can recover ambiguous calls this way. In Zelda, bank switching occurs very often, so I get nice results from this. For 2000 procedures analysed (that's much, but I got this number with aggressive procedure splitting) only around 15 contain calls that couldn't be followed.
  • control structure recovery - probably the coolest. Finds loops and forks and uses some heuristics to generate nice if/else and do/while. Some gotos remain, but usually the code is nice.
  • switch statement/jumptables - Zelda really abuses this construct - I found more than 200 jumptables. Heuristics decide on jumptable sizes, sometimes giving false positives, but overall it is helpful.
  • procedure references - For each procedure I get a list of callers. This can also output call graph to GraphViz, but at the moment it is too big to be useful.
  • data references - most recent feature, currently works only for fixed addresses. For each global variable I get a list of procedures that access it. Ultimate helper. Refs to 0xFF00? Yeah, here must be the joypad routine.
  • written in Python, GUI is served as HTML. Allows assigning names to procedures, etc.
  • output is not really C at the moment, but gives an idea of what's going on in the code.

  • recognize array indexing
  • obtain full code coverage with no more ambiguous calls. I believe I've got around 90% of procedures now.
  • find a way to cope with so many small procedures.
  • a lot of other work...

I would like to release it one day, but it is very custom right now and requires coding Python to do stuff. Maybe when I improve the algorithms I can drop some hardcoded Zelda stuff and it will be useful for other Roms too.

Also, source:


Pages: [1]