Emulators, cores, and the architecture behind preserving and playing classic games today.
Emulator software and the copyrighted files it needs to run are two separate legal questions with two separate answers — and conflating them is where most confusion about 'is emulation legal' comes from.
The time between pressing a button and seeing the result on screen passes through more stages than most players realize — and emulation adds a few of its own on top of the ones a real console already had.
Both let you run software that wasn't written for the machine in front of you — but one translates between two different instruction sets, and the other doesn't translate at all.
A 256x224 image was never meant to be seen as a grid of hard, discrete pixels. Recreating how it actually looked on the display it was designed for is its own genuine technical problem.
A ROM file isn't downloaded into existence — it's read directly off the memory chips inside a real cartridge, with the same care a museum takes digitizing a fragile original.
The internet has unavoidable latency. Rollback netcode doesn't eliminate it — it hides it, by having both players simulate a guessed future and quietly correcting the guess when reality disagrees.
RetroArch supports dozens of systems without reimplementing shaders, netplay, or rewind for each one — because the emulator logic and everything around it are deliberately different programs.
A save state isn't a save file — it's a snapshot of literally everything, taken mid-execution. That distinction is why it's so powerful, and why it's so fragile across versions.
'Runs the game correctly' and 'matches the original hardware cycle-for-cycle' are very different bars. Most emulation clears the first one easily — the second one has taken decades of reverse engineering.
Every emulator has to answer the same question: how do you run code written for one processor on a completely different one? Two fundamentally different answers, and why most serious emulators eventually need both.