[Coco] What would a CoCo successor have to have as a minimum?

[Rob Rosenbrock]

I "reverse engineered" a few arcade games for the MAME project, and I can appreciate the specialized design of the hardware. The games I worked on were mostly based on the 6809 cpu, but the video generation was accomplished with nothing but 74xx series logic gates.

Using shared memory, the program running on the 6809 could describe a 256x256 screen using a much smaller matrix. A single byte in that matrix would be decoded (much like the video circuitry on the Mod I) to data stored in a ROM describing a tile. By adjusting a counter offset, scrolling was achieved. And by duplicating the circuitry, 4 layers of graphics were achieved while accomplishing a sprite-like effect.

The hardware is designed so that the cpu doesn't have to do much regarding what is seen on the monitor. The cpu has enough of a burden handling the npcs. (Visible once many are on the screen at once.)

On Nov 23, 2010, at 1:30 AM, Steve Bjork wrote:

> On 11/21/2010 1:18 PM, Mark McDougall wrote:
>> We don't have 250MHz to play with on an FPGA. We have ~25MHz atm. I haven't checked your maths but assuming you're in the ballpark we're now at 15 times per second. Most arcade games run at least 30fps, better is 60fps. And you're only looking at the CPU blatting a frame buffer in that time...
> Every game for the arcade that I have work on or taken apart was 60 FPS.  This made the graphics smooth.
> 
> Now, most of my CoCo game never ran at 60 FPS because of the speed of the coco and the work that was needed per game frame.  But the CoCo was design to be a cheap home computer that could do many things.  An arcade game (like Zaxxon) was design to play just one game with hardware tuned for just that task and at cost 25 times higher.
> 
> Steve Bjork
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco