I think that main reason for such, 'attribute' based graphic systems was cost of RAM - so they made color graphic with low RAM usage. Machine like Spectrum 16K could not be done with some better graphic (palette based) - because video RAM only would be more than 16K.
And similar stays for C64. Where sprite logic and other was present - likely not less complex than some better graphic logic.
And additionally, more RAM means more CPU time to calculate, write graphic. It was the problem with Amstrad CPC and MSX - Z80 was just too slow for their higher graphic modes.
Actually, wait states were a problem for the MSX which slowed down the CPU.
I couldn't find a CPC page that said anything about wait states but it might have a similar issue.
Here is a page talking about added wait states with the MSX engine:MSX Link
FWIW, wait states are what killed the NEC Trek, but on later machines they were acceptable?
I never understood that. Many of the same things that ran poorly on the Trek would run poorly on later machines like the MSX.
The programmer writing the game said the Trek was too slow to include the zoom window for Mega Bug and I don't find anything like it on the MSX. Go figure.
Even the 1MHz Apple II with it's messed up screen had the same game under the name Dung Beetles.
Really, if you start trying to drive too much data with too slow of a CPU it catches up with you. If you add wait states you compound the problem.
Even though the IIgs was clocked faster than any other 6502 machine of that time, it's a bit slow for driving full screen 320x200 16 color animation.
Some of the IIgs games with large sprites are a bit sluggish unless you have an accelerator. I think even 4MHz would have made a huge improvement and is what the IIgs should have been. An 8MHz accelerator on a IIgs is pretty fast and some people have much faster.
The 6502 world really needed to transition to CPUs that were at least 4MHz if they were going to upgrade the graphics and sound significantly.
They would also need 16 bit support so the 65802/65816 would be a must.
The Z80 world would have to go to 8MHz or you have to start optimizing the Z80.
The prefetch and wider ALU in the 64180/Z180 made it much faster (20%?) on the same code than the Z80 in native mode.
At that point the speed difference between the 6502 and Z80 narrows considerably. Then the Z80 might need to run at 6MHz.
After that you have to go to fully pipelined architectures, cache memory, etc... to really improve performance and things like self modifying code and timing loops start to break. You have to offer some sort of compatibility mode that adds wait states or disables features to run old software.
I do think the 64180/Z180 enhancements would have been sufficient for the CPC and MSX, or the Trek for that matter.
Edited by JamesD, Sat Dec 1, 2012 12:33 PM.