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.

Game Boy emulator tutorials are all over the web.

This might have to be my next project then cheers

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 :(

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.

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/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

Thanks for that! You put it into a very understandable form

You're welcome.

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.

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.

Shameless plug: I gave a presentation about this at last FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-...

(otherwise @xcv123's sibling comment is very true).