The History of UAE: From Unusable to Everywhere

The Amiga’s startup hand was holding something that looked roughly like a Workbench disk. Roughly was the problem. Bernd Schmidt’s emulator had produced a badly distorted version of the familiar picture, and there was still work to do before anyone could call this an Amiga they would want to use.

Schmidt fixed his blitter code, and the picture improved. Later, Workbench booted from a floppy image with a convincing color display and something approaching a useful speed. A PC was beginning to behave like the computer he had wanted to keep.

UAE began in 1995, when moving from an Amiga to a PC could feel like exchanging one software world for another. The newer machine might be faster, but that did not mean it could run the demos, games, and music left on the old disks. Schmidt had already tried emulating a CPC. Now he wanted to bring along a considerably more awkward machine.

His written interview with Retro Replay supplies the personal account behind this history. The original source, contributor records, and contemporary Usenet discussions tell the rest of the story from several different desks.

Before UAE: Fish disks, a CPC emulator, and Turrican’s music

Schmidt was programming before he owned an Amiga. He recalls becoming fascinated with it around age nine, using a CPC, then finding plenty to investigate on Commodore’s machine. Demos were invitations to work out how somebody else had managed an effect. With a friend who made graphics and music, he produced a demo and a game of his own.

Another education arrived through the Fish disks. These collections gave Amiga users a way to encounter programs they could inspect, modify, and learn from. Schmidt remembers finding some of them in a bookstore. A trip into town could end with a disk full of other people’s working ideas.

He used Z80 CPU emulation from Charlie Gibbs’s CP/M emulator to build a CPC emulator on the Amiga. It was slow enough that he did not describe it as particularly useful. It was still a beginning: instead of asking another machine to run a port, he was making the older program’s expected hardware exist in software.

Turrican supplied a less abstract reason to pursue the idea. Schmidt wanted to keep hearing its music correctly. The PC players he knew did not quite reproduce it, and moving to a newer computer threatened to leave that experience behind. Emulating the Amiga could let the original software do the playing.

1994: could a PC do it at all?

A question appeared in comp.emulators.misc in July 1994: did anybody know of an Amiga emulator for a PC? The surviving thread soon moved beyond where to find a download. Participants disputed whether the project was feasible, with the Amiga’s custom chips and the speed of contemporary PCs at the center of the argument.

The custom chips were a reasonable thing to worry about. Amiga software could ask the display hardware to change things while a picture was being drawn. A PC’s video hardware could not simply be handed the Amiga’s memory and expected to interpret it the same way. The machines did not share a display format or the same rules for generating an image.

Schmidt thought that objection confused two different jobs. A PC did not need an equivalent of each Amiga chip sitting on its motherboard. Its CPU could calculate what those chips would have done and put the resulting image on the screen. There would be a cost in speed, but that was a different problem from impossibility.

He also remembers how closely technical arguments could follow platform loyalties. Accepting that a PC might reproduce the Amiga did not sit comfortably with everyone who believed the Amiga was the better computer. The thread contains disagreement, not a unanimous verdict from Amiga users, and Schmidt’s later account is his own recollection of that atmosphere.

For him, upgrading from a 386 to a 486 helped make the project seem more practical. Computers were improving quickly enough that an emulator did not have to reach its final performance target on the machine that first ran it.

1995: a CPU, a crooked hand, and an unfortunate floppy bug

Schmidt remembers spending a weekend with an assembler and disassembler on the Amiga, building a table of 68000 opcodes and their encodings. That gave him a basis for the CPU emulator. Before worrying about a perfectly drawn game, he needed the instructions to execute well enough for the machine to start doing something recognizable.

The first visible progress included the distorted startup hand. It was encouraging even with the blitter misbehaving. Once the image improved and Workbench could load, the remaining questions became more specific: which program broke, what piece of hardware it expected to find, and how quickly the host computer could reproduce it.

The name came partly from a magazine story about Windows NT error codes, Schmidt recalls. He thought the initials UAE would fit an Amiga emulator. He remains unsure whether the magazine’s claim about those error codes was accurate, so it is best treated as an influence on his naming decision rather than a claim about Windows terminology.

