Here we are some decades on from the C64, and other 8 bit computers.

New ideas that resulted in some new graphics effect or mode seem to happen, though we may be near the end of all that.

Took a long while though. Longer than I suspect many expected. Longer than I expected.

I don't recall OCS (original Chip Set) Amigas being exploited in quite this same way. Were they? Can you link me to examples?

  • 8
    Given the stark insane genius of the demoscene, it's pretty safe to bet that any bug or quirk in the audio or video subsystems was exploited to do something. Feb 3 '20 at 10:42
  • 1
    I remember there was a demo from NewTek (I guess it's from NewTek and I don't remember the demo name) that was able to tweak the palette between each line was draw. So it could render 32 different colors from one line, and 32 different for the other and so on. No, it doesn't used HAM. Sorry I can't remember it's name.
    – LucasBr
    Feb 6 '20 at 11:43
  • 2
    LucasBr : That would be "Copper Chunky" - Although the resolution wasn't that great and the image buffer was inline with the copper list.
    – PaulHK
    Feb 25 '20 at 8:36

The Amiga OCS was not exploited in the same way as the C64's VIC-II simply because the OCS was designed from the beginning to support rapidly changing video output modes.

Unlike the C64, and most 8-bit machines, the Amiga's display coprocessor (the "Copper") existed to allow display mode updates to occur many times during the raster. For machines like the C64, such mid-raster techniques were more idiosyncratic and able to produce results that the original hardware designers (and less bold programmers) wouldn't really expect possible. But the Amiga's Copper made the exploration of these techniques commonplace.

The first common usage of these mid-raster mode changes was built into the Amiga's GUI ("Intuition"), which allowed a front screen to be smoothly dragged up or down to review the screens behind it. There could be many such screens at once, just limited by the CHIP RAM, and each screen could have any of the Amiga's display modes with its own resolution, palette, etc. Naturally, this capability was used in programs to allow portions of one app's logical screen to utilize different video modes. A common example being a 4096-color HAM mode paint program with a toolbox at the top or bottom that used a higher res non-HAM mode.

enter image description here

Besides the fact that most games and demos on the Amiga used these mid-raster effects, some photo showing apps also used them to great effect. The best example of this is "Sliced-HAM" mode, which allows 4096 colors in hi-res (640, or more pixels wide) by simply remapping the palette throughout the raster display. Such "exploitation" of the OCS could create images that were much more photo-realistic than the standard lo-res HAM mode.

  • 13
    It might be worth to mention that the flexibility is much inherited from it's predecessor, the Atari 8 bit chipset, which in turn is build up on the flexible screen creation the 2600 had. It's a linage quite different from other, more fixed screen orientated, architectures, like the C64.
    – Raffzahn
    Feb 2 '20 at 19:02
  • 7
    I see TIA, GTIA, ANTIC less as technical predecessors having little actual silicon in common. It's more about the human story of one engineer (Jay Miner) perfecting his craft and refining his approach over multiple iterations.
    – Brian H
    Feb 2 '20 at 19:45
  • 2
    I agree Brian with your assessment of the earlier chips. In general, software driven video tends to perform above it's original spec. As people get smarter, more can be done. Maybe I should rephrase the question somewhat. The bugs in the older, simpler chips, allowed for a lot. Even interlace on some of them. (Atari 8 bit, C64 for sure) Maybe examples where the Amiga OCS was pushed to it's absolutes is a better question. Thanks for a great answer!
    – Spud
    Feb 2 '20 at 20:34
  • 2
    While the answer is technically correct, hardware exploits were not only limited to display mode changes. See the famous VSP bug on the Commodore 64 which allowed a faithful Super Mario implementation that was otherwise impossible.
    – Selcuk
    Feb 3 '20 at 2:40
  • Dragging up and down was something the Atari 8-bits did as well. Anything that could tie an interrupt to the start-of-raster did this. Multi-resolution displays were quite common on these machines. Feb 4 '20 at 19:00

If one game would qualify, that would be Alien Breed: the game switches from PAL to NTSC rapidly to emulate a damaged CRT display (extract of longplay at this point). A PAL to NTSC switch should occur at the top of a frame, so doing that in the middle of a frame can be considered like exploiting a bug.

Now, whereas games didn't push the tricks too far, that wasn't the case with demos, who always tried to push things with the various co-processors.

The co-processors are so complex that are a lot of cases where the behaviour is undocumented. WinUAE was often updated just to fix some borderline cases (sometimes not)

In some cases the author of WinUAE didn't want to imitate this.


Running on Quickstart A500 OCS/ECS glitches on "SMOOTH COPPER" part an UPFRONT logo only when is copper plasma behind (see attach pict. 1 & 2). We have a winner here! This has to be the most ugliest and weirdest way to synchronize CPU to display..

It WRITES to VPOSW to force CPU vs chipset sync! It writes to chipset registers in a loop, then increases vpos counter and writes it to VPOSW and then starts processing next line.

WTF? Why? This is too crazy..

I guess timing is close enough to real hsync and TV allows small jitter in hsyncs without causing display glitches.

I don't think I want to bother with this. It would require huge changes everywhere..

So, yes, demo makers didn't really care about using the machine properly or not. They tried stuff, and if it worked on a real OCS Amiga, then they'd use that.

