
The new released YouTube movie by Ranko Rodic “AGA on AmiCube is finally running!” is not a product launch, and it does not pretend to be one. It is a development video: a board, a screen, a working test, and a developer showing that a difficult part of the AmiCube project has started to behave. That makes it more interesting, not less. In the video, Ranko Rodic demonstrates AGA graphics running on AmiCube hardware with a 68000 CPU and SRAM. For the Amiga community, that is a meaningful step. AGA support moves AmiCube beyond the earlier Amiga 500-style target and toward the later machines many users still associate with the final commercial years of Commodore’s classic Amiga line. The important point is not simply that graphics appear on screen. The important point is that AGA is one of the harder compatibility targets for an FPGA Amiga system. It involves memory timing, display fetches, bitplanes, chipset behaviour and a long list of small details that older Amiga software can expose very quickly.
A development video, not a victory lap
Rodic’s video is best read as a progress report. It shows AGA running, but it does not claim that AmiCube has suddenly become a complete Amiga 1200 replacement. That distinction matters. Amiga compatibility is difficult because much of the software was written close to the hardware. Games, demos and graphics programs often expect the chipset to behave in very specific ways. A small difference in timing or memory access can be enough to cause display errors, broken effects or unstable behaviour.
That is why the work mentioned around the demo is important. The progress is tied to experiments with timing, the memory bridge and prefetch behaviour. These are not headline-friendly features, but they are the kind of engineering details that decide whether an FPGA core becomes useful beyond simple tests.
For AmiCube, getting AGA to run visibly is a useful milestone because it creates a stronger base for real compatibility testing. The next step is not just showing more screens. It is running more software and finding out where the implementation still differs from original Commodore hardware.
What AGA adds
AGA, short for Advanced Graphics Architecture, was Commodore’s final major graphics chipset for the classic Amiga line. It appeared in the Amiga 1200, Amiga 4000, Amiga 4000T and Amiga CD32, and became the graphics target for many later Amiga games, demos and graphics applications. Compared with the earlier OCS and ECS chipsets, AGA gave the Amiga a larger colour palette, more flexible display modes and better support for richer late-era graphics. It still used the familiar Amiga bitplane system, so it was not a clean break from the older machines, but it expanded what developers and artists could put on screen.
In standard indexed-colour modes, AGA could display up to 256 colours on screen from a 24-bit palette. That was a clear improvement over the earlier chipset generations and made Workbench screens, game graphics and painted artwork look more modern. AGA also introduced HAM8, an enhanced version of the Amiga’s Hold-And-Modify display mode. Under the right conditions, HAM8 could display many more colours on screen, which made it useful for image viewers, digitised pictures and graphics demonstrations. Another important change was support for eight bitplanes. In practical terms, this allowed more detailed indexed-colour screens and gave developers more room to build complex visual layouts.
The chipset also improved sprite colour options and widened display fetches, helping the machine cope with more demanding graphics modes. These changes mattered for games, demos and graphical user interfaces, where colour depth and display bandwidth could make a visible difference. AGA was not a full 3D or chunky-pixel graphics system, and it arrived late compared with the fast-moving PC VGA and SVGA market. But within the classic Amiga architecture, it was a significant upgrade. It gave the final Commodore Amigas their late-generation visual identity and remains an important target for any FPGA Amiga project that wants to go beyond the Amiga 500 experience.
Why AGA is harder than it looks
It is easy to describe AGA as “better graphics”, but that undersells the work involved in recreating it. The Amiga display system is closely tied to the machine’s memory architecture. Bitplanes are fetched from chip memory. The chipset competes for bus time. The CPU, blitter, copper, sprites and display hardware all have to share the system in a way that old software often assumes will be predictable.
That is the challenge for AmiCube. An FPGA system does not only need to produce a similar image. It has to reproduce enough of the original behaviour that real software does not notice the difference. This is where timing work becomes central. Demos are especially unforgiving because they often use the hardware in ways that normal applications do not. Games can be just as demanding, particularly when they rely on precise display tricks, copper effects or unusual screen setups. Workbench itself can also reveal problems through different resolutions, palettes and display modes. So AGA running on AmiCube is not the end of the work. It is the point where the harder testing can properly begin.
The Minimig foundation
AmiCube sits in a wider FPGA Amiga history, and that history matters. The most important earlier project is Minimig, created by Dennis van Weeren. Minimig showed that an Amiga-compatible computer could be recreated in FPGA logic rather than only simulated in software. It began as an Amiga 500-style reimplementation and became one of the reference points for later FPGA retro-computing work.
That background is important because AmiCube is not simply another emulator box. It belongs to the hardware-recreation side of the Amiga scene. The goal is to rebuild Amiga-style behaviour in programmable logic, close enough that software written for the original machines can run convincingly.
Rodic’s AmiCube work continues that line, but the target is broader. With AGA now appearing on real hardware, the project is moving toward the later Amiga generation, not only the OCS and ECS machines that defined the earlier period.
FPGA Amiga versus software emulation
A software emulator imitates an old computer by running code on a modern processor. It can be very accurate, convenient and flexible. An FPGA system recreates the logic of the old hardware inside a programmable chip. Instead of one modern CPU pretending to be the whole machine, the FPGA design can model different parts of the original computer as hardware blocks.
That does not automatically make FPGA better for every user. Emulators are easier to distribute, easier to update and often more practical. But FPGA projects are attractive when timing, signal behaviour and hardware-level accuracy are central goals. For the Amiga, that distinction matters because so much software interacts directly with the custom chipset.
AmiCube as a development platform
AmiCube is also becoming interesting as a development environment, not only as a future user machine. The AmiCube DEV1 board is designed for running and testing the AmiCube Minimig core on Artix-7 FPGA hardware, using an Edge FPGA baseboard. That makes it more than a closed retro product. It is a platform for FPGA developers, hardware engineers and Amiga enthusiasts who want to test the core, debug behaviour and experiment with features.
The board’s focus is practical: classic-style joystick support, PS/2 keyboard and mouse connections, HDMI and VGA output, and attention to safe handling of 5V-era peripherals. Those details matter because Amiga-compatible hardware has to live between two worlds. It needs to respect old hardware expectations while still being usable with modern displays and development setups.
The availability of a development board also changes the project’s rhythm. Once more people can test the core on real hardware, compatibility work can become more structured. Bugs can be reproduced. Timing issues can be narrowed down. Software that fails can become useful test material.
The developers in the wider line
The AmiCube story is not isolated. It is part of a chain of Amiga hardware work stretching from the original machine to modern FPGA projects. Jay Miner and the original Amiga engineering team established the custom-chip design approach that made the platform different from many other home computers of its time. The Amiga was built around the idea that graphics, sound, DMA and coprocessors could carry much of the workload.
Dennis van Weeren later brought that idea into the FPGA age with Minimig, proving that an Amiga-compatible chipset could be recreated in programmable logic. Till Harbaum became another important name in the FPGA retro-computing scene through MiST, which helped popularise FPGA-based recreations of classic systems, including Amiga-related work. Ranko Rodic is now pushing AmiCube forward, taking the Minimig tradition into a newer hardware direction and demonstrating AGA progress on real hardware. That lineage is useful because it keeps the project in perspective. AmiCube is not appearing in a vacuum. It builds on years of work by developers who treated the Amiga as a hardware design that could be studied, rebuilt and improved.
What the YouTube movie shows
The YouTube movie shows a specific technical milestone: AGA graphics running on AmiCube. It also points to the kind of work that had to happen before the display could come alive, including experiments with memory access and prefetch behaviour.
That is enough to make the video newsworthy, but it should not be overstated. A working demonstration is not the same as broad compatibility. The Amiga software library is large and inconsistent. Some programs are well-behaved. Others depend on exact hardware behaviour, undocumented quirks or timing that only becomes visible under stress.
The value of the video is that it moves AmiCube from theory into a more testable stage. Once AGA is running, developers can begin comparing more software, looking for weak points and improving the implementation.
Why this matters for users
For ordinary users, the significance is simple: AGA support expands the useful software target. An FPGA Amiga that only aims at OCS and ECS can cover a large part of the classic Amiga library, especially the Amiga 500 era. But it does not fully address the later machines. AGA support brings the target closer to the Amiga 1200, Amiga 4000 and CD32 period.
That matters for later games, demos, Workbench configurations, graphics tools and software that expects the enhanced chipset. It also matters psychologically for the community. The Amiga 1200 remains one of the most familiar late-classic machines, and any modern FPGA project that wants to be taken seriously in that space eventually has to address AGA. AmiCube is not there yet as a finished replacement. But this demo shows that the project is working on the right level of problem.
What still has to be proven
The next stage is compatibility. AmiCube will need to be tested against a wide range of AGA software: games, demos, utilities, Workbench screen modes, graphics applications and edge-case programs that stress the hardware. It will also need testing across different display outputs and memory configurations.
This is where many FPGA cores mature. Initial success gets the system running. Wider testing reveals what is still wrong. Small fixes improve timing, display behaviour and software compatibility over time. That process can be slow, but it is also how credible hardware recreation projects are built. The important part is that AGA on AmiCube has moved from an intended feature to something visible and testable.
Final word
“AGA on AmiCube is finally running!” is a compact development video, but it marks a serious step for the project. Ranko Rodic has shown AGA graphics running on real AmiCube hardware, after work on the timing and memory-side problems that make this kind of project difficult. That does not make AmiCube a finished Amiga 1200 replacement, and it should not be presented as one. But it does show real progress toward late-classic Amiga compatibility. For an FPGA Amiga project, AGA is one of the milestones that matters. AmiCube has now reached the point where that work can be seen, tested and judged by the software it can run next.














