Dynarec for first emu project?

[phytoporg]

Okay, so a month or so ago I decided that emulation is fascinating, and thought I'd give it a shot. I was inspired by the comp. architecture class I'm currently taking, along with the fact that I've spent so many years taking advantage of the emulators that other people have written... figured it'd be cool to try it out.

Naturally, since my epiphany I've done a good deal of reading. I looked around to see what would make a good first project for a console emulator, and stumbled across a thread on retrogames from which I gathered that the NES would be a good idea. The nesdev community has been really helpful in giving me a good idea of what needs to be done and how difficult it might be to implement everything. It's a little overwhelming at first, but I'm slowly getting a better grasp on the specifics.

It seems that most classic console emulators out there are interpreters, which is reasonable. I was digging through the Nestra source earlier though and I think it'd be neat to write a dynamic recompiler-- it might be unecessary for an NES emulator, but I ultimately do want to pursue more ambitious projects, and maybe diving into the basics of dynarec would help me get through more complex emus in the future?

The issue is that it'd be more difficult to write and debug. I'm definitely up for a challenge, but I don't want to try and tackle something that would just be way over my head. I haven't been able to find much info on dynarec, and I'm barely even aware of what implementing one might entail.

So, yeah. Any input or opinions would be greatly appreciated.

 

[refraction]

this should help you out

http://www.zenogais.net/projects/tutorials/Dynamic Recompiler.html

 

[phytoporg]

Ahh, thanks a lot. That helps quite a bit.

 

[ShizZy]

Well, it's really hard to say. I guess it mostly depends on how much programming experience you've had overall. And considering that you're starting with NES, which isn't the *easiest* system IMHO. I started with chip8, then gbc - both interpreters. Now I'm doing GCN, still with an interpreter. Dynarecs can be really really messy, and a solid interpreter first helps with debugging.

 

[mono]

Zenogais's tutorial isn't really enough to make a dynarec. How are you supposed to handle timing, for example?

 

[phytoporg]

I mainly wanted something to give me a general idea of how a dynarec would be implemented. Even something simple with some kind of inter-architecture dictionary would be sufficient (which is more or less what's going on in the tutorial I guess).

I have found other resources that touch a little on timing issues. This thread here is very informative, and some of the bigger issues in dynarec development are briefly addressed in Victor Moya del Barrio's enormous pdf book thing.

None of this stuff is necessarily straightforward, but it's somewhere to start, at least.

[edit:]

Well, it's really hard to say. I guess it mostly depends on how much programming experience you've had overall. And considering that you're starting with NES, which isn't the *easiest* system IMHO. I started with chip8, then gbc - both interpreters. Now I'm doing GCN, still with an interpreter. Dynarecs can be really really messy, and a solid interpreter first helps with debugging.

I wouldn't say I'm that experienced, really. My most ambitious personal project to date is a basic raytracer... otherwise, I don't have anything substantial under my belt.

Would you say it's impossible to pick up, though? I mean, yeah, debugging a dynarec is probably a little more than frustrating, but the concept interests me a lot, and I feel like if I ever want to work on a large scale emulator for a recent console, it's something I'm going to have to learn eventually. Or am I wrong about that? It just seems that most of the more popular programs that emulate anything released after the Playstation go with dynarec.

 

[mono]

Yes, that is true. A dyanrec is necessary for speed on emulators for newer consoles. They still usually have an interpreter, as well, for debugging purposes, though.

EDIT:

I took a look at that link you gave. I found the answer to how you handle timing disappointing. It was just what I assumed (that you have to sacrifice some timing accuracy to achieve speed). I suppose that most games aren't too picky about timing, but you still have those that are.

 

[hap]

on the NES, many games are picky about timing

 

[mono]

Well, the only serious emulator I've written was a GB emulator. I didn't experience too many issues with timing. However, the game Altered Space is very sensitive to timing. It certainly wouldn't work on an emulator that only checks cycles after each block because it needs to call an interrupt right after a certain opcode in the middle of the block is executed or it will go into an infinite loop.

 

[zilmar]

Depends on how the timer has to be used (which is system based), you could do it as a seperate thread and just check it, you could do a check at a jump, you could check every opcode. The less you check the faster you get but the less accurate. For something that needs it more accurate you could check on certain op types or after X number of ops, etc.

Dynamic recomp is not that hard, tho it can be challenging. You just have to be able to imagine what the code should look like in your target asm then create a set of rules to translate the input to look like what you want as the output

 

[phytoporg]

Well, that's encouraging news. Maybe I could throw in some kind of cycle check frequency setting? Timing wasn't something I'd given much thought to... should look into that a bit more. D: