FalconFPGA is an attempt to recreate Atari’s Falcon030 in FPGA hardware, and while developer David Dunne is understandably cautious about where the project may eventually lead, the progress so far is fascinating. TOS is booting, storage is working, software is running and David has been digging deep into the behaviour of the 68030 processor that sits at the heart of the machine.
The reason for starting it is wonderfully relatable. David had always wanted a Falcon but could not justify spending the £2,000 to £3,000 that an original machine can now cost, so he began exploring whether he could build his own recreation instead.
There is an important qualification before getting carried away. David does not want FalconFPGA treated as a promised product, finished replacement Falcon or project with a guaranteed destination. He is still working through fundamental technical problems and has been clear that he does not yet know how far the project will ultimately get.
Even if it never reaches every goal, David hopes the work itself can still be useful to other people. His own description of the project is refreshingly modest too, saying he is approaching it with “less skill than the job deserves and more stubbornness than is healthy”. Judging by the amount of low-level investigation already involved, the stubbornness appears to be doing plenty of work.
Getting the Falcon right rather than getting it running
FalconFPGA runs on a Sipeed Tang Console 138K, but David deliberately avoided starting with a complete 68030 built in FPGA logic. The board also contains an 800MHz RISC-V processor, so the early machine used the established Musashi 68000-family emulator for the CPU while software models recreated parts of the Falcon chipset and the FPGA handled jobs such as HDMI output, USB input and precise timing.
That hybrid approach meant David could get a complete machine working early and then replace individual pieces as they became ready. EmuTOS reached a GEM desktop with working USB mouse and keyboard support, giving every later component something real to be tested inside rather than months of development ending at a blank screen.
The project then started becoming something closer to a usable computer. ST and Falcon video modes were brought up over HDMI, floppy images became usable, the SD card gained a proper filesystem, hard disk support arrived through the same HDDRIVER software used on real Ataris, and Atari TOS 4.04 eventually booted from a ROM image stored on the card.
Getting TOS 4.04 running required the Falcon’s blitter, which became an early test of David’s insistence on verification. His software model was compared against an independent implementation across 200,000 randomly generated operations before being trusted with real software, with no disagreements between the two.
Timing caused another problem. Early versions ran at somewhere between a third and half the speed of a real Falcon depending on the screen mode, so cursor blinking, keyboard repeat, double-clicks and drag-and-drop all inherited the slowdown. David moved system timing away from the emulated processor and onto a precise counter in the FPGA, while later performance work brought the overall machine to around 90 per cent of real Falcon speed.
One particularly punishing test used a 1992 copy of POV-Ray from an ST Format coverdisk. David rendered the same 320×200 scene on FalconFPGA and his real Atari STe, involving more than a quarter of a million rays and 17 million intersection tests. The STe spent around 36 hours on the job, and the two finished files were byte-for-byte identical.
The current focus goes deeper still. David is now working towards replacing the emulated CPU with a 68030 soft core running directly in the FPGA, starting from one of the few viable open-source 68030 implementations rather than building a processor completely from scratch.
Verification has turned into a project of its own. Every opcode is now covered by tests based on Motorola documentation, fixes are only made once a failing test exists, and David deliberately puts bugs back afterwards to prove that the test actually catches them. That process has uncovered and fixed around 40 defects in a processor core that already appeared to work.
The complete EmuTOS boot has also been compared between the FPGA core and Musashi instruction by instruction. Around 28,000 instructions were checked with zero differences.
The most interesting part is how David settles disagreements. When documentation is unclear, or different implementations behave differently, he turns to a real 68030 processor in an accelerated Amiga A1200 and treats the silicon itself as the final authority.
That has already produced some unexpected results. The real processor has exposed behaviour that documentation and software implementations could not settle, including cases where several apparently sensible answers turned out to be wrong. An Amiga acting as referee for an Atari processor dispute would probably have caused trouble in a 1993 playground, but here it is an unusually useful piece of test equipment.
The FPGA 68030 core now passes David’s tests and clears the Falcon’s 16MHz clock. It currently does less work per cycle than a real 68030 because it has no cache yet, but that is deliberate. David’s approach throughout has been correctness first, getting the Falcon running second and speed last.
The project has already progressed far enough to boot both EmuTOS and Atari TOS 4.04, while floppy and hard disk storage are usable. Software is running too, including Frontier: Elite II, with David previously identifying timing issues that still needed attention.
Compatibility testing has produced another satisfying kind of result too: software failing in the right way. David says running Atari ST games through the Falcon’s GameX wrapper has shown that titles which fail on FalconFPGA can fail in exactly the same way on a real Falcon.
As David puts it, sometimes the project has “failed successfully”. A game refusing to run is not automatically evidence that FalconFPGA is wrong if original hardware rejects it in the same way. Reproducing those awkward incompatibilities is another sign that the recreation is behaving like the machine it is trying to replace.
The next major step is to give the FPGA processor its own dedicated RAM and place it into the Falcon in Musashi’s place. From there, David intends to move more of the machine out of software and into FPGA logic one component at a time, with sound, the blitter, timers and I/O among the areas still ahead.
Memory management is another significant unknown. MultiTOS and MiNT with memory protection need functionality from the 68030’s MMU that the current open core does not provide, so David has devised an approach that would split the work between the FPGA and the board’s RISC-V processor. It works on paper, but this is exactly the sort of unfinished area he does not want presented as a promised feature.
The Falcon’s Motorola DSP comes later, along with further work on video, sound and the rest of the chipset. The long-term technical aim is straightforward to describe even if achieving it is anything but: run TOS, MultiTOS, MiNT, games and demos without the software being able to tell that it is not talking to an original Falcon.
David has even kept open the possibility of another kind of hybrid, this time using a real Motorola 68030 on a carrier board while the FPGA provides the Falcon hardware around it. Because the chipset layer was designed from the beginning without caring whether its CPU is an emulator, FPGA core or physical processor, much of the work could remain unchanged.
There are some intriguing possibilities there, including putting RAM on the same carrier so that video hardware stealing processor cycles would happen naturally on a real bus. The setup could also become a way of measuring a physical 68030 cycle by cycle and feeding those findings back into the FPGA implementation.
It is an option rather than a commitment. A carrier board would add another hardware project on top of the FPGA work, while a complete machine that runs on one readily available board without needing an increasingly scarce 68030 is the more practical direction for most people.
I have a particular weakness for this project because I owned an Atari Falcon myself and, rather painfully in hindsight, sold it years ago for somewhere around £300. I even spent a while believing it might still be hidden in my parents’ attic before discovering that no, past me really had let it go.
That makes the prospect of an FPGA recreation especially appealing, but it is important not to turn that enthusiasm into expectations David has never offered. FalconFPGA may eventually become a way of experiencing something close to a Falcon without paying current collector prices. It may instead produce a verified open 68030 core, reusable tests, hardware findings and code that somebody else can take further.
Either outcome would make the work worthwhile. For now, there is something deeply satisfying about watching TOS boot, storage come online, software begin to run and another piece of Atari hardware gradually reveal exactly how it works, even when getting it right occasionally means failing in precisely the same way as the original.
