This also gives me a bit more understanding of how the Video Toaster was possible to architect in a day with such slow CPU clock speeds. It seemed like magic at the time compared to limited capabilities of IBM PC clones. I hadn't realized how much capabilities these other Amiga chips provided.
Some additional context that isn't really covered in the readme - there are two components in the Amiga chipset that are especially relevant here, the copper and the blitter. The copper (named because it's a coprocessor) is a separate execution core contained within Agnus, one of the custom chips. It only supports three instructions - move, wait, and skip. Skip will skip the next instruction if a condition is met, wait will block execution until the condition is met (in both these cases, the condition can only be the location of the video beam), and move can write an arbitrary value to a custom chip register. This means that the copper can't write to other pieces of hardware (like the CIA chips that control various things like system timers and the audio filter), but also that it can't write to RAM. The copper is used fairly heavily in the demo scene, but in gaming it's probably most commonly used to reprogram the colour palette as the screen is being displayed, increasing the number of on-screen colours. The code the copper runs is in RAM so the copper can't directly modify it, but the copper can reprogram the registers telling it where its code is, so it's possible to use the skip instruction to conditionally bounce to different code depending on where you are in scanout.
The blitter is another coprocessor with a different set of limited features. Blitter as a generic term refers to a piece of hardware that can copy memory from one location to another without CPU involvement, but the Amiga blitter is more full featured than that. It also has the ability to render lines, fill areas of the screen, and apply shifts and masks to data rather than just copying it. Of course, when I say "render lines" or "fill areas of the screen", what I actually mean is that it can write specific patterns to regions of memory - there's no actual requirement that they be on screen at the time.
A really important thing here is that while the copper can't write to memory itself, it can configure the blitter, and the blitter can then modify memory. One fun thing here is that there's absolutely nothing stopping you from using the blitter to modify the code that the copper is executing.
The naive implementation of a no-cpu demo would simply be to load all the assets into RAM and then have the copper reprogram the custom chips to display them and play audio. But combining the copper and the blitter gives a turing complete execution environment that ought to be able to do almost anything you could do with the CPU (the blitter can't touch hardware registers so you're still limited to whatever registers the copper can access, and you can only access the RAM the custom chips have access to, not the larger range of fast RAM), just somewhat more slowly.
The copper was widely used in the OS not just to change the entire colour palette half-way down the screen - it could change the display resolution half-way down the screen, along with other things such as the colour depth and memory location of the bitmap data. This allowed the OS to support having multiple "screens" with different resolutions, colour depths, and palettes, and you could drag the front one down to reveal the one behind it.
It would also be used to support double-buffering for displaying smooth videos or other moving graphics - you'd have the two buffers, and the copper would change which one was being displayed while the scan was in the flyback period between frames.
Demoscene has always been about hacking machines to make them do what they're not supposed to do.
I made a "Star Wars" scrolltext once, on a so-called "bazaar" screen with other effects... but it was on ST, kind of challenging ;) I still have the floppy disk in a box, but I'm afraid it's been demagnetised like the others over time (~35 years ago).
Go for it, you might be surprised!
In the last 6 years or so, I decided to poke at my childhood Amiga 500 again when visiting family (which is where it still lives) and I wasn't sure how many of the errors I saw came from a dead disk drive or fading floppies.
Last week, enraged with disk/drive issues, I rushed a poor man's drive cleaning with 90 proof alcohol on the heads (99.9 IPA much preferred), and WD40/90 proof in the disk presence switch (again, proper contact cleaner and IPA much preferred).
Most disks behaved well after that - original software or user written, a few of my own disks had errors, and a couple sound like they need gluing back to the center spindle.
These are all disks from 90-98 and I was able to move data back and forth through the serial cables I'd finally acquired for that purpose.
This machine now has more problems with flaky IC connections and wonky caps than disks. Given the visual glitches in some of my old DeluxePaint files viewed on the actual machine, I'm surprised the circuits didn't mess up any of the transfers, because I didn't get the glitches in the emulator afterwards..
10 comments
[ 1.8 ms ] story [ 36.0 ms ] threadhttps://youtu.be/OXT5MrDdyB8?si=cZChImbAi3JBbFFl&t=49
This also gives me a bit more understanding of how the Video Toaster was possible to architect in a day with such slow CPU clock speeds. It seemed like magic at the time compared to limited capabilities of IBM PC clones. I hadn't realized how much capabilities these other Amiga chips provided.
I'd have loved to live through 10 years of the Commodore 64, 10 years of the Amiga, 10 years of the NES, 10 years of the SNES...
what are these not-CPU chips even capable of?
Interesting parallels with GPUs too.
The blitter is another coprocessor with a different set of limited features. Blitter as a generic term refers to a piece of hardware that can copy memory from one location to another without CPU involvement, but the Amiga blitter is more full featured than that. It also has the ability to render lines, fill areas of the screen, and apply shifts and masks to data rather than just copying it. Of course, when I say "render lines" or "fill areas of the screen", what I actually mean is that it can write specific patterns to regions of memory - there's no actual requirement that they be on screen at the time.
A really important thing here is that while the copper can't write to memory itself, it can configure the blitter, and the blitter can then modify memory. One fun thing here is that there's absolutely nothing stopping you from using the blitter to modify the code that the copper is executing.
The naive implementation of a no-cpu demo would simply be to load all the assets into RAM and then have the copper reprogram the custom chips to display them and play audio. But combining the copper and the blitter gives a turing complete execution environment that ought to be able to do almost anything you could do with the CPU (the blitter can't touch hardware registers so you're still limited to whatever registers the copper can access, and you can only access the RAM the custom chips have access to, not the larger range of fast RAM), just somewhat more slowly.
It would also be used to support double-buffering for displaying smooth videos or other moving graphics - you'd have the two buffers, and the copper would change which one was being displayed while the scan was in the flyback period between frames.
I made a "Star Wars" scrolltext once, on a so-called "bazaar" screen with other effects... but it was on ST, kind of challenging ;) I still have the floppy disk in a box, but I'm afraid it's been demagnetised like the others over time (~35 years ago).
This machine now has more problems with flaky IC connections and wonky caps than disks. Given the visual glitches in some of my old DeluxePaint files viewed on the actual machine, I'm surprised the circuits didn't mess up any of the transfers, because I didn't get the glitches in the emulator afterwards..
Data can probably still be read. Especially if the floppies are DD. Don't wait for it to become unreadable. Backup now rather than later.
0. https://github.com/keirf/greaseweazle/