Some additional context that isn't really covered in the readme - there are two components in the Amiga chipset that are especially relevant here, the copper an

Some additional context that isn't really covered in the readme - there are two components in the Amiga chipset that are especially relevant here, the copper and the blitter. The copper (named because it's a coprocessor) is a separate execution core contained within Agnus, one of the custom chips. It only supports three instructions - move, wait, and skip. Skip will skip the next instruction if a condition is met, wait will block execution until the condition is met (in both these cases, the condition can only be the location of the video beam), and move can write an arbitrary value to a custom chip register. This means that the copper can't write to other pieces of hardware (like the CIA chips that control various things like system timers and the audio filter), but also that it can't write to RAM. The copper is used fairly heavily in the demo scene, but in gaming it's probably most commonly used to reprogram the colour palette as the screen is being displayed, increasing the number of on-screen colours. The code the copper runs is in RAM so the copper can't directly modify it, but the copper can reprogram the registers telling it where its code is, so it's possible to use the skip instruction to conditionally bounce to different code depending on where you are in scanout. The blitter is another coprocessor with a different set of limited features. Blitter as a generic term refers to a piece of hardware that can copy memory from one location to another without CPU involvement, but the Amiga blitter is more full featured than that. It also has the ability to render lines, fill areas of the screen, and apply shifts and masks to data rather than just copying it. Of course, when I say "render lines" or "fill areas of the screen", what I actually mean is that it can write specific patterns to regions of memory - there's no actual requirement that they be on screen at the time. A really important thing here is that while the copper can't write to memory itself, it can configure the blitter, and the blitter can then modify memory. One fun thing here is that there's absolutely nothing stopping you from using the blitter to modify the code that the copper is executing. The naive implementation of a no-cpu demo would simply be to load all the assets into RAM and then have the copper reprogram the custom chips to display them and play audio. But combining the copper and the blitter gives a turing complete execution environment that ought to be able to do almost anything you could do with the CPU (the blitter can't touch hardware registers so you're still limited to whatever registers the copper can access, and you can only access the RAM the custom chips have access to, not the larger range of fast RAM), just somewhat more slowly.