“Unusable” also described the first version rather honestly: it could not boot. Schmidt thinks he had swapped the two sides in his floppy emulation, or made a similar mistake. He recalls finding the problem quickly once he tried to fix it, but the early release and the joke had already escaped.

He wanted to show that the thing people had argued about could work. There was also the suspicion that somebody else might be close to doing the same thing. A rough version in public was still a version in public.

The original changelog dates UAE 0.1 to September 1, 1995, followed by 0.2 on November 6 and 0.3 on December 12. In 1996 came 0.4 on February 5, 0.5.0 on March 15, and 0.6.0 on June 17. These were public releases that other people could test while the machine underneath was still being repaired.

The picture appears, then the timing goes wrong

Making Workbench recognizable did not mean that an action game would behave. An Amiga program could depend on the CPU, the Copper, display fetches, the blitter, and interrupts agreeing about where the machine was in a frame. Reproducing their work separately could still put an effect in the wrong place.

The Copper repeatedly brought Schmidt back to the same question: when did a register write actually take effect? Something would look a little early in one program, or a little late in another. Years later he formed a theory about an additional delay when the Copper in Agnus wrote registers associated with Denise. It helped explain the behavior he was seeing. In our interview he carefully stopped short of claiming that this remains the explanation used by modern implementations.

Commercial games could be just as inventive as demos. Schmidt recalls a vertically scrolling area in Turrican using a large Copper list and repeated sprite-position changes to build its display. A screen that looked ordinary while playing could be doing something quite unreasonable behind the scenery.

He spent time with Sanity’s Interference as well. He cannot now separate how much of that time came from its technical demands and how much came from liking the demo. That uncertainty is useful: developers were also watching and playing the software they wanted to reproduce.

Doing every operation in tiny steps would have made these relationships easier to reason about, but it could cost too much speed on a Pentium-class machine. Schmidt looked for work that could safely be combined. If the Copper had done nothing on a line, for example, the emulator might calculate that line in one go instead of paying for every possible intermediate interaction.

Some tricks remained outside his rendering approach. Changing resolution in the middle of a line was one example. His practical target was the behavior required by real programs, rather than every strange arrangement a programmer might theoretically construct.

Disks and sound have different problems

The Amiga’s disks looked like an obvious nightmare from outside the project. Schmidt’s memory is less dramatic. The emulation itself was manageable, although protected disks could need a format beyond a conventional image. Getting those images onto the PC was often the more immediate obstacle for users.

He had already disassembled Turrican’s loader on his Amiga because he wanted its music modules. That experience helped when transferring the game into the emulator. Preserving the software did not begin only after the emulator existed; some of the knowledge came from trying to get at a favorite recording while the original computer was still in use.

Paula, the Amiga’s audio hardware, was not the mysterious part in his account either. It played digital samples. A slow host could simply fail to produce enough audio to keep a continuous stream going, leaving audible gaps. Later improvements in filtering and signal processing came from collaborators with expertise he did not claim for himself.

The emulator could therefore have several different kinds of “wrong” at once. A tune might contain the right samples but break up because the PC could not keep pace. A display might show the right graphics while changing them at the wrong moment. Each needed a different repair.

1996: an Amiga future, or the end of an argument?

By July 1996, people were debating a different proposition in “UAE, The Amiga of the Future.” An emulator that could run Amiga software was no longer merely something to dismiss. It forced a question about where that software, and the people attached to it, might go next.

Amiga Report editor Jason Compton welcomed UAE while resisting the idea that it should replace the Amiga’s own future. His contribution supported software emulation as a way forward for older programs without treating the physical platform as already irrelevant. Other positions appear in the thread, too. UAE could be useful without settling the larger argument.

Schmidt remembers a warmer reception from people who had already accepted the move to another computer. For those users, an emulated Amiga could be a pleasant return. For someone still fighting for the platform, the same program could look like an admission they did not want to make.

