The Amiga had a great trick. Both the CPU and the display/audio hardware share the same RAM (called Chip RAM), so they have to arbitrate for access to it, through a chip called Agnus, which prioritises who gets to read/write memory, depending on importance. You can starve the blitter, you can starve the CPU, but you can't starve the audio or video or disk I/O. As the 68000 CPU only needed memory access every second clock cycle, the Amiga designers arranged it so that the custom chips preferred odd cycles and saved the even cycles for the 68000. So your 68000 runs at full speed.
But if you need more and more work done by the custom chips, it starts to rob some of the even cycles from the 68000.
If you have a 16-colour lowres screen (4 bitplanes), Denise (the chip that turns RAM values into video signals) only reads display data on odd cycles. But if you add another bitplane for 32 colours, she needs some of the even cycles. If you add another bitplane for HAM or EHB mode, she needs even more.
In hires mode, it needs twice the bandwidth for twice the pixels. So if you have a 4-colour hires screen, it only needs odd cycles and the 68000 is full speed. If you go for 8 or 16 colours, it starts slowing the 68000 down.
This is why the default Workbench screen is 4-colour hires. It's hires to look nice and professional like an IBM, and not like a kid's toy like the Atari ST's default lowres GEM interface. It's 4-colours to show it's colourful and not black-and-white, but it's not 8- or 16- colours because that would nearly halve the speed of the CPU !!!
Was all this engineered and then implemented, or did they play it by ear? Seems very complex for the time. Now with Pis and ESP32s one can just cobble up together whatever Frankenstein with off the shelf parts, but this seems very elegant with bespoke chips, sans 68000. This is way way way over my head, but intellectually intriguing.
Most of it was architected before implementation, The timing was a pretty core part of the system, I believe the intention was to give every machine some fast RAM that had a CPU only bus, but that fell to budget demands. You could still get a memory expansion which the CPU would have all to itself. There were a few details that were late tweaks, and there were a whole bunch more that could have been easy additions at implementation time if they had known at the time what we knew after 20 years worth of demo coding on the Amiga.
A lot of the features of the Amiga came from exactly that form of hindsight with the 8 bit machines. The Copper, sprites being arbitrary height, and display addresses being 'live' rather than top-of-frame initialisation values came from seeing programmers of the 8-bit machines finding tricks to undo much of the fixed function behaviour so they could reuse sprites or trick the display RAM fetch to suddenly jump to another place. The Amiga came with a lot of that automatic behaviour removed and then performed by the copper allowing for low level coders to just access the core behaviour instead of trying to trick the hardware into doing it (like the way you remove borders on the c64)
amiga386 · · focus · HN ↗
<a href="https://amigadev.grimore.org/Hardware_Manual_guide/node02d4.html" rel="nofollow">https://amigadev.grimore.org/Hardware_Manual_guide/node02d4....
The Amiga had a great trick. Both the CPU and the display/audio hardware share the same RAM (called Chip RAM), so they have to arbitrate for access to it, through a chip called Agnus, which prioritises who gets to read/write memory, depending on importance. You can starve the blitter, you can starve the CPU, but you can't starve the audio or video or disk I/O. As the 68000 CPU only needed memory access every second clock cycle, the Amiga designers arranged it so that the custom chips preferred odd cycles and saved the even cycles for the 68000. So your 68000 runs at full speed.
But if you need more and more work done by the custom chips, it starts to rob some of the even cycles from the 68000.
If you have a 16-colour lowres screen (4 bitplanes), Denise (the chip that turns RAM values into video signals) only reads display data on odd cycles. But if you add another bitplane for 32 colours, she needs some of the even cycles. If you add another bitplane for HAM or EHB mode, she needs even more.
In hires mode, it needs twice the bandwidth for twice the pixels. So if you have a 4-colour hires screen, it only needs odd cycles and the 68000 is full speed. If you go for 8 or 16 colours, it starts slowing the 68000 down.
This is why the default Workbench screen is 4-colour hires. It's hires to look nice and professional like an IBM, and not like a kid's toy like the Atari ST's default lowres GEM interface. It's 4-colours to show it's colourful and not black-and-white, but it's not 8- or 16- colours because that would nearly halve the speed of the CPU !!!
stasomatic · · focus · HN ↗
Lerc · · focus · HN ↗
A lot of the features of the Amiga came from exactly that form of hindsight with the 8 bit machines. The Copper, sprites being arbitrary height, and display addresses being 'live' rather than top-of-frame initialisation values came from seeing programmers of the 8-bit machines finding tricks to undo much of the fixed function behaviour so they could reuse sprites or trick the display RAM fetch to suddenly jump to another place. The Amiga came with a lot of that automatic behaviour removed and then performed by the copper allowing for low level coders to just access the core behaviour instead of trying to trick the hardware into doing it (like the way you remove borders on the c64)