Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How to write an emulator?
#1
Hello there. I'm a game enthusiasm and very interested in emulation. My school does not teach me C++. My teacher said that they did it several years ago, but no longer. They think C/C++ is out of date now, and teach us Java/asp.net instead. After seeing many famous PC software such as Windows and Office written in C++, and the majority of console emulators are written in C++ as well, I decide to study C++ by myself. And at last, I become a C++ programmer, although I am just a noob.

I've got a job recently, which is 'bout a C++ project. I join the project as an apprentice, with the hope someday, when I master C++, I can write an emulator on my own. But when I ask the seniors in my company whether or not they can write an console emulator, they said that it is completely a different field -- maybe something related to embedded system or processing, and if the company has such project, even experienced programmers as them must study this from the beginning. I'm really disappointed.

I know that writting an emulator is extremely difficult, depending on the complexity of the hardware to be emulated. Even a weak console as NES requires few developers working in 1 - 2 years. And one such as the PS2 requires many years with contribution of many people, and yet it isn't fully emulated -- many games are not playable. But it does not quench the hope in my breast. I still want to learn how, even if I am never be able to do it.

I really want to know where PCSX2 programmers learned to write emulators. I do not think if there is any school that teaches them to do this. Still I don't even know where to begin, what to do in progess, and what I end up with. Can anyone give me some documentations, ebooks, tips... that help me in the first step? Any help would be very appreciated.
Reply

Sponsored links

#2

Hmm, ask Bositman for a link to the google code(pcsx2 code), he will also give you a link on how to compile it. I think you can start from there.
Processor: Intel Core 2 Duo 2.8GHz
Vid Card: Geforce 9400GT
OS: Windows 7 ultimate 32-bit
Reply
#3
(09-15-2010, 03:52 PM)Livy the pixie Wrote: I know that writting an emulator is extremely difficult....
I really want to know where PCSX2 programmers learned to write emulators.

i'd find that very interesting, too.

every time is start pcsx2 it blows my mind, that there are people out there, that understand all this technical ps2 snu-snu and are capable of translating all the commands and stuff into bits and bytes the pc understands. and they all do this for free. amazing.

would be nice to hear a little backstory of how some of you got into programming emulators^^
Intel 486 DX33 33Mhz
8MB EDO Ram
S3 Graphics Trio64V+
Windows 95
Running MGS3 Snake Eater fully playable @ 0.05 fps
Reply
#4
Sounds like two questions, really. "How did you get into programming emulators?" and "What is a good starting point to learn about programming emulators?"

The second is probably more useful of a question for me to answer, since while I had read about programming emulators and knew some of the basics, I hadn't actually worked with an emulators code before pcsx2. It was more of that I wanted to run pcsx2-pg on Linux, spent a good deal of time tracking down which changes broke it, wrote guis for the new options pcsx2-pg had, submitted a bunch of patches, and eventually joined the team.

For the first, though, first, if you don't already know assembly, learn at least the basics, since you'll need to know how in order to emulate a microprocessor. You'll also want to get an idea of all the parts of a computer or console and how they interact. You may want to pick out a simple computer or console, and study it's specs, and try emulating it, or, just for practice, you could try to emulate an imaginary processor with a basic set of instructions, and go from there.

You might also look at things involving virtual machines. You can think of that as programming an emulator for a machine that doesn't exist. That has applications in real life. Infocom wrote a virtual machine, ported it to a bunch of platforms, then wrote all their games to that virtual machine, so they didn't have to port their games over multiple platforms. And when you run Java programs, that's running on a virtual machine on your computer as well...

