[Coco] A Technical Question

[T. Franklin]

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