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

[Theodore (Alex) Evans]

On 11/21/2010 03:18 PM, Mark McDougall wrote:

> 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...


The 250MHz figure was the only bandied about in the message I was 
replying to.  Besides at 10fps things aren't very jerky.

Is our target to have our CoCo4 have a performance similar to a modern 
PC?  If we make the (unrealistic) assumption that everything scales 
linearly, a CoCo3 uses up to about 32k for a screen buffer using a 
1.89MHz processor, so going to 25MHz we have 423k to work with at 16 
colors this is sufficient for 1024x768, at 256 colors nearly 800x600, at 
64k colors 512x384, and at true color with alpha about 400x300.  This is 
assuming that you aren't using any kind of graphics acceleration.

> 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.

This is why modern designs with huge amounts of video memory don't have 
the CPU doing these things.  We don't have to map (all) of the video 
into the main memory map all the time.  You can reduce memory contention 
through a number of means.  For one thing there is such a thing as 
dual-port memory.

Maybe it is that I see higher resolutions as useful for other things 
than video games.