Every hacker appreciates humor, but unless it's part of a more substantial post, it has to be a bit more clever than the modified 4chan memes that get massive upvotes on Reddit.
I'm also not the HN culture police, and there are obviously exceptions. But with two -4 replies to each other, I figured I'd step in and mention why. Seems to be good netiquette.
I asked this question. I've been studying and working on emulators since then.
Another good resource if you are interested in this sort of thing is Victor Barrio's thesis he wrote on the subject of emulation techniques (148pg - PDF): http://db.tt/dUJwwR
It looks like you asked this question about a year ago -- since then, what have you done with emulators? (Just curious.) Did you find it easy / hard to get started?
I'm at my college graduation ceremony right now replying on my phone, so bear with me. I'll try to expand on my posts when I get home.
I didn't do anything with the information from this question for several months after asking it. Then, at a university programming competition one of the problem sets included a problem on implementing a simple virtual machine and interpretting a set of instructions. My team solved the problem in about 1.5 hours and it gave me a renewed interest in writing a game emulator. I also spend a lot of time studying reverse engineering which is somewhat related.
I decided to write an NES emulator as my first serious attempt. Emulating the processor in my opinion is one of the easier tasks and I was able to bang it out in a couple weekends. Now I'm focusing on the graphics and sound systems and these take a little more effort. Also, emulating the system timing of the original CPU is a key consideration as well.
I only wish I could somehow turn my emulator / reverse engineering hobbies into a career. I find the work much more rewarding than the typical software shop crud apps.
If I could carve out a job description that mostly involved analyzing and writing runtimes, I would do that. The best I can say off the top of my head is, "we get projects where being able to throw together an emulator in a high-level language inside of a billable week is very useful."
If you want me to be specific: automated runtime-level analysis of subroutines for embedded and smartphone platforms, analysis and design of secure sandboxes for software and content protection, semi-automated generation of fuzzers for protocols from stimulus-response tests and bblock-level analysis, and, of course, reverse engineering in general.
Hey, if you aren't going to commercialize your emulator, do you mind putting the source up somewhere for free or atleast writing some article about CPU emulation. I understood how to read and decode the opcodes. But the CPU emulation is what still makes me ponder
Hey Simucal. I'm the Cody Brocious that answered this, and as much as I love this question, it pains me to see it. I edited it so much, it went into community wiki, before it even had 10 upvotes ;)
But for the record, I'm about 1/4 of the way through a book on emulator development, and I'm currently in preliminary talks with one of the bigger names in tech publishing about getting it out there. Not nearly enough resources on emulation these days.
Edit: I've created a poll to gauge interest for such a book, as I've previously believed strongly that the market is very small. Feedback would be greatly appreciated.
Don't see link to your poll, so I up voted you. Both this thread's karma and the stackoverflow's should give you a litter indication of people's interest.
Think of it this way. A program is just a set of bytes (which are numbers from 0 to 255) which describe what it should do. The goal of most programs is usually just to read in some data (again, just a set of bytes) which is stored in memory, then manipulate that data.
The easiest way to understand how to emulate hardware in software is to just make up your own simple assembly language. For example, let's say you want to have these operations:
"set <memory location> <value between 0 and 255>" -- sets the value at <memory location> to the specified value
"add <src memory location 1> <src memory location 2>" -- adds the numbers at the two memory locations, and stores the result into memory location 1
The point is to keep it ridiculously simple for now, so let's assume the memory locations we provide are also values between 0 and 255 -- effectively giving us 256 bytes of memory to work with.
So let's write a very simple program. It will perform 2 + 2.
set 0 2
set 1 2
add 0 1
The result is now in memory location 0, and the result is "4" obviously.
So what might the program look like on disk? Well, we only have two instructions, so let's say the code for "set" is "0" and the code for "add" is 1". If we store the program in a file, then it might look like this:
0 0 2 0 1 2 1 0 1
Now that we've defined an extremely simple assembly language, we can write a virtual machine for it as follows.
First, write a program which allocates 256 bytes of memory. This is our virtual machine's memory space.
- Read in the first byte of the program.
- If it's 0 ("set"), then read in two more bytes (the dst and value arguments for "set"). Set mem[dst] = value.
- If it's 1 ("add"), then read in two more bytes (the "dst" and "src" arguments for "add"). Set mem[dst] = mem[dst] + mem[src].
- If it's > 1, then abort (the program is invalid).
If this all made sense to you, then you should be a stone's throw away from being able to write a VM for more complicated instruction sets. Just find out what the instruction set can do, and then write a VM which allows the instructions to do those things.
My "Aha!" moment came during my foundations of CS class at uni. As such, I'd suggest reading up on the work of Alan Turing (Church is good too, but Turing's state-machine-based definitions are usually more approachable to a beginner).
If you're interested in seeing (another) emulator implementation, the Computer History Simulation Project (simh) package <http://simh.trailing-edge.com/>; emulates various boxes.
I found http://openbookproject.net/py4fun/ a while back. It has quite a few projects, one of which is a "toy computer" emulator written in Python. It goes from the raw emulator, through to writing a simple language and compiler for it.
It is a toy example (hence the name, I guess), but a picture is worth a thousand words, if you're wondering about the nitty gritty of it all.
27 comments
[ 5.7 ms ] story [ 82.7 ms ] threadI'm also not the HN culture police, and there are obviously exceptions. But with two -4 replies to each other, I figured I'd step in and mention why. Seems to be good netiquette.
Another good resource if you are interested in this sort of thing is Victor Barrio's thesis he wrote on the subject of emulation techniques (148pg - PDF): http://db.tt/dUJwwR
It provides a good overview to get you started.
I didn't do anything with the information from this question for several months after asking it. Then, at a university programming competition one of the problem sets included a problem on implementing a simple virtual machine and interpretting a set of instructions. My team solved the problem in about 1.5 hours and it gave me a renewed interest in writing a game emulator. I also spend a lot of time studying reverse engineering which is somewhat related.
I decided to write an NES emulator as my first serious attempt. Emulating the processor in my opinion is one of the easier tasks and I was able to bang it out in a couple weekends. Now I'm focusing on the graphics and sound systems and these take a little more effort. Also, emulating the system timing of the original CPU is a key consideration as well.
I only wish I could somehow turn my emulator / reverse engineering hobbies into a career. I find the work much more rewarding than the typical software shop crud apps.
(or, more generally: you have an extremely valuable skill set).
If I could carve out a job description that mostly involved analyzing and writing runtimes, I would do that. The best I can say off the top of my head is, "we get projects where being able to throw together an emulator in a high-level language inside of a billable week is very useful."
If you want me to be specific: automated runtime-level analysis of subroutines for embedded and smartphone platforms, analysis and design of secure sandboxes for software and content protection, semi-automated generation of fuzzers for protocols from stimulus-response tests and bblock-level analysis, and, of course, reverse engineering in general.
I would guess that whenever you hire someone in this way you find someone who fits the job perfectly. It's a win-win situation for everyone.
http://mutantlemon.nfshost.com/omegagb/devlog
Screenshots of the emulator and full haskell source code here:
http://mutantlemon.nfshost.com/omegagb/
But for the record, I'm about 1/4 of the way through a book on emulator development, and I'm currently in preliminary talks with one of the bigger names in tech publishing about getting it out there. Not nearly enough resources on emulation these days.
Edit: I've created a poll to gauge interest for such a book, as I've previously believed strongly that the market is very small. Feedback would be greatly appreciated.
The easiest way to understand how to emulate hardware in software is to just make up your own simple assembly language. For example, let's say you want to have these operations:
"set <memory location> <value between 0 and 255>" -- sets the value at <memory location> to the specified value
"add <src memory location 1> <src memory location 2>" -- adds the numbers at the two memory locations, and stores the result into memory location 1
The point is to keep it ridiculously simple for now, so let's assume the memory locations we provide are also values between 0 and 255 -- effectively giving us 256 bytes of memory to work with.
So let's write a very simple program. It will perform 2 + 2.
The result is now in memory location 0, and the result is "4" obviously.So what might the program look like on disk? Well, we only have two instructions, so let's say the code for "set" is "0" and the code for "add" is 1". If we store the program in a file, then it might look like this:
Now that we've defined an extremely simple assembly language, we can write a virtual machine for it as follows.First, write a program which allocates 256 bytes of memory. This is our virtual machine's memory space.
- Read in the first byte of the program.
- If it's 0 ("set"), then read in two more bytes (the dst and value arguments for "set"). Set mem[dst] = value.
- If it's 1 ("add"), then read in two more bytes (the "dst" and "src" arguments for "add"). Set mem[dst] = mem[dst] + mem[src].
- If it's > 1, then abort (the program is invalid).
If this all made sense to you, then you should be a stone's throw away from being able to write a VM for more complicated instruction sets. Just find out what the instruction set can do, and then write a VM which allows the instructions to do those things.
It is a toy example (hence the name, I guess), but a picture is worth a thousand words, if you're wondering about the nitty gritty of it all.