Bit Blit Algorithm (Amiga Blitter Chip) - Computerphile

The Bit Blit algorithm dates back to Xerox PARC, but was famously used to sell the Amiga home computer among others. Dr Steve Bagley takes us through how it works.

This is a re-upload due to an audio problem on the earlier edit -Sean


This video was filmed and edited by Sean Riley.

[laurencevanhelsuwe]

The Amiga blitter also had something amazing (for that time): a mode to render lines. If I remember correctly it implemented Bresenham's line drawing algorithm.. in hardware. This was pretty mindblowing stuff, at the time. I got it to work (banging pure hardware) and managed to get a wireframe space shuttle rotating smoothly on the screen. Those were the days.

[ScottLahteine]

For my 1990 Amiga game "Dino Wars" I went "straight to the hardware" for everything, bypassing the OS, and there is a lot of unique and clever use of the Blitter to optimize drawing of large graphics. Specifically, I implemented a "blit strips" compression/decompression algorithm that divided up all the large dinosaur bitmaps into vertical strips, only where the data was non-zero, and with a minimum gap between strips. All the size and blitter setup info is interspersed in the data, so it is read sequentially during the full blit operation. The Amiga also used "bit planes" for its graphics, so the bits in each plane always correspond to one pixel. This meant that some of the data planes in the source graphics were mostly empty. The mask –which is just an OR of all the planes in the bitmap– was the largest blob of data, but also the most vital, as it was used to do "cookie cutter" operations. And, depending on how the image mask was applied to the bit planes, the graphics could be made to use different parts of the color palette, so the same bitmap data could be used to draw different colored dinosaurs. Even though the blit strips method uses the CPU a lot more during drawing, since the overall strip-compressed data size was a lot smaller than the raw rectangle the end result was much faster drawing. On top of using the blitter in this clever manner, I also ended up writing blitter code to handle the MFM (or was it GCR?) floppy disk encoding/decoding because I even bypassed the OS for disk I/O. I no longer have the originsl source code, but someday I hope to use the debug monitor in an Amiga emulator to extract some of these cool bits and showcase them someplace for posterity. I know of no other game that thought to employ the blitter in just this way.

[dansalvato]

I love Amiga and never expected this crossover! I always think about the blitter and how it could be leveraged to create really interesting visual effects and blazing fast graphics, but specifically if the application/game is designed with the blitter in mind (like many demos are). I think the blitter was more often used to emulate "chunky" graphics. It made sense during a time where such colorful 16-bit graphics was a cutting-edge novelty, and games were often even marketed with having "arcade-quality" visuals.

But the gaming landscape is so different now - especially in the indie space, we prioritize design so much more than "realistic" graphics, and I think that opens up a world of potential for Amiga and its powerful and unique blitter. Seeing releases like Sam's Journey for C64 and Micro Mages for NES makes me excited for the future of our favorite retro platforms!

[isyt]

Love this.
As a middle aged software engineer who grew up learning to code on amigas and Atari st’s I had no idea what was going on under the bonnet.

Brilliant video!

[treyquattro]

should have mentioned that "blt" is short for block transfer

[zanesthename]

I learned that from the book Smalltalk 80 and later used it to implement the display for the first raster-scanned anti-aliased heart monitor. Previous to that vector displays, large, heavy, power guzzlers, were used by all displays.

[DavePoo]

24:48 - "you can't have 2 things accessing memory at the same time" - well, that's not quite true with the Amiga, as it had the ability to access the non shared RAM at the same time as the blitter was accessing the shared ram -> from The Amiga Hardware Manual -> "Performance of the 68000 is enhanced by a system design that gives it every alternate bus cycle, allowing it to run at full rated speed most of the time. As described in the section below, the special purpose hardware can steal time from the 68000 for jobs it can do more efficiently than the 68000. Even then, such cycle stealing only blocks the 68000's access to the shared memory. When using ROM or external memory, the 68000 always runs at full speed. "

[ltdowney]

Blitting in some sense is more alive than ever. Deferred rendering techniques in modern graphics engines involve rendering to an offscreen buffer for various uses. These could be postprocessing effects like bloom or shader-based antialiasing, but the best example is probably environment mapping. If you’re playing a game and you walk into a bathroom (toilet, for the Brits), and you’re impressed that you can see your character move back and forth in the mirror, it’s really nothing too fancy happening there. The game is rendering the scene once from the mirror’s perspective into a texture buffer, and then rendering the scene again from the player’s perspective after mapping the texture onto the mirror in 3D space. All this takes place inside the graphics card, so the programmer doesn’t interact with it quite the same way any more. We don’t have to worry about the copy operations pixel-by-pixel, per se, although in a fragment shader you are computing the output of each pixel, but the graphics hardware and driver take care of calling it repeatedly, in parallel, over the entire scene.

[captainboing]

the Amiga used the blitter for disk access too. Because of the encoding, there was a "soft index" (4489h... maybe... ?) that could never be the result of a data encoding action. AmigaDOS just dropped the head on the disk, read an entire track (+ a bit). The blitter was then tasked to find the index and re-construct the entire track in the right order. The DOS firmware then just picked out the sectors it wanted.

[tramsgar]

I used the Amiga blitter to write programs for it's 'Copper' video coprocessor to create colourful gradients otherwise not possible with the limited number of bitplanes. Very useful hardware indeed.

[discoisdead]

Yay Amiga. The 80s, a time when computers were much more interesting than today.

[АртёмСабадырь]

BitBlit hardware is still there actually. Every smartphone has 2D acceleration block inside SoC. And its main task is BitBlit. Yes, it's a bit more advanced since it can convert colorspace and do alpha blending. It also can "fill rectangle with color" and "draw line". But 2D accelerator is mostly (like 80%) a BitBlit chip.
2D accelerator easily outperforms both CPU and GPU inside mobile chipsets.
And there are more 2D hardware in a smartphone. Like Image Signal Processor which can crop and resize image from your camera.
Or Video Output Processor which can blend several planes (aka windows) on the fly pixel by pixel while sending result directly to display. Much like graphics editors handle multiple layers.

[TheTurnipKing]

it was massively useful for graphics operations because early days, that's what 95% of graphics operations were: Copying (relatively) huge chunks of data around.

Scrolling is the defacto example of this. You're moving 95% of the already on-screen data from one location in memory to another area nearby and then copying a small amount of new data onto one or two of the borders of that screen ram.

[davidgillies]

It would be interesting to see a detailed examination of the QuickDraw CopyBits function that Apple used in early versions of the Mac. That was a software blitter, but incredibly highly optimised and included the ability to clip the destination with an arbitrary region (which is a video all by itself). The Apple engineers were justifiably proud of how much work went into CopyBits.

[BrekMartin]

About time the Amiga featured here! :D

[SteelHorseRider]

Amiga also had the "Copper" (simply an abbrev. for "Co-Processor") in addition to the Blitter - and although it had only three commands built in it understood (move, skip, wait) it could get very complex in using it...

[feppfepp]

That's an zx spectrum A. I still recognise the byte values from creating fonts for it almost 40 years ago...

[PaulFisher]

One example of the “bitplanes” you discuss at about 07:45 is on the SNES. Retro Game Mechanics Explained has an excellent video about how backgrounds and color work on that system!

[recompile]

Steve, you can very easily divide a box into 8 parts by cutting things in half 3 times. (From your starting rectangle, making 2, then 4, and finally 8 boxes) 2^3=8 after all! Estimating half is easy for humans, so your boxes will come out very even.

[FinaISpartan]

Anyone who works directly with the win32 API for graphics knows bit blit very intimately. Interesting to learn of its history.