4 ms·

This is one of the things the Amiga did really well. Among its specialized hardware was the Copper, which was a very simple processor whose clock was tied to t

by Ogre 15y ago

This is one of the things the Amiga did really well. Among its specialized hardware was the Copper, which was a very simple processor whose clock was tied to the video clock. You could use it to schedule blits (using the Blitter, another special bit of hardware whose specialty was moving rectangular bits of rasters around) and other operations (like moving hardware sprites around) immediately after the CRT beam passed the location where it was being drawn. So with careful planning, you could get all your draws done without tearing and without having to resort to double buffering. I recall hearing that the reason the Video Toaster was an Amiga exclusive piece of hardware was the availability of the video clock as well. I miss that stuff. But not all the time, double and triple buffering are certainly much easier. It was also possible quite easily to do double buffering on the Amiga, and I think it was probably much more common than the bare-metal copper approach. But for people who really wanted that level of control, it was there.

CJefferson 15y ago
The amiga is a fasinating example. The various processors did give the Amiga amazing performance, but they also made it very difficult to update the Amiga hardware as time went on, as apps were tuned to the exact number of cycles which would occur before X or Y, and break if anything changed. There were many examples of Amiga games breaking if you added even a RAM extension, as it threw off the timings, and programs expected to know exactly how the hardware was laid out.
- Flow 15y ago
  The programs that had those problems also probably jumped directly into the KickStart ROM and expected it to be of version 1.2. When KickStart 1.3 came out quite a few games broke. I know of only one case where some german demo coders used CPU/chip timing to multiplex sprites to get more than 8 sprites per row. Most of the timing bugs were of the kind that the CPU got faster(maybe due to code running from RAM not affected by custom chip cycles, or perhaps a 68020 or better was used) and neglected to wait for the blitter to be ready. "Fast-RAM" was common enough after a few years to this not being a huge problem. AmigaOS and the whole of Amiga was a thing of beauty IMHO.
- Flow 15y ago
  That the Amiga didn't get any decent custom chip upgrade was probably due to inter-custom chip timings more than software being carelessly put together. Perhaps the resources was not there to upgrade all of the chips at the same time. The AGA upgrade didn't affect several of the custom chips, like the blitter and the sound chip. At least that's my impression.
- Ogre 15y ago
  That wasn't usually a timing problem, though there were programs that broke if you added more RAM. The original Amigas (A1000 and A500) only had "Chip RAM", IE memory that the custom processors could access. Today we'd call it Video RAM, except that it was also directly addressable by the CPU. Later, we got "Fast RAM" that was faster (hence the name) but only usable by the CPU, not the custom chips. Some badly written programs assumed any RAM they found could be used for anything. And then they blew up when they loaded something past the bottom 512K (or 1MB or 2MB depending on the model) and told the blitter or copper to use it. As another poster mentioned, it wasn't really a huge problem. Most programs were written correctly before Fast RAM was common, and afterwards, everyone knew about the issue. A bigger memory related problem was that the original 68000 CPU had no MMU. The system APIs (for apps that weren't written to the bare metal) included the idea of shared and private memory. But on the 68K it didn't actually make any difference, it was all one big flat memory space addressable by every process. Later, on the 68020 and up, a real MMU was available, but so many programs had been written to just allocate everything in public memory that it was impractical to actually use that MMU properly. That's a major reason the OS never got real virtual memory despite having hardware that should have been capable of it on later models. Having dual-booted NetBSD on an A3000 for a while, my first Unix system at home, I can vouch for the hardware working properly.

by Ogre 15y ago

CJefferson 15y ago

The amiga is a fasinating example. The various processors did give the Amiga amazing performance, but they also made it very difficult to update the Amiga hardware as time went on, as apps were tuned to the exact number of cycles which would occur before X or Y, and break if anything changed. There were many examples of Amiga games breaking if you added even a RAM extension, as it threw off the timings, and programs expected to know exactly how the hardware was laid out.

Flow 15y ago
The programs that had those problems also probably jumped directly into the KickStart ROM and expected it to be of version 1.2. When KickStart 1.3 came out quite a few games broke. I know of only one case where some german demo coders used CPU/chip timing to multiplex sprites to get more than 8 sprites per row. Most of the timing bugs were of the kind that the CPU got faster(maybe due to code running from RAM not affected by custom chip cycles, or perhaps a 68020 or better was used) and neglected to wait for the blitter to be ready. "Fast-RAM" was common enough after a few years to this not being a huge problem. AmigaOS and the whole of Amiga was a thing of beauty IMHO.
Flow 15y ago
That the Amiga didn't get any decent custom chip upgrade was probably due to inter-custom chip timings more than software being carelessly put together. Perhaps the resources was not there to upgrade all of the chips at the same time. The AGA upgrade didn't affect several of the custom chips, like the blitter and the sound chip. At least that's my impression.
Ogre 15y ago
That wasn't usually a timing problem, though there were programs that broke if you added more RAM. The original Amigas (A1000 and A500) only had "Chip RAM", IE memory that the custom processors could access. Today we'd call it Video RAM, except that it was also directly addressable by the CPU. Later, we got "Fast RAM" that was faster (hence the name) but only usable by the CPU, not the custom chips. Some badly written programs assumed any RAM they found could be used for anything. And then they blew up when they loaded something past the bottom 512K (or 1MB or 2MB depending on the model) and told the blitter or copper to use it. As another poster mentioned, it wasn't really a huge problem. Most programs were written correctly before Fast RAM was common, and afterwards, everyone knew about the issue. A bigger memory related problem was that the original 68000 CPU had no MMU. The system APIs (for apps that weren't written to the bare metal) included the idea of shared and private memory. But on the 68K it didn't actually make any difference, it was all one big flat memory space addressable by every process. Later, on the 68020 and up, a real MMU was available, but so many programs had been written to just allocate everything in public memory that it was impractical to actually use that MMU properly. That's a major reason the OS never got real virtual memory despite having hardware that should have been capable of it on later models. Having dual-booted NetBSD on an A3000 for a while, my first Unix system at home, I can vouch for the hardware working properly.