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?
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.
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.
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.
And now here are some really non-trivial hacks played with amiga chipset:
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.
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.
blitter-related:
- 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)
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 :)
