Nice to see a Amiga featured in a Computerphile video, but the amiga blitter was much more complex, it could for example combine 3 sources in one operation, for example a char of a font, a mask which defines which pixels to copy over, the destination (yes as source also) and the destination again, so that only the bits set in the mask are blitted over, at the same time the barrelshifter could shift the whole operation multiple bits to the side (for pixelexact placement/scrolling), it could also draw lines, fill outlines, all this made the amiga far ahead of any pc for a long time, when 386 with ~80Mhz and the first Geforce cards showed up pc slowly had the same power as an plain Amiga 500 with 68000@7Mhz.
I've seen 386 at 40 running elite II fluently. On the Amiga.. 5fps? Cannon fodder ran fine on a 386slc at 25 MHz. Even with smooth paralaxing intro and everything. PCs by then had such fast cpus and buses that they didn't even need a blitter.. But some had them in the form of "windows accelerators". Amiga was great tech and a bag of tricks, but by 1992, they were behind.
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.
@@eadweard. Banging = just writing to the blitter registers. If my memory doesn't fail me, the hard part was that your code needed to figure out in which of 8 octants the line would fall into.. this information was needed by the blitter to properly render the line. So it wasn't as simple as passing (x1,y1) and (x2, y2) to the registers..
@@laurencevanhelsuwe3052 I wrote a lot of stuff for the Amiga back in my youth, and started doing some programming on it again recently to render filled vector objects. Getting the line drawing code right is quite finnicky as you say. The Amiga also had a primitive polygon filling operation built into the blitter, which had some subtleties to overcome when used with the line drawing hardware. Amazing machine for it's time though.
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.
In the day, Bit Block Transfers were called 'Bit Blot' operations and Block Image Transfers were called 'Blit' operations. The real trickiness happens with blitting, on screen or off, when the source and target rectangles memory regions overlap, then you might have to read rows, or columns, or both in reverse order to not wreck the source data during the copy. I worked on coin-op conversions back in the 6502 and Z80 days. Non-contiguous display memory rows like the Apple ][ were a pain!
... and blitter = BLock Image Transferrer. When the ST finally got some more advanced gfx hardware, I heard it called a "blimmer" which was a block image manipulator. Mag article and jealousy slap at Amiga hw
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!
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!
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.
All gpu operations render to an offscreen framebuffer before swapping to the screen, even window managers do this, compositing everything together before showing the final result.
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.
@@squishmastah4682 Thanks yeah, it was interesting. Either directly from Smalltalk 80 or something else I had read I learned that if you have a monochrome display where each pixel has several levels of intensity you could make it appear that a pixel was located somewhere between two pixels by appropriately setting the intensity of those pixels. That let me make a smooth curve even on the then low-resolution displays.
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.
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.
I have been wondering about that too - especially considering how far ahead of the competition it was in the late 80s. Full 32-bit preemptive multitasking, with OS-wide cross process scripting and what not. The HAM (hold-and-modify) mode is worth a video all by itself, I think. Imagine doing 1448 x 720 in 262144 colors in 1991? Yup, it did that.
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.
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.
Dark Winter but regions and bitblit implementations were down in ROM - at the time, they were impressive graphics primitives even though coded to execute on the 68000 cpu
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. "
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.
@@VastyVastyVoid That's a perfect example of WHY companies started introducing hardware assistance like Blitters and such into their systems to perform these tasks.
@@VastyVastyVoid Yup, or update the LMS addresses for Antic on it's true predecessor, the Atari 8 bit machines. No screen memory moves, the 'Window' into memory moves.
@@Jimbaloidatron Eh, I wouldn't call the Atari 8-bit its predecessor. I could be convinced, but the evidence would have to be something special -- the engineers having worked at Atari wouldn't be sufficient, given the differences in terms of architecture, OS decisions, microkernel etc. But yes, that part works in a similar fashion, or at least as far as I know.
@@VastyVastyVoid I don't believe you can really be thinking in terms of the OS and microkernel software when comparing to any 8 bit system, Atari or otherwise! Without even knowing that Jay Miner designed the Antic and C/GTIA chips, you can see things in the hardware; like how the Amiga sprites have unlimited height is an evolution of the C/GTIA columnar 'players'. That _by design_ you can display multiple modes of different resolutions all on the screen simultaneously from different places in memory. The emphasis toward graphical co-processor use itself. It's inevitable some concepts will have stayed with him, evolved and been turned up to eleven in the Amiga - the clues are there. When Atari released the ST, I was among many Atari 8 bit users who could not accept a bunch of off-the-shelf components as a compelling upgrade and instead bought an Amiga. Maybe I choose to see things that way, and it's entirely confirmation bias, but I'm happy with that. We all learn as we go and our successes will influence our future choices, no reason to think it wouldn't have applied back then and it does no harm to the Amiga legacy, except perhaps if there are those who think a beam of golden light came from the sky and the wire-wrapped prototype descended slowly in a shimmering cloud of beautiful copper bars! :-)
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!
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...
@@hardware4200 No, HAM was implemented in the graphics chip, but you could use the copper to increase the effective palette in all modes by switching palette entries when you got to specific screen positions.
@@hardware4200 Slice HAM mode used copper to reload the color palette at a specific display location. Normal HAM used specific hardware features in Amiga's custom chip.
The Copper chip was far more innovative than the Blitter. It was the Copper that allowed the multiple vertically-sliding “screens” with different graphics modes. They could only be partitioned vertically, because the Copper chip could only change mode between scan lines, not in the middle of a scan line. But being able to dynamically rebuild a display list was (in those days) much quicker than having to copy entire screenfuls of pixels around.
@@lawrencedoliveiro9104 The Copper could change a register in the middle of a scan line. However, for one change along a vertical line you would have to do perform a Copper operation in every scan line. And the horizontal resolution for changes was limited (I assume 4 pixels).
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.
I guess I don't see the utility outside of older computer graphics. Do you have an example of where you'd need to copy data that isn't byte aligned to a source that is misaligned differently?
@@recompile In it's simplest form just to copy big blocks of memory (without shifting or bit operating), to free up the CPU to do other things. It was even mentioned in the video.Then it's basically DMA (which the Amiga also implemented btw.).
I've made Conway in the Win32 API recently. would love to learn more about its bit blit functionalities more in-depth if you have any resources and/or advice you're willing to share
It would have been great to have done the setup starting with one of the first GUI's based on Smalltalk in the mid 1970's, and the need to move / manipulate bitmaps.
I suggest folks go read about how John Carmack implemented side-scrolling on PC using the EGA latches. PC graphics hardware was never made for gaming but a lot of clever tricks were used to speed up blitting in ways never really intended.
@@uriituw if you mean blitter, no, they are not saying that. They are saying that EGA has horizontal and vertical offset values for the frame buffer. This drastically reduced the amount of blitting needed for scrolling graphics. Do as they suggest and google that "John Carmack implemented side-scrolling on PC using the EGA latches", and you'll find the Wikipedia article describing the whole process.
One big problem with the video. "You could do this much faster than you could in software" - on Amiga, actually, no! Blitting using CPU was roughly the same speed on A500, and significantly slower on A1200 - simply because Blitter operated at much slower clock than the CPU. It still had its uses because you could blit areas of memory using the blitter while the CPU was busy doing other, unrelated stuff - or even blitting *other* areas of memory, say, have a game with a couple objects maintained as BLOBs (Blitter Objects) and majority generated by CPU. Plus Blitter could keep your software short and sweet, setting it up was way less work. But apples to apples, it wasn't faster.
It was faster. We are talking OCS here and 68000 and try to do a 3 source data manipulation with bit shifting with the CPU (who has not any bit barrel rotation in hardware) as fast. So yes the blittwr was indeed faster. If we talk just simple word aligned data A to B copy. Then yes they where more or less same speed. But that is not what blitting was
Essentially it's DMA with some extra capabilities. Somewhat unfortunate that the 90s was dominated by the IBM compatible alone, since programmable logic could have made blitting virtually omnipresent.
I see that planar graphics made a lot of sense to exploit a blitter chip...but it's a pain in the 0xA55 to do texture mapping with. No wonder only now the Amiga got a proper Doom clone (as in, it plays *fast* on a stock A500, in Fullscreen)
It's quite cool that Intuition (or is it from a layer below?) exposes all this to the graphic routines to plot shapes... something the Win32 API would have to wait a little to see the same level of versatility
Indeed. Even when the Atari st also copied that idea. You actually need that blitter. The 68000 didn't have a barrel shifter so every sprite needed preshifting. Better if they'd just used chunky nibbles. Especially for texturing and sprite scaling and rotating
Thanks, Steve. Quite interesting. Have you heard of NAPLPS? And if so, perhaps you might consider a segment covering the once popular graphics protocol.
NAPLPS? Videotex/Teletext Presentation Layer Protocol Syntax (North American PLPS)? ANSI BSR X3.110-198X? X3L2.1? Successor to TELIDON? Never heard of it. Though, come to think of it, back in June 1983, I had a weird dream that was picked up by a tornado and dropped in Chicago, where I represented Digital Equipment Corp. (not as the primary representative) at a trilateral (ANSI-CSA-EIA) meeting where we spent much of the time arguing over unprotected fields or some such nonsense. I woke from the dream is a cold sweat, clutching the draft proposal closely. Was it real? That was definitely my handwriting on the March trilateral meeting draft. My name isn't in the standard, I don't think, so maybe it was a dream... I still have a photocopy of the June 10, 1983 draft, and I spent several months implementing PDIs and DRCS for the NAPLPS and TELEDON terminal emulator for the DEC Professional 350, working late into the night in my cube on the 2nd floor of building 5 of the Mill in Maynard, MA. What utter BLISS (the language I wrote it in).
There also is the BItBlt Win16 SDK API, that wasn't implementeed in HW, but relied on auto-modifying code, if I do remember correctly Matt Pietrek's artticle from Beautiful Code. That was the reason why the first Microsoft WIndows was astoundingly fast ("fast" in the '80s).
I'm not sure if it's worth another reupload to fix it, but at 7:19, 9:54, 21:48, 24:11 it's very quiet and only plays in the left ear. The marker scratching is also a little out-of-sync at 12:11. At 20:40 it's also quiet, but that might just be the original volume picked up by the microphone of him whispering. :-)
It sounds to me like he spent 15 minutes describing copying data from one memory location to another, and I don't really understand how there's really any other way to do it. You read from the source and write to the destination. I feel like he's describing something clever, but it sounds very obvious to me. What am I missing? I guess it's just the boolean operation in the middle?
It is what he's describing. What you're missing is the many variations (start part way through a byte/word, start part way through one block, discard part of a block, and so on) of how that move happens and the fact that while CPU can do it, it is designed for a more general case so it does it poorly. Blitter chip specializes in the moving and combining of large data sets quickly with low latency, something the CPU wasn't designed for.
If you do such copy operations with the cpu you first need a command to read the source-byte, then maybe shift it to get to the exact destination adress, "and" it to mask the bits you dont want, read the destination, "or" the source/masked/bits with it, write it to the destination .. and that for every byte (and also skip x bytes after a row is complete) - with a blitter you tell him the source, destination, modulos (how many bytes to the next line), shift how many bits, copy how many pixel in x&y - and then the blitter does the rest, your cpu can do something else ..
I understand the advantage of offloading a process from the CPU, but that's advantageous regardless of what you're offloading. He did mention that it was particularly efficient in hardware, but then never described why.
@@wbfaulk Because you need multiple cpu-commands, read the bits, mask it with AND, read the destbits, OR the destbits, write to the destination, and that over and over again, and skip row-bytes to get to the next row and so on .. a blitter has these commands "baked" in hardware, you just say how much to copy and he does his thing and the cpu is free to do other tasks.
@@Lynxxde Again, that's true of any offloading. What makes this more advantageous than other things you could offload? Also, my point is more about the incompleteness of the video than the idea that I can't find this information elsewhere.
Interesting. Makes me think of sprites. I guess the same mechanization but not storing the result in the original memory but combining the original memory with the 'sprite'content.
Do modern computers have chips for this? Or do they just do it on the CPU? Is it a part of the GPU now? Edit: I see, less useful with higher bits per pixel
At least on the CPU, with random access memory there isn't much need to copy things around. Most instructions can use one memory operand (source/destination) and the others are registers. So the AND could be either "read and AND" or "read, AND and write". Pure memory copy instructions are not prioritized because the limiting factor is usually latency. On my CPU: read (from cache) and add value takes effectively 0.5 cycles (out of 5Ghz, e.i. 5 billion/s), but the latency is 5 cycles. Accessing RAM takes hundereds. Even light could only travel ~6cm per cycle. CPUs have more power than simple operations require, so they make them more complex by combining them and executing them in parallel.
GPUs are more generic now. So they work quite differently. And video output hasn't used bit planes since vga. GPUs have tons of parallel processors that can operate on each pixel at the same time. And each one can often operate on multiple pixels with a single instruction. But you code it up directly. It can get complicated with shared registers, shared local memory, latency and other things. Loading data has latency, so you need multiple things to run on the same core so that when one program is waiting for data, it can execute a different program in the meantime. RDNA from AMD tried to reduce the number of programs you need. It can be on the order of 16... with AMD trying to reduce that to 4 or 8. And by program, they're really smaller sections of code and are called something else on GPU.
As fast as stuff like GLSL and Vulkan are, blitting is just SO much more intuitive. In some ways it's raised the barrier to entry for new programmers through the roof. Why should you have to write program files in an alien language and work backwards inventing projection from "first principles" just to say "put a red pixel at 3,4"? Parallelism is fast but woof it's a dog when compared to pushing colors into memory directly.
Because shader operations are inherently parallel. It's definitely less intuitive, but it's far more powerful overall if you take the time to figure out what is really happening. Still, maybe you are right that there is scope for a higher level of abstraction which could make this process simpler for some limited set of operations..
I remember a project in school we did in Assembly. It had a custom character set and bitmaps. And the display had to run through some cycles to change to a different characters l
my minesweeper automating dissociated bot uses bitblt to copy the hardware context screen buffer to a memory block that doesn't need to be locked to read. fastest screen grab function I tested by a factor of 50. it had the added benefit of being able to hold a copy of the hardware device context live in memory instead of asking for it every refresh. gotta eek out every ms I can! average solve time 175ms on an fx-8350. I think an older computer on 32bit would run substantially faster ironically. our of those 175ms average, 160+ms is just waiting for minesweeperx to refresh its state after sending a dozen clicks directly to its input queue... a windows 8+ only feature that saves a ton of time by not having to actually take control of or move the mouse cursor to do clicks. womp womp.
In Atari Falcon, for just simple memory copy, Blitter is slower than CPU, so it makes no sense to use it for HDD data transfer and is not used for that.
The source code for AHDI definitely has code for using the blitter to read from the IDE, and as far as I can tell it’s enabled if IDE exists, and the machine isn’t an ST Book, which leaves the Falcon. Yep, the Falcon's CPU can out run the blitter, but the IDE isn’t just a straight memory copy since you are reading from a single location, and writing to many which forces you to use move.w (a0), (A1)+ type code, that won’t get the full performance out of the 030 anyway.
correct me if i'm wrong but can't every algorithm be faster if implemented in hardware? Sure for some it's not really neccessary or efficient to do so but with tailor made hardware it'll still be faster
With all due deference to your Atari and Amiga fanbois (😊), let us not forget Bill Atkinson's Quickdraw programming tour-de force on the original Macintosh (128kb, 1984), which packed all this BitBlitty goodness, plus graphics line-drawing primitives (including circles, arcs etc), rounded corners, drawing regions, font drawing, scaling, rotation, all in 24KB of hand-optimized assembly code. You say, for example, that someone wrote a screen-copying algorithm that took 8 minutes to run? Then why was QuickDraw so damned quick, considering it was all done in 68000 code, and without even the benefit of a barrel-shifter, which only appeared in the much later 68020.
Well the Amiga had drawing code like this done in asm as well. Same cpu. Difference was that the line drawing code had help by hardware line drawings from the blitter
Commodore aimed for simplicity, so they used the same address generator in graphics mode as used in text mode, so the screen was still laid out as little 8x8 character regions. So in effect the whole screen was an agglomeration of characters with the bits of each character laid out as if they were little 8x8 raster scanned screens in memory.
@@mrxmry3264complicated? It was a stroke of genius. Also well almost all arcade hardware and consoles up to the first PlayStation used character / tile based approach. Made total sense for many reasons. If you wanted you had a bitmap mode in C64. With the issues that created of course.
Booooring 😉 Seriously, would have been cool, however, for games the ANTIC mode 4 is preferred. And using Blitter with char based gfx is not useful AFAICS.
Me programming low level graphics with color mapping: brighter colors will always have a higher value, that's obvious right? Steve using paper: so black will be a 1
Of course you could be working with CMYK or something, but if you're doing bit-level stuff in CMYK you're either a madman or you're doing something wrong.
What do you mean by "paged graphics"? Blitting is just a basic process where you copy image data (could be other data, but usually image) from memory to other parts of memory. If you have separate video memory, then quite often the copy happens from CPU memory to video memory. Nothing related to paging here. Blitting can be done with arbitrary-sized source data from any memory position to an arbitrary position in the destination memory. If by paging you mean double buffering, the answer is still no. Blitting is in no way dependent on the amount of frame buffers.
My memory is that the Amiga sprites were not written directly to the main bitmap, they were a separate bitmap that the video generation logic combined with the main raster at the right point in the encoding for each scan line they intersected with to produce the output signal. This allows moving the sprite around without having to redraw the bits in the bitmap. This also permitted them to be used over alpha-mosaic graphics modes on some devices like the Commodore 64.
Depends on the architecture, on some platforms (eg the ST, or Archimedes) then nothing everything is done by manipulating the in memory bitmap, on others such as the Amiga then sprites are composited onto the background as the image is drawn to the screen by the video hardware, the hardware effectively reads the background bitmap and the sprite bitmap and combines them. You can then move the sprite just by updating its position and altering where they are combined, rather than having to redraw it into the bitmap
AFAIK the difference is that a BOB consists of actually writing the graphic into the display memory whereas the sprite is not written into video memory but instead overlayed on the output stream. Put differently, as the pixels are being scanned and sent to the ADC, when a pixel position is reached where the sprite is not transparent the DAC will read that pixel from the memory where the sprite is stored rather than from the memory where the pixel at that position is stored.
@@listerdave1240 Probably more accurate to say that the "GPU" reads both and when the sprite isn't transparent it writes the sprite data, instead of the buffer data, to the DAC.
Nice to see a Amiga featured in a Computerphile video, but the amiga blitter was much more complex, it could for example combine 3 sources in one operation, for example a char of a font, a mask which defines which pixels to copy over, the destination (yes as source also) and the destination again, so that only the bits set in the mask are blitted over, at the same time the barrelshifter could shift the whole operation multiple bits to the side (for pixelexact placement/scrolling), it could also draw lines, fill outlines, all this made the amiga far ahead of any pc for a long time, when 386 with ~80Mhz and the first Geforce cards showed up pc slowly had the same power as an plain Amiga 500 with 68000@7Mhz.
Was looking for this comment. The Amiga’s blitter could be used to paint filled polygon 3d graphics with the right setups
I've seen 386 at 40 running elite II fluently. On the Amiga.. 5fps? Cannon fodder ran fine on a 386slc at 25 MHz. Even with smooth paralaxing intro and everything. PCs by then had such fast cpus and buses that they didn't even need a blitter.. But some had them in the form of "windows accelerators". Amiga was great tech and a bag of tricks, but by 1992, they were behind.
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.
What do you mean "banging"?
@@eadweard. Banging = just writing to the blitter registers. If my memory doesn't fail me, the hard part was that your code needed to figure out in which of 8 octants the line would fall into.. this information was needed by the blitter to properly render the line. So it wasn't as simple as passing (x1,y1) and (x2, y2) to the registers..
@@laurencevanhelsuwe3052 oh right thanks I thought at first it was some kind of depravity.
@@laurencevanhelsuwe3052 I wrote a lot of stuff for the Amiga back in my youth, and started doing some programming on it again recently to render filled vector objects. Getting the line drawing code right is quite finnicky as you say. The Amiga also had a primitive polygon filling operation built into the blitter, which had some subtleties to overcome when used with the line drawing hardware. Amazing machine for it's time though.
@@eadweard. It definitely is and a great time in history of programming :D
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.
Would be really nice to see a more detailed writeup on this!
@@noor-rx1ij agreed
should have mentioned that "blt" is short for block transfer
But what if The Master gets in and corrupts the process?! It’ll be Logopolis all over again 😫
tf you mean? blt stands for bacon lettuce tomato smh
In the day, Bit Block Transfers were called 'Bit Blot' operations and Block Image Transfers were called 'Blit' operations.
The real trickiness happens with blitting, on screen or off, when the source and target rectangles memory regions overlap, then you might have to read rows, or columns, or both in reverse order to not wreck the source data during the copy.
I worked on coin-op conversions back in the 6502 and Z80 days. Non-contiguous display memory rows like the Apple ][ were a pain!
... and blitter = BLock Image Transferrer. When the ST finally got some more advanced gfx hardware, I heard it called a "blimmer" which was a block image manipulator. Mag article and jealousy slap at Amiga hw
yum, virtual burguer
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!
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!
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.
We have bathrooms in Britain. If you walk into a toilet you get wet feet.
Thank you for this explanation.
@Xeno The Strange Or brown toes?!
All gpu operations render to an offscreen framebuffer before swapping to the screen, even window managers do this, compositing everything together before showing the final result.
superscatboy Yep, though you can also "go to" the toilet (presumably stopping before stubbing your toe).
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.
Sounds like a definite win.
@@squishmastah4682 Thanks yeah, it was interesting. Either directly from Smalltalk 80 or something else I had read I learned that if you have a monochrome display where each pixel has several levels of intensity you could make it appear that a pixel was located somewhere between two pixels by appropriately setting the intensity of those pixels. That let me make a smooth curve even on the then low-resolution displays.
@@zanesthename You were lucky! Getting to play with anti-aliasing while I was busy fixing S.E Labs (later Thorn EMI) CardioStore heart monitors. :-)
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.
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.
About time the Amiga featured here! :D
I have been wondering about that too - especially considering how far ahead of the competition it was in the late 80s. Full 32-bit preemptive multitasking, with OS-wide cross process scripting and what not. The HAM (hold-and-modify) mode is worth a video all by itself, I think. Imagine doing 1448 x 720 in 262144 colors in 1991? Yup, it did that.
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.
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.
Well, QuickDraw and MacPaint have been open-sourced, so…
Dark Winter but regions and bitblit implementations were down in ROM - at the time, they were impressive graphics primitives even though coded to execute on the 68000 cpu
@@TheSulross QuickDraw was ROM-resident and the source for that part of the ROM is included in the package of source code.
They got a patent on the QuickDraw region structure, and wouldn’t let anybody else use it until it expired in about the 200x’s.
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. "
You can also send blitter commands via the copper, freeing the CPU even more. It's not often used though, as I believe it can can get a little messy.
Yes, but only because the bus accessors are slow. If you'd need the dma to go as fast as physically possible, wait states would ensue.
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.
True, but not always. On the Amiga, you would simply update the bitplane pointers to point to the new location.
@@VastyVastyVoid That's a perfect example of WHY companies started introducing hardware assistance like Blitters and such into their systems to perform these tasks.
@@VastyVastyVoid Yup, or update the LMS addresses for Antic on it's true predecessor, the Atari 8 bit machines. No screen memory moves, the 'Window' into memory moves.
@@Jimbaloidatron Eh, I wouldn't call the Atari 8-bit its predecessor. I could be convinced, but the evidence would have to be something special -- the engineers having worked at Atari wouldn't be sufficient, given the differences in terms of architecture, OS decisions, microkernel etc.
But yes, that part works in a similar fashion, or at least as far as I know.
@@VastyVastyVoid I don't believe you can really be thinking in terms of the OS and microkernel software when comparing to any 8 bit system, Atari or otherwise! Without even knowing that Jay Miner designed the Antic and C/GTIA chips, you can see things in the hardware; like how the Amiga sprites have unlimited height is an evolution of the C/GTIA columnar 'players'. That _by design_ you can display multiple modes of different resolutions all on the screen simultaneously from different places in memory. The emphasis toward graphical co-processor use itself. It's inevitable some concepts will have stayed with him, evolved and been turned up to eleven in the Amiga - the clues are there. When Atari released the ST, I was among many Atari 8 bit users who could not accept a bunch of off-the-shelf components as a compelling upgrade and instead bought an Amiga. Maybe I choose to see things that way, and it's entirely confirmation bias, but I'm happy with that. We all learn as we go and our successes will influence our future choices, no reason to think it wouldn't have applied back then and it does no harm to the Amiga legacy, except perhaps if there are those who think a beam of golden light came from the sky and the wire-wrapped prototype descended slowly in a shimmering cloud of beautiful copper bars! :-)
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!
Bitplanes in the ST or Amiga are different from background layers of the SNES.
Bit is not bitplanes that is display layers. Very very different
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...
Wasn't copper used to implement hold and modify. This goes way back for me.
@@hardware4200 No, HAM was implemented in the graphics chip, but you could use the copper to increase the effective palette in all modes by switching palette entries when you got to specific screen positions.
@@hardware4200
Slice HAM mode used copper to reload the color palette at a specific display location.
Normal HAM used specific hardware features in Amiga's custom chip.
The Copper chip was far more innovative than the Blitter. It was the Copper that allowed the multiple vertically-sliding “screens” with different graphics modes. They could only be partitioned vertically, because the Copper chip could only change mode between scan lines, not in the middle of a scan line. But being able to dynamically rebuild a display list was (in those days) much quicker than having to copy entire screenfuls of pixels around.
@@lawrencedoliveiro9104 The Copper could change a register in the middle of a scan line. However, for one change along a vertical line you would have to do perform a Copper operation in every scan line. And the horizontal resolution for changes was limited (I assume 4 pixels).
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.
Nice way to do it. Works great for any 2^x divided boxes (8, 16, 32, etc.).
that is also why Imperial length units live on.
I was watching the video thinking the exact same thing... every... single... time... I thought it was a natural programmery thing to 'binary chop' it!
I was just about to comment that, too! 😀
That's an zx spectrum A. I still recognise the byte values from creating fonts for it almost 40 years ago...
Yeah and when he inverted it, it made me think of the inverse video button (symbol shift 4?)
This sounds extremely useful, not just for graphics but in data transfer in general.
I guess I don't see the utility outside of older computer graphics. Do you have an example of where you'd need to copy data that isn't byte aligned to a source that is misaligned differently?
@@recompile In it's simplest form just to copy big blocks of memory (without shifting or bit operating), to free up the CPU to do other things. It was even mentioned in the video.Then it's basically DMA (which the Amiga also implemented btw.).
yeah GPUs were a main driver in the reduction of that bottleneck. Fastest circuits in any comp were the video circuits.
Anyone who works directly with the win32 API for graphics knows bit blit very intimately. Interesting to learn of its history.
I've made Conway in the Win32 API recently. would love to learn more about its bit blit functionalities more in-depth if you have any resources and/or advice you're willing to share
It would have been great to have done the setup starting with one of the first GUI's based on Smalltalk in the mid 1970's, and the need to move / manipulate bitmaps.
I suggest folks go read about how John Carmack implemented side-scrolling on PC using the EGA latches. PC graphics hardware was never made for gaming but a lot of clever tricks were used to speed up blitting in ways never really intended.
Are you saying EGA had a blitter?
@@uriituw if you mean blitter, no, they are not saying that. They are saying that EGA has horizontal and vertical offset values for the frame buffer. This drastically reduced the amount of blitting needed for scrolling graphics. Do as they suggest and google that "John Carmack implemented side-scrolling on PC using the EGA latches", and you'll find the Wikipedia article describing the whole process.
VGA had some latches could be used to make a de facto blitter.. Albeit a very limited one that still required a lot of cpu pokes.
One big problem with the video. "You could do this much faster than you could in software" - on Amiga, actually, no! Blitting using CPU was roughly the same speed on A500, and significantly slower on A1200 - simply because Blitter operated at much slower clock than the CPU. It still had its uses because you could blit areas of memory using the blitter while the CPU was busy doing other, unrelated stuff - or even blitting *other* areas of memory, say, have a game with a couple objects maintained as BLOBs (Blitter Objects) and majority generated by CPU. Plus Blitter could keep your software short and sweet, setting it up was way less work. But apples to apples, it wasn't faster.
It was faster. We are talking OCS here and 68000 and try to do a 3 source data manipulation with bit shifting with the CPU (who has not any bit barrel rotation in hardware) as fast. So yes the blittwr was indeed faster.
If we talk just simple word aligned data A to B copy. Then yes they where more or less same speed. But that is not what blitting was
You guys really need to do an entire series on c64.
Yes. This please. That’d be like 100 videos just going over the basics of how the hardware worked. This would be glorious!
Who do you think should be the guest? I’m thinking 8- but show and tell. Or 8-bit-guy. Heck, why not both.
for a few moments I wondered why Steve was answering a question I couldn't hear and then I realized I was only wearing my right earpiece 😅
And here I thought my office workstation headset output was mono, turns out it's right channel only 😝
The Amiga was amazing. It's a shame Commodore UK didn't manage to get the deal through to buy the rights for the IP from the GHQ in the US
This seems like an early version of single instruction multiple data (SIMD).
Essentially it's DMA with some extra capabilities. Somewhat unfortunate that the 90s was dominated by the IBM compatible alone, since programmable logic could have made blitting virtually omnipresent.
Every time I see Dr Bagley, I feel like parallel universes somehow merged.
Berenstain Bears.
I see that planar graphics made a lot of sense to exploit a blitter chip...but it's a pain in the 0xA55 to do texture mapping with. No wonder only now the Amiga got a proper Doom clone (as in, it plays *fast* on a stock A500, in Fullscreen)
It's quite cool that Intuition (or is it from a layer below?) exposes all this to the graphic routines to plot shapes... something the Win32 API would have to wait a little to see the same level of versatility
Indeed. Even when the Atari st also copied that idea. You actually need that blitter. The 68000 didn't have a barrel shifter so every sprite needed preshifting. Better if they'd just used chunky nibbles. Especially for texturing and sprite scaling and rotating
Thanks, Steve. Quite interesting. Have you heard of NAPLPS? And if so, perhaps you might consider a segment covering the once popular graphics protocol.
NAPLPS? Videotex/Teletext Presentation Layer Protocol Syntax (North American PLPS)? ANSI BSR X3.110-198X? X3L2.1? Successor to TELIDON?
Never heard of it.
Though, come to think of it, back in June 1983, I had a weird dream that was picked up by a tornado and dropped in Chicago, where I represented Digital Equipment Corp. (not as the primary representative) at a trilateral (ANSI-CSA-EIA) meeting where we spent much of the time arguing over unprotected fields or some such nonsense. I woke from the dream is a cold sweat, clutching the draft proposal closely. Was it real? That was definitely my handwriting on the March trilateral meeting draft. My name isn't in the standard, I don't think, so maybe it was a dream...
I still have a photocopy of the June 10, 1983 draft, and I spent several months implementing PDIs and DRCS for the NAPLPS and TELEDON terminal emulator for the DEC Professional 350, working late into the night in my cube on the 2nd floor of building 5 of the Mill in Maynard, MA. What utter BLISS (the language I wrote it in).
My right ear has been satiated.
This comment will bring a lot of confusion to people without the context.
@@editedreality7955 Makes perfect sense to me.
@@editedreality7955 pls help me understand
This video is a reupload because the previous upload had an audio problem
@@AhmedHOmar-vz4qz no don't explain keep it a secret
There also is the BItBlt Win16 SDK API, that wasn't implementeed in HW, but relied on auto-modifying code, if I do remember correctly Matt Pietrek's artticle from Beautiful Code. That was the reason why the first Microsoft WIndows was astoundingly fast ("fast" in the '80s).
I'm not sure if it's worth another reupload to fix it, but at 7:19, 9:54, 21:48, 24:11 it's very quiet and only plays in the left ear. The marker scratching is also a little out-of-sync at 12:11. At 20:40 it's also quiet, but that might just be the original volume picked up by the microphone of him whispering. :-)
Because Sean's wearing a mask and sitting to the left of the camera. ;)
Nice to know that smalltalk had a influence on the Amiga. Like stars aligned
It sounds to me like he spent 15 minutes describing copying data from one memory location to another, and I don't really understand how there's really any other way to do it. You read from the source and write to the destination. I feel like he's describing something clever, but it sounds very obvious to me. What am I missing? I guess it's just the boolean operation in the middle?
It is what he's describing. What you're missing is the many variations (start part way through a byte/word, start part way through one block, discard part of a block, and so on) of how that move happens and the fact that while CPU can do it, it is designed for a more general case so it does it poorly. Blitter chip specializes in the moving and combining of large data sets quickly with low latency, something the CPU wasn't designed for.
If you do such copy operations with the cpu you first need a command to read the source-byte, then maybe shift it to get to the exact destination adress, "and" it to mask the bits you dont want, read the destination, "or" the source/masked/bits with it, write it to the destination .. and that for every byte (and also skip x bytes after a row is complete) - with a blitter you tell him the source, destination, modulos (how many bytes to the next line), shift how many bits, copy how many pixel in x&y - and then the blitter does the rest, your cpu can do something else ..
I understand the advantage of offloading a process from the CPU, but that's advantageous regardless of what you're offloading. He did mention that it was particularly efficient in hardware, but then never described why.
@@wbfaulk Because you need multiple cpu-commands, read the bits, mask it with AND, read the destbits, OR the destbits, write to the destination, and that over and over again, and skip row-bytes to get to the next row and so on .. a blitter has these commands "baked" in hardware, you just say how much to copy and he does his thing and the cpu is free to do other tasks.
@@Lynxxde Again, that's true of any offloading. What makes this more advantageous than other things you could offload? Also, my point is more about the incompleteness of the video than the idea that I can't find this information elsewhere.
Interesting. Makes me think of sprites. I guess the same mechanization but not storing the result in the original memory but combining the original memory with the 'sprite'content.
Thanks for bringing me back to my MSDOS days of programming and graphics memory at A000:0000. Far pointers... AHHHHHHH!
Barrel Shifter: shifts an arbitrary number of positions in one operation
Is that what the trick in the end is called?
Do modern computers have chips for this? Or do they just do it on the CPU? Is it a part of the GPU now?
Edit: I see, less useful with higher bits per pixel
At least on the CPU, with random access memory there isn't much need to copy things around. Most instructions can use one memory operand (source/destination) and the others are registers. So the AND could be either "read and AND" or "read, AND and write". Pure memory copy instructions are not prioritized because the limiting factor is usually latency.
On my CPU: read (from cache) and add value takes effectively 0.5 cycles (out of 5Ghz, e.i. 5 billion/s), but the latency is 5 cycles. Accessing RAM takes hundereds. Even light could only travel ~6cm per cycle. CPUs have more power than simple operations require, so they make them more complex by combining them and executing them in parallel.
GPUs are more generic now. So they work quite differently. And video output hasn't used bit planes since vga. GPUs have tons of parallel processors that can operate on each pixel at the same time. And each one can often operate on multiple pixels with a single instruction. But you code it up directly. It can get complicated with shared registers, shared local memory, latency and other things. Loading data has latency, so you need multiple things to run on the same core so that when one program is waiting for data, it can execute a different program in the meantime. RDNA from AMD tried to reduce the number of programs you need. It can be on the order of 16... with AMD trying to reduce that to 4 or 8. And by program, they're really smaller sections of code and are called something else on GPU.
DMA Move Engines.
Nice! What is the title of the paper in which they implement the bit blit in hardware?
As fast as stuff like GLSL and Vulkan are, blitting is just SO much more intuitive. In some ways it's raised the barrier to entry for new programmers through the roof.
Why should you have to write program files in an alien language and work backwards inventing projection from "first principles" just to say "put a red pixel at 3,4"? Parallelism is fast but woof it's a dog when compared to pushing colors into memory directly.
If you want to write to display memory directly in Linux then grab a pointer to the frame buffer - have fun…
Because shader operations are inherently parallel. It's definitely less intuitive, but it's far more powerful overall if you take the time to figure out what is really happening. Still, maybe you are right that there is scope for a higher level of abstraction which could make this process simpler for some limited set of operations..
Try doing perspective correct texturing with anisotropic filtering using a BLIT.
The next logical thing to talk about after this would be Porter-Duff operators.
Amiga's masked blit operation or "Cookie Cut"
Amigaaaaaaaaa!
I pretty much gave up computers as a hobby when I sold my Amiga, it just wasn't enjoyable tinkering with PCs.
... and that's why screen scrolling was always much more fluid on Amiga than on the Atari ST :-)
That was because the Atari st lacked horizontal hardware scroll.
@@earx23haha yes I was going to say that. Screen scrolling was so much more than just blitting.
Amiga! 🤘
Only amiga makes it possible.
Programmed that one int assembler on a MC68K atari for the fun of it. pretty fun to do... hard to debug if you have a bug... lol
I remember a project in school we did in Assembly. It had a custom character set and bitmaps. And the display had to run through some cycles to change to a different characters l
@Steve Bagley. Does the hardware "shift" register (that doesn't actually shift) have a name?
Did you realize that even the paper he is drawing on is from the 80's? Where did he store all that paper over 30 years?
Tractor feed paper you mean? They still make that stuff, so he probably just ordered it.
I wasn't looking when this came on and I thought "WOW I didn't know JARED HARRIS is a technophile".
Finally you fixed left channel in this re-upload
I remember first hearing about bitblit in highschool thinking it sounded funny
thanks to blitter and copper Amiga was able to do chunky mode and run games like Doom, that carmack said it was impossible!
Funny that just when he said "greyscales" the lights in the background turned off.
my minesweeper automating dissociated bot uses bitblt to copy the hardware context screen buffer to a memory block that doesn't need to be locked to read. fastest screen grab function I tested by a factor of 50. it had the added benefit of being able to hold a copy of the hardware device context live in memory instead of asking for it every refresh. gotta eek out every ms I can! average solve time 175ms on an fx-8350. I think an older computer on 32bit would run substantially faster ironically. our of those 175ms average, 160+ms is just waiting for minesweeperx to refresh its state after sending a dozen clicks directly to its input queue... a windows 8+ only feature that saves a ton of time by not having to actually take control of or move the mouse cursor to do clicks. womp womp.
In Atari Falcon, for just simple memory copy, Blitter is slower than CPU, so it makes no sense to use it for HDD data transfer and is not used for that.
The source code for AHDI definitely has code for using the blitter to read from the IDE, and as far as I can tell it’s enabled if IDE exists, and the machine isn’t an ST Book, which leaves the Falcon. Yep, the Falcon's CPU can out run the blitter, but the IDE isn’t just a straight memory copy since you are reading from a single location, and writing to many which forces you to use move.w (a0), (A1)+ type code, that won’t get the full performance out of the 030 anyway.
correct me if i'm wrong but can't every algorithm be faster if implemented in hardware? Sure for some it's not really neccessary or efficient to do so but with tailor made hardware it'll still be faster
In general yeah. Its just it is usually far easier to keep hardware general.
Wow, we're gonna need a bigger Chip.
Amiga's recent Dread game has used Blitter for C2P.
So those blitter chips were basically just some clever DMAs?
Yes .. Amiga had several DMA's, for Sprites, Copper, Disk, Blitter, Sound, Video-Out, ...
No.
No DMA was the memory access the blitter as explained in the video was for logic operations on memory blocks
With all due deference to your Atari and Amiga fanbois (😊), let us not forget Bill Atkinson's Quickdraw programming tour-de force on the original Macintosh (128kb, 1984), which packed all this BitBlitty goodness, plus graphics line-drawing primitives (including circles, arcs etc), rounded corners, drawing regions, font drawing, scaling, rotation, all in 24KB of hand-optimized assembly code.
You say, for example, that someone wrote a screen-copying algorithm that took 8 minutes to run? Then why was QuickDraw so damned quick, considering it was all done in 68000 code, and without even the benefit of a barrel-shifter, which only appeared in the much later 68020.
Well the Amiga had drawing code like this done in asm as well. Same cpu. Difference was that the line drawing code had help by hardware line drawings from the blitter
Wow what a lengthy explanation... how about showing some Amiga demos
7:20 i thought that was how it worked in the graphics mode on the C64, but it turned out it was quite a bit more complicated than that.
Commodore aimed for simplicity, so they used the same address generator in graphics mode as used in text mode, so the screen was still laid out as little 8x8 character regions. So in effect the whole screen was an agglomeration of characters with the bits of each character laid out as if they were little 8x8 raster scanned screens in memory.
@@ChrisSmith-tc4df and that is what made graphics programming on the C64 considerably more complicated than it should have been.
@@mrxmry3264complicated? It was a stroke of genius. Also well almost all arcade hardware and consoles up to the first PlayStation used character / tile based approach. Made total sense for many reasons.
If you wanted you had a bitmap mode in C64. With the issues that created of course.
@@ChrisSmith-tc4dfnot just simplicity but also for optimization and memory efficiency
@@litjellyfish bitmap mode? On the c64 the only graphics mode i know of is that weird tile-based mode.
Felt tip marker ASMR
George Constanza's mathematician brother. (even same mannerism at 2:59)
Creator of ZX Spectrum Clive Sinclair died 17.09.2021
I think the cameraman needs a tripod!
Is this unlisted?
He over-explained the obvious part but completely failed to adequately explain the part that's not so intuitive.
Would've been cool if someone had made a blitter chip add-on for the Atari 8bits (via cart or PBI port). Ah well.
Booooring 😉
Seriously, would have been cool, however, for games the ANTIC mode 4 is preferred. And using Blitter with char based gfx is not useful AFAICS.
I want that shirt.
What’s the modern way to bitblt?
Me programming low level graphics with color mapping: brighter colors will always have a higher value, that's obvious right?
Steve using paper: so black will be a 1
Of course you could be working with CMYK or something, but if you're doing bit-level stuff in CMYK you're either a madman or you're doing something wrong.
His screen is white paper, so for him 0 is white :D
I remember playing with bitblt in VB6 and alpha blit!
the dog looks fine
which is better, avx compared to cores, same amount of atomic ops in memory size
compare single core doing say 10x n-bit ops as single avx op, or 10x cores doing single-bit ops
its the same speed, if all the cores run the same program in the same place, different register contents
result buffer of single operation, of two 8-bit operands, is 2^(8+8)bytes = 64kbytes, result is one byte, as a cached op chip
Sensible soccer
Wow, you didn't use the word 'sprite' once!
Because done with a blitter, they are called bobs (blitter objects).
For a moment I was impressed at how fast he is Converting binary and ORing stuff. Then I noticed 66 or 32 is 98 not 96 as he claimed.
Also short for Bacon, Lettuce & Tomato
6:34 That letter "A" is lookin a bit sus
Thank you! I always wondered why the operation in PyGame was called Blit()
This video seams to describe some sort of , 'paged graphics' : am I right?
What do you mean by "paged graphics"? Blitting is just a basic process where you copy image data (could be other data, but usually image) from memory to other parts of memory. If you have separate video memory, then quite often the copy happens from CPU memory to video memory.
Nothing related to paging here. Blitting can be done with arbitrary-sized source data from any memory position to an arbitrary position in the destination memory. If by paging you mean double buffering, the answer is still no. Blitting is in no way dependent on the amount of frame buffers.
6:30 A? Amongus?
Why are you not stabilizing your camera footage?
Not an algorithm
Didn’t the amega and comadore use sprite based graphics?
The Amiga had both hardware sprites and blitter objects. The sprites were quicker but more limited in number, size and colour.
@@shadout ah cheers! Distant memories
The what and what?
My memory is that the Amiga sprites were not written directly to the main bitmap, they were a separate bitmap that the video generation logic combined with the main raster at the right point in the encoding for each scan line they intersected with to produce the output signal. This allows moving the sprite around without having to redraw the bits in the bitmap. This also permitted them to be used over alpha-mosaic graphics modes on some devices like the Commodore 64.
Even on 386 platform with modest video card it was very very fast.
I frigging Love this guy!
1970’s SPACE INVADERS uses cascaded Am25S10 hardware to perform the bit selection described @20:48
Computerphile: Damn, I forgot my tripod.
Nobody: Ah, don't worry about it, we won't notice.
How is a BOB different from a Sprite?
Depends on the architecture, on some platforms (eg the ST, or Archimedes) then nothing everything is done by manipulating the in memory bitmap, on others such as the Amiga then sprites are composited onto the background as the image is drawn to the screen by the video hardware, the hardware effectively reads the background bitmap and the sprite bitmap and combines them.
You can then move the sprite just by updating its position and altering where they are combined, rather than having to redraw it into the bitmap
@@DrSteveBagley Thanks
AFAIK the difference is that a BOB consists of actually writing the graphic into the display memory whereas the sprite is not written into video memory but instead overlayed on the output stream. Put differently, as the pixels are being scanned and sent to the ADC, when a pixel position is reached where the sprite is not transparent the DAC will read that pixel from the memory where the sprite is stored rather than from the memory where the pixel at that position is stored.
@@listerdave1240 Probably more accurate to say that the "GPU" reads both and when the sprite isn't transparent it writes the sprite data, instead of the buffer data, to the DAC.
9:48 As the autistic nerd I am I have to correct this to 98 😊
Oh, "Gamma Channel BitBlt Failure" @25:02 ;-)
great