WonderSift

Tag: Retro Computing

  • Jurassic Park’s Computers Were Real—and Stranger Than the Movie

    Jurassic Park’s Computers Were Real—and Stranger Than the Movie

    For a certain generation, the most thrilling computer lesson of the 1990s arrived with alarms blaring and velociraptors nearby. Lex sits down at a terminal, looks at a strange three-dimensional display, and recognizes it: “It’s a Unix system.” The line became a joke because the interface looked exactly like the sort of luminous Hollywood invention that computers never actually used.

    Except this one was real. The program was fsn, an experimental file-system navigator from Silicon Graphics. And it was not the only authentic machine in Jurassic Park. Contemporary reporting names Apple and SGI hardware on the set, while Fabien Sanglard has painstakingly matched several models to individual scenes. The control room is less a pile of props than a very expensive 1993 showroom—with dinosaurs.

    The trailer laptop was small, serious, and very new

    In the park trailer, the computer that helps reveal the approaching danger is an Apple PowerBook. A 1993 Washington Post report confirms the brand family; Sanglard identifies the specific machine on screen as a PowerBook 100. Apple had introduced that compact model in October 1991, so it still felt strikingly modern during production.

    The PowerBook 100 was modest even by later laptop standards: a 16 MHz Motorola 68000 processor and a 640-by-400 monochrome display. Its usefulness in the scene was not raw speed but portability. In a movie about advanced systems breaking loose, the laptop could travel to the danger instead of waiting safely in an office.

    The control room mixed Macs with Silicon Graphics muscle

    Back at headquarters, the desks held Macintosh Quadras alongside Silicon Graphics workstations. The Quadra 700, introduced in 1991, paired a 25 MHz Motorola 68040 processor with built-in Ethernet. It was a high-end desktop that could plausibly sit at the center of a networked operation, not a painted plastic box pretending to be one.

    The SGI machines were the more exotic visitors. Contemporary production reporting names Indigo Elan and IRIS Crimson systems on the set. SGI specialized in three-dimensional graphics, and its machines ran IRIX, the company’s Unix operating system. Sanglard’s scene study supplies more precise placements, but a visible case does not prove its exact internal configuration—or that an actor was driving every picture on its monitor.

    fsn was real, although it never ruled the desktop

    Lex’s glowing landscape of towers and corridors was not invented by a prop department. Silicon Graphics described fsn as a three-dimensional navigator for the IRIX file system and explicitly noted its appearance in Jurassic Park. It turned folders and files into shapes that a user could travel around, making ordinary directory browsing look like a flight through a tiny city.

    That does not mean Unix users spent the 1990s swooping through neon folders. SGI called fsn a prototype and an experiment, not a complete commercial product. The scene is accurate in the most entertaining possible way: Lex recognizes the operating environment, then encounters an unusual interface that really did exist. Hollywood selected the flashy edge case, but it did not simply fabricate one.

    Movie myth / hardware fact

    The screen was not a generic Hollywood invention. It was SGI’s experimental fsn. But prototype software running on real machines still does not prove that every nearby keyboard drove every display live; contemporary accounts describe more than one screen workflow.

    A field guide to the park’s computers

    Four clues for separating production-confirmed hardware from later frame-by-frame identification.

    PowerBook 100

    The 1993 report confirms a PowerBook; Sanglard identifies the compact trailer laptop as the 100 model.

    Quadra 700

    Real control-room Quadras are production-confirmed. Apple records a 25 MHz 68040 and built-in Ethernet.

    SGI Indigo / Crimson

    Production reporting names both SGI families. Sanglard’s closer model-to-shot matches remain attributed analysis.

    fsn / CM-5 context

    fsn was real prototype software. The red-lit background included a loaned CM-5 shell, not proof of a live supercomputer.

    Those red lights came with an important asterisk

    The control room’s blinking red cabinets evoke the Thinking Machines Connection Machine 5, one of the era’s most recognizable supercomputer designs. A working CM-5 was a parallel system built from many processing nodes; NCAR’s 32-node “Littlebear,” received in 1993, ran a Sun-based Unix environment.

    But the machines behind the actors should not be promoted to full supercomputer status. The contemporary report describes a CM-5 shell loaned to the production. That makes the silhouette authentic while leaving the computing power offstage. It is a perfect bit of set dressing: real industrial design, carefully deployed, without pretending the entire installation was calculating dinosaur logistics between takes.

    Real hardware, two accounts of how the screens worked

    The uncontested point is that at least some display imagery came from systems positioned behind or beside the set, not necessarily from the chassis under each monitor. The Post reported that SGIs behind the Los Angeles set generated displays in real time in response to instructions actors typed on the keyboards. A making-of account quoted by Sanglard offers a different production detail: animations prepared over six months were routed by adjacent operators responding to radio cues.

    The sources do not show whether those accounts describe different scenes or workflows, so we cannot flatten them into one system. Both reveal clever filmmaking: actors performed amid real contemporary gear while specialists out of frame helped the displays hit their dramatic beats. That is subtler than saying every keyboard drove its nearby workstation—and more interesting than dismissing every screen as canned playback.

    The set computers and the dinosaur computers had different jobs

    One more boundary matters. The Macs and SGIs seen inside the fictional park belong to the set story. Industrial Light & Magic also used Silicon Graphics systems in the separate effects pipeline that helped create the dinosaurs. The two groups share a manufacturer and a moment in computing history, but they are not interchangeable. One sold the illusion of a technologically ambitious park; the other helped manufacture the creatures threatening it.

    That distinction is why the computer scenes still reward close viewing. They are neither a documentary inventory nor a random wall of blinking props. They capture a brief era when graphical workstations, networked Macs, experimental interfaces, and supercomputer styling all looked like a plausible route to the future. The park failed spectacularly, but its computer department had excellent taste.

    Primary sources and further reading

  • Tiny Emulators Turns Your Browser Into an 8-Bit Time Machine

    Tiny Emulators Turns Your Browser Into an 8-Bit Time Machine

    AI-generated editorial concept image: WonderSift.

    The first thing you meet is a blank screen and a blinking cursor. Then comes a chirp, a blocky menu, or the faint sensation that you should be hunting for a cassette deck. Except there is no cassette deck. There is not even an installation wizard. You are staring at an entire 8-bit computer squeezed into a browser tab.

    Tiny Emulators offers one gallery, many vintage machines, and almost no ceremony. The better story sits under the hood: old hardware, modern WebAssembly, and unusually tidy open-source code meet in the middle.

    A whole computer, flattened into a tab

    The core chips repository is not a folder of game downloads. It describes itself as a toolbox of chip emulators, helper code, and complete embeddable systems written as dependency-free C headers. A companion project, chips-test, contains tests and sample emulators. Its README points to Tiny Emulators as the live home of those examples compiled to WebAssembly.

    The deployment code packages each demo's .wasm and JavaScript files into the site. That makes local, client-side execution a reasonable inference from the architecture, not a marketing slogan. The repositories also document separate native desktop builds. Those sample builds have prerequisites even though the core chips headers themselves are described as dependency-free.

    Browser emulation is not new, and Tiny Emulators did not invent it. What feels special is the clean bridge from readable source code to a machine you can poke five seconds later.

    From C headers to a living browser tab

    The project’s documented build path, simplified.

    01 · Model
    C headers
    Chip and system models live in the open-source chips project.

    02 · Build
    Examples
    Tests and sample emulators are assembled in chips-test.

    03 · Package
    WASM + JavaScript
    WebAssembly modules and browser glue are packaged for the site.

    04 · Explore
    Browser tab
    Client-side execution is a reasonable inference from that architecture.

    Remember: Open-source emulator code does not automatically grant rights to every ROM, game, firmware, tape, or disk image.

    Nostalgia's guest list just got more interesting

    The current gallery includes familiar names: Commodore VIC-20 and C64, ZX Spectrum 48K and 128, Amstrad CPC464 and CPC6128, and Acorn Atom. Then the tour takes a welcome turn into machines that appear less often in English-language retro roundups: KC85/2, KC85/3, KC85/4, KC Compact, LC-80, Robotron Z1013, Z9001 with BASIC and RAM modules, and KC87.

    There are also visual remixes of the 6502, Z80, and 2A03 processors. In other words, this is not only a C64-versus-Spectrum reunion. It is a small museum where home computing, education, regional manufacturing, and processor design share a hallway.

    Calling these “full computers” needs one useful asterisk. The project models a CPU, memory, video and sound devices, and input/output hardware closely enough that software sees a recognizable system. It does not reproduce every transistor or the physical machine. The chips README says components exchange bit masks representing chip pins and are wired together roughly like parts on a breadboard; it also openly notes some callbacks and address-decoding shortcuts.

    Your five-minute field trip

    Start with one of the gallery's UI links. The project's help page says arrow keys usually handle direction and the space bar acts as jump or fire. Some demos wait for Space or 1 at their own title screen. If the opening is silent, click or press a key: browser audio policies may be holding the sound until you interact.

    The UI builds are also the recommended choice for loading a local file because they let you toggle joystick emulation. Drag a supported file onto the browser window; a green flash means success and red means error. The accepted formats depend on the machine—C64 supports PRG and TAP, ZX Spectrum supports Z80 snapshots and TXT, and Amstrad CPC supports DSK, TAP, SNA, BIN, and TXT, among others.

    Loading is not the same as launching. A CPC disk image may ask you to type CAT and then RUN"filename; a C64 PRG usually needs RUN. That tiny bit of friction is historically honest. You are meeting the original machine's habits, not a universal media player wearing a beige costume.

    Try this responsibly: Begin with the built-in examples, software you wrote, or files whose rights holder authorizes your use. Keep a note of the source and license. An emulator can be open source while a ROM, game, firmware image, tape, or disk file remains separately protected.

    The breadboard is made of bits

    Why bother putting this in a browser? A URL turns setup into an invitation. A teacher can place an emulator beside a manual. A developer can share a reproducible bug or timing experiment. A curious reader can compare several computer designs without installing a shelf's worth of desktop packages.

    The browser can also become a window into timing. Weissflog's account of his cycle-stepped Z80 core explains how advancing one clock cycle at a time simplifies whole-system emulation and debugging; the Z80-based Tiny Emulators gained cycle stepping in their CPU debugger. His earlier 6502 article shows why coordination between a processor and its peripheral chips matters.

    There are limits. Browser sound can wait for interaction, modern keyboards do not reproduce every original layout, touchscreens are poor substitutes for vintage joysticks, and the project's documented modeling shortcuts can affect edge-case fidelity. Code can preserve behavior remarkably well; it cannot recreate the weight of the keyboard, glow of a CRT, or room in which somebody first typed 10 PRINT.

    Open code is not an all-access pass

    The distinction is simple and worth repeating. The chips code uses the zlib license, while chips-test uses the MIT license. Those licenses grant permissions for the emulator projects. They do not automatically grant rights to every program the emulator could run.

    Some software is public domain, openly licensed, distributed with permission, or yours because you created it. Other material may still be protected. Use authorized copies and check the terms attached to them. That is practical housekeeping, not legal advice—and it keeps a lovely technical project from being confused with a software free-for-all.

    The tab is small; the rabbit hole is not

    Tiny Emulators is less a technological first than a beautifully made bridge. On one side: C headers, clock cycles, pin masks, and test programs. On the other: a link that boots a computer many readers have never touched.

    That crossing turns nostalgia into curiosity. Click for the blinking cursor; stay to compare designs, read the code, try a BASIC program, or discover why a machine from another place and decade behaved the way it did. The computers may be tiny on screen. The history they open is anything but.

    Primary and authoritative sources