(For the interested, if you browse around http://www.ifarchive.org/ , you'll be able to find source code to a dozen implementations of infocoms virtual machine, the z-machine, as well as documents with most of the information you would need to write your own, and lots of [free] games you can play on it.)

This topic's come up in other forums before, too. Here's a thread on the same topic, with a link to a 152 page pdf talking about how to program emulators right at the top:
http://www.emutalk.net/showthread.php?t=30272

Hopefully that helps. If not, well, there are a number of people here knowledgeable about emulators...
Reply
#5
Arcum, very interesting pdf.

Quote:I know that writting an emulator is extremely difficult....
Actually, the concept of an emulator is easy.
The real difficulty are
1/ Performance. Write a slow emulator is much more easier. Do not need to bother with advance coding (dynamic recompiler). You can emulate full timing which lead to a better accuracy.
2/ Understand what the system does. If you have the complete instruction set of a CPU (think a Rosetta stone), it is much more easier to translate instructions. The hardest part is probably the timing.

A good idea to learn hardware emulation is to learn how hardware is working concept is enough.
CPU-> while (1) fetch; decode; execute; -> then understand cache, memory, MMU etc...
Non-master CPU-> read/write registers (which are the instruction or result of the block) etc...
Reply
#6
Quote:You might also look at things involving virtual machines. You can think of that as programming an emulator for a machine that doesn't exist. That has applications in real life. Infocom wrote a virtual machine, ported it to a bunch of platforms, then wrote all their games to that virtual machine, so they didn't have to port their games over multiple platforms. And when you run Java programs, that's running on a virtual machine on your computer as well...

I have learned Java so far, and heard something called "Java virtual machine" (JVM) at the first lesson. All Java code is not compiled to a native machine code, but rather a intermediate language called "bytecode", which is then re-compiled by the JVM to native machine code. My teacher says each platform has their own version of Java Runtime Environment, which includes JVM, and all JVM does is translating bytecode to the machine code for its own platform. So I used to think of it as a "just-in-time compiler", nothing more. But you make me understand it in a different way (and more accurate of course): the so-called "Java virtual machine" is actually an inexistent machine. Sun writes an emulator for that imaginary machine on Windows & Solaris, Apple writes one for Mac OS, and many mobilephone manufacturer writes their own emulators too. And the bytecode thing is actually the native machine code for that JVM. That's the reason why Java is cross-platform, and also the reason why Java is slow than C/C++ (the same is also true for Microsoft Common Language Runtime). Interesting!

It seems that writing an emulator requires a deep understanding of hardware. Even experienced programmers in my company don't know how many components a PC has. Perhaps I should study computer hardware first. I admit that I don't know anything 'bout hardware, since all I have been taught is software programming. It will takes time, but I will try.

P.S: I wonder why Sun/Oracle doesn't manufacture a "Java Real Machine" to run Java applications faster, and why PS3 game developers do not create a "PS3 Runtime Environment" to make their games cross-platform Blink.
Reply
#7
that's really difficult to do so
Reply
#8
Quote:I wonder why Sun/Oracle doesn't manufacture a "Java Real Machine" to run Java applications faster
Honestly for what java does, it is fast. Moreover they must keep some compatibility between multiple versions. A virtual machine cost some instructions cycles. However there is an interesting property. The native compilation is done at run-time so you could add some extra optimization not possible in the static word.

Quote:Why PS3 game developers do not create a "PS3 Runtime Environment" to make their games cross-platform
It costs too much. The PS3 have 200Mb of memory. Moreover to use a maximum power of the cell they probably use some ASM. Actually standard C code is cross-platform except if you want to really use the power of your hardware.

Quote:Even experienced programmers in my company don't know how many components a PC has. Perhaps I should study computer hardware first. I admit that I don't know anything 'bout hardware, since all I have been taught is software programming.
I'm a little shocked (well I work on the hardware conception, maybe the reason ^^). It seems a F1 pilot without car notions. My opinion, HW and SW are 2 side of the same piece
Reply
#9
(09-15-2010, 03:52 PM)Livy the pixie Wrote: Hello there. I'm a game enthusiasm and very interested in emulation. My school does not teach me C++. My teacher said that they did it several years ago, but no longer. They think C/C++ is out of date now, and teach us Java/asp.net instead. After seeing many famous PC software such as Windows and Office written in C++, and the majority of console emulators are written in C++ as well, I decide to study C++ by myself. And at last, I become a C++ programmer, although I am just a noob.

My school does the same thing. There is a strong focus on Java and very-little c/c++.
I learned c++ on my own outside of my schools curriculum.

(09-15-2010, 03:52 PM)Livy the pixie Wrote: I've got a job recently, which is 'bout a C++ project. I join the project as an apprentice, with the hope someday, when I master C++, I can write an emulator on my own. But when I ask the seniors in my company whether or not they can write an console emulator, they said that it is completely a different field -- maybe something related to embedded system or processing, and if the company has such project, even experienced programmers as them must study this from the beginning. I'm really disappointed.

most programmers are not good programmers. imo to become a good programmer you need to understand what your code does at a low-level and be able to "think in code" to figure out how to code your algorithm in a way your target architecture can run optimally.

there are many coders that never bother to understand what their code is doing. they just do stuff that works (or use code someone showed them) and continue doing so. these people don't have coding talent, they just are able to get-by.

i think you need 3 qualities to be a good programmer:
1) knowledge and understanding (of your programming language, target architecture, and general algorithms)
2) experience (with your current programming language and programming in general)
3) the love for programming

its a bit surprising, but i think some 'programmers' don't even have the 3rd quality. it seems some programmers just do it to get the job done, but think of programming as tedious (at least this is the impression i get from overhearing my classmates).

