Posted: 7/23/2017 7:41 PM
Post subject: What skills and knowledge are needed to code an emulator?
Quote
ClearSky
He/Him
Joined: 7/18/2017
Posts: 16
I've been wondering about this. What skills and knowledge does one need to learn to be able to code an emulator, or at least understand what is going on in the source code? Do you need to be a computer scientist or a software engineer to be able to do that? Could someone post a list, in order of importance, of topics that one needs to learn to be able to get involved in making emulators? Thanks.
Posted: 7/23/2017 7:50 PM
Quote
Bobo_the_King
Player (79)
Joined: 8/5/2007
Posts: 865
I've never coded an emulator myself, but I'd start with assembly language, since your main goal is emulating the system's processor. The other thing you should probably understand is hardware architecture so you know how all the pieces fit together. Far more learned people will be along to answer your question shortly.
Posted: 7/23/2017 7:53 PM
Quote
DeHackEd
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
This is such a vague topic for someone who clearly doesn't know about software development. First thing, I'd make sure you know how to make a simple game like Pong. You need to be able to render graphics pixel-by-pixel on-screen into a viewport and accept inputs from the keyboard in raw format (as opposed to the OS processing keypresses for you, such as ignoring Shift when pressed all by itself). Next learn how the hardware works. You'll need details about how the memory is mapped, how the CPU accesses memory, how the graphics chip works, etc. For example on the SNES the sound, graphics and main CPU are basically independent systems. Even if you crash the CPU the game keeps playing music and keeps the image on-screen in spite of the SNES not having a framebuffer. You can optimize it later, but first you have to run well enough to convince a game that it's running on real hardware. Make sure it can't write to the ROM and actually modify it. Make sure that if something is changed on the GPU half-way through a frame that the image is half old and half new. And this is just off the top of my head. It's a huge undertaking to simulate all the hardware of a console.
Posted: 7/23/2017 8:08 PM
Quote
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
First you will need a decent understanding of programming and programming languages. The languages you can choose from depends on the system you wish to emulate and how accurately you want to emulate it. For older systems and with decent accuracy you can get away with almost any language. For newer systems or high accuracy, the options decrease. Second, you need to have a good idea about hardware architecture and how to read technical manuals / specifications, there are many types of chips and buses you will come across, which you will need to emulate to certain degrees for the full emulated system to become functional. Third, the assembly language, and translating from binary data back to text. Because you will encounter bugs, and it helps debugging immensely. You may also need to develop your own ROMs to trace bugs and/or test your implementations. Which leads me to: Fourth, compiler theory, because a lot of compilers have cryptic documentation and understanding how a compiler functions on a deeper level than "source code goes in, binary comes out" will be very important. If you make a really bad choice of console, you may also have to write the compiler. Fifth, which by now should be unnecessary: Working with multiple operating systems, as some tools are only available on Windows or Linux, or even require specific versions of these operating systems to function. Which may make point 4 appealing again. Finally, don't expect to make money from this, and don't do it for fame either. Do it because you find it interesting.
Posted: 7/23/2017 8:57 PM
Quote
p4wn3r
Player (42)
Joined: 12/27/2008
Posts: 873
Location: Germany
Lucky TAS of 2011 Gameboy TAS of 2011
It mostly depends on what you mean by "coding an emulator". It might seem pedantic, but when you start understanding how computers work, you will find out that they are divided on a large number of moving parts, and the skills needed to contribute to each of these parts may differ dramatically. In the case of emulators, you can divide them into essentially two parts: the backend (or core), which abstract the hardware of the machine it is emulating, and the frontend which does things closer to the user, like keeping a list of recent roms, loading and saving the program state, applying cheats, etc. If you want to contribute to the frontend, it's much simpler. An emulator frontend is just a GUI application that needs to do something that a simple game would do, like polling input from keyboard or joypads, emitting audio data, and rendering video. If you're interested in writing a backend, then you basically need to understand how the hardware you're trying to emulate works, and depending on performance constraints the entire architecture might change. For example, most game boy emulators use simple C functions to decode CPU instructions, while the PS3 emulator uses a process similar to just-in-time compilation, because the former approach is too slow. If you're starting now, I strongly advise you to not code an emulator from scratch. Say, if you just want to write an interpreter for some CPU, pick an open source one, and replace its interpreter code with yours. This will be much easier for you to test, and then later you can migrate this code to a program you write.
Posted: 7/23/2017 9:10 PM
(Edited: 1/19/2021 6:48 PM)
Quote
scrimpeh
Editor, Skilled player (1404)
Joined: 3/31/2010
Posts: 2086
TAS of 2017 First edition TAS of 2017 PSX TAS of 2017
I should preface what I say with that I've only really worked with NES emulation, which is admittedly a very simple console. So my experience is somewhat limited. Emulation is very large topic, and writing an emulator is a pretty difficult undertaking. There are a bunch of different facets to consider if you want to get into emulator coding. To begin with, you should have an impeccable grasp on the system you're trying to emulate. Each console is comprised of many different components, such as the CPU, RAM, Video Processor, Control Input and others. You should know exactly what components your system needs to emulate, and how you would go about emulating each and every single one of them. Start by asking how you would represent something like RAM in your own emulator. How would you emulate the CPU state and the CPU opcodes? For me, personally, I started homebrewing NES games (or trying to, anyhow) long before I even thought about writing an emulator. Having this kind of inside perspective before going in helps immensely. To actually build a functional core, you need to connect all of your components to interface like they would on real hardware. How do you construct your own emulator architecture and timing model around the system architecture? On consoles like the NES, this is relatively simple, on more complex systems, it's not. If you want to write an actually usable emulator, you're gonna need some kind of interface for the user to interact with. There's a bunch of different problems to solve here, like writing a GUI, loading a ROM, getting user input, getting visual and audio output or writing advanced features like save states, movie recording or debugging tools. These problems are all fairly distinct and don't have much to do with emulation directly. Instead, they are more about your ability to program a multimedia application in general. Optimization is also a pretty large concern for more advanced emulators, but in the beginning, I wouldn't focus on it. Personally, if you want to start, I'd recommend by starting out simple and looking at a system such as the NES or GameBoy, as these are not only very simple systems, but they are very well understood and documented also. You can find many resources on emulating them online. Obviously, being adept at a suitable programming language like C, C++ or others is vital as well. You can check out the source code of existing emulators also if you're stuck, but be warned, some codebases are hell. I hope this was kinda helpful.
Posted: 7/23/2017 11:49 PM
Post subject: Re: What skills and knowledge are needed to code an emulator?
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
ClearSky wrote:
I've been wondering about this. What skills and knowledge does one need to learn to be able to code an emulator, or at least understand what is going on in the source code?
Divide the problem into sub-problems until the problems become trivial; then put the solutions together. This means that if you want to create your own emulator, after learning about the console you must start at the bottom (the CPU) and work your way up. Don't start at the GUI and "work your way down". Anyway, here's a short introduction:
  1. An emulator recreates a video game console. It does that by simulating the functions of the hardware components. (Video game consoles are just computers - though not IBM compatible - they have microprocessors (CPU) and memory chips (ROM, RAM) and digital signal processors (DSP) and digital-to-analog converters (DAC) just like a PC.)
  2. It turns out that the CPU is the most important piece, and about the most important thing it can do is adding two numbers. → These two numbers are stored in registers; find out what registers exactly are available on your console's CPU. → Oops, first you need to know what CPU you're dealing with. → Looks like a CPU can only add numbers of a certain length, like 8, 16, 32 or 64 bits. (This is so important that we've named entire video game console generations after them.) → Note that they can also detect if the result overflows the allowed number of bits.
  3. CPUs can also subtract numbers; they just make one of them negative and add them together.
  4. CPUs can also compare numbers; they just subtract them and look if the result was zero. (There's more stuff you can do with the result, like finding out which number was larger.)
  5. Adding or subtracting only the same two numbers all the time is boring, so there's a whole infrastructure for feeding new values to the CPU. On the CPU there's usually one physical pin per bit, and the voltage level on that pin determines if it's 0 or 1. (Note that this may be inverted.) This set of pins is the data bus.
  6. Theoretically the data bus could be connected to anything, but in practice each data bus line is connected to a memory chip that provides the numbers to the CPU. This chip also needs a number to select one of its memory cells, so there's a second set of lines (the address bus) going into the memory chip. → The number of lines in the address bus roughly determines how much memory can be used by the system. It can (and often is) different from the data bus width.
  7. You might think that with all these pins you could directly select a cell in the memory chip and directly instruct the CPU what to do with the number going into (or out of) the CPU; turns out that it's much faster to also give the CPU address bus pins, connect the memory chip's address bus to these pins, and store instructions for the CPU in the memory chip alongside the data. → The instructions are called opcodes, and the CPU has a special register called program counter (PC) to keep track of its position in the instruction stream.
  8. The opcodes (which are themselves just numbers, most often 1 byte in size) plus their operands form the machine language of the CPU. Writings programs in this machine language is extremely tedious (basically it would amount to putting a sequence of hex numbers into memory), but this is in fact what is involved in creating an ACE TAS. → The human-readable translation of machine language is assembly code (ASM), and this is what people used to write their games in. (At least until about the 32-bit era.) → When you look at a game's ROM file in a hex editor, you see its machine language code. It can be automatically translated ("disassembled") back to ASM, but the original identifiers are lost and making sense of the code takes lots of time.
  9. You'll see that the game code seems to read from and write to special addresses. The truth is that there are often much more addresses available to the CPU than how much memory is installed in the system. In fact the address bus and the data bus are not only connected to "the memory chip" mentioned above, but also to other devices like RAM chips, video chips, audio chips, or even the controller port connectors. → These extra addresses are listed in video game console-specific memory maps. → What numbers can be sent to or received from these addresses, and when, is discussed in the programming manual for a particular video game console, written by the manufacturer (or by hackers).
  10. Emulating a game means creating variables to record the state of every component in the system, and then looking at the game's instruction stream and changing those variables accordingly. The GUI sets the variables that record the state of the input devices, and reads out the variables that record the state of the video/audio output.
ClearSky wrote:
Do you need to be a computer scientist or a software engineer to be able to do that?
No. If you can write programs and if you can understand the programming manuals for your chosen console then you can in theory also write an emulator.