4 ms·

How do people get into emulation? It seems like an incredibly challenging niche within software. You basically have to understand electronics and deep programm

How do people get into emulation? It seems like an incredibly challenging niche within software. You basically have to understand electronics and deep programming wizardry

PartiallyTyped 2y ago
I tried to get into it many moons ago, and the guidelines were to start from something very simple and well documented, and build your skills from there. I still have the itch but lack the time :(
OnlyMortal 2y ago
It depends what you mean by emulation. For instance, I ported a 6502 interpreter from UNIX to Classic Macintosh back in the day. This was to play SID music files. So long as it ran fast enough, clock cycle accuracy wasn’t important. It worked by calling C code from the interpreter.
immibis 2y ago
Game Boy emulator tutorials are all over the web.
- purple-leafy 2y ago
  This might have to be my next project then cheers
anthk 2y ago
CPU's are emulated on a high level way. If you can shift bits, you can understand a Z80 or a 6502 in no time.
xcv123 2y ago
You start by reading hardware documentation and you don't need to understand the machine at an electronic level. It's not a simulation of digital circuits. It doesn't need to be that complicated. An 8-bit CPU is a simple state machine with only a few bytes of state (registers). You can read the program one byte at a time and simulate whatever operation the CPU would do after reading that byte. They are very simple operations like adding and subtracting numbers, loading and storing bytes. http://www.6502.org/users/obelisk/6502/registers.html http://www.6502.org/users/obelisk/6502/registers.html http://www.6502.org/users/obelisk/6502/instructions.html http://www.6502.org/users/obelisk/6502/instructions.html Your 6502 CPU emulator would read the next few bytes of the program, interpret the bytes as an instruction, execute the instruction, which involves updating a couple of registers/counters in the CPU, doing some arithmetic or bitwise operations, and possibly loading or storing a byte of data from one location to another. This process is then repeated in an endless loop. It is a simulation of the fetch-decode-execute cycle. https://en.wikipedia.org/wiki/Instruction_cycle https://en.wikipedia.org/wiki/Instruction_cycle
- purple-leafy 2y ago
  Thanks for that! You put it into a very understandable form
  - xcv123 2y ago
    You're welcome. I learned about the basics here http://www.emulator101.com http://www.emulator101.com Then I read the docs at NESdev Wiki and eventually wrote my own NES emulator. https://www.nesdev.org/wiki/Nesdev_Wiki https://www.nesdev.org/wiki/Nesdev_Wiki If you have good documentation then you're just following the specs and turning that into code. Next level difficulty is reverse engineering the hardware, figuring out how it works when there isn't any documentation. These guys did that for NES back in the 90s and early 2000s, writing little test ROMs to see what the hardware does, in addition to whatever official or unofficial developer docs they could find.
Dessesaf 2y ago
Like anything else, gradually. You really don't have to understand any deep wizardry to get started (or, for the most part, even to finish). For the most part, you just look at a specification, and implement what it says. It requires some code architecting skill to not make a mess, but there are common patterns and it becomes a lot easier once you've built one or two emulators. And you almost never need to understand electronics. You're only emulating behavior. When someone discovered bugs in the behavior of the original hardware, you usually just need to special-case it in your emulator. It might help to know some electronics to understand how those behaviors came to be, but that's more so of historical interest than actually practical. There are certain unique challenges, but it's nothing too difficult. When there's an issue, you're usually debugging three things at once: Your understanding of the hardware, your implementation of the emulator, and the game you're emulating. It can be hard to pin down the exact problem. But here, I encourage you to just hack something together. It's not clean, but all emulators are full of special cases that try to somehow get popular games working. If a couple unclean hacks mean you can get a game working, just do so. You don't really need to exactly implement the original hardware's behavior. Just get the game working.
Aissen 2y ago
Shameless plug: I gave a presentation about this at last FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-do-you-write-an-emulator-anyway-/ https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-... (otherwise @xcv123's sibling comment is very true).

How do people get into emulation? It seems like an incredibly challenging niche within software. You basically have to understand electronics and deep programming wizardry

PartiallyTyped 2y ago

I tried to get into it many moons ago, and the guidelines were to start from something very simple and well documented, and build your skills from there. I still have the itch but lack the time :(

OnlyMortal 2y ago

It depends what you mean by emulation. For instance, I ported a 6502 interpreter from UNIX to Classic Macintosh back in the day. This was to play SID music files. So long as it ran fast enough, clock cycle accuracy wasn’t important. It worked by calling C code from the interpreter.

immibis 2y ago

Game Boy emulator tutorials are all over the web.

purple-leafy 2y ago
This might have to be my next project then cheers

anthk 2y ago

CPU's are emulated on a high level way. If you can shift bits, you can understand a Z80 or a 6502 in no time.

xcv123 2y ago

You start by reading hardware documentation and you don't need to understand the machine at an electronic level. It's not a simulation of digital circuits. It doesn't need to be that complicated. An 8-bit CPU is a simple state machine with only a few bytes of state (registers). You can read the program one byte at a time and simulate whatever operation the CPU would do after reading that byte. They are very simple operations like adding and subtracting numbers, loading and storing bytes. http://www.6502.org/users/obelisk/6502/registers.html http://www.6502.org/users/obelisk/6502/registers.html http://www.6502.org/users/obelisk/6502/instructions.html http://www.6502.org/users/obelisk/6502/instructions.html Your 6502 CPU emulator would read the next few bytes of the program, interpret the bytes as an instruction, execute the instruction, which involves updating a couple of registers/counters in the CPU, doing some arithmetic or bitwise operations, and possibly loading or storing a byte of data from one location to another. This process is then repeated in an endless loop. It is a simulation of the fetch-decode-execute cycle. https://en.wikipedia.org/wiki/Instruction_cycle https://en.wikipedia.org/wiki/Instruction_cycle

purple-leafy 2y ago
Thanks for that! You put it into a very understandable form
- xcv123 2y ago
  You're welcome. I learned about the basics here http://www.emulator101.com http://www.emulator101.com Then I read the docs at NESdev Wiki and eventually wrote my own NES emulator. https://www.nesdev.org/wiki/Nesdev_Wiki https://www.nesdev.org/wiki/Nesdev_Wiki If you have good documentation then you're just following the specs and turning that into code. Next level difficulty is reverse engineering the hardware, figuring out how it works when there isn't any documentation. These guys did that for NES back in the 90s and early 2000s, writing little test ROMs to see what the hardware does, in addition to whatever official or unofficial developer docs they could find.

Dessesaf 2y ago

Like anything else, gradually. You really don't have to understand any deep wizardry to get started (or, for the most part, even to finish). For the most part, you just look at a specification, and implement what it says. It requires some code architecting skill to not make a mess, but there are common patterns and it becomes a lot easier once you've built one or two emulators. And you almost never need to understand electronics. You're only emulating behavior. When someone discovered bugs in the behavior of the original hardware, you usually just need to special-case it in your emulator. It might help to know some electronics to understand how those behaviors came to be, but that's more so of historical interest than actually practical. There are certain unique challenges, but it's nothing too difficult. When there's an issue, you're usually debugging three things at once: Your understanding of the hardware, your implementation of the emulator, and the game you're emulating. It can be hard to pin down the exact problem. But here, I encourage you to just hack something together. It's not clean, but all emulators are full of special cases that try to somehow get popular games working. If a couple unclean hacks mean you can get a game working, just do so. You don't really need to exactly implement the original hardware's behavior. Just get the game working.

Aissen 2y ago

Shameless plug: I gave a presentation about this at last FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-do-you-write-an-emulator-anyway-/ https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-... (otherwise @xcv123's sibling comment is very true).