15 ms·

A bitplane is a region of memory rendered as pixels. The Amiga hardware allowed you to (basically) define a width and height for the region, as well as a x,y of

by Luc 10y ago

A bitplane is a region of memory rendered as pixels. The Amiga hardware allowed you to (basically) define a width and height for the region, as well as a x,y offset. So by e.g. increasing the x-offset you could scroll horizontally through a bitplane with a width larger than the screen's. The ball is in the middle of a large empty bitplane. By simply changing the offset values it bounces around the screen. The graphics hardware does the heavy lifting. No pixels need to be erased, no polygons rendered. You're just looking at the same ball, but the window through which you look has moved. Colour cycling can be used with palettes. Lets say you have 32 colours in your palette. Draw a row of 32 pixels, each in a different colour. Now change the palette so all colours are white, except for the first, which is red. Your pixels still refer to their respective colours in the palette. A frame later, make color 1 white and color 2 red, etc. This way you get animation without redrawing pixels (expensive), but simply by resetting the palette (cheap). Anything else?

nemetroid 10y ago
Great explanation. The intersection of people familiar with those terms but not familiar with how this iconic demo works is probably small.
anexprogrammer 10y ago
It's worth mentioning the reveal, which the page omits entirely, and was the astonishing bit of the CES demo at the time. In the original demo they were showing the normal desktop screen, showing window dragging, resizing, showing text editors, clocks, shell and what not. Running 640x480 4 colour. The whole time you could hear the bang bang of the boing ball bouncing, but see nothing. At some point a viewer asks "what the heck's that noise?" and the demoer pulls down the desktop screen to smoothly, and without glitching, reveal a 320x240 32 colour screen running the Boing demo behind it. In its day, that was almost unbelievable. PCs had just got 16 colour EGA and switching res resulted in a couple of seconds of monitor blanking or losing sync as it switched. I can't remember if they also had a 4096 colour HAM image (Hold and Modify - a way of cheating with palettes and getting a LOT more colours) behind that. The Amiga had virtual screens that operated a little differently to a modern approach - they could be massive with a monitor sized viewport onto it. They could have multiple resolutions and bit depths. They could be brought forward and sent back, and dragged (only up and down) to reveal multiple screens at a time. Visualise having a full size browser window, and dragging the whole window down to reveal the desktop, but switching resolution and colours as you go. People left speechless. The copper (display co-processor) allowed switching of palette and resolution, with 0 cpu use, on a particular scan line every frame. It seriously took 10 years or more before a Windows desktop could move stuff around the screen as smoothly, mainly as the Amiga didn't actually move a lot of stuff a PC did. PCs were upping colour depth as they aged rather than chasing more speed though. Virtual screens were a shadow of their Amiga implementation.
- digi_owl 10y ago
  While i own an A500 (still sitting in the basement) i was too young to really grasp what i was dealing with. Recently i learned that the Amiga was effectively two computers in one. you had the 68k doing its thing, and then you had the custom chips doing their thing, and in the middle you had a shared RAM pool. I guess to a degree the current CPU+GPU setup comes close, but that on the Amiga the GPU had priority. That said, the tight coupling of CPU, RAM and the custom chips was perhaps the Amiga's Achilles heel. While on the PC you could switch out the various parts, the Amiga, at least on the A500, A600 and A1200, could not.
  - anexprogrammer 10y ago
    It's hard trying to answer this briefly. Hope it doesn't come out meaningless! It's comparable with current CPU+GPU but on a vastly simpler scale. The copper only had 3 instructions! Blitter, well most things, were DMA controlled but the whole chispet had a ton of special registers that both CPU and copper could get at. You could set what got priority. Coders had to learn to wait on blits as anything else - OS as you moved a window, another app or screen could have got it first. Hence why many games just hit the hardware - keep it simple, and single threaded, and to hell with the OS. :) About chip memory. Amigas had two types of memory Chip RAM and Fast RAM. Chip could be accessed by CPU and any of the chips, Fast RAM just the processor for programs and data. Modern CPU+GPU has two separate pools of RAM linked via the PCIe. If there were a similar architecture to the Amiga, but with modern complex silicon and design, I'm sure games coders would have dreamed up a few extra effects and tricks. Or maybe it wouldn't matter any more with the vast speeds we now reach, I don't know. Incidentally that tight linking, display coprocessing, along with the DMA channels, and readily available genlock, is why it ended up a niche success in broadcast. Nothing else apart from £10,000+ dedicated things like a Quantel Paintbox (who bizarrely still exist) could touch it, especially after the Video Toaster came along. The chipset needn't have been the achilles heel if Commodore had not been run by an asset stripping moron at the time. Designs were being done for follow on sets, but never made it, and we got AGA (a fraction of AAA) years late. I think they started on AAA in 87, and cancelled it or put it on hold probably a dozen times. The 3000+ was an astonishing prototype machine that only existed on Dave Haynie's desk, for ages. Commodore gave us the lousy cost cutting 4000 with IDE not SCSI as follow up.
hansjorg 10y ago
It might be obvious from the name, but there's also just one bit per pixel in a bitplane, and then you stack five bitplanes to get 32 colors. You can have different offsets into each bitplane, which is why the grid could stay in the same place while the ball bounced. The Amiga only supported bitplanes and not "chunky" modes like VGA where you have one byte per pixel. This made graphics with 256 colors (supported by the later AGA chipset) really slow as you had to do eight writes per pixel. For a while there was a lot of competition between coders to write the best chunky to planar routine. This enabled you to write graphics effects with a chunky graphics buffer and then convert every frame on the fly to planar. One of the fastest was written by Kalms: http://www.lysator.liu.se/~mikaelk/doc/c2ptut/ http://www.lysator.liu.se/~mikaelk/doc/c2ptut/
- afandian 10y ago
  The offsets were measured in bits rather than bytes? That must have been a lot of engineering work.
  - hansjorg 10y ago
    If I remember correctly, the offsets were measured in words (16 bits on the M68k), and then you had scroll registers where you could offset with 0-15 pixels. This was complicated a bit since you only had two scroll registers, one for even and one for odd bitplanes. No idea how this was implemented in hardware.
  - pjc50 10y ago
    Not particularly. Think of the display as a "stack" of monochrome one-bit-per-pixel images. Then bit offsets become completely natural.
    - afandian 10y ago
      I was thinking in terms of word alignment and synchronisation issues.
- elektropionir 10y ago

by Luc 10y ago

nemetroid 10y ago

Great explanation. The intersection of people familiar with those terms but not familiar with how this iconic demo works is probably small.

anexprogrammer 10y ago

It's worth mentioning the reveal, which the page omits entirely, and was the astonishing bit of the CES demo at the time. In the original demo they were showing the normal desktop screen, showing window dragging, resizing, showing text editors, clocks, shell and what not. Running 640x480 4 colour. The whole time you could hear the bang bang of the boing ball bouncing, but see nothing. At some point a viewer asks "what the heck's that noise?" and the demoer pulls down the desktop screen to smoothly, and without glitching, reveal a 320x240 32 colour screen running the Boing demo behind it. In its day, that was almost unbelievable. PCs had just got 16 colour EGA and switching res resulted in a couple of seconds of monitor blanking or losing sync as it switched. I can't remember if they also had a 4096 colour HAM image (Hold and Modify - a way of cheating with palettes and getting a LOT more colours) behind that. The Amiga had virtual screens that operated a little differently to a modern approach - they could be massive with a monitor sized viewport onto it. They could have multiple resolutions and bit depths. They could be brought forward and sent back, and dragged (only up and down) to reveal multiple screens at a time. Visualise having a full size browser window, and dragging the whole window down to reveal the desktop, but switching resolution and colours as you go. People left speechless. The copper (display co-processor) allowed switching of palette and resolution, with 0 cpu use, on a particular scan line every frame. It seriously took 10 years or more before a Windows desktop could move stuff around the screen as smoothly, mainly as the Amiga didn't actually move a lot of stuff a PC did. PCs were upping colour depth as they aged rather than chasing more speed though. Virtual screens were a shadow of their Amiga implementation.

digi_owl 10y ago
While i own an A500 (still sitting in the basement) i was too young to really grasp what i was dealing with. Recently i learned that the Amiga was effectively two computers in one. you had the 68k doing its thing, and then you had the custom chips doing their thing, and in the middle you had a shared RAM pool. I guess to a degree the current CPU+GPU setup comes close, but that on the Amiga the GPU had priority. That said, the tight coupling of CPU, RAM and the custom chips was perhaps the Amiga's Achilles heel. While on the PC you could switch out the various parts, the Amiga, at least on the A500, A600 and A1200, could not.
- anexprogrammer 10y ago
  It's hard trying to answer this briefly. Hope it doesn't come out meaningless! It's comparable with current CPU+GPU but on a vastly simpler scale. The copper only had 3 instructions! Blitter, well most things, were DMA controlled but the whole chispet had a ton of special registers that both CPU and copper could get at. You could set what got priority. Coders had to learn to wait on blits as anything else - OS as you moved a window, another app or screen could have got it first. Hence why many games just hit the hardware - keep it simple, and single threaded, and to hell with the OS. :) About chip memory. Amigas had two types of memory Chip RAM and Fast RAM. Chip could be accessed by CPU and any of the chips, Fast RAM just the processor for programs and data. Modern CPU+GPU has two separate pools of RAM linked via the PCIe. If there were a similar architecture to the Amiga, but with modern complex silicon and design, I'm sure games coders would have dreamed up a few extra effects and tricks. Or maybe it wouldn't matter any more with the vast speeds we now reach, I don't know. Incidentally that tight linking, display coprocessing, along with the DMA channels, and readily available genlock, is why it ended up a niche success in broadcast. Nothing else apart from £10,000+ dedicated things like a Quantel Paintbox (who bizarrely still exist) could touch it, especially after the Video Toaster came along. The chipset needn't have been the achilles heel if Commodore had not been run by an asset stripping moron at the time. Designs were being done for follow on sets, but never made it, and we got AGA (a fraction of AAA) years late. I think they started on AAA in 87, and cancelled it or put it on hold probably a dozen times. The 3000+ was an astonishing prototype machine that only existed on Dave Haynie's desk, for ages. Commodore gave us the lousy cost cutting 4000 with IDE not SCSI as follow up.

hansjorg 10y ago

It might be obvious from the name, but there's also just one bit per pixel in a bitplane, and then you stack five bitplanes to get 32 colors. You can have different offsets into each bitplane, which is why the grid could stay in the same place while the ball bounced. The Amiga only supported bitplanes and not "chunky" modes like VGA where you have one byte per pixel. This made graphics with 256 colors (supported by the later AGA chipset) really slow as you had to do eight writes per pixel. For a while there was a lot of competition between coders to write the best chunky to planar routine. This enabled you to write graphics effects with a chunky graphics buffer and then convert every frame on the fly to planar. One of the fastest was written by Kalms: http://www.lysator.liu.se/~mikaelk/doc/c2ptut/ http://www.lysator.liu.se/~mikaelk/doc/c2ptut/

afandian 10y ago
The offsets were measured in bits rather than bytes? That must have been a lot of engineering work.
- hansjorg 10y ago
  If I remember correctly, the offsets were measured in words (16 bits on the M68k), and then you had scroll registers where you could offset with 0-15 pixels. This was complicated a bit since you only had two scroll registers, one for even and one for odd bitplanes. No idea how this was implemented in hardware.
- pjc50 10y ago
  Not particularly. Think of the display as a "stack" of monochrome one-bit-per-pixel images. Then bit offsets become completely natural.
  - afandian 10y ago
    I was thinking in terms of word alignment and synchronisation issues.
elektropionir 10y ago