Real PCs from the 8088 to the Pentium era, running in your browser.

Quick start

Launch emulator opens the app. The loading card boots the WebAssembly core, then scans this server's /roms directory — the exact directory layout a desktop PCem install uses. The footer of the left sidebar shows the result: ROMs: N of 97 machines ready. A machine appears in the editor only when its complete ROM set was found.

1. Boot something hosted here: use a card in Ready-to-boot systems — it opens the emulator with that machine's profile and boots it automatically.
2. Or build your own: in the emulator, click + New, pick a machine on the Machine tab, attach media on the Media tab, then Save system and Boot from its sidebar card.

Your systems are saved in this browser (localStorage) and reappear on the next visit. Media you attach from local files is re-attached per session — the profile remembers the slot, you re-pick the file.

This page

The cards under Ready-to-boot systems are exported machines hosted on this site. Each card's Boot this machine → link carries a ?system= deep link: the emulator fetches the machine's profile.json, restores its CMOS, attaches its disks lazily (nothing big downloads up front) and boots.

• Your session is yours. Everything the guest writes to disk stays in your browser's memory for that session. Close the tab and the hosted machine is exactly as published for the next visitor.
• Linked machines aren't saved to your systems list automatically — they run as one-off sessions. Build your own copy in the emulator if you want to keep one.

Systems sidebar

The left rail is the systems manager — every machine you've built, as a card.

• + New opens the machine editor with a fresh profile.
• ⇩ (Import) loads a profile .json you exported earlier.

Each system card

ROMs footer

ROMs: N of 97 machines ready counts machines whose full ROM set was found on the server. After adding files to /roms, click Rescan — no reload needed. ROMs are fetched on demand, straight from the server, exactly like the desktop build reads its roms folder.

Machine tab

The editor is generated from the same hardware tables the native PCem GUI reads, so everything here has a desktop counterpart.

