The astonishing unpopularity of "dynamic-highres"

[SamuraiCrow]

Custom copper-lists were used extensively in games but typically only the background color and possibly some sprite colors were changed to keep the copper from hogging too much bandwidth.  Also, the SHAM file format was hard-coded to a vertical resolution of 200 pixels IIRC and therefore didn't look right on a PAL screen.

Also, since AGA supported HAM8 in full super-high-resolution, the hardware solution solved much of the software kludging.  Secondly, using TrueBrilliance on the AGA chipset combined both techniques for better 24-bit resolution images.

[SamuraiCrow]

@Mr_A500

The Copper is a separate processor unto itself.  It has 3 kinds of instructions: move, skip, and wait.  Wait is executed by allowing the blitter to have the time that the Copper would have used if it were executing another instruction until the raster reaches a certain screen position.  Skip is usually used to skip over a wait instruction if the raster has already passed a certain position.  Move is the most common one: it pokes values into the custom chip registers.

The reason the system doesn't seem to slow down is becuase the custom chips have a separate bus called the CHIP bus with their own CHIP memory.  The FAST bus allows the CPU to continue processing regardless of the bandwidth conditions of the CHIP bus unless you have no FAST memory.

There are DMA channels on the Chip bus that are allocated according to usage.  Dynamic highres inserts a lot of Move instructions into the Copper-list (program) that is being executed so more bandwidth is spent by the Copper to execute these moves than if it were simply executing a wait instruction.  The more bandwidth is used by the bitplanes and the copper, the less bandwidth is left for the blitter and, if necessary, the CPU.

As a side-note:  Copper-chunky is a form of screenmode that changes color palettes as fast as possible on a 0-bitplane (1 color) screen.  Since there are no bitplanes in use, the blitter can execute its copy instructions directly on the Move instructions in the Copper-list which is much faster.

Unfortunately the Copper DMA only executes once every 8 lowres pixels on ECS therefore limiting Copper-chunky to 80x256x4096 PAL or 80x200x4096 NTSC.  AGA has a faster copper so it can do 160x256x4096 PAL and so on.

IMHO the ideal modern Amiga chipset would do nothing but Copper-chunky all the time and just optimize the Copper instruction set to execute faster with byteruns so it could copy multiple pixels to a queue with a single instruction.  It could even have a special byterun for emulating HAM8 mode if you wanted it to.  The only problem with this idea is that we'd have to figure out a way around an NVidia patent on graphics streaming and we'd be in the clear.