[Coco] A Technical Question

[Mark McDougall]

On 18/05/2012 2:02 AM, T. Franklin wrote:

> I have atechnical question about the video link and RAM on a computer
> (not necessarilya CoCo). I'm creating my own 6809 basedcomputer on an
> FPGA and stuck on a direction as to implementation. It has to dowith the
> write CPU cycle of the video area.

Are you implementing this entirely within the FPGA? Or are you planning on 
using some external support chips? eg. CPU, RAM etc.

Steve & James have already offered excellent answers to the video memory 
question, so I'll try not to re-hash too much.

You have 4 options in terms of video memory:

1. Interleaved access (IDMA) like the Coco. As mentioned, it ties the system 
timing to the video timing and associated RAM bandwidth issues.

2. HALT CPU access to video memory during active video. Obviously 
detrimental to CPU performance.

3. Give CPU priority to video memory. Causes "snow" effects when CPU is 
accessing video memory.

4. Dual-port video memory. Expensive.

Option 4 is the "best" option for text-based, tile/sprite and perhaps very 
low-resolution bitmap systems. Dual-port memory is expensive. In an FPGA, 
you're obviously limited to the amount of on-chip RAM. However, I've done a 
lot of designs using on-chip dual-port RAM for video memory and it's by far 
the easiest to design around. You can change the video clock (resolution) 
at-will, and there's no arbitration issues to deal with. But generally, 
we're talking about systems with only a few KB of video memory. Wouldn't be 
suitable for, say, the Coco, unless you have some serious silicon to play with!

> Some of theideas I had with this venture is to (like others) implement a
> CoCoin an FPGA but modify all the graphics routines (i.e. lines, circles,
> draws andPCLS) to all FPGA core implementation. I?m thinking about adding
> a 3D FPGA coreimplementation similar to OpenGL for some real cool
> CoCogaming. This is just mydream but as I slowly get started, I?m finding
> that questions like this oneplague me for weeks. So any help would be
> appreciated.

That really is quite an ambitious project, even for someone with experience 
in FPGA designs.

I'd like to understand more about what you mean when you talk about 
"modifying all the graphics routines"? Since they're implemented in software 
in the Coco BASIC ROMS, I can only assume that you're looking at adding a 
'graphics co-processor' of sorts and then patching the ROM to make use of 
said co-processor?!?

A 3D 'OpenGL'-like implementation is no trivial task. There's a lot of maths 
in there which is not straight-forward to do in an FPGA. You start to get 
involved in pipe-lined operations for all your maths that take X clocks and 
the timing that goes around that. I'd also venture to suggest that perhaps 
the 6809 wouldn't really be up to the task of even co-ordinating OpenGL 
graphics, even done in a co-processor. There's still a lot of data to be 
moved around during a 3D game that isn't strictly rendering...

Anyway, don't mean to sound negative. Would love to be proven wrong!

An aside, IMHO the Coco could really benefit from some basic sprite 
hardware. One step further would be a 'tile' layer. And 'proper' X-Y 
scrolling would also go along way to making some pretty cool 2D platformers 
on the Coco.

Regards,

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