Become a member

Get the best offers and updates relating to Liberty Case News.

― Advertisement ―

spot_img

11 Fall Beauty Must Haves According to a Beauty Editor

While each product featured is independently selected by our editors, we may include paid promotion. If you buy something through our links, we may...

CodeSOD: Functionally, a Date

HomeStartupsaskeksa/NoCpuChallenge: The No-CPU Amiga Demo Challenge

askeksa/NoCpuChallenge: The No-CPU Amiga Demo Challenge

This is an open challenge to create demos that run entirely on the Amiga custom chips without involving the CPU.

This repository contains the rules of the challenge and a runner application for launching no-CPU demos. This is intended as a standard specification of the no-CPU platform for demo competitions.

There will be a dedicated no-CPU Amiga demo competition at Gerp 2026, January 23-25, 2026. In addition, this is an ongoing challenge — an invitation to explore a different kind of demo platform.

An invitation demo — itself a no-CPU demo — was released at Evoke 2025. The full source code for the demo is available here.

Whenever you release a no-CPU demo, you are encouraged to write a comment about it on the demo announcement issue.

There’s also a FAQ.

The Amiga custom chips (affectionately named Alice, Lisa and Paula in the AGA version of the chipset) were remarkably powerful for their time, enabling the Amiga computers — with their modestly-powered CPUs — to perform graphical and musical feats that required heavy computation on most contemporary platforms.

This challenge aims to discover just how powerful these chips really are by exploring what they can do completely on their own, without the CPU even telling them what to do.

There have been several demo competitions in the past with a technical theme. Examples include Atari zero bitplane, Atari mixed-resolution, C64 only sprites and C64 border only. This is a similar idea for the Amiga — no CPU, custom chips only.

A no-CPU demo takes the form of a raw memory image that specifies the initial contents of chip memory. Together with the initial state of the hardware registers (specified below) this memory image fully defines the demo.

The memory image is loaded into memory by a runner application, which serves as the demo executable. You can use the runner as is or modify it to your liking, but in order to qualify as a no-CPU demo according to this challenge, your chip memory image has to work with the official runner (with the same behavior).

The maximum size of the chip memory image depends on the targeted Amiga chipset: 512k for OCS, 1MB for ECS (or OCS with ECS Agnus and 512k expansion, likely the most common Amiga 500 configuration), and 2MB for AGA.

The audio filter is disabled. Since the filter is controlled via the CIA registers, which the copper does not have access to, the demo does not have the option of enabling the filter.

The initial hardware register contents are as follows. Registers with ECS/AGA specific bits are generally initialized to their OCS defaults. This makes it easier to make a demo targeting OCS without worrying about AGA compatibility (as long as you are not using incompatible features, such as the 7 bitplane trick).

Register Address Value Comment
VPOSW $dff02a $8000 Long frames
COPCON $dff02e $0002 Copper danger flag set
COP1LC $dff080 $000000 Copper initially starts at address 0
DMACON $dff096 $87c0 Bitplane, copper and blitter DMA enabled, sprite DMA disabled, Blitter Nasty set
ADKCON $dff09e $xx00 All modulation disabled
BPLCON0 $dff100 $0200 OCS default
BPLCON1 $dff102 $0000 OCS default
BPLCON2 $dff104 $0024 OCS default
BPLCON3 $dff106 $0c00 OCS default
BPLCON4 $dff10c $0011 OCS default
COLOR00 $dff180 $000 Black background
BEAMCON0 $dff1dc $0020 PAL
FMODE $dff1fc $0000 OCS default

The values of all other registers are undefined.

The demo can signal that it has ended by clearing the Blitter Nasty flag (i.e. by executing the copper instruction $0096,$0400). Depending on the hardware configuration, the runner may not actually be able to exit back to the OS, so the demo should still maintain a valid display.

If you have questions or comments, you are welcome to open an issue. I am particularly interested in feedback in these areas:

  • If there is something in the rules or the runner that you think puts undue limits on what no-CPU demos can do under this formalism.
  • If you find a security hole in the runner sandbox, enabling a demo to reactivate the CPU.

Source link