---
title: "To revive his 1999 browser, he first had to rebuild the computer around it"
locale: "en"
url: "https://irz.fr/en/articles/am29000-compiler-browser-revival-en"
markdown_url: "https://irz.fr/en/articles/am29000-compiler-browser-revival-en.md"
category: "tech"
tags: ["compiler", "browser", "Am29000", "emulation", "preservation"]
published_at: "2026-08-19T09:56:00.000Z"
author: "Manon Girard"
translation: "https://irz.fr/fr/articles/am29000-compiler-browser-revival-fr.md"
---

# To revive his 1999 browser, he first had to rebuild the computer around it

Biyubi ran on a homebuilt Am29000 computer. Seeing it again in 2026 required rebuilding the emulator, storage, video, C environment and a network bridge around the recovered software.

A browser from 1999 can survive perfectly well on a disk and still be almost impossible to run.

Biyubi was written by Oscar Toledo G. for a homebuilt computer based on AMD's Am29000 processor. The program depended on a homegrown operating system, TCP/IP stack, graphical environment, bitmap fonts and a C compiler built specifically for that machine.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Twenty-seven years later, recovering the executable was therefore only one part of the job. The world in which that executable made sense had to be rebuilt around it.

That makes the project more interesting than a simple “old browser runs again” story. Software preservation concerns the final program, but it can also depend on **the tools that produced it, the services it expects and the hardware it talks to**.

## At first, writing software itself became the problem

The first G11 computer used an Am29000, a RISC architecture introduced by AMD in the late 1980s. Toledo built a windowed operating system for it directly in machine code between 1996 and 1998.[2](https://nanochess.org/the_am29000_computer.html)

That choice eventually became a trap: changing a function required planning where its instructions would fit in memory, growing one routine could move the next, and moving either one meant fixing branches. Toledo recalls leaving runs of NOP instructions in places simply to reserve room for future expansion.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

This works while software stays small. The system did not.

The next problem was therefore no longer which application to write, but how to recover a high-level language on the machine.

A GCC release with Am29k support existed, yet Toledo judged the required memory and supporting infrastructure to be beyond a system with only 512 KB of RAM: a richer operating-system environment, assembler, linker, Flex and Bison would all become part of the bootstrap problem.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Instead of porting that entire stack, he returned to a C compiler he had previously written for his transputer computer.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)[4](https://github.com/nanochess/transputer)

> Illustration: Floppy disk containing multiple stages of the Am29000 C compiler. Before Git, Toledo preserved stages of the compiler by copying daily versions onto floppy disks. Decades later that improvised version history became part of the reconstruction material. Credit: [Oscar Toledo G. / Nanochess](https://nanochess.org/am29000_c_compiler_web_browser.html).

## A different processor forces a different way of thinking about the compiler

The transputer and Am29000 create very different problems for a code generator.

On the transputer, a stack architecture handles much of the movement of values. The Am29000 exposes many registers, leaving the compiler responsible for deciding where variables, arguments and temporary values should live.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Toledo consequently changes the compiler architecture. Rather than immediately emitting code as parsing proceeds, it retains a whole function in an intermediate representation built from trees and linked lists. The compiler can then see which variables need an address in memory, which can remain in registers and how many local registers the function requires.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

That detail says something useful about compiler ports.

A compiler is not merely a dictionary between “C” and “assembly”. Its internal architecture eventually reflects properties of the target machine, and a sufficiently different processor can make decisions inherited from the previous target impractical.

Toledo started the Am29000 generator in May 1998. By early June he could compile the compiler, assemble its output and reproduce the same binary on successive builds.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

The machine had recovered a language tool capable of rebuilding itself inside its own environment.

## Self-hosting turns the computer into a workshop

The compiler alone was still insufficient, because an assembler had to turn its output into machine instructions and an editor was needed to write new programs comfortably. Toledo first ported the assembler by hand into machine code, then eventually compiled its C implementation with the compiler he had just brought to life; a text editor followed, initially written in machine code as well.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Roughly two months of work produced a complete development environment: editor, C compiler and assembler.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

> Bootstrapping
> **The useful application comes after its own tools**
> - A windowed OS exists, but machine-code development has become painful to extend.: 1
> - The transputer C compiler is reshaped to generate Am29000 code.: 2
> - The compiler becomes self-hosting and works with a native assembler.: 3
> - That environment makes much larger applications, including a browser, realistic for one developer.: 4
> The browser depends on a software workshop that had to exist first.

The sequence resembles building a machine tool before the part that motivated it. On a contemporary system, `cc`, a linker, editor and standard library feel like landscape; on a homebuilt architecture outside the normal tool ecosystem, they become products that have to be manufactured, and the compiler matters because it makes a browser-sized project economically possible for one person.

## Biyubi is a consequence of the compiler

Toledo began his browser on March 22, 1999. By April 9, an early HTML version could run locally, while he was also building the TCP/IP stack, PPP, PAP and modem-control pieces around it.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

On June 24, 1999, the browser reached the Internet for the first time from the Am29000 computer using a friend's Prodigy account.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

The hardware context is difficult to picture now. The browser environment described by Toledo ran around a 12 MHz processor with only hundreds of kilobytes of RAM available, while the Biyubi executable itself reached 362 KB.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

It could not simply occupy memory like an ordinary modern application.

In reconstructing the system, Toledo rediscovered that the browser had been burned into EPROM along with its network stack. Part of the application environment therefore lived directly in the machine's non-volatile memory.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

> Illustration: Bitmap font cache used by the Biyubi browser. Biyubi used a pregenerated bitmap-font cache to make page rendering faster on a 12 MHz system. Recovering the browser meant recovering apparently secondary files like this one too. Credit: [Oscar Toledo G. / Nanochess](https://nanochess.org/am29000_c_compiler_web_browser.html).

Finding a single binary was therefore nowhere near enough: during the 2026 revival, Biyubi attempted to load a missing font cache, sending Toledo back into old mini-CD backups until he found the 1999 file required to render pages efficiently.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Old software is rarely one lonely executable. It is surrounded by small pieces that looked disposable while the original machine was still intact.

## In 2026, the first tool to rebuild is the emulator

The original computer is no longer available as an easy platform to use, but Toledo retained floppy images, memory dumps, ROMs and backups.

He wrote a modern Am29000 emulator to make them executable again.[2](https://nanochess.org/the_am29000_computer.html)[3](https://github.com/nanochess/Am29000)

Toledo never tries to recreate every historical component down to the transistor. He chooses pragmatic boundaries instead: a floppy controller can be bypassed into emulator services, the Cirrus Logic graphics hardware is implemented around behaviours the operating system actually uses, and some storage or keyboard operations are intercepted rather than reproducing an entire historical peripheral.[2](https://nanochess.org/the_am29000_computer.html)

> Illustration: Fénix windowed system running inside the modern Am29000 emulator. Fénix boots again after rebuilding the pieces of hardware its software actually depends on: processor, graphics, storage, keyboard and useful peripheral behaviour. Credit: [Oscar Toledo G. / Nanochess](https://nanochess.org/the_am29000_computer.html).

This preservation choice matters because a perfect electrical museum is not always required. The appropriate fidelity depends on what needs to survive; here Toledo wants the operating system and its applications to execute, their dependencies to remain understandable and the result to be reproducible on current computers.[2](https://nanochess.org/the_am29000_computer.html)[3](https://github.com/nanochess/Am29000)

To be sure, every shortcut changes what the emulator proves. Fidelity is negotiated function by function, which is why those boundaries have to remain visible.

## Reconnecting the browser also means translating the 1999 network

Even once Biyubi appears on screen, the modern Web creates another boundary.

The 1999 browser expects its own TCP/IP stack, which in turn was built around a modem and protocols such as PPP. Recreating that entire path would add little to the 2026 demonstration.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Toledo builds a bridge instead.

Inside the emulator, selected services from the old networking layer are redirected to contemporary host functions for DNS resolution and TCP connections. Biyubi continues calling its 1999 interface while the emulator translates those operations into sockets on the host system.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

The browser remains severely limited on today's Web. HTTPS, modern JavaScript, CSS and decades of protocol evolution have moved the target, although sufficiently simple HTTP sites can still answer it.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

> Illustration: 1999 Biyubi browser visiting wiby.me inside the emulator in 2026. The 2026 connection does not reproduce the original modem. The emulator translates old DNS/TCP services towards the modern network while the browser remains inside its own software environment. Credit: [Oscar Toledo G. / Nanochess](https://nanochess.org/am29000_c_compiler_web_browser.html).

The solution is almost the inverse of a modern port: instead of transforming Biyubi into a macOS application, the environment changes around the program so that Biyubi can remain Biyubi.

## The compiler becomes evidence of preservation, not only a historical tool

The recovered environment does more than execute a few binaries.

Toledo includes the C compiler and assembler sources again inside the development environment, and demonstrates the compiler processing its roughly 10,000 lines of source to reproduce the same binary under the machine's tight memory constraints.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)

Seeing the compiler rebuild itself is a much stronger preservation test than seeing a boot screen, because an old system can boot while remaining effectively dead as a development platform; if the compiler, assembler, editor and libraries remain usable, the environment recovers a capacity for transformation.

A program can be corrected, another can be compiled, and the machine's limits can be encountered through its own workshop rather than only described from outside.

Preserved software becomes productive again.

## A dead architecture is more than an instruction set without a processor

The Am29000 is no longer a living general-purpose computer platform, yet its instruction set is only the first layer of what disappeared around the G11.

The compiler, assembler, calling conventions, storage, graphics drivers, disk images, fonts, build utilities and expected network services all have to be recovered or reconstructed.

That is why “keep the binary” eventually reaches a limit. If we preserve only the executable, what have we actually kept? A binary preserves one final state, while **the ability to produce the next state** disappears unless the surrounding development machinery survives too.

For a commercial game, console emulation may preserve an enormously important part of the experience; for a personal development environment like Fénix, we also need the other half of the story, which is how new software could still be written from inside that machine.

Toledo's C compiler is therefore almost more revealing than his browser.

Biyubi shows what the computer could do in 1999, while Fénix C shows what the computer could still become.

## Sometimes the best archive is a system capable of rebuilding itself

Toledo's floppies, ROMs and mini-CDs survived imperfectly. Some backups are unreadable, files are missing, addresses have to be rediscovered in binaries, and hardware dependencies reappear only when an emulator crashes into them.[1](https://nanochess.org/am29000_c_compiler_web_browser.html)[2](https://nanochess.org/the_am29000_computer.html)

The restoration is therefore a reconstruction from fragments rather than a clean recovery from one perfect disk image.

Yet the self-hosting compiler changes the nature of what comes back. The environment is no longer useful only for looking at 1999; it can process its own source and manufacture software according to its original rules.

The revived system regains a familiar property of living computing environments: it contains part of the machinery required for its own evolution.

A browser loading a page again after twenty-seven years is a wonderful image, but being able to compile the software behind it may be the more important resurrection.

## References

1. [Oscar Toledo G., How I developed an Am29000 C compiler and web browser, 2026](https://nanochess.org/am29000_c_compiler_web_browser.html)
2. [Oscar Toledo G., Developing a windowed OS for a homebrew Am29000 computer, 2026](https://nanochess.org/the_am29000_computer.html)
3. [nanochess/Am29000, emulator and recovered environment](https://github.com/nanochess/Am29000)
4. [nanochess/transputer, earlier C compiler and operating-system sources](https://github.com/nanochess/transputer)