English Amiga Board - View Single Post - Things the Amiga didn't get right from Day 1

axilmar · 23 February 2022, 14:59

While I love the Amiga (due to the fact it brought so many joys to me with its software, both games and productivity (Deluxe Paint, I am looking at you!)), I can't stop thinking how a few small changes could have vastly improved the system. Many of these changes are already mentioned in this thread, so I won't repeat them here.

One thing I would particularly want is for the blitter to have its own programs. I.e. just like the copper has copper lists, the blitter should have had blitter lists. The CPU would then prepare the next frame's blitter list as the current frame was rendered by the blitter, without tying up the copper. Or have two coppers actually, one driving the blitter and the other driving the color/palette changes!

Another thing that I would love is for the blitter to do some ...sprite scaling. I am in love with sprite scaling, since the moment I played Outrun in the arcades. I believe that the blitter could incorporate some logic to 'scale' individual bits, i.e. have a few more registers and logic gates that affect the source bits before they reach the part that applies the selected minterm and writes the result back to memory. After all, scaling up bits of a bitplane is nothing more than repeating those same bits at particular intervals, and very few registers could be needed for that.

If I designed a computer in the 80s, would I design it like the Amiga? Most probably I wouldn't. I would have dedicated custom cpu/ram for the sound, dedicated custom cpu/ram for the graphics, the main cpu would have its own dedicated ram (still an 68000 though), very fast buses from/to each cpu, with the largest bandwidth possible at the time (32 bits), and bus mastering when data needed to be transferred from one cpu's ram to the other cpu's ram. And I would possibly do banked ram access, so when for example the graphics cpu rendered the display from one memory bank, the main cpu could work in the other memory banks of the display without wait states, and then the main cpu would switch banks on the co-processors, so as that they work on the new data, while the main cpu prepares the data in the other banks. The end result would be better games, better arcade conversions (my favorites), easier programmability and better machine longevity (as this kind of design probably scales better than sharing of the same memory by multiple devices using cycles)...

23 February 2022, 14:59	#802
axilmar Registered User Join Date: Feb 2022 Location: Athens, Greece Posts: 41	While I love the Amiga (due to the fact it brought so many joys to me with its software, both games and productivity (Deluxe Paint, I am looking at you!)), I can't stop thinking how a few small changes could have vastly improved the system. Many of these changes are already mentioned in this thread, so I won't repeat them here. One thing I would particularly want is for the blitter to have its own programs. I.e. just like the copper has copper lists, the blitter should have had blitter lists. The CPU would then prepare the next frame's blitter list as the current frame was rendered by the blitter, without tying up the copper. Or have two coppers actually, one driving the blitter and the other driving the color/palette changes! Another thing that I would love is for the blitter to do some ...sprite scaling. I am in love with sprite scaling, since the moment I played Outrun in the arcades. I believe that the blitter could incorporate some logic to 'scale' individual bits, i.e. have a few more registers and logic gates that affect the source bits before they reach the part that applies the selected minterm and writes the result back to memory. After all, scaling up bits of a bitplane is nothing more than repeating those same bits at particular intervals, and very few registers could be needed for that. If I designed a computer in the 80s, would I design it like the Amiga? Most probably I wouldn't. I would have dedicated custom cpu/ram for the sound, dedicated custom cpu/ram for the graphics, the main cpu would have its own dedicated ram (still an 68000 though), very fast buses from/to each cpu, with the largest bandwidth possible at the time (32 bits), and bus mastering when data needed to be transferred from one cpu's ram to the other cpu's ram. And I would possibly do banked ram access, so when for example the graphics cpu rendered the display from one memory bank, the main cpu could work in the other memory banks of the display without wait states, and then the main cpu would switch banks on the co-processors, so as that they work on the new data, while the main cpu prepares the data in the other banks. The end result would be better games, better arcade conversions (my favorites), easier programmability and better machine longevity (as this kind of design probably scales better than sharing of the same memory by multiple devices using cycles)...