7 ms·

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 diff

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
This also let you make "memory peekers". It was just a simple assembly program that would offset the pointer to a bitplane based on the mouse vertical movement. You could "look" at the RAM and it was one way to rip images since you would see the bitmaps of images from the game still in RAM after the reset.
- vardump 10y ago
  Yeah, that was a great way to "visualize" chip RAM contents. Curiously, on some later A500 OCS models, you could also see that into "slow RAM" expansion module range! Just needed to point bitplane pointers above 0x80000. It appeared at 0xc00000 for the CPU and 0x80000 for chipset.
Corrado 10y ago
Yes, this is why recreating Doom on the Amiga was so difficult. I remember wanting to play a Doom-like first person shooter back in my youth and being completely frustrated because the performance just wasn't there. It took several years before anything even close became available and by that time the world had moved on. I really think this limitation was one of the reasons that the Amiga faltered; it was a terrific platform in almost every single way, but it couldn't do first person shooters worth a damn. :(

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

This also let you make "memory peekers". It was just a simple assembly program that would offset the pointer to a bitplane based on the mouse vertical movement. You could "look" at the RAM and it was one way to rip images since you would see the bitmaps of images from the game still in RAM after the reset.

vardump 10y ago
Yeah, that was a great way to "visualize" chip RAM contents. Curiously, on some later A500 OCS models, you could also see that into "slow RAM" expansion module range! Just needed to point bitplane pointers above 0x80000. It appeared at 0xc00000 for the CPU and 0x80000 for chipset.

Corrado 10y ago

Yes, this is why recreating Doom on the Amiga was so difficult. I remember wanting to play a Doom-like first person shooter back in my youth and being completely frustrated because the performance just wasn't there. It took several years before anything even close became available and by that time the world had moved on. I really think this limitation was one of the reasons that the Amiga faltered; it was a terrific platform in almost every single way, but it couldn't do first person shooters worth a damn. :(