I'd like to write my own emulator for an older console, I was thinking NES at first, but perhaps something simpler like an atari or something would be a more reasonable goal. Anyway, I hear that an emulator is pretty much a compiler, but I don't know anything about how to write one. I know C++, some C, and I'm learning java for one of my classes(pun intended :)) and my thought was to do it in java for the whole portability thing.
Does anyone have any good ideas of how to find resources about compiler coding? Would java be a REALLY bad idea because of the whole interpreted language thing? Is this realistic for a 4th semester sophomore Computer Science student?
Thanks a bunch.
-nospoon
Do not try to bend the spoon, that's impossible. Instead only try to realize the truth.
What Truth?
There is nospoon. Then you will see it is not the spoon that changes, it is only yourself
Writing a compiler for any modern language brings about a lot of issues that you don't need to consider when writing an emulator.
Much more important is to understand how a CPU works, i.e. assembler programming.
If you are newbie at that, search for 8051 CPU specs (as far as I know, it is the most common microprocessor teaching subject), and get a simulator for it and play with it a bit. Perhaps some basic information on what to expect, would be useful too...
As for one's first emulation project, I would suggest trying to emulate some very simple computer, such as the Commodore 64.
You would need to search for information on which CPU it uses, how it maps memory, how timers work, and how it accesses peripherials, and how the display is rendered, among other things.
If you have some programming experience (or more precisely, experience reading source code), I would greatly recommend studying an existing emulator, locating the relevant emulation cores (such as the CPU emulation), and inspecting them. It may bring a lot of good ideas to start with.
Edit: And despite the fact that the smallest Commodore PET 2001 emulator (which can run Microsoft BASIC among other things) fits in under 4 kilobytes of C code, you should not try to take example on that one :)
I took a class last semester on pretty much this topic. Some MIPS assembly, although not much. . . and then most of the course on CPU design.
Would you suggest writing it in an OOL or does it not make much of a difference?
Do not try to bend the spoon, that's impossible. Instead only try to realize the truth.
What Truth?
There is nospoon. Then you will see it is not the spoon that changes, it is only yourself
Would you suggest writing it in an OOL or does it not make much of a difference?
It does not make much of a difference.
However, if speed is of importance (as it often is with emulation), you should ensure there's at least a way to write efficient code that doesn't allocate dynamic items and do tons of pointer references in an inner loop, as opposed to how Java works. :)
And despite the fact that the smallest Commodore PET 2001 emulator (which can run Microsoft BASIC among other things) fits in under 4 kilobytes of C code, you should not try to take example on that one :)
And it probably doesn't support re-recording.
So boooooooooooo.
Writing a compiler for any modern language brings about a lot of issues that you don't need to consider when writing an emulator.
Much more important is to understand how a CPU works, i.e. assembler programming.
If you are newbie at that, search for 8051 CPU specs (as far as I know, it is the most common microprocessor teaching subject), and get a simulator for it and play with it a bit. Perhaps some basic information on what to expect, would be useful too...
MIPS R2000 is commonly used in a lot of educational institutions. You can use SPIM (both unix/windows) to simulate it.
A good book I recommend is "Computer Organization and Design" by David Patterson and John Hennessy.
You could also look at some useful webcasts:
http://webcast.berkeley.edu/courses/archive.php?seriesid=1906978272
and/or lectures that complement the webcasts:
http://inst.eecs.berkeley.edu/~cs61c/sp06/
(sroll down to weeks 4-5)
You could also try out our MIPS project on for size, I still have a semi-working solution in notepad... The final solution was submitted, and then lost on an institutional machine :(...
That's the textbook we used in the class I took last semester :)
Do not try to bend the spoon, that's impossible. Instead only try to realize the truth.
What Truth?
There is nospoon. Then you will see it is not the spoon that changes, it is only yourself
I figured as much. It's used in a lot of educational institutes.
So your assembly knowledge encompasses what I know, and probably exceeds mine, as you seem to be a CS oriented student. I leaned more towards the Electrical Engineering side, but boolean logic, and cpu design is still a very important class for us EEs. *CoughCoughVerilogCoughCough*
I don't know crap about compilers itself, and have a slight familiarity with interpreters (made a MIPS interpreter in C, and a SCHEME interpreter in SCHEME (bootstrapping)). But I hear that compilers completely differ from interpreters! :D.
Good luck with your endeavor, I probably cannot be of further assistance, but I can provide you with moral support ;).
Joined: 12/26/2006
Posts: 256
Location: United States of America
Bisqwit wrote:
Edit: And despite the fact that the smallest Commodore PET 2001 emulator (which can run Microsoft BASIC among other things) fits in under 4 kilobytes of C code, you should not try to take example on that one :)
OK, I'm familiar with C (somewhat), but that's just like... WTF???
OK, I'm familiar with C (somewhat), but that's just like... WTF???
Hint: If you want to understand it, or intentionally obfuscated C code in general, try these steps:
1. Remove standard #includes and #defines that you do not want to expand.
2. Preprocess the source code. This can be done with with gcc -E source.c > preprocessed.c.
3. Add back the removed #includes (and #defines if you removed any).
4. Prettyprint it with a program such as GNU indent.
5. Tidy the prettyprinting manually. Very long expressions are common in obfuscated C code, and they cannot be easily automatically re-indented.
6. Find things you understand and add comments. Continue tidying.
In the case of the PET emulator linked above, the result would look something like this: http://bisqwit.iki.fi/src/ioccc2005sykespretty.c
It is now a lot easier to comprehend (at least I understand quite well what's going on in it*), even though it is still the same program (and compiles to exactly identical executable file).
----
*) Partly because I have extensive knowledge on how emulators such as this are designed in general. The PET CPU is very similar to the one in NES and C64.
You're an awesome guy, Bisqwit!!
The details of this program are completely lost on me, but the overall outline seems pretty simple. I'm going to study this.
I love the way the author chose, functional, descriptive variable and function names. : )
Re: ioccc2005sykes; for the record, in the 2006 IOCCC there was also an emulator winner. This time, the emulated system is a 8080. http://www.ioccc.org/whowon2006.html
The source code is not yet available though.
EDIT: 8080, not 4004. I remembered wrong.
Anyway, I hear that an emulator is pretty much a compiler
I don't think an emulator has anything to do with compilers. What an emulator really is, is a bytecode interpreter. A compiler is a program which takes an input in some high-level syntax, parses it and produces bytecode from it (could be eg. native machine code or some abstract bytecode for some VM). An interpreter is a program which reads this bytecode and interprets it. An emulator doesn't have to parse anything. It simply reads the bytecode of the game and interprets it.
The core of an emulator can probably be simplified as:
switch(ram[IP])
{
case OPCODE1: (do whatever OPCODE1 is supposed to do); break;
case OPCODE2: (do whatever OPCODE2 is supposed to do); break
case OPCODE3; ... etc ...
...
}
Of course implementing the 'case' blocks will be quite laborious, as you need to emulate the entire hardware, etc.
The core of an emulator can probably be simplified as:
switch(ram[IP])
{
case OPCODE1: (do whatever OPCODE1 is supposed to do); break;
case OPCODE2: (do whatever OPCODE2 is supposed to do); break
case OPCODE3; ... etc ...
...
}
Yeah, that part is just the CPU. You also need to know how to emulate the hardware and peripherials; for example, knowing that when the CPU wants to write to address $4002, the sound emulator should catch that write and realize that aha, the lower 8 bits of the square wave generator's wave length were changed, or that to render the screen, you need to check what's in PPU's VRAM at the address pointed by the register that was written through address $2002, and how to construct tiles from that and how to color them, etc.
(Note: The addresses in this example were fictional.)
Btw, where do emulator makers find all the detailed hardware specs of a console like NES or SNES? It doesn't sound like something a company like Nintendo would publish.
Btw, where do emulator makers find all the detailed hardware specs of a console like NES or SNES? It doesn't sound like something a company like Nintendo would publish.
Generally that's determined by reverse engineering. Though there are very detailed specs available.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Btw, where do emulator makers find all the detailed hardware specs of a console like NES or SNES? It doesn't sound like something a company like Nintendo would publish.
Generally that's determined by reverse engineering. Though there are very detailed specs available.
I've heard of these methods: Debug existing program code. Use a writable cart for trying custom code. Use an oscilloscope or other measuring tools to probe the raw signals.
Yep, just about all of those specs you'll see were either released by the companies back when they had balls, or have been reverse-engineered. I'd assume companies now would offer (incomplete) specs as part of their 'design toolkits'... or maybe not. Those SDKs tend to be rather expensive, though. That's why the XBDN or whatever it's called seems a really good initiative.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I know it's experimental and this is not a request thread, but why write yet another NES emulator? I could use a better atari 2600 emulator for the NDS (one that actually works with most flash card devices).
I know it's experimental and this is not a request thread, but why write yet another NES emulator? I could use a better atari 2600 emulator for the NDS (one that actually works with most flash card devices).
Presumably because writing a NES emulator is easier than writing an atari 2600 emulator.
Not that I really know, but as I understand it, the Atari 2600 does all video and audio in analog signal processing instead of digital logics, which makes it harder to describe and to emulate properly.
Wikipedia wrote:
For example, because of the lack of a frame buffer (discussed below), 2600 emulators must not only emulate the console, but the television as well.
And, because the NES has a lot more fascinating games than the A2600 has :P
Actually, I'd say the NES is more difficult due to having to implement the numerous mappers.
One of these days I'll finish my TG16 emulator (planned re-record) :P.
