[RuneLancer]

My god, I can't believe how easy this is!

When I'm not working on Endless Saga or busy chasing down a checkbook down at the bank to move into my new appartment, I do some ROM hacking. Not the pityful "open the rom in an editor and tweak stuff" kind, but the raw and gory hex-tweaking/assembly-editing kind. My primary interest lies in dumping a game's code and figuring the whole thing out.

Needless to say, I have a hefty amount of experience with the 65816 processor. And even more needless to say, getting my hands on some tools to debug code makes the task far easier. :P But I have a sick aversion to using others' code and programs in my own personal projects and write my own utilities. As a result, I have, among other things, an intelligent 65816 decompiler. Writing this instead of using someone else's taught me a heap of stuff about the 65816 and was, all in all, a very enriching experience. The kind I wouldn't have gotten if I had just hunted around for a pre-written program. :P

Lately, I've had an idea that would simplify my work quite a bit: something that would be able to take 65816 code, a few initial values, and run a function and provide a step-by-step trace of what goes on. Sure as hell beats doing it all by hand! Seemed easy enough, too, as assembly isn't exactly a difficult language to learn despite what people think. Most instructions are basically single bitwise operations (x = y, x |= y, x += y, x -= y, x &= y...) with a few modifications thrown in depending on the state of the processor flags.

It's been two days and I'm slowly finding myself writing an emulator now (sans hardware addresses; though by the time I'm done I'll have to emulate at least a few basic ones, such as the arithmitic coprocessor and mode 7 matrix operations.) And I'm blown away by how easy this actually is. Granted, low-level code is definately my forte, but still, I was expecting a major mess. And after two days I've pretty much attained my initial goal. Now all's I can do with this is finish writing the handfull of missing opcodes and implementing hardware addresses. Two days and it's rapidly becomming a basic but fully-functional emulator. Huh...

Although I never have and never will release open source code, I fully intend to write a very in-depth document on how the experience went and how everything was implemented for anyone interested in partaking in this sort of experience. All's I have to say is this: "Wow. This shit is FUN. :P"
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[Mandrake]

Fuck Opening the source, this document sounds much more beneficial, and I for one would love to read it.
_________________
"Well, last time I flicked on a lighter, I'm pretty sure I didn't create a black hole."-
Xmark

http://pauljessup.com

[tcaudilllg]

Decompiler or disassembler?

[RuneLancer]

[tcaudilllg]

[RuneLancer]

[DeveloperX]

interesting.
I'll be watching the development of this for sure. :D
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[tcaudilllg]

[RuneLancer]

[tcaudilllg]

I began a CPU core for the NES some years ago, and got pretty far on it... but I did it in QBasic. Once I realized its performance issues were insurmountable, I stopped work on it.

Decompilation is probably the best route to extending existing games. Like for example, making a massively multiplayer FFVI. (if it struck someone's fancy to do so) Far faster than recreating the project through reductive reasoning, as was done with Zelda Classic.

What would be most beneficial, although I'm sure it'd cause a few shockwaves in our world, would be first to decompile the game, and then to recompile it for a different architecture. One-time emulation. No speed issues at all.

But expect vigorous retaliation from untold quarters of the software industry if such a thing were to even begin taking place. That said... it's not as difficult as it sounds. It would take a lot of planning, to correspond the functions of a console to those of a PC, however emulators already do this. The only difference is that they don't reflect the correspondence in compiled code.

[RuneLancer]

What you're describing is called Dynamic Recompilation. The world has already thought of that a long time ago.

http://acorn.cybervillage.co.uk/emulation/dynrcomp.htm

Of course, this no longer has anything to do with ROM hacking.
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[Sirocco]

[RuneLancer]

Most of the more recent systems are emulated via dynamic recompilation. It would be too horrific to bear for anything but the top specs otherwise, as emulation is, after all, interpreted code otherwise.

The fact remains that even though the assembly code is recompiled from the chipset of the system being emulated to (say) x86 assembly, that does zilch for the hardware. Which is the most important part. Software can only get a system so far, hardware is where all of the emulation problems occure.

An example of this is the SNES math coprocessor. The way it works is pretty simple. Suppose you want to multiply two values together...

[tcaudilllg]

Ignore the machine cycles. Ignore everything having to do with the machine cycles. You'll have to rearrange the code, though.

[RuneLancer]

That code is absolute crap. :) Even if you ignore machine cycles, which are there to prevent resource conflicts (among other vitally important things.)

In a best-case scenario, the arithmetic coprocessor will not have been used and you'll pull a 0, which will give incorrect results in most cases (generally when grabbing an index into a structure), but chances are you'll have called it at some other point in your code and the arithmetic coprocessor won't have overwritten the new value. (And in fact, I believe the SNES doesn't initialise these, so there'd be crap in it either way.)

That address contains VERY unreliable data until the 8 cycles have taken place. While your idea sounds good in theory, it will fail quite badly in practice. You can't fire off an LDA until after the 8 cycles have elapsed.

Basically, an instruction enters the processor via a bus called the "data bus." It gets shoved into the instruction register when the instruction fetch signal is fired and sits there. The TCU (timing control unit) is reset to 0 every time an instruction fetch is issued and increments at the beginning of every cycle until the required amount of cycles to execute the instruction have taken place. This whole thing serves as a means of pacing instructions so that no conflict occures (ie, an LDA and STA reading/writing to the same offset could lead to very, VERY unpredictable data if it could occure. Which it can't because of the TCU.) This also makes sure that coprocessor routines don't end up entering a deadlock or fighting for resources with processor routines. Such as the ALU putting the finishing touches on a multiplication.

As a result, the LDA will be fired off before the ALU finishes multiplying (as the LDA is issued before the 8 cycles are over) and it'll read what's essentially crap from the register, THEN the value will be written to it, but the LDA will have already been shifted out of the instruction register and the NOPs will be queued up all nice and snug.

You ARE thinking along the right lines, though: you could, say, LDA from some other offset (to retreive the stat ID to check after issuing a multiplication (CharID x CharStructureSize) to get the offset into the character's stats) in the meantime. But you can't do zilch with the ALU until it's done.

Edit: Here's an example of what I mean. I'll forego the flag manipulations, just pretend the accumulator's 8 bits and the index registers are 16 bits.