This seems to be a popular resource about how they work.
TL;DR - The architecture is totally different, and this takes a lot of parallel resources to achieve the original architecture.
The CPU architecture for game consoles is often somewhat exotic compared with your average desktop machine. Emulation means to perform in software everything that the original hardware did. That is, while the original console may have had dedicated graphics, audio, etc. chips as well as a CPU with a different instruction set, the emulator must perform all the functions of these parallel resources at speed.
Unless the console's GPU is old, it
almost certainly must be emulated on
the GPU of the host machine, as modern
graphics cards, even cheap ones, have
many times the throughput (for
graphics workloads) of even the most
expensive multicore CPUs. Compounding
this difficulty is the fact that
communication between CPU, GPU, any
other onboard DSPs, and memory was
probably highly optimized on the
console to take advantage of the
specifics of the hardware
configuration, and therefore these
resources must be rate-matched as
Compounding all these difficulties,
usually little is known about the
specifics of the console's hardware,
as this is kept very much under wraps
by design. Reverse engineering is
getting less and less feasible for
hobbyists to do.
To put things into
perspective, an architectural
simulator (a program which can run,
for example, a PowerPC program on an
x86 machine and collect all sorts of
statistics about it) might run between
1000x and 100000x slower than
real-time. An RTL simulation (a
simulation of all the gates and
flip-flops that make up a chip) of a
modern CPU can usually only run
between 10Hz and a few hundred Hz.
Even very optimized emulation is
likely to be between 10 and 100 times
slower than native code, thus limiting
what can be emulated convincingly
today (particularly given the
real-time interactivity implied by a
game console emulator).