What Kind Of Knowledge Is Required To Develop An Emulator ?


maximus

Still Fresh
Joined
Jun 6, 2010
Messages
14
Hello

I was wondering about the kind of knowledge required to build a basic emulator (say a NES one..)

I suppose, i need to first pickup a programming language, let's go for C.

So what are the next steps ?
in a probably naive way, i would think it could be something like :

1/ Learn some computer architecture basics : is x86 architecture a possible choice ? it has a lot of documentation. Can i transfer this knowledge to a different architecture, like the NES ?

2/ Learn the assembly language of the target architecture. Again, is it possible to transfer some knowledge of x86 assembly to another kind of proc ?

Now, i think of all others things needed to be emulated, like graphics and sound chips, and it seems overwhelming...

Does any kind of reference book, or documentation or tutorial exist on this subject, that covers all the details from the first step to the last, for a "simple" system like the NES ?

Where did those guys like notaz, exophase, cpasjuste, ari64, zottd etc.. who keep me astonished by the skills they possess got them ? (university, self-taught ??)
What are they doing for a living ? (low-level programming ? compilers ? what ??? :) )

I would be very happy to get some answers ;)

Big kisses.
Mac

P.S : sorry for the bad english, i'm just another curious french guy
 
Also, youll probably want to make some simple programs for the system, so you know your way around it better.
 
Here is a good document that explains several techniques used in emulation. I would recommend reading it :)

http://personals.ac.upc.edu/vmoya/docs/emuprog.pdf
 
It is actually not too hard to write a basic interpreter emulator (as opposed to dynamic or static recompilers etc) same old same old - break the problem into pieces - CPU, ram, video etc. Going to write it from scratch or re-use existing CPU code for instance? Use another emu as documentation or go from schematics and first priniples?

So it depends on target system, And what level - reuse or do it all?

In the end most emu challenge is an optimization game at first - completeness is hard too. Butting getting a single game to work is not too hard, sometimes

I'd choose arcade space invaders first; very specific and nothing tricky going on

can't say much now, on phone and no time, but just dive in :)

jeff
 
The best thing to do is start with a very simple platform and work your way up to more complex ones. A lot of people start with "Chip8." Chip8 is not real hardware but instead is a virtual machine spec made for simple games many years ago. It only requires emulation of a simple RISC CPU and a simple blit-based monochrome display (and if you feel like it, an audio buzzer). You don't have to worry about interrupts or getting timing right or a number of other trickier topics. An experienced emulation coder can code up a Chip8 emulator in just a few hours, and a less experienced one perhaps in a few days.

I recommend looking at the threads here:

http://emutalk.net/forumdisplay.php?f=30

After Chip8 I recommend moving to a simple arcade game like Space Invaders. This will introduce you to emulating more specialized video and audio hardware, while keeping things limited to one piece of software so you don't have to debug much. In practice, debugging libraries of hundreds or thousands of games is the most difficult part of emulation - if something doesn't work it can be extremely difficult to determine why.

After that I would suggest moving to emulating a simple gaming platform. A couple of the simplest I can think of are Gameboy and SMS. An experienced emulation programmer can do emulators for these platforms in a few days.

NES is a little more complex, particularly because of "mapper hell" where you eventually have to support a lot of add-on chips that were present on cartridges, some of which containing pretty sophisticated hardware functions. However, NES emulation has been such a hot topic (especially at nesdev.parodius.com/bbs) and emulators have been made by so many people that it has become a pretty systematic thing. In fact, a reference manual has even been written specifically for emulating NES:

http://nesdev.parodius.com/NES%20emulator%20development%20guide.txt

But even if you don't end up emulating NES you might learn a lot from reading that guide. There are several other emulation tutorials on the internet, just be careful when reading very old ones because they might contain a lot of obsolete advice, like tricks for DOS or what to code in ASM.
 
Use the source.

Get it, unpack it, grok it. Repeat until done.

There are so many great emulators for different systems out there, which use standard techniques for emulation (after all, emulation is as old as computers are...), you can just read a few codebases over a week and get a good feel for what the state of the art is doing on some of the more simpler CPU architectures. From there you can spend 6 months exploring things in the more advanced realms - dynarec, etc.

For me it started with the EDSAC emulator in the BCPL language package, some time in the 80's .. I've dabbled a lot since then, but my last serious emulator was that of the hazeltine era .. long since past cool. Nevertheless, I like to keep up with the new-school generation of emulators simply by grokking the code .. there is a lot going on in the scene that makes for interesting reading, that is for sure, and there is really no reason not to learn what others have done, first. Emulation is never a glorious subject until its *done* .. you're never inventing things with emulation.
 
@skeezix, Exophase, torpor

Thank you very much for the advices and the links, I have some good reading to do.

Btw, do you think "Compiler building" knowledge can help ? (I may have access to books about that field..)
I was wondering if your background knowledge was more on the hardware side (electronic engineering) or on the software side (computer science/software engineering) ?

Mac
 
Learning compilers can help a little bit. At the very least it'll make you a better programmer in general. It'll help a lot specifically if you ever do a recompiler.

My background is in computer science and I'm a software engineer by occupation, but the work I do (embedded, often w/o any operating system and code in C or even ASM, real time work and also DSP coding) often falls more into the domain of what EEs do, because programmers often shy away from it. It's a shame because while the programming world pretends embedded is niche it's actually what the great great vast majority of CPUs out there are doing.
 
Back
Top