Bernd Schmidt Interview: UAE and the Amiga Emulator That Worked

The first hand on Bernd Schmidt’s emulated Amiga screen was badly misshapen. It was supposed to be holding a Workbench disk, but his early blitter code still had bugs. Fixing those brought the picture closer to the familiar startup screen, and the next job was getting the rest of the machine to behave.

Schmidt wanted to keep using Amiga software as he moved toward PCs, including the music from Turrican. Some Usenet regulars argued that a PC could never reproduce the Amiga’s custom chips. He thought it could, and began working out how much speed he would need.

Here the creator of UAE recalls those first experiments, the hardware problems, the open-source collaborators, and the point when other people wanted an Amiga rather different from the A500 he knew. He also supplied two contemporary Usenet threads, linked beside the relevant answers below. Our history of UAE follows the project and its descendants in more detail.

Compilers, an Amiga on the shelf, and old music

Retro Replay: Before I drag you back to 1995, what are you actually doing these days? Are computers, programming, emulation, or the Amiga still part of your life at all?

Bernd Schmidt: Computers for certain. I've been working on compilers for decades now. Although with the rise of LLMs there is doubt creeping in whether software engineering will still exist in a year as either a profession or a hobby.

The Amiga is still part of my life in the sense that it's there on a shelf in my bedroom. I have no compatible display hardware to hook it up to, however, and I'm not convinced I should trust the power supply anymore. I do occasionally still boot up UAE, mostly to listen to some old music. Although it's all on Youtube now anyway.

Video games are also still a passion, although making good ones seems to be becoming a bit of a lost art in the industry.

Retro Replay: What was your own relationship with the Amiga before UAE? Were you primarily using it for games and demos, programming on it, or all of the above?

Bernd Schmidt: I was very much programming on it, like on the CPC before that. That's what fascinated me from age 9 or so. Of course the games and demos were welcome and fun, the creativity on display was awesome. The demos in particular were a source of inspiration to try and replicate some of the things they did.

I had a friend who liked to do graphics and music, and together we made a demo and a computer game. I keep thinking I ought to record a bit of the latter and put it on Youtube at some point. I don't think it was great, I was always more a systems guy than someone who can actually discover the part that makes a game fun.

The Fish disks were my introduction to what we called "public domain" software back then, which would be more accurately labeled free or open source software nowadays. Unless my memory is playing tricks on me, you could walk into a bookstore in the city and they'd have some of them – which seems crazy looking back. There were lots of things to discover on these.

Retro Replay: You mentioned that the Fish disks were your introduction to what we would now call free or open-source software, and that you could apparently buy them in bookstores. Did that culture directly influence your decision to make UAE open source from the beginning? Was there a specific piece of Amiga software whose source code taught you something important?

Bernd Schmidt: Oh absolutely. That stuff was eye-opening. There were a few C compilers in there which I started using (never try using C without an explanation of how the language works, kids). I'm looking around and can't find any evidence that gcc was on them, so maybe my memory is wrong on that point and I must have somehow gotten it somewhere else. But I'm certain I had an Amiga port of version 2.3.3. It was fascinating even just reading the documentation that came with it. My 3MB of RAM weren't quite enough to use it seriously though.

Someone named Charlie Gibbs made a CP/M emulator from which I reused the Z80 CPU emulation to build a CPC emulator on the Amiga. Not very useful, because it was really slow, but those were my first steps trying something like this.

The machine a PC supposedly could not emulate

Retro Replay: You have said that part of the motivation for UAE came from moving toward other operating systems while not wanting to lose access to Amiga games, demos, and music. Was preservation already in your mind at the beginning, or was it initially much more personal: "I still want to run my Amiga stuff"?

Bernd Schmidt: We're getting into "memory could well be unreliable after 30 years" territory here. I think the technical challenge was a large part of it. I'd already written a CPC emulator; that was of course a much simpler 8 bit machine. And it was pretty clear at that point that PCs were the future, and I'd eventually stop using the Amiga. That was regrettable and I definitely wanted to somehow be able to keep the software alive.

There were standout things on the Amiga like the Turrican soundtrack, and no really good TFMX players on the PC (even the official ports, when they eventually came out, didn't quite play it correctly), and that did seem like a potentially severe loss that was coming in the future unless something was done to preserve Amiga software and keep it running.

Retro Replay: There also seems to have been a widespread belief that properly emulating an Amiga in software was essentially impossible on contemporary PCs and workstations. Did people actually tell you that directly, and did being told it could not be done make you want to try it even more?

Bernd Schmidt: Not directly really – it was a frequent topic of lively discussion on Usenet(*). The argument was usually something along the lines that the Amiga had custom chips, and the PC didn't have equivalent ones, therefore the PC simply couldn't do what the Amiga did.

A simple-minded approach might be to just map Amiga video memory to PC video memory and hope that the PC video chip can somehow interpret it and produce the correct image – that would never work for an Amiga emulation for a number of reasons. PCs had a different format for the data, and on the Amiga the "Copper" coprocessor could wait for a specific position on the screen and change the colour registers.

But if you have a fast enough CPU, you can emulate all the effects of the Amiga hardware step by step to compute the image that the Amiga and its custom chips would have displayed, and then just put that on the PC screen. All this was fairly obvious, I thought, so I followed the discussion with a certain amusement.

The real reason some people thought it impossible was of course a belief in the superiority of one platform over the other. If the Amiga is better than the PC, surely the PC couldn't ever do what the Amiga can. Back in the day we didn't have XBox and Playstation, so people had to fight over other systems.

I think at the time people (myself included) didn't quite appreciate the gulf between a Pentium-90 and a 7Mhz 68000. It's much larger than just dividing the clock frequencies would suggest. Basically every computer you could buy in the 1980s was using technology that was roughly 10 years out of date. The 68000 came out in 1979. I bought my Amiga in 1989.

(*) For those who've never heard of Usenet, it was an early kind of discussion forum. "A primitive version of Reddit" is a reasonable analogy.

From the archive: Bernd pointed us to “amiga emulator for PC?”, a discussion that began in July 1994. Its replies show people arguing over the custom chips, CPU speed, and whether software emulation could work.

A misshapen hand and an unusable emulator

Retro Replay: Your old development history dates the beginning of UAE to February 1995. Do you remember sitting down and actually deciding, "I'm going to try to emulate an Amiga," or did it begin as a smaller experiment that gradually got out of control?

Bernd Schmidt: It was very much on the todo list for a while after I'd written a CPC emulator. It kind of seemed like an obvious thing to do once PC hardware got a little better, and it was progressing rapidly at the time. I'm not sure about the exact timeline, but I probably shelved the idea while I was still using a 386 and then started thinking more seriously about it after the upgrade to a 486. Back in the day you'd get a new computer every year and just about double your performance, and at some point the project must have felt realistic enough.

I do remember the first steps surprisingly clearly. I spent a weekend playing around with assembler/disassembler on the Amiga to create a mapping of 68000 opcodes to instruction encodings. Once I had that table, I could start writing the CPU emulation. Purely from a "I want to make something appear on the screen, visuals don't have to be super accurate" perspective this is probably the biggest block of work initially.

Retro Replay: Within days you apparently had the 68000 emulator executing the first Kickstart instructions, and not long afterward something resembling the familiar Kickstart screen appeared. Do you remember seeing that screen for the first time? Was that the moment you realized this crazy idea might actually work?

Bernd Schmidt: I'm not even sure that there was any doubt that it would eventually work. But seeing something appear for the first time was of course satisfying. I remember seeing a very misshapen hand holding something resembling a workbench disk – the blitter implementation did not start out bug free. I don't remember the moment too clearly, but there have been many similar ones on other projects – there's excitement and the feeling that you are getting close. More so once the blitter was fixed.

Retro Replay: The early name "Unusable Amiga Emulator" has become part of emulator folklore. Was that simply programmer humor because the first version could barely do anything, or were you genuinely uncertain that it would ever become usable?

Bernd Schmidt: It's a silly little story – in a computer magazine I read about Windows NT error codes and they were claiming that they were called "UAE" (I assume "User Application Error", but I never actually found information whether this is really a thing or whether the magazine made it up). This was at a time when I was thinking about a name for my program, and "AE" could stand for "Amiga Emulator"… and the first version was Unusable in the sense that it couldn't boot. I think I'd switched side 0 and side 1 in the floppy disk emulation, or something like that.

I should just have debugged the problem and released a fully working version (I think I found and fixed it really quickly once I tried), but I also felt like I wanted to show the world that no, it isn't actually impossible. And there may have been the thought that I wanted to be the first to do it. Surely the time was about ripe and other people would have had the same idea?

And of course I'd never heard of the United Arab Emirates at that point, and had no idea I'd be getting weird messages about that in the future.

Retro Replay: What was the first actual Amiga software that UAE ran well enough that you could look at it and say, "This is no longer just a technical experiment. This is an emulator"?

Bernd Schmidt: Pretty much as soon as it booted into Workbench from a floppy image. And maybe after I'd thrown out the very naive and slow initial rendering code. I seem to remember getting a good-looking workbench screen in color, and at vaguely reasonable speed, I think with the version that was going to become 0.2. At that point the rest was going to be "just details". There was never really any doubt that it could work, it was more a question of "how fast will it be in the end". I think in the original README I said an "Intel Octium" at 800MHz should be sufficient for full A500 emulation, and that honestly wasn't a bad guess for the most demanding demos and games. Systems of that nature then became available much more quickly than I thought possible.

The Copper, timing, and games that push back

Retro Replay: Emulating the 68000 is one problem. Emulating the Amiga's custom hardware is another entirely. Which chip or subsystem gave you the biggest headache in the beginning: Agnus, Denise, Paula, the CIAs, the blitter, copper, floppy controller, or something else?

Bernd Schmidt: One real headache were the timings of the copper related to everything else. The copper waits for a certain position on the screen and then writes to a hardware register. When does the write take effect? There was always some piece of software where something seemed to happen a little too early, or a little too late. Eventually (and I mean: years later) I arrived at the idea that the copper is in Agnus, and if it has to write to a register that's related to Denise, there is an extra delay. That seemed to clear up a lot of the confusion, and was perhaps the biggest lightbulb moment I experienced on the project, but I haven't actually paid attention whether modern versions still do this or whether there was actually some other reason for the things I observed.

The main problem in the beginning was simply speed. If you try to be cycle-accurate and emulate a 68k instruction, then do bitplane fetches, convert a tiny part of the screen to the PC image format, then look for copper activities… it's not going to be efficient. On Pentium-class hardware, you have to apply tricks where you detect things like "the copper did nothing on this scanline, so I can just compute it in one go, which is much faster". You want to pretend and make the user believe you're cycle accurate, without paying the price for doing it very strictly in the normal case where you can avoid a lot of the overhead.

Retro Replay: The Amiga is famous for software that depends on exact interactions between the CPU, custom chips, display timing, copper lists, blitter activity, interrupts, and DMA. When did you realize that simply emulating each component individually was not going to be enough and that the timing between them mattered enormously?

Bernd Schmidt: That was clear from the start. It's obvious if you've programmed the machine.

Retro Replay: Did demos cause more problems than commercial games because demo coders intentionally pushed the hardware into strange timing situations?

Bernd Schmidt: You'd be surprised what some commercial games do. If you look at the vertically-scrolling world 3 in Turrican, it has parallax scrolling with rather more colours than you'd think possible with double playfield mode. IIRC it was a monster copper list that changed sprite positions multiple tines during each line so that every sprite could be displayed multiple times.

There are now visualizers that you can use to show how an Amiga image is constructed, and some Youtube videos demonstrating it on a few different games like Shadow of the Beast and such.

Retro Replay: Was there a particular demo or game that became almost a torture test for UAE because every time you thought the emulator was improving, that program found another way to break it?

Bernd Schmidt: I remember spending a lot of time with Sanity's Interference demo, but I can't recall whether that's because it was problematic or because it was awesome. Possibly both. Super stylish and probably my favourite.

Hardware information from the supermarket

Retro Replay: In 1995, you obviously did not have today's giant hardware databases, FPGA recreations, logic-analyzer projects, or decades of accumulated reverse engineering. Where did your technical information about the Amiga hardware actually come from?

Bernd Schmidt: Some of it was from computer magazines. I think they must have provided a very large amount of information, rather surprising when you think about it. You go to the supermarket and you come back with a document that tells you about hardware register mappings. But there was also a Hardware Reference Manual published by Commodore, and a friend owned a copy, and that was of course more definitive.

The world feels poorer now that this kind of thing no longer exists.

Floppy disks, copy protection, and Paula

Retro Replay: Floppy disks must have been an especially nasty problem because Amiga software frequently used custom disk formats and copy-protection tricks. How difficult was accurate disk emulation compared with getting the CPU and graphics running?

Bernd Schmidt: Not that bad, to be honest. In the grand scheme of things it's not very complicated. Of course you may need to invent a special disk file format for copy-protected disks that don't quite match the usual format.

The main problem for users was getting software into disk files in the first place – that had to be done on a real Amiga since PC hardware couldn't be made to read Amiga disks at all.

Retro Replay: Did copy-protected games teach you things about the Amiga floppy hardware that ordinary software never would have exposed?

Bernd Schmidt: The "Long Tracks" thing was rather clever. Apparently you could slow down the rotation rate to write a disk with a little more data, and a normal Amiga could still read it, but wouldn't be able to write it. But I'd known about that, and I had disassembled the Turrican disk loader back in my Amiga days already because I wanted to extract the music modules. That helped when it came to transferring the disk to the emulator.

A more spectacular protection scheme was actually on the CPC, for the game The Bard's Tale. The Z80 has an "R" register, which isn't really used by programs – it's used by the hardware for refreshing the DRAM periodically. Well, turns out it still changes predictably, and you can encrypt/decrypt your code, using self-modifying code that changes itself based on the value of that register. You can't really disassemble such code since it changes under you, and if you want to emulate it, you have to implement this rather esoteric hardware feature. That realization, although so long ago, still sticks in my mind. Although I'm not sure how it helped with the copy protection because as far as I remember the disk was completely standard. Maybe it was more a protection against disassembly for whatever reason.

Retro Replay: Sound emulation is another area where early emulators often struggled. What made Paula particularly difficult to reproduce convincingly on mid-1990s hardware?

Bernd Schmidt: Oh, on the whole Paula isn't a problem. It's all digital samples after all. I'm pretty sure the C64 crowd have a much bigger task emulating SID. The main problem on, say, a 486 is that you won't produce audio data fast enough to generate a continuous sound, so you'll have audible gaps.

Later on you can get into the mathematics of signal processing, if you want to do a proper job doing high-quality filtering and such. That stuff got contributed by someone else, it was never my area of expertise. Signal processing was oddly absent when I was at university. Or maybe I didn't know to look for it.

Retro Replay: Were there behaviors you deliberately approximated because emulating them properly would have made UAE impossibly slow on contemporary machines?

Bernd Schmidt: There are a few things that were out-of-scope. Changing resolutions in the middle of the line, for example, is not something any of the rendering algorithms are going to cope with gracefully. I think I heard of one program that may have used such tricks but I never saw it. There are probably other situations you can set up to break the rendering with copper tricks. But the first (and realistically only serious) goal is only to make real-world software run correctly.

Linux, portability, and an emulator on the Amiga

Retro Replay: UAE was written with portability in mind and quickly appeared on an extraordinary number of operating systems and machines. Was portability a major design goal from the beginning, or did you only realize later that people were going to port this thing everywhere?

Bernd Schmidt: The more I think about it, the more unclear it becomes. I don't think version 0.1 was all that bothered about portability, beyond the fact that I'd just started running Linux at home recently, and the university had different Unix machines, and I definitely wanted it to run on all of these. But these were all similar enough systems: all with X11 for windowing and graphics. The Unix vendor C++ compilers sucked, though, which was a problem for a while.

I think some abstraction and portability must have come in when I decided I wanted to be able to run it without X11. My normal setup at the time was just 10 virtual text-mode terminals, and there was a library called SVGALib which you could use to program the graphics hardware fairly directly without the overhead of running X.

I'm not sure actually when portability became a real goal to be taken seriously for me. Up to a certain time everything was tied to a specific machine – the CPC, the Amiga, or a DOS PC (directly accessing the VGA hardware and such). A lot of that was simply by necessity. I guess the transition to Linux must have changed something in my mind. Or perhaps I'd already started looking at GCC (an old version 2.3.3 was on one of the Fish disks) and marvelled at the lengths it went to for portability. But I have no definite recollection of the thought processes.

Retro Replay: Do you remember receiving the first message from somebody who had ported UAE to a platform you had never even considered?

Bernd Schmidt: A specific message, no. But I seem to remember it was funny to me when it was ported to the Amiga itself.

Open source, collaborators, and competing priorities

Retro Replay: Why did you decide to release UAE as free software under the GPL? In retrospect, that decision seems incredibly important because so many later Amiga emulators and ports grew from the same codebase.

Bernd Schmidt: It wasn't really GPL originally but some sort of silly homebrew license. The GPL came in when Cloanto wanted to package it with licensed ROMs, I think they pushed for a more serious license and I couldn't think of a reason not to use the GPL.

But yes, open sourcing it was the idea from the start. I could already see what collaboration could achieve in open source programs, never mind just how much fun it was to be able to download amazing software and actually modify and extend it.

Retro Replay: Did you have any idea that opening the source would eventually produce an entire family tree of UAE-derived projects rather than just a few patches to your own emulator?

Bernd Schmidt: The specifics I couldn't foresee, and I don't think I spared any thought for the more distant future.

If anything, UAE was a little more successful than I was hoping. For C64, CPC, and all the other 8-bit systems there were competing efforts and various different emulators. For the Amiga, not so much. Fellow arrived at some point, but on the whole I would have liked to see more people try different approaches with some serious competition.

These days there's also a program called vAmiga which looks interesting but infuriatingly only works on MacOS. I've been meaning to try and get it running on Linux but never had the time so far. Perhaps I need to accept the new reality and use an LLM.

Retro Replay: How collaborative did development become once the source was public? Was there a point where contributions were arriving faster than you could realistically keep track of them?

Bernd Schmidt: There was a feeling of not being able to keep up with the Windows version at some point. I was not very happy with it; I felt that some people were adding poorly thought out stuff which would be hard to fix later when users had started to rely on it. The whole "inputdevice" layer is one such example, I never even understood the WinUAE GUI for configuring the thing. On the whole I was trying to apply caution and keep things portable and future-proof; others were more interested in adding more features.

In the marketplace, more features win.

Retro Replay: You mentioned being uncomfortable with some additions to the Windows version because features were being added faster than you felt they were being designed properly, and then summed it up with “In the marketplace, more features win.” Did maintaining UAE change the way you think about open-source project leadership? Looking back, would you have imposed stronger architectural control, or would that have undermined the collaborative success that made UAE so influential?

Bernd Schmidt: I don't think you can really impose too much, because in the end people will just route around you. You can't have collaboration without there being different ideas of what should be done. That's not something that's obvious when you first release an open-source project, and you have to get lucky to attract collaborators in the first place for the problem to even show up.

In the end you just have to learn to live with it, or step away. I think it's something that other open-source maintainers have also found.

JIT experiments and the limits of personal interest

Retro Replay: Bernd Meyer later added JIT compilation, allowing emulated Amiga code on x86 machines to become dramatically faster. When you first saw JIT applied successfully to UAE, did it feel like another one of those "this shouldn't really be possible" moments?

Bernd Schmidt: Bernie wasn't actually the first to add a JIT compiler. I'd played around with one fairly early on, but the thing is: my Amiga was an A500, and my interest in the machine was primarily games and demos (and programming, but I didn't need it for that anymore). Accesses to the custom chips were always going to be a bit of a problem for such a JIT, and the CPU was never the bottleneck for emulating these types of programs anyway.

So to summarize the thought process, in words I wouldn't have used at the time: this was an interesting technical challenge, I have a proof of concept that shows it's feasible, but I don't actually have a compelling personal use case myself, and it doesn't help with the things I really want to achieve.

Also the code I had wasn't great and I didn't really feel like trying to maintain it. Perhaps I was also wondering about a potential non-x86 future and what it would mean for JIT compilation? People were still hyping PowerPC at the time and I don't know whether I'd already gotten over that.

In any case, Bernie made a greater effort and took it more seriously, and I seem to recall he applied more technology to the problem of how to deal with hardware accesses in JITted code.

One project I thought of that never came into existence was to precompile the Kickstart ROM to native code. That could have made certain things a lot faster. But of course you couldn't distribute such a thing, so it wasn't a very compelling idea.

Retro Replay: Was there ever a point where you deliberately stepped back because UAE had become bigger than something you personally wanted to spend your life maintaining?

Bernd Schmidt: I guess you could put it that way. As I said in answer to the previous question – in my personal experience an Amiga was usually an A500. A slightly upgraded one with a harddisk and extra memory, but still a 7MHz machine from the mid-1980s with cool video hardware.

A lot of people (or maybe a few vocal ones) wanted more, however. Some of the extra features I found neat and useful: file system emulation, higher-resolution graphics card emulation for a nicer Workbench, things like that. But there was also stuff for which I personally had no use, like network emulation.

I remember when someone suggested that I could/should emulate one of the 3D cards you could buy for the Amiga, so that one could play an emulated Quake. An utterly pointless goal, in my opinion, because there's no need to emulate Quake, you can play it natively, and it's not something I associate with the Amiga at all. But certain users were quick to suggest spending a lot of effort on questionable things. In my mind that particular email marks the point in time when I burnt out on the project, although realistically it was probably a process.

Retro Replay: Your answer about the request to emulate an Amiga 3D accelerator just so somebody could run Quake really caught my attention because you describe it almost as the moment UAE stopped being the project you personally wanted to build. Did UAE gradually shift, in your mind, from “preserve the Amiga I knew” into “emulate every possible Amiga configuration anyone ever created,” and was that philosophical change as important to your burnout as the workload itself?

Bernd Schmidt: 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.

Retro Replay: The original UAE code still survives, and descendants of it are actively used more than 30 years later. Do you know whether there are still recognizable pieces of your earliest 1995 code buried somewhere inside modern UAE descendants?

Bernd Schmidt: The overall structure still seems roughly the same, and so are the basic concepts. If you want to look for something, I'd say chances are you'd find it in pretty much the same general area (except the CPU emulation was entirely rewritten very early on, so that part of the "earliest" code is gone). All the details have been thoroughly churned, of course, and a lot of things were greatly extended.

Retro Replay: Today emulator developers sometimes pursue extremely fine-grained cycle accuracy, obscure chipset revisions, expansion hardware, and bugs that perhaps only a handful of programs ever relied upon. Is that where you imagined Amiga emulation eventually going, or would that level of accuracy have seemed ridiculous in 1995?

Bernd Schmidt: Not ridiculous, but obviously unachievable on hardware of the time.

Licensed ROMs and the reaction from Amiga users

Retro Replay: Were Commodore, Amiga Technologies, software publishers, or anyone else ever concerned enough about UAE to contact you legally or commercially?

Bernd Schmidt: No, no concern I'm aware of. I had no desire to see the project taken down, so I was careful not to include any actual Amiga software. Cloanto later licensed the system software and a bunch of other things and made a nice distribution out of it, I was obviously in contact with Mike Battilana at the time. I hear he owns it all nowadays, poor lad.

Retro Replay: Commodore had collapsed shortly before UAE appeared. Did that timing affect how Amiga users reacted to the emulator? Was there already a sense that emulation might become necessary to keep the platform alive?

Bernd Schmidt: Rather the opposite. As I said earlier when talking about the Usenet discussions – a lot of people who were sticking with the Amiga were very much not open to the idea of using an emulated Amiga on a PC. They had an established identity as Amiga users, and PCs were beneath them. I think UAE was more welcomed by people who had already moved on emotionally and perhaps found it a pleasant surprise that the Amiga wasn't gone forever after all.

From the archive: For the reaction among Amiga users, Bernd supplied the July 1996 thread “UAE, The Amiga of the Future.” The conversation includes enthusiasm for UAE alongside resistance to treating emulation as the replacement for the physical platform.

Mechanical sympathy and advice for 1995

Retro Replay: Looking back, is there a feature or technical breakthrough in UAE that you personally consider your best work but that rarely gets mentioned because everyone focuses on the fact that you created the emulator in the first place?

Bernd Schmidt: Not really. In reality emulators aren't that hard, and at the time I was still really just a self-taught kid. Like with everything, if you start dedicating your life to an activity when quite young, you can become quite good at it, but the things I think of as my "best work" came somewhat later and elsewhere. Also quite a lot of the good stuff in UAE came from other people.

But perhaps one of my strengths is a certain kind of Vogon bloody-mindedness where I won't let myself be stopped by a silly technical problem just because it's considered impossible.

Retro Replay: You modestly said that emulators “aren’t that hard” and that your best work came later. After spending decades working on compilers, when you look back at the 20-something-year-old version of yourself writing UAE, what do you now recognize that he was actually unusually good at? Was it the programming itself, breaking large problems into manageable pieces, refusing to believe something was impossible, or something else?

Bernd Schmidt: I think starting at an early age and continuously working on new ideas does in the end make you develop a certain sense for how things should work. I think "mechanical sympathy" is a term I've heard for the phenomenon. It's something that I find is absent in most people who just learned programming at university.

Retro Replay: If you could recover one thing from the early UAE years that might now be lost… old source snapshots, emails, mailing-list discussions, test programs, screenshots, documentation, anything… what would you most like to see again?

Bernd Schmidt: Having a full git history would be nice. But no longer achievable.

Retro Replay: If you could sit beside yourself on the first day of the project in 1995, knowing that people would still be using descendants of this code more than 30 years later, what would you tell that version of yourself?

Bernd Schmidt: "Forget about C++ until maybe 2011." "Buy AAPL". "Back things up when using IBM DeskStar drives". … sorry, can't really think of any serious ones.

Retro Replay: Finally, when I publish the interview, are there any UAE archives, source repositories, Amiga preservation projects, people who contributed to UAE, or other resources you think readers should specifically be directed toward?

Bernd Schmidt: My guess is I'm probably not aware of any you don't already know.

Thank you, Bernd

Thank you, Bernd, for sharing your memories, revisiting the early debates, and helping us document the work behind UAE. Take care, and we appreciate the time you gave us.

Explore UAE and its history

• Bernd’s UAE source repository
• Bernd Schmidt’s biography
• The history of UAE
• WinUAE on Retro Replay
• FS-UAE on Retro Replay

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