The software travels, and the team grows

Linux was Schmidt’s newer home, and the university gave him access to other Unix machines. An X11 environment made those early targets similar enough to be approachable. Supporting other display arrangements and operating systems made portability a more deliberate job.

The preserved contributor list names programmers who worked on Mac, DOS, BeBox, NeXT, Amiga, and other ports. It also records display, floppy, sound, and CPU work. Those are cumulative credits, not a claim that every feature arrived at once.

Running UAE on an Amiga amused Schmidt. It was a curious destination for an emulator built partly because he expected to stop using that machine. The port still had to solve real display and operating-system problems, whether or not he had considered it an essential use.

Contributors also changed what UAE could do. In the credits, Ed Hanway is associated with the original filesystem work, while Toni Wilen is credited with extensive compatibility work and additional emulation features. A project that began on one programmer’s desk now contained answers to other people’s requirements.

1996–1998: UAE moves onto the Windows desktop

An Amiga program opening in a Windows window was a much easier proposition to show a PC-owning friend than a set of Unix build instructions. The old software was still expecting an Amiga underneath, but getting to it no longer had to begin in the operating system Schmidt had chosen for himself.

The Windows work belonged to several people. WinUAE’s own credits identify Mathias Ortmann with the Windows port and networking support, Brian King with the port, interface, and Picasso96 graphics, and Toni Wilen with Windows and core development beginning in 1998. Their overlapping dates are a useful antidote to the idea of one programmer simply handing a finished emulator to the next.

Picasso96 opened up a different kind of Amiga use. Workbench did not have to stay inside the display limits of a stock A500. An emulated graphics board could give desktop software more room and more colors, even while a game booting from a disk image still needed the older custom chips to behave. One installation could serve people trying to recover their old machine and people interested in building a much more elaborate one.

Schmidt was already finding some of those ambitions less appealing than his original project. In our interview, he describes the tension between portable code and Windows-specific additions, and between his own A500 interests and the machines other users wanted. The Windows branch had work of its own to do, and its contributors kept doing it.

1997: Amiga Forever puts the missing pieces on a CD

In September 1997, eight UAE developers met in Freiburg. Cloanto’s photo record puts Schmidt, Ortmann, King, Dana Peters, Mike Battilana, Christian Schmitt, Andreas Schildbach, and Stefan Reinauer together in a room with four computers. The subjects included graphics-board support, expansion hardware, and choppy sound. A program that had begun with one malformed startup picture now needed people to sit together and argue about its next pieces.

That November, Cloanto gave users a way to acquire more of those pieces together. Amiga Forever packaged the emulator with licensed Amiga operating-system software, ROM images, networking tools, applications, games, and demos. UAE alone did not supply Commodore’s startup software. Buying this CD supplied an authorized collection instead of leaving the new user to work out what was missing.

Schmidt recalls that UAE’s first source license was a custom one, with the GPL following during the Cloanto discussions. He had kept commercial Amiga software out of his own package. Amiga Forever supplied licensed system software alongside the emulator rather than treating the two as the same product.

Amiga Explorer also connected the two computers over a serial cable. The Amiga sitting beside the PC could become a source of files rather than an isolated machine that needed its own monitor every time somebody wanted something from it. That was a practical companion to the emulator, especially for someone whose own disks mattered more than a ready-made game collection.

The launch at Computer ’97 in Cologne was wonderfully less tidy than the promise of an Amiga appearing with one click. The workshop on November 15, the day after release, had a full room, early projection trouble, and enough questions to stretch an hour into two. Schmidt and Battilana demonstrated the software together. By the end of the evening, the familiar Workbench desktop was running on a notebook for an audience that knew exactly what it was looking at.

2000–2001: a faster kind of Amiga

A faster CPU could make an Amiga desktop feel wonderfully overqualified for the work in front of it. It could not, on its own, persuade an old game’s display hardware to behave. Those two jobs were becoming easier to separate as UAE grew beyond the A500 Schmidt had started with.

Bernd “Bernie” Meyer’s JIT engine belongs to 2000–2001 in WinUAE’s contributor credits. A JIT translates blocks of the Amiga’s CPU instructions into code the PC can execute directly, then reuses the translated work. A program repeatedly visiting the same stretch of code no longer needs every instruction interpreted from scratch.

The benefit was especially attractive for programs doing substantial CPU work. Drawing through an emulated graphics board and processing data were different prospects from making an A500 game wait for exactly the right part of a scanline. Throwing more speed at the latter could leave it just as broken, only more promptly.

Schmidt had tried a JIT himself. He describes his earlier proof of concept in our interview, along with the difficulty of keeping hardware accesses in step and his reluctance to maintain the extra machinery. His favorite games and demos leaned heavily on those chips. Meyer pursued the idea further, and Schmidt credits him with the more sustained work.

The Windows integration was not a switch somebody simply flipped. A March 2001 development update from the WinUAE project reported direct-mode JIT working with Bernd Roesch’s patches, but with a compiler requirement that broke networking support in that build. The same update tracked sound problems, mouse support, and floppy fixes. Speed was arriving alongside the ordinary business of making the next version work.

Schmidt also considered translating Kickstart ahead of time. That remained an idea, with distribution difficulties he did not want to take on. The downloadable emulator still had to be useful on somebody else’s computer, with somebody else’s collection of software.

The Amiga other people wanted

The project became harder for its creator to recognize as his own set of priorities. Filesystem access and a larger Workbench display appealed to him. Other requests did not. Somebody wanted an emulated Amiga 3D accelerator so that Quake could run inside the emulated machine.

Schmidt remembers that request as a marker of his burnout. He could already play Quake natively and did not associate it with the Amiga he wanted to preserve. The suggestion made sense to a user with a different idea of an Amiga, but it did not give him a reason to spend his own evenings implementing it.

“Not in my mind as such, but it became clear that other people had different ideas of where the project could go. And in part that was what made it successful, because I’d never have done half the things it has myself.”

Bernd Schmidt, speaking to Retro Replay.

He also found some Windows additions too hurried or difficult to reconcile with his preference for portability and cautious design. That is his assessment of the tradeoff, not a reason to write the contributors out of the story. The extra features were often precisely what users wanted.

Asked whether stronger architectural control would have helped, he gave a less tidy answer than either side of that argument might prefer. Collaborators bring different ideas. A maintainer can learn to live with them or step away, and attracting enough collaborators to encounter the problem is itself a kind of luck.

2002–2014: the game starts, then something goes wrong

Getting past a title screen can be a wonderfully misleading victory. The next scroll, disk access, or burst of animation may expose something the opening never asked the emulator to do. WinUAE’s long development record is full of repairs to programs that were already almost working.

Toni Wilen kept pursuing those failures. Early-2000s entries in the project changelog describe an experimental mode that brought CPU and blitter timing closer together. It helped software such as P.P. Hammer, but demanded considerably more PC power. Other fixes stopped an immediate death in Hostages or corrected graphics in Banshee. These were changes a player could notice without knowing a register from a radiator.

Hostages is already quite capable of killing its commandos through the player’s own mistakes. Sneaking past a searchlight or moving through the occupied embassy is tense enough without an emulator adding its own fatal surprise. A fix to that behavior does more for an evening’s play than an impressive benchmark in a program somebody never uses.

WinUAE reached 1.0 on June 6, 2005. The number did not retire the bug reports. Its final beta still corrected a display-memory interaction that spoiled two demo intros. Later development kept returning to the old question of which part of the machine had done what, and when. Faster PCs bought room for closer timing, rather than making timing irrelevant.

Disk preservation gave the emulator another kind of material to handle. Ordinary disk images were convenient, but unusual disk layouts and protections needed more of the original recording preserved. The 2.8.0 development record includes support for raw captures from KryoFlux and the Software Preservation Society’s tools. That widened the route from a surviving physical disk to software that could examine its behavior.

