[Coco] A Technical Question

[T. Franklin]

Thanks all for all the replies. Your responses pretty much told me what I need to know.

In summery, the implementation of the Video/RAM methods is as I thought. There seems to be more than one method and there doesn't appear to be a "standard which was my basic question.

As for the OpenGL that was a general "concept". I agree that implementing a full boat OpenGL wouldn?t be practical but it would be cool to take some of the graphic functionality off the 6809 and put it in a co-processor to free up and speed up game programs. As one of you stated, maybe not OpenGL but perhaps just implement of a sprite engine complete with masking and full screen scrolling along with some basic draw functionality. That would leave the processor to do the game-play aspects. I?m just toying with ideas at this point. I also thought of a possible mode with a 1/2 graphic 1/2 text screen for adventure style games.

Furthermore, yes, I plan on implementing the entire thing on an FPGA. Right now I?m working on the DE-1. There?s no timetable for this. It?s more of a "can it be done and if so. How" type project.



-----Original Message-----
From: Mark McDougall [mailto:msmcdoug at iinet.net.au]
Sent: Friday, May 18, 2012 01:03 AM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] A Technical Question

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|  | with less resistance!"--Coco mailing listCoco at maltedmedia.comhttp://five.pairlist.net/mailman/listinfo/coco