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.
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.
'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.
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.
Characters look too wide, too thin, or the image doesn't fill the screen correctly. This almost always traces to a pixel-aspect-ratio setting, not the emulator core rendering incorrectly.
The core loads but the game never appears — just a black screen, or an immediate crash back to the menu. Here's how to isolate whether it's the ROM, the core, or your video configuration.
Your character walks by itself with the stick untouched, or a full push barely registers. This is distinct from a controller not being detected at all — it's a calibration problem, and it's fixable in software.
A console emulator refuses to boot anything, citing a missing or invalid BIOS file. Here's what these files actually are, why an emulator needs them at all, and how to fix a checksum mismatch.
A save state that worked before an update now fails to load, or loads into a corrupted state. This is expected behavior given how save states actually work — here's what to do about it.
A frame-perfect run suddenly hitches every time a new visual effect appears on screen. It's not a savestate or performance problem — it's your GPU driver compiling a shader for the first time, mid-frame.