• Machine — the motherboard/BIOS model. Only machines whose ROM set is on the server are listed. The ⚙ button next to it opens the board's own options when it has any (same dialog the desktop version generates).
• CPU family / CPU / FPU — what this board accepts, from PCem's CPU tables. Fast models carry honest cost labels: “— demanding” (≥60 MHz-class) and “— very demanding” (≥120 MHz-class) mean the browser may not hold 100% speed. Start slower; the status bar tells you what your host actually achieves.
• Memory — sized to the machine (XT-class machines count KB, AT-class MB, stepping at the board's granularity).
• Wait states — 8088/8086-era memory timing. Default is correct unless you know the software needs otherwise.
• Mouse — serial (Microsoft 2-button / Logitech 3-button / Intellimouse), PS/2 flavours, Amstrad, Olivetti M24, MSystems. Match what the guest OS's driver expects; DOS setups usually want a serial Microsoft mouse.
• CPU recompiler — optional, per system, 386+. It converts hot guest code to WebAssembly at runtime and is verified instruction-for-instruction against the interpreter. It wins clearly on tight compute (number crunching, inner loops) but the per-block overhead makes a Windows 9x desktop slower — the interpreter is the honest default. Tick it only if the status bar measures better for your workload.

Display tab

• Video card — every card the desktop build registers, plus Built-in video on machines that have it (fixed-video machines lock the select). The ⚙ opens the card's own options (memory size, refresh, card-specific toggles) generated from its device table.
• Video speed — how fast the emulated bus lets the card go, from 8-bit bus to Fast VLB/PCI. Default picks the card's period-correct setting; raising it can help software that's video-bound, at the cost of authenticity.
• 3Dfx Voodoo add-on card — a PCI board, so it's only available on PCI machines (greyed out elsewhere, same rule as the desktop GUI). Configure… sets the model, framebuffer and texture memory, bilinear filtering, and how many render threads the rasteriser may use. The pixel pipeline is recompiled to WebAssembly at runtime and oracle-verified against PCem's reference rasteriser.

Sound tab

• Sound card — AdLib through SB16/AWE32-class, from the same device list as the desktop build. The ⚙ dialog is where the card's address / IRQ / DMA / OPL options live — the values your DOS SET BLASTER line and game setup programs must match. It's also where MIDI out device appears once WebMIDI is enabled (see Input / Network).
• Game Blaster / Gravis Ultrasound / SSI-2001 — extra boards that can sit alongside the main card, like real ISA slots.

Storage tab

• HDD controller — MFM, ESDI, IDE or SCSI-class controllers appropriate to the era, with a ⚙ for controllers that have options (e.g. the XTIDE's BIOS address). The controller decides how many drives exist and how big they can be — and the CD-ROM drive rides the IDE bus, so an IDE-class controller is what makes the CD drive exist at all.
• Drive A: / B: type — the physical floppy drive fitted: 5.25" 360k / 1.2M (incl. dual-RPM), 3.5" 720k / 1.44M / 3-mode / 2.88M, or Disabled. The drive must be able to read the image you insert (a 1.2M image needs a 1.2M 5.25" drive). Disabled drives disappear from the Media tab and the 💿 Media menu.
• The panel below lists attached hard disks with their geometry — attach the images themselves on the Media tab.

Media tab

Nothing here uploads anywhere — local files are read in place by your browser.

Floppy A: / B:

• Choose local image… accepts .img .ima .fdi .dsk .360 .720 .12 .144. Floppies are staged into the emulator's in-memory file system (they're small).
• Download saves the image back to your computer including everything the guest wrote to it this session.
• Eject empties the slot.

Hard disk 0 / 1

• Local files attach lazily — no copy, no meaningful size limit: the emulator reads 128 KB blocks on demand, so an 8 GB image boots in seconds. Guest writes go to a session-only overlay; your original file is never modified.
• Geometry (C/H/S) is parsed from VHD footers or guessed from raw image size, and can be edited — it must match what the guest OS was installed with.
• VHD support: fixed VHDs work natively (and Download returns a valid VHD). Dynamic VHDs only work up to 256 MB (they must be staged into memory — convert bigger ones to fixed/raw). Differencing VHDs are not supported.
• Create blank… makes a zeroed image (up to 2047 MB) with sensible geometry — FDISK/format it in the guest like a real new drive.
• Download image streams the disk out with this session's writes merged in — the way you keep an installed OS.

CD-ROM

• A single .iso attaches lazily from your local file at any size — the header is pre-read so mounting is instant.
• For .cue/.bin discs, use the 💿 Media menu while the machine runs — it lets you select the .cue and its .bin files together.

Input / Network tab

Joystick & gamepad

• Emulated joystick — what the guest sees on the game port (2-button, 4-button, flightstick-with-hat types, etc.). The game port itself comes with the sound card.
• Use host gamepads — connected pads map 1:1 onto the emulated stick: left stick → axes 0/1, right stick → axes 2/3, buttons in gamepad order, d-pad → the POV hat on stick types that have one. Connect a pad and press any button so the browser exposes it.

MIDI output

Enable MIDI output… asks the browser for WebMIDI access, then lists your synths (hardware or software). Pick the output in the sound card's ⚙ dialog under MIDI out device. This routes the emulated MPU-401 — General MIDI music in DOS games via SB16/AWE32 — to a real synth.

Network

• Network card: on PCI machines pick the Realtek RTL8029AS — it's Plug & Play and Windows 9x sets it up by itself. The NE2000 is legacy ISA (real ones were too): add it in Windows via Add New Hardware → “Novell/Anthem NE2000 Compatible”, then set I/O 300–31F, IRQ 10 in Device Manager. DOS packet drivers take the same values: ne2000.com 0x60 10 0x300.
• MAC address: every machine needs its own on a shared relay — Randomize makes one.

Screen, mouse & keyboard

• Mouse capture: click the screen to capture the mouse (pointer lock — the guest gets relative movement, exactly what DOS/Win9x drivers expect). Ctrl+End releases it, mirroring native PCem. The hint pill under the screen reminds you.
• Keyboard goes to the guest while the screen has focus. Switching away from the tab releases everything, so no stuck keys when you come back.
• Aspect & scaling: the canvas presents at the aspect ratio the emulated card asks for (CGA line-doubling included), scaled to fit. ⛶ goes fullscreen.

The status bar, left to right

Hot-swapping media 💿

The 💿 Media button in the status bar is the disc tray of the running machine. Swaps are live: the guest OS receives a real media-change notification (the SCSI “medium may have changed” attention, same as native PCem's CD menu), so installers that ask for disc 2 or disk 2 detect the swap and carry on. No restart, ever.

• Rows: one per floppy drive fitted (A:, and B: if enabled on the Storage tab) plus the CD-ROM. Each shows what's inserted, with Load… and Eject.
• CD — single .iso: mounts instantly, read lazily from your local file at any size. Nothing is copied.
• CD — .cue/.bin: in the file picker, select the .cue together with its .bin file(s) (Ctrl-click) — the set is staged and the .cue mounted as one disc.
• Floppies: pick a new image and it's in the drive — mid-install disk swaps work the way they did in 1994, minus the drive noise.
• Eject leaves the drive empty — some installers genuinely want the disc out before they continue.

Prefer the full dialog? Configure on the running system's card works too: floppy/CD image changes apply the moment you save, and a toast confirms what was swapped. Everything else (CPU, RAM, cards, hard disks…) is queued for the next boot — hard disks can't hot-swap because IDE geometry binds at reset, exactly like the real machine.

Export & deep links

Exporting a system

Export on a system card writes a self-contained, hostable folder (Chromium-family browsers — it uses the folder picker):

• profile.json — the hardware profile with a media manifest pointing at the files below.
• Every disk image, with your session's guest writes merged in (fixed VHDs come out as valid VHDs). Floppies and CDs included.
• Saved CMOS (.nvr) so the BIOS remembers its setup.
• LINK.txt — the exact URL recipe for wherever you upload the folder.

The deep link

Upload the folder anywhere static (same origin as the emulator, or CORS-enabled) and share pcem/?system=…/profile.json. Visitors boot your exact machine; their changes stay in their own browser session — your hosted images are read-only. Every visitor gets a fresh random MAC, so several people on the shared relay LAN don't collide.

Performance

PCem is cycle-paced: emulation cost scales with the guest's clock speed, not with what the guest is doing. A Pentium 200 costs the browser the same whether it idles at the DOS prompt or runs Quake. That's why:

• Speed % is the honest number. 100% means the guest lives in real time — smooth audio, correct game pacing. Below that, everything in the guest slows uniformly (it isn't “lag”; it's a slower universe).
• CPU choice is the main lever. The editor labels expensive models (demanding / very demanding). If the status bar can't hold ~100%, configure a slower CPU — a solid Pentium 75 beats a stuttering 166.
• The recompiler is situational: clear wins on tight compute, slower on desktop-y workloads (Win9x idle loops, I/O-heavy code). Measure with the status bar; a differential oracle keeps it bit-exact either way.
• Voodoo render threads (Voodoo ⚙) spread the rasteriser across cores — 2 is a good desktop default.
• Underspeed is announced. If a machine can't sustain ~90% for a stretch, a one-time toast says so and points at the fix, instead of letting it stutter silently.
• Keep the tab in the foreground for full speed — browsers throttle background tabs.

Troubleshooting

Privacy & data

• Nothing you attach is uploaded. Local images are read in place with the browser's File API; staged copies live in the tab's memory and die with it.
• Guest disk writes never touch your files. They live in a session overlay; the only way they reach your computer is when you click Download/Export.
• Profiles (hardware descriptions, no disk contents) are stored in this browser's localStorage.
• Networking is opt-in per machine. When enabled, the guest's LAN frames go to the relay you chose — the shared public one, your own, or tabs-only which never leaves your browser. Everything else is client-side; the server only serves static files and ROMs.