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

[Mark McDougall]

On 22/11/2010 11:02 AM, gene heskett wrote:

> AIUI, with the fpga, we could well simulate the dual port by interleaving
> the writes with the reads, essentially using the memory as a large depth
> fifo.  I don't see that as a problem other than implementing the concept on
> one corner of the fpga.

The concept is no different to the original Coco, where the SAM interleaves 
CPU and video accesses. And it is certainly the way to go on any FPGA 
design. Dual-port memory is great for small blocks, and I've used it 
extensively in some of my FPGA designs. The main advantage is that it 
completely decouples the video clock from the system clock - something that 
wasn't really an option back in the days of the coco etc.

Higher video modes and more program memory pretty much mandates the use of 
SDRAM if you're worried about cost. Minimig (Amiga 500) on the DE1 manages 
it for video/CPU memory so it's definitely feasible. Of course it's easier 
with the 68K asynchronous bus; but that's always an option on the Coco 4 too 
with a soft core 6x09.

SDRAM refresh and latencies are the killers here. Any attempt to interleave 
discrete single-word accesses is going to severely cripple your memory 
bandwidth and hence effective CPU clock rate. With some caching you can 
fetch bursts of video memory (something you can't hold off) and then give 
access to a suitably modified 6x09 whilst the video doesn't require access 
and you're not refreshing.

Adding sprites and blitters into the mix complicates it again. With modest 
sprite capabilities you could probably get away with dual-port memory in the 
FPGA. Blitters become a bus arbitration problem between the DMA engine and 
the CPU. But again, the Amiga/Minimig has the same issues.

Regards,

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