[Coco] A Technical Question

[T. Franklin]

Steve,

I guess first... It's Tim not Tom... Just a friendly FYI.

As for my background, I'm not sure that's relivent to tossing out ideas. After all, IF I decide to take on a project like this then it would be my time, effort and money so why be so negative? Starting any project always starts with ideas. It then moves to practicality/feasibility. Then onto prototype & development. I'm at the idea stage. Your already questioning my qualifications for the development stage which I don't find relevant.

But thanks for your opinions, they are always welcome.



-----Original Message-----
From: Steve Bjork [mailto:6809er at srbsoftware.com]
Sent: Sunday, May 20, 2012 10:12 AM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] A Technical Question

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,SteveOn 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 spri te 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 proje ct!> 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--Coco mailing listCoco at maltedmedia.comhttp://five.pairlist.net/mailman/listinfo/coco