(09-15-2010, 03:52 PM)Livy the pixie Wrote: I know that writting an emulator is extremely difficult, depending on the complexity of the hardware to be emulated. Even a weak console as NES requires few developers working in 1 - 2 years. And one such as the PS2 requires many years with contribution of many people, and yet it isn't fully emulated -- many games are not playable. But it does not quench the hope in my breast. I still want to learn how, even if I am never be able to do it.

you're right that an emulator can be complex. The complexity of the emulator depends on the architecture you're emulating and the capabilities of the target platform your emulator will run on.
If for example your target platform does not support features that you're emulating, you have to come up with your own software solutions or work-arounds to simulate the behavior.

I think it is a misconception that just because a system is old, it is easier to emulate. The NES for example is pretty old, but it is pretty challenging to emulate correctly. Although there are 100's of NES emulators out, no NES emulator has 100% accuracy and the most popular NES emulators still fail many homebrew accuracy-tests.

However in order for an emulator to play games you don't need to be super-accurate, just accurate enough to get the results the game wants; this is the thinking that's needed with modern emulators, as we cannot afford to be 100% accurate with everything.
Instead we have to think about how games will use features of the system, and then emulate accordingly.
Of course we try to be as accurate as possible where it matters, but its just that its unrealistic to code something like a 100% accurate ps2; no-one will ever do-so.

I have a NES emu project I'm working on, and it does take a while before your emulator is in a good enough state to run games. To get the basics coded so that you can run stuff probably takes around a month (part of that time is also spent reading and understanding the specifications of the system, as well as planning out the design of the system); but to get it working good with a handful of games takes much more time. And finally to get it working well with most-games can probably take 1~2 years as you mentioned. Part of the reason for this is that you not only need to emulate the NES console but different games have what we refer to as mappers, which essentially add new hardware which you need to emulate. (the reason for mappers is that the NES wasn't powerful enough to run a lot of the games it has, so game makers used additional hardware inside the actual NES cartridges to add more functionality to the NES; newer consoles don't have this problem since games are CD/DVD-based, and the systems are more powerful)

However there are some systems out there that are relatively easy to emulate. I was able to do the basics of a Chip-8 emulator in about 2 days, and fully finished the emulator in about a week (including Super Chip-8 support).
The Chip-8 is commonly emulated by beginners in order to learn the basics; since its kindof easy its probably a good place to start, but at the same time it never was a real system and thus has some design flaws that make games run weird even though you emulate things correctly. (the chip-8 was essentially a virtual machine that had its own instruction set including instructions to draw to screen and poll gamepad input; it didn't define any realistic cpu speed or screen refresh timings, so because of this you can have games run too fast or flicker a lot...)

(09-15-2010, 03:52 PM)Livy the pixie Wrote: I really want to know where PCSX2 programmers learned to write emulators. I do not think if there is any school that teaches them to do this. Still I don't even know where to begin, what to do in progess, and what I end up with. Can anyone give me some documentations, ebooks, tips... that help me in the first step? Any help would be very appreciated.

I started out by looking at simple parts of pcsx2's source-code and trying to understand how it worked. In the very beginning it was taking a look at pcsx2's frameskip, vu-skip, and framelimiter code, and then eventually rewriting it to work much better (this was ~2 years ago, and since then Jake has rewrote all that code again).
From there i moved on to fpu interpreters, then later vu interpreters, then the recompilers, then finally i knew enough to start my own recompiler project microVU.

This learning process takes time and its not something that happened overnight. When i first started i didn't even know c++, but i knew java and was able to guess how stuff worked.

What i will mention is that with pcsx2 as it is now, you can't really do what i did anymore. I was able to do what i did because back-then pcsx2 had a lot of crappy code; We've already rewritten most of the bad code so its hard to find small isolated crappy-code which you can improve little by little. Most of whats left are the 'hard parts' and require either big rewrites or lots of knowledge to fix.

So i suppose you might want to start out with a chip-8 emulator:
http://forums.ngemu.com/web-development-...hread.html
Then extend the chip-8 to be a super chip-8 emulator (its just a few more instructions you need to implement).

After that project, make your way over to a gameboy emulator. I haven't tried a gameboy emulator, but i think its a decent system to attempt after doing a super chip-8 emu.

at some point if you wish to truly extend your skills, you need to read other people's source code and preferably talk with other emu coders to get techniques on how to implement things optimally.
you may have for example implemented something some-way, then later learn there's a much-better way to do so.

but anyways you don't just become a good emulator coder overnight, its an experience that takes time and experience.
Check out my blog: Trashcan of Code
Reply




Users browsing this thread: 1 Guest(s)