Menu
What's new
By:
Filters

The "I want to Code an Emulator" Suggestion thread

Cyberman

Cyberman

Moderator
Moderator
This has become a VERY Frequently Asked question therefore this new shiney Sticky thread is appearing. Suggestions other than asking how to start (which the thread is about) are welcome, I will remove anything that doesn't relate to the topic or is asking what to do (since the entire topic is what to do) to start programming an emulator.

Some tips:
  1. Have a programming language you are familiar with, it doesn't matter if it's C, C++, C#, or even Visual Basic (scarey that is). It just has to be something you are familiar with.
  2. Learn to program. Yes you must know how to program in order to make an emulator because an emulator is a program.
  3. Do something SIMPLE to start out. I don't suggest trying to make a WII emulator because .. you'll be looking a LONG time for information on that. There is a LIST of simple console emulation developement threads at the top of the programming forum for this very reason. here are a few GameBoy, Chip8, NES (Nintendo Entertainment System), SMS (Sega Master System), PC-Engine, Space Invaders, and there likely will be more. Pick the SIMPLEST first (Chip8 for example) because you will be very confused at first otherwise.
  4. Get TOOLS, don't sit there and say "WHAT do I get to make a program?" Yes there are tools available free on the net LOOK AT THIS thread to find some links (please let me know of dead links).
  5. ROM images et al. DO NOT ask for ROM images, you should be able to find these without asking where to get them. Find some demo ROM images to test your emulator I will add a post to this thread for that.
Most of all HAVE FUN, if it's not fun .. I suppose do something else? :)

Cyb
 
OP
Cyberman

Cyberman

Moderator
Moderator
Demo ROM links for platforms

This post is for Demo ROM links, as of Right now I have none however I am sure I'll be bombarded with suggestions for them soon enough.

NES:

PC-Engine:

Game Boy:

Chip-8:

Sega Master System:

Nintendo-64:


Cyb
 
E

Exophase

Emulator Developer
Since you mentioned what a "simple" emulator is, I thought maybe this would be useful (or maybe not, who knows)

Exophase's tiers of console emulator difficulty (I haven't done most of these so they're just rough ideas based on what I know about the hardware, take them with a grain of salt)

simple: Gameboy/Color, SMS/GameGear
moderate: NES, PC-Engine, Lynx, NeoGeo, Wonderswan/Color, NeoGeoPocket/Color
slightly complex: Genesis, N64 w/HLE, Virtual Boy, GBA
complex: SNES, PS1, Dreamcast, Jaguar, 3DO, N64 w/o HLE
highly complex: Saturn, PS2

This is all relative though, doing anything beyond "very simple" will give a lot of headaches for all but the most experienced emu coders.

These are the basic criteria I used:
- Complexity of CPU (6502 in NES is relatively simple, as is MIPS, ARM7 and x86 are relatively complex), having multiple CPUs drives up the complexity a lot
- Complexity of audio (SMS's PSGs are very simple, GB/NES are more complex, Genesis, SNES, and PS1 are much more complex)
- Complexity of video, including things like different modes, layers, tile formats, sprite storage, scrolling features, priority, affine transformations, blending, 3D, etc
- Complexity of cartridge hardware if available - mappers (many have almost none, GB has a few, NES has a ton), backup storage, extra hardware/special chips (SNES especially)

What wasn't considered, but can be even bigger factors in practice:

- Performance requirements - it's much more difficult to write a very optimized emulator than a straightforward implementation, and with recompilers the sky is the limit on what you can do with them. What the requirements are will depend on how powerful the platform is, how complex it is, and what you intend to run it on.
- Compatibility requirements - writing a very compatible emulator is also much more difficult, and getting the last few percent of games to work can be especially challenging. This can also impact performance requirements.
- Amount of documentation available - the more you have to look, the hardware it will be to get it right. If there's no documentation then you have to either try things on intuition based on what the game does or run tests on the console itself which can range from tedious to extremely challenging and time consuming (assuming you have the hardware and a way to run code on it)
- Test ROMS - the more that are out there the easier it'll be to debug your emulator. Actually, debugging is the hardest/most time consuming part of any emulator, so this can make a dramatic difference. If there are no test ROMs you might want to consider writing one, then sharing it with everyone else (this rarely happens unfortunately)
- Other emulators - Although this is kind of cheating, if you can compare with other emulators by using their debuggers you can fix a lot of problems. If you're doing an emulator for reasons beyond just getting the experience (like, doing one that's much faster than any other out there) then don't hesitate to do this, or look at their source code for ideas.
 
A

AamirM

New member
Hi,

I wouldn't put Neogeo in moderate category if I were you. YM2610 is very hard to emulate. And M68K take loads of time to implement.

stay safe,

AamirM
 
E

Exophase

Emulator Developer
AamirM said:
Hi,

I wouldn't put Neogeo in moderate category if I were you. YM2610 is very hard to emulate. And M68K take loads of time to implement.

stay safe,

AamirM
Click to expand...

Okay, let's say under moderate with YM2610 not emulated, since most games don't use it or at least not extensively. Basically compare with the level of emulation NeoDS achieves. Even then if you compare with Genesis there's a pretty big difference in video complexity and quantity/diversity of games.
 
H

HardwareSlayer

New member
Alright, so I have a totally n00b question, and I really hope I don't get laughed off the forum with my first post, lol!

But I am really interesting in making a career move into programming, and I've always loved emulators, so I figured I would like to go to college to study programming to program my own emulators, and in doing so, I would learn a valuable skill for advancing my career...

Now, I know NOTHING about programming, here's where the laughter comes in, I can hear it now....lol

So lets say I was some wacko with no life whatsoever, lol, is it possible to take apart something, say, a PS one and knowing assembly, be able to figure out how parts work without having the proper documentation, or do you ABSOLUTELY 100% NEED the documentation?

I know this sounds crazy coming from someone who doesn't know the first thing about C#, but it's kind of been a dream of mine to write an emulator that some would find almost impossible to emulate because of the lack of documentation on the processors and such...
 
Last edited:
E

Exophase

Emulator Developer
HardwareSlayer said:
So lets say I was some wacko with no life whatsoever, lol, is it possible to take apart something, say, a PS one and knowing assembly, be able to figure out how parts work without having the proper documentation
Click to expand...

No.

HardwareSlayer said:
, or do you ABSOLUTELY 100% NEED the documentation?
Click to expand...

If you don't have some kind of documentation then you won't get anywhere, but if you can program for the machine then you can figure out a lot by doing software tests. This is very difficult though.

HardwareSlayer said:
I know this sounds crazy coming from someone who doesn't know the first thing about C#, but it's kind of been a dream of mine to write an emulator that some would find almost impossible to emulate because of the lack of documentation on the processors and such...
Click to expand...

The documentation is out there. Game consoles tend to use variations of publicly available CPUs that have documentation available, so offer a good place to start for reverse engineering them. But the reality is that information about consoles tends to be known because someone leaked official documents and/or SDKs, then someone verified the information on a console, and from reverse engineering games.
 
H

HardwareSlayer

New member
Hey thanks for the reply Exophase, the reason I ask is because I'm not sure if some smaller things like the Super FX or Super FX 2 Chips have been perfectly emulated for the Super Nintendo yet. I haven't followed up recently on them though, so maybe they have been...although by the time I actually know what I'm doing, someone will have beaten me to it, ha! Thanks again.
 
X

Xtreme2damax

New member
Thanks for the information, I do have a quick question:

Do you need to actually have the system you intend to emulate, in order to program an emulator of that system?

Are documents really the only thing that is needed or is there more to it than that?

I'm considering an emulation project in the future, however the only obstacle in my way is learning how to actually code.

Any decent tutorials that can help simplify the C++ or coding learning process?
 
Toasty

Toasty

Sony battery
Nope, you don't need the original console, just good documentation about the functions of the platform you want to emulate. In fact, there was never a real CHIP-8 machine - CHIP-8 was just a specification for CHIP-8 emulators. Though, in cases where there is little documentation available, having the original hardware can be helpful if you need to do some reverse engineering.
 
blueshogun96

blueshogun96

A lowdown dirty shame
Just wondering, are there any dynarec tutorials for those who have written an emulator, but don't know how? I'm not asking for my sake, but for everyone elses. If none exist, then I'll happily write one in my spare time explaining one I'm writing now (if anyone wants it that is).
 
C

CodeSlinger

New member
Toasty said:
I'd certainly read it if you did. :)

(You can never have too many emulation tutorials.)
Click to expand...

Agreed. I'd love to read it.

Edit:

On a side note does anyone have any documentation on emulation with threaded interpretation?
 
Last edited:
OP
Cyberman

Cyberman

Moderator
Moderator
CodeSlinger said:
Agreed. I'd love to read it.

Edit:

On a side note does anyone have any documentation on emulation with threaded interpretation?
Click to expand...
Dynamic Rec requires a bit of memory management you should look at TR64 source for some clues there :D

Threaded interpretation? Hmmm do you mean running the interpreter for the system in one thread and the GPU in the primary thread of the application? The biggest issue you have is syncing the two separate threads.

Right now I'm playing with a C51 processor interpreter in one thread and using the main thread to handle physical hardware (LCD emulation basically) it's interfaced with. Syncing the Read and Writes is done via separate functions that actually perform the writes and using the sync call in windoze. It isn't beautiful but that's just the interpreter not quite done with that yet.

Anyhow using the built in semaphor handling in windows is thread safe although I am not sure how FAST it is. :(

Cyb
 
C

CodeSlinger

New member
synch: Yeah if you could upload it that'd be great as I havent been able to find it anywhere.

Cyberman: From what I understand threaded emulation is similar to dynarec with how it translates basic blocks and caches them for later use. As far as I understand dynarec translates the basic block to code where as threaded interpretation translates the cache to function pointers to emulate each instruction. This is pretty much exactly how a normal interpreter emulator works but without the constant decoding of the next instruction. Apparently though it gives a decent speed improvement because most of the time consumed by a normal interpreter is spent checking what the state of the flags should be. But with a threaded interpreter it can deduce which flags need to checked and which dont because the next instruction in the block my overwrite some of the flags without testing them, so there was no need checking and setting the flag in the previous instruction.

Id imagine that threaded interpretation is slower than dynarec but faster than a normal interpreter. However it would be much easier to debug and maintain than dynarec. I've got source code of an emulator that uses threaded interpretation so I'll give it a look over to see how worth while it is to implement http://www.squish.net/generator/description.html
 
Last edited:
You must log in or register to reply here.

Top