The player’s collection and the emulator were improving together. A better capture could retain something a simpler image had lost. A better drive model could then make use of it. Neither guaranteed that every protected disk would work, but the answer no longer had to be replacing the program with a conveniently altered copy.

2003–2007: bringing the improvements back out of Windows

On November 24, 2003, Richard Drummond offered Mac users an experimental build of his UAE work. His announcement was not dressed up as an effortless return to the Amiga. The interface needed extra software, windowed operation was slow, and networking was troublesome. He wanted people willing to test it anyway.

Drummond was drawing on WinUAE’s increasingly capable core and making that work useful elsewhere. It was a reversal of the early journey from Unix to Windows. Improvements made for one branch could come back to Linux, Mac OS X, BeOS, and Amiga systems, provided somebody did the platform work rather than assuming portable meant automatic.

His archive follows that work in small, revealing steps. In January 2004, JIT became available in his BeOS build. A 2005 release candidate brought across compatibility fixes from WinUAE 1.0.0 and repaired an IBrowse filesystem failure. In July 2006, he explained that thunderstorms, damaged equipment, and limited spare time had slowed the binaries. The downloads were still being prepared on actual computers that could fail.

The branch became E-UAE, a name Drummond acknowledged other people were already using. Its March 27, 2007 WIP4 release included performance work and an experimental OpenGL renderer. The surviving download list ranges from Linux PCs to PowerPC Macs and AmigaOS. Not every build offered identical features, but a Windows improvement no longer had to stay on Windows.

2012 onward: choosing a game instead of rebuilding its computer

Frode Solheim’s FS-UAE reached version 1.0.0 on March 28, 2012. His next progress report discussed performance, graphics-board support, and making the menu work on older OpenGL hardware. There was still plenty of emulator work beneath the surface. The way a player reached that surface was becoming a project in its own right.

FS-UAE paired a cross-platform emulator with a launcher and, later, an Arcade interface. The launcher could organize the information needed to start a particular game rather than ask its owner to remember every setting. Browsing covers made an Amiga collection look like something to play again, rather than a directory of disk images with increasingly mysterious filenames.

The WHDLoad integration made that difference particularly clear. WHDLoad is Amiga software that installs and adapts games for running from a hard drive. It is not an emulator. FS-UAE Launcher could recognize suitable game files, obtain matching configuration information, and assemble a temporary hard-drive environment to start them.

The game data still had to be present on the user’s computer. The useful trick was matching the files and preparing the machine around them. A player could spend less time deciding which Amiga model, memory arrangement, or startup files belonged with a particular installation.

That convenience depended on more than Solheim’s interface. WHDLoad’s game-specific work, the database information, and the inherited emulation all met at the launch button. FS-UAE’s own project description traces its core through WinUAE to the original UAE. The box art was the part the player saw first, but the code underneath had a much longer guest list.

2016 onward: an Amiga beside the television

A Raspberry Pi did not look much like an Amiga, but it could fit into the sort of small, inexpensive setup that made returning to old games appealing. With a controller and a display attached, the computer doing the emulation could disappear into the furniture.

Dimitris Panokostas’s Amiberry was part of that shift. An August 2016 DietPi development thread records collaboration on integrating it, including builds for different Pi models and an option to boot directly into the emulator. The work reached beyond running a program on the board. It included getting from power-on to an Amiga session without a desktop full of distractions.

The ARM branch had its own practical constraints. A modest board could not simply absorb every expensive feature without a cost. The Amiberry source preserved by Retro Games Ltd. describes a WinUAE-derived core adjusted for lower-powered hardware, alongside JIT support, a WHDLoad booter, and controller mapping. The priorities included making a game start cleanly and making the buttons do something sensible when it did.

Amiberry also reached a ready-made miniature Amiga. Retro Games Ltd.’s repository identifies its own branch for THEA500. The emulator that had once been shown on a notebook was now part of the software behind a commercial machine made to evoke the old computer. Its case and front end were new work around a much older inheritance.

The project subsequently spread well beyond the Pi. Its current platform list includes desktop operating systems and several CPU families. The small-board origin remains part of the appeal, but Amiberry is no longer adequately described as a Raspberry Pi version of UAE.

The 2020s: the same family, different jobs

A document written on an Amiga could outlive the printer it was supposed to use. By the 2020s, some of the work around UAE concerned getting that document onto a newer screen or into a usable file, while other developers were still making the next game easier to start.

Cloanto’s July 2025 release record describes virtual printers, print preview, and touchscreen work. A user returning to an old application might care more about recovering a document than achieving another frame per second. The package was still finding ways to make the Amiga software useful beside newer devices.

Solheim published the first public FS-UAE 5 alpha on September 5, 2025. Two days later, 3.2.35 repaired a crash in the stable branch’s input menu. Maintaining what people already used and preparing a replacement could happen in the same week.

For a player choosing where to begin, our WinUAE entry covers the Windows branch, while FS-UAE offers another route across desktop systems. Our Amiberry entry covers its own hardware and interface priorities. They share substantial work, but their release numbers are not interchangeable steps on one ladder.

Schmidt would have welcomed more independent Amiga emulators, too. In our interview, he contrasts the competing approaches to several 8-bit machines with UAE’s unusually large role. He can appreciate what its descendants became without wishing every other approach out of existence.

The Amiga on the shelf

Schmidt’s professional work moved into compilers. Looking back in our interview, he credits other people with much of what became good about UAE, and says the work he considers his best came later.

His original Amiga now sits in his bedroom without a compatible display attached. He is also wary of trusting its old power supply. Occasionally, he starts UAE to listen to music. The computer on the shelf can stay there while the tune plays.

More from Retro Replay

Follow UAE through the 1995 and 1996 emulation timeline chapters, and see our WinUAE emulator entry for its Windows descendant.

• Our full interview with Bernd Schmidt
• Bernd Schmidt’s biography
• The 1995 emulation chapter
• The 1996 emulation chapter
• FS-UAE profile and setup resources

Sources and further reading

• Bernd Schmidt’s written interview with Retro Replay, October 2026. Firsthand recollections of programming, early UAE, hardware behavior, collaboration, and stepping back.
• “amiga emulator for PC?”, 1994. Contemporary discussion supplied by Schmidt.
• “UAE, The Amiga of the Future.”, July 1996. Contemporary reception and disagreement over the platform’s future.
• UAE-core README. Project scope, hardware support, operating systems, and practical requirements.
• UAE contributor credits. Specific roles and operating-system ports across the project’s development.
• Richard Drummond’s E-UAE site. Its relationship to UAE and WinUAE, and surviving release information.
• Official FS-UAE site. The project’s current description, interface imagery, and lineage.
• Sanity’s Interference, Demozoo. Demo identification and archive.
• Original UAE changelog. Early release dates and development milestones.
• WinUAE source credits. Windows contributors and the JIT engine.
• WinUAE development changelog. Compatibility work, the 1.0 release, and disk-capture support.
• Cloanto’s September 1997 UAE meeting archive. Identified developers and period photographs.
• Amiga Forever’s original 1997 announcement. Licensed system software, tools, and the CD package.
• Amiga Forever at Computer ’97. The November launch demonstration.
• Amiga Forever release log. Release dates and later product changes.
• WinUAE’s March 2001 status update. Contemporary project update reproduced by Amiga-News.
• Richard Drummond’s E-UAE news archive. Dated platform work and release notes.
• FS-UAE’s 2012 news archive. Version 1.0.0 and subsequent development.
• FS-UAE WHDLoad documentation. The launcher’s integration with game installations.
• DietPi’s August 2016 Amiberry integration thread. Contemporary collaboration and Raspberry Pi boot integration.
• Retro Games Ltd.’s Amiberry branch. THEA500 project source and ARM-era design.
• Official Amiberry project. Current platforms and features.
• FS-UAE 5 alpha announcement. September 2025 development release.
• FS-UAE 3.2.35 announcement. The stable branch’s September 2025 update.