Another example of a demo:

  • Pax Americana by Complex -> (It writes to blitter registers while blitter is active ... impossible to fix without having blitter's original logic diagrams/schematics.)

If the programmers found a way to save cycles and cause bugs that either are not noticeable or even created a cool effect they used it.

Good luck to emulator programmers and new ECS/AGA machines to run those demos. Some demos can only run 100% perfectly on an OCS, unemulated Amiga.

So for demos, willingly or unwillingly, one could say that the bugs/undocumented stuff were exploited.

  • Any precise reference, video, etc, about the Alien Breef hack? Feb 3 '20 at 20:44
  • 2
    added link to the video at this exact moment. WinUAE now is able to emulate it. That wasn't the case in earlier versions. Feb 3 '20 at 21:06
  • Real OCS Amigas are rare. There were eight major revisions of the A500 and the most sold revisions already had an ECS Agnus. The fact that Commodore did such upgrades silently made exploiting bugs quiet dangerous for any commercial software.
    – Holger
    Feb 4 '20 at 9:16
  • as long as you used the OS, you were safe, but games couldn't afford that. So sometimes they stumbled into a bug, without even trying. Just an unnoticed programming error. One of the reasons why Commodore didn't release the full documentation of AA chipset… it had to be reverse-engineered Feb 4 '20 at 9:52

And now here are some really non-trivial hacks played with amiga chipset:

  1. 7-bitplane ECS hack: https://groups.google.com/forum/#!topic/comp.sys.amiga.misc/HQBzx6E0K1Y (see the first message in the topic)

When you fill register $dff100 with value which has the number of bitplanes specified as 7 (lo-res) something strange is going on. On screen you will notice only 4 bitplanes but further checking has revealed to me that there are still some differences from usual 4 bitplane mode.

When 7 bitplanes are 'opened' color index is 6 bit wide. (It would be better to say 5 bit wide with halfbright enabled.) First 4 bits of color index is fetched from BPL1DAT-BPL4DAT ($110 through $116) registers which are filled through DMA channels. 5th and 6th bit of color index is taken from BPL5DAT and BPL6DAT which are NOT disturbed by DMA. In other words, you can put in, i.e. BPL5DAT value $aaaa and you will get at odd pixels on screen color which is indexed as $10 trough $1f. (Same is with BPL6DAT, value $aaaa would give you halfbright odd pixels.)

The benefit of this is accesing of all colors ($00-$1f) without loosing speed of copper. Okay, okay, this is maybe not so worth to use except in 4x4 pixel 4096 color rotators where you can now have 31 instead 30 colors for columns. Now, you may ask why is my 4096 color rotator in "B2" (Lazy Bones) using columns of color $01-$0f and non DMA sprites for columns of color $11-1f. That was before I was sure that this 'trick' with 7 bitplanes will work on ECS Denise.

  1. Lots of tricks described here: http://eab.abime.net/showthread.php?t=19676

for example, copper-related:

  • Writing to "dangerous register" with COPCON bit 1 zeroed stops the copper (See AGA.guide COPCON for more information)

  • SKIP doesn't really skip anything, it just prevent's next MOVE to do its write. SKIP followed by WAIT or another SKIP never "skips". (Game Apocalypse, uses SKIPs as nops in copper list)

  • skipped MOVE to "dangerous register" (and COPCON zeroed) also stops the copper (Rainbow Island requires this.. it has quite buggy copperlist.)

  • Copper is waiting, disable copper DMA, access both COPJMP1 and COPJMP2, enable DMA -> copper stops.


  • D-channel can be disabled. No effect on anything.. (even speed of blit stays the same)
  • C must be enabled (nothing is drawn without C)
  • B (not tested)
  • disabling A stops BLTAPT from updating (result is incorrect lines)
  • BLTDMOD is not used in line mode. BLTCMOD is used for both C and D.

And here is the most interesting undocumented feature ever:

  • First pixel is written to address pointed by BLTDPT, all following pixels are written to address pointed by BLTCPT! (Demos Cardamon and Cardamom)
  • 2
    This is more in line with what I was looking for. Thank you.
    – Spud
    Feb 3 '20 at 1:27
  • But the question was, if I got it correctly, whether or how much this was exploited in actual software. Most of the things here are rather esoteric…
    – Holger
    Feb 4 '20 at 9:09
  • 1
    7-bitplane hack is routinely used in demoscene productions for speeding up C2P routines. Blitter line hacks are used for 3D polygons drawing and filling (see the linked topix).
    – lvd
    Feb 4 '20 at 10:49

I've been asked several times about discovered "interesting behavior" of the OCS chip set when the registers were updated at certain times in a certain order (at a certain rate, etc.), and whether that behavior was intentional or not.

Simple stuff like changing modes or palettes synchronized to the NTSC "beam" was certainly intended.

But I am also certain that the design team did not anticipate all of the possibilities (note that I'm listed as inventor on all the OCS patents, along with Jay and Joe.). We had no advanced debugging tools except the towers of emulator boards. The only computer logic simulations were done after the original chips taped-out. So likely a huge amount of register setting combinations and state possibilities were never thought out, tested, or debugged.

So, yes. (Happy hunting.)


If both the blitter's vertical and horizontal filling mode was enabled and launched on a stray pixel it created a simple fractal image known as the Sierpinski triangle. It can be seen in use in the 4K intro Heartcore by Delon.

Another famous trick was rewriting BPLCON1 (the copper scroll register) to emulate a zooming effect as seen in many Sanity demos like Elysium or Jesterday (and a few more demos and games by others, mostly used for Star Wars-style scrollers). The method is described here in detail (it is in French, though).

I don't know if these count as bugs but they are certainly exploits :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.