These are cross-links rather than isolated facts. Each theme points back to the actual machines so you can compare an architectural idea and then immediately run examples of it.
01CPU families: cheap 8-bitters, 68000, x86 and ARM
The collection is a map of changing CPU economics. Intel's 8080 and the Z80 made CP/M practical; MOS Technology's 6502 and its derivatives underpinned KIM-1, Commodore, Atari and BBC systems. Texas Instruments followed a different path with the 16-bit TMS9900 in the TI-99/4A, bringing a minicomputer-derived register model into a cost-sensitive home machine. The Motorola 68000 then made a large linear address space and a richer register set affordable enough for Macintosh, ST and Amiga. IBM compatibility pulled the centre of gravity toward x86, while ARM later moved from Acorn's desktop research into embedded and handheld systems.
The important point is that CPU lineage does not uniquely determine a computer's character. C64, Atari XL and BBC Micro are all 6502-family machines but behave very differently because their video, sound, memory maps and operating environments are different. Macintosh, ST and Amiga share the 68000 family yet divide work between CPU and custom hardware in radically different ways.
02Custom silicon: when the peripheral becomes the personality
Early general-purpose computers could be described largely by CPU, RAM and I/O. Home computers and consoles quickly changed that. Atari's ANTIC/GTIA/POKEY complex, Commodore's VIC-II/SID pairing, Nintendo's PPU and the Amiga chipset move essential behaviour into dedicated state machines, DMA engines, sprite systems and audio generators. Emulating the CPU correctly is therefore necessary but insufficient.
Custom silicon also changed market economics. A vendor could offer effects that competitors could not reproduce simply by running the same CPU faster. Conversely, unique chips created unique software dependencies and made backwards compatibility difficult when the hardware line changed.
03Memory: 64 KB is not a simple ceiling
Eight-bit CPUs exposed a 16-bit address space, but designers repeatedly found ways to make more hardware visible than 64 KB at once. ROMs, I/O registers and RAM competed for address ranges; bank switching changed which physical memory appeared at a given address. C128 is an especially rich example because its memory-management logic supports multiple modes and must coexist with C64 compatibility and a Z80 processor.
Later 68000 and x86 systems made larger address spaces normal, but memory mapping remained central. Video RAM, ROM windows, I/O apertures, EMS/XMS-style expansion and device buffers all make “how much RAM?” a less useful question than “what can the CPU see at this address at this moment?”
04Video: from character generators to sprites, vectors and frame buffers
The exhibits span fundamentally different display models. PET and early business micros lean on character-oriented video. ZX81 famously steals CPU time to generate a television picture. Vectrex uses a vector CRT rather than a raster display. C64, Atari and consoles expose tile/sprite hardware designed around television timing. Macintosh popularised a bitmapped graphical desktop, while later PCs and handhelds normalised frame-buffer-like access combined with acceleration or dedicated 2D engines.
These models create different emulation problems: cycle timing and raster position for border tricks, palette and priority rules for sprites, scan conversion for vectors, or packed-pixel and stride rules for frame buffers. A visually plausible screenshot can still hide serious timing or memory-model inaccuracies.
05Sound: beeps, programmable generators, samples and DMA
Sound hardware evolves from simple tone generation to programmable synthesis and sample playback. The C64 SID is effectively an instrument with oscillators, filters and envelopes. Atari POKEY combines audio with other I/O functions. Consoles use purpose-built channel architectures. Amiga's Paula makes digital sample playback a normal hardware service, while the IBM-compatible world eventually treats audio as an add-in peripheral rather than a fixed part of the base machine.
Accurate audio is tightly coupled to time. If CPU, video and audio emulation advance with inconsistent clocks, pitch, tempo, buffering and interrupt timing all drift. This is why sound bugs often reveal broader scheduling problems rather than a defective waveform generator alone.
06Storage and boot: software arrives through very different machines
A monitor ROM and manually entered bytes, cassette tape, floppy disk, cartridge, ROM card, hard disk, flash memory and SD storage are not interchangeable media from an emulator's point of view. Each carries controller behaviour, geometry, timing and file-format assumptions. The storage mechanism also changes the user experience: a cartridge console expects instant mapping, while a disk computer expects a controller, a filesystem or boot sector, and often substantial mechanical latency.
The IBM PC/XT is especially important because BIOS services and standardized disk conventions helped software survive hardware changes. Commodore's serial disk drives represent the opposite extreme: intelligent peripherals with their own processors and firmware can themselves become computers that need emulation.
07Input is architecture: matrices, mice, joysticks and touchscreens
Keyboard mapping is not just a UI convenience. Vintage computers scan electrical matrices with machine-specific modifier logic; games may read joystick lines directly; Macintosh and ST software assumes a mouse-driven graphical interface; Palm relies on a resistive touchscreen and hard/soft buttons; pocket computers and graphing calculators depend on dense key matrices, shifted functions, soft menus and sometimes simultaneous key combinations. The emulated interaction path must therefore match what the firmware expects, not merely translate a browser key into a character.
This is also where browser emulation can improve access without falsifying the machine. A virtual keyboard, touch mapping, drag-and-drop disk image or PC-file transfer can be a modern front end to an accurately modelled historical input or storage path.
08Standards versus islands: compatibility is an engineering feature
CP/M demonstrated that applications could outlive one vendor's hardware if a narrow hardware-dependence layer was defined. MSX attempted a related idea for consumer computers by specifying a common architecture across manufacturers. IBM PC compatibility went further: BIOS expectations, expansion buses, DOS conventions and eventually clone chipsets created an ecosystem in which the reference platform was larger than the company that introduced it.
Proprietary platforms could still win through stronger integration, lower cost or better software — C64, Macintosh, Amiga, Game Boy and Palm all prove that. The recurring trade-off is between a controlled machine whose uniqueness can be exploited and a standard whose value comes from interchangeability and ecosystem scale.
09Portability: battery life and interaction beat desktop specifications
Portable machines force a different optimization. Sharp’s PC-1500/PC-1350 and Casio’s PB series put programming languages, battery-backed RAM, LCDs and full keyboards into calculator-sized pocket computers. Epson’s HX-20 expanded the same early-1980s low-power ideal into a self-contained portable computer with keyboard, LCD, printer and storage. Atari Portfolio later traded display size and performance for a genuinely pocketable DOS-compatible environment; Game Boy prioritised battery life, cost and software; Palm stripped the computer down to instant-on personal information and pen input.
Programmable calculators form another branch of pocket computing. HP 48GX and HP 50g are not miniature PCs; their keyboard, stack model, symbolic mathematics and long-lived software environment are the product. Portability changes what “good computer architecture” means.
10Calculators: specialised computers with unusually persistent interfaces
Programmable calculators and pocket computers compress the whole machine around a very specific workflow. Sharp and Casio pocket computers expose BASIC, assembly or C behind dense keyboards and tiny LCDs. Casio's graphing line makes the display itself part of mathematical exploration. HP's 48GX builds the machine around RPN/RPL objects and a persistent stack. TI's 68000-based symbolic line centres on algebra, graphing and downloadable software.
The remarkable engineering feature is continuity. A calculator user can keep a keyboard model, programming language and mathematical workflow for years while the underlying processor changes radically. HP's path from Saturn in the 48GX to ARM in the 50g is a particularly clear example; TI's TI-92-to-TI-89 lineage shows a 68000 computer-algebra platform being repackaged into a conventional calculator body.
11From BBC Micro to ARM handhelds
The BBC Micro itself uses a 6502-family processor, but Acorn's need for a more powerful successor led its engineers to develop the Acorn RISC Machine in the mid-1980s. That makes the BBC exhibit an architectural starting point for a processor family that later escaped the desktop market in spectacular fashion.
Game Boy Advance uses an ARM7TDMI, while HP 50g uses an ARM920T-based Samsung system-on-chip. The software environments are entirely different, yet the CPU lineage illustrates a major historical shift: efficient RISC cores became ideal embedded building blocks as computing moved into battery-powered handhelds and specialised devices.
12The browser as a preservation host: portability without redesigning the old machine
A browser-native emulator separates two concerns that conventional desktop emulators often combine. Outside the emulated machine, the browser supplies a widely available host, responsive layout, touch events, local file selection and audio/video output. Inside, the historical architecture can retain its own memory map, keyboard matrix, timers, display model and media conventions.
That separation is useful for preservation. An emulator HTML file can be kept with user-owned ROMs and software without an installer, operating-system package or app-store dependency. The same code can be designed to remain usable on a desktop computer, tablet or smartphone while virtual keyboards and machine-specific controls preserve interfaces that would otherwise disappear on touch-only devices.
13What accurate emulation actually requires
A CPU interpreter that executes opcodes is only the centre of an emulator. A useful machine model must coordinate interrupts, timers, DMA, bus-visible I/O, display scanning, audio clocks, storage controllers and user input. Some software relies on documented interfaces; demos and games often rely on exact timing or undocumented behaviour. That is why “boots the ROM” and “runs the machine convincingly” are very different milestones.
The browser adds another clock domain: JavaScript execution, animation frames, audio buffers and user events are scheduled by the host. Good emulation therefore needs explicit virtual time rather than assuming that one JavaScript loop iteration corresponds to one historical machine cycle.
Accuracy also includes the human-facing hardware. Keyboard matrices, sticky modifiers, joysticks, touch calibration, CRT/television aspect ratio, LCD geometry and display persistence can change how software behaves or how its graphics were intended to be perceived. A complete emulator therefore models the interface as part of the machine rather than treating it as decoration.
