[Coco] A Technical Question

[Steve Bjork]

Tom, I'm going along with Mark on this one.

A 800*600 direct 32-bit color screen is 1,920,000 bytes and would need 
to double that for dual frame graphics system. (Draw on one while 
displaying the other.) True the CoCo's 6809 would not need to touch this 
memory if the FPGA is doing all the drawing.  But the 6809 would need 
access to the Texture Map and Graphic Co-processor's command memory for 
updating on each and every video frame.  This is a nightmare in dual 
memory system access control.

As for your statement "*In theory, there's no real limit to the 
resolution or colour depth if you're re-generating the screen in an 
FPGA.*" is very questionable.
There is always a limit. Because of the speed of the memory systems, you 
can not go faster than the read and write speed of the texture map 
memory and the display buffer.  There are many other limits like the 
Math Processor that plots the source of the texture data and the screen 
location to draw.

As for you last statement, "Just think'in"...

It's also good to come up with new ideas.  I'm just wondering just how 
much FPGA or general hardware design work you have done?  Also, what is 
your programming background?  Please post them next time so we can talk 
at your level of expertise.

Thanks,
Steve

On 5/20/2012 7:04 AM, T. Franklin wrote:
> Interesting point but if you combine his idea with mine, the "pushing the graphics around" issue isn't too much of one. Use the FPGA to not only generate the higher graphics resolutions but, after adding external DRAM, use the FPGA to also act as a graphics engine. Add a sprite state machine and other forms of graphics controls accessed through a port or two. Download the graphics to the engine to be stored in some on-board RAM. Then use the CoCo to issue commands to the state machine to do the high speed functions. This leaves the CPU to take care of the gameplay tasks.
>
> Just think'in
>
>
>
> -----Original Message-----
> From: Mark McDougall [mailto:msmcdoug at iinet.net.au]
> Sent: Sunday, May 20, 2012 08:18 AM
> To: 'CoCoList for Color Computer Enthusiasts'
> Subject: Re: [Coco] A Technical Question
>
> On 20/05/2012 5:10 AM, Fedor Steeman wrote:>  That sounds like an awesome idea! I hope this would become a reality some>  day. Given the CoCo3's capabilities, what would be the highest>  resolution/color depth you could push it up to through VGA? Perhaps>  800x600x32 ???In theory, there's no real limit to the resolution or colour depth if you're re-generating the screen in an FPGA. However, you quickly run into practicality problems of how much graphics data the 6809 can push around.Besides, my aim wasn't really to produce a new Amiga, but rather enhance the current hardware with perhaps a few more colours and sprites etc. We still want 100% backwards compatibility, and still have the new modes 'look like' a Coco...My thoughts were much along the same lines as the (Apple II) Carte Blanche, and have the cartridge "snoop" (video) memory accesses. It then re-generates the VGA video from an internal copy of the memory, whilst being able to overlay sprites, for example. The sprite con
>   troller would be mapped into Coco memory space somewhere suitably unobtrusive.The main problem I can see with this approach is the fact that the VGA video generation is completely asynchronous to the GIME, even more-so for a PAL Coco. This precludes any "bare-metal" programming of the GIME that relies on horizontal raster interrupts, for example.I'm really not sure how to solve this issue. One possibility would be to connect the RGB sync output to the FPGA on a separate cable, and derive the video timing from there. Another is to somehow (partly?) 'disable' the on-board GIME and have the FPGA implementation 'master' the system. Don't know, haven't thought it through so I'm thinking out loud here...But, as I said, this is something that can be prototyped wholly within an FPGA! It would involve taking a complete Coco3 implementation, and adding the 'cartridge' logic wired via the bus (complete with 2nd GIME) and extended graphics functionality. Would be an interesting project!
>   One could even get real fancy and provide advanced functions to rotate the video memory mapping, or maybe provide software programmable resolutions. This would make porting of the Williams arcade games and Tutankham, for example, much much easier! ;) Actually there's a point; maybe a blitter could be added too!Then again, this is also something you could do with an 'enhanced GIME' that simply replaced the original one. I really like the idea of using a stock Coco as far as possible.Regards,-- | Mark McDougall | "Electrical Engineers do it|  | with less resistance!"--Coco mailing listCoco at maltedmedia.comhttp://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco