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
You basically have to understand electronics and deep programming wizardry
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.
http://www.6502.org/users/obelisk/6502/registers.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.
I learned about the basics here 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
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.
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.
(otherwise @xcv123's sibling comment is very true).