writing an emulator?

Started by
19 comments, last by doynax 18 years, 7 months ago
Quote:Original post by Scet
Just be sure to get one written by someone sane(not ZSNES [lol])


I didn't say they were sane, after all! [lol]
Advertisement
Actually, you may benefit more by creating a Virtual Machine of your own design first. Less worrying about why this program doesn't work well, but this one runs too fast, and that one is all wonky. (Because in emulators, you do have to count cycles for each opcode, or at least guess moderately well.) At least, if you design the system, you have less to worry about, and you can focus more on the task at hand. Pulling out an opcode, getting the operands, executing, increasing the PC, whatever.

A great book on the subject is Virtual Machine Design and Implementation, by Bill Blunden. It covers way more than you'll need for an emulator (including creating an assembler for a virtual machine), but I strongly believe it will help in the long run.
Quote:Original post by Nychold
... Pulling out an opcode, getting the operands, executing, increasing the PC, whatever.

I'm a little confused about this. Do you mean IP?
:stylin: "Make games, not war.""...if you're doing this to learn then just study a modern C++ compiler's implementation." -snk_kid
The hardest problem in writing an emulator, in my opinion, is to emulate the hardware. Most important thing is to know how the hardware works, so you'd best choose a device for which there are plenty of documentation.
First actual programming task should be to write (or acquire by other means) a processor emulator. It can be a bit tedious to write and you need to write small test programs in assembly to test for bugs. It's important that you understand the semantics of all of the instructions well. In other words, you need to be able to program in assembly for the target device.
Once you've got a processor emulator, you can start working on the other hardware.
Quote:Original post by stylin
Quote:Original post by Nychold
... Pulling out an opcode, getting the operands, executing, increasing the PC, whatever.

I'm a little confused about this. Do you mean IP?


IP (Instruction Pointer) is the same as PC (Program Counter).
Quote:Original post by FlowingOoze
Quote:Original post by stylin
Quote:Original post by Nychold
... Pulling out an opcode, getting the operands, executing, increasing the PC, whatever.

I'm a little confused about this. Do you mean IP?


IP (Instruction Pointer) is the same as PC (Program Counter).

Thanks for the clarification. I figured as much, but I wasn't sure.
:stylin: "Make games, not war.""...if you're doing this to learn then just study a modern C++ compiler's implementation." -snk_kid
Ok for all these people who said you need to be a pro asm programmer or W/E, dont listen to em, I wrote a CPU core for the nes, without any knowledge of asm when I started, and I wrote it in VB. It helped me learn ASM, or at least alot of the fundamental concepts, like addressing modes. Writing an emulator isnt as hard as everyone makes it out to be, its just hard to make a good fast one.
Alright so then the 2600 isn't simple to emulate eh, I don't know what gave me the idea it was :). Ok then I'll try to write a gameboy emulator instead hopefully when I get some free time. The Virtual Machine idea sounds interesting as well. Does anybody know of some open source gameboy emulators I can look at?
And I wouldn't like to start off trying to emulate the snes I want to keep my sanity for now. [lol]
I've written an x86 emulator that handled bios images and such and a few devices. The biggest problems are documentation on the cpu's, documentation on the hardware, and timing issues. I'd say timing issues are the biggest, even later Zsnes versions had timing issues. If you can get a nice scheduler and such going then you'll be fine.
The (legendary) emulator author Marat Fayzullin has some good resources on his site:

http://www.komkon.org/fms/EMUL8/

Pete

This topic is closed to new replies.

Advertisement