[Coco] What would a CoCo successor have to have as a minimum?

[Mark McDougall]

On 22/11/2010 6:30 AM, Theodore (Alex) Evans wrote:

> A 640x480 16 color screen requires only 153600 bytes, if it takes 10
> cycles to move a single byte, the CPU could replace the entire screen
> roughly 150 times in a second at 250MHz. This seems more than sufficient.

We don't have 250MHz to play with on an FPGA. We have ~25MHz atm. I haven't 
checked your maths but assuming you're in the ballpark we're now at 15 times 
per second. Most arcade games run at least 30fps, better is 60fps. And 
you're only looking at the CPU blatting a frame buffer in that time...

> In any case, if one is making a CoCo4, one does not have to just just
> unaccelerated bitmap graphics. You could have an auxiliary processor that
> is capable of performing functions similar to the GFX2 commands used
> under OS-9 Level II. This would make higher resolutions and greater color
> depths practical. As for the data bus width, the CoCo 3 already uses a
> 16-bit data bus for memory access by the GIME.

A graphics processor can help but it's not a magic bullet. Aside from 
blitters (DMA) and sprites, accelerators really come to the fore with 3D 
graphics, texture mapping, shaders etc. And you still need CPU grunt to 
render your 153kB screens (only 16 colours) - just not scroll them.

And the GIME simply does not "use a 16-bit bus for memory access".

> How many times do you think the CPU needs to be able to completely redraw
>  the screen in a second?

It's not as simple as that. You need to multiplex the video with CPU 
accesses, which cuts into your bandwidth - for both CPU AND 'accelerator' 
access. You also need to manage video addressing via bank-switching of the 
CPU, which adds overhead. Any video memory pointers are now 24-bits, 
difficult and costly for a 6809.

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"