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

[Aaron Wolfe]

On Sun, Nov 21, 2010 at 4:18 PM, Mark McDougall <msmcdoug at iinet.net.au> wrote:
> On 22/11/2010 6:30 AM, Theodore (Alex) Evans wrote:
>
>> A 640x480 16 color screen requires only 153600 bytes, if it takes 10
>> cycles to move a single byte, the CPU could replace the entire screen
>> roughly 150 times in a second at 250MHz. This seems more than sufficient.
>
> 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...
>
>> In any case, if one is making a CoCo4, one does not have to just just
>> unaccelerated bitmap graphics. You could have an auxiliary processor that
>> is capable of performing functions similar to the GFX2 commands used
>> under OS-9 Level II. This would make higher resolutions and greater color
>> depths practical. As for the data bus width, the CoCo 3 already uses a
>> 16-bit data bus for memory access by the GIME.
>
> A graphics processor can help but it's not a magic bullet. Aside from
> blitters (DMA) and sprites, accelerators really come to the fore with 3D
> graphics, texture mapping, shaders etc. And you still need CPU grunt to
> render your 153kB screens (only 16 colours) - just not scroll them.
>
> And the GIME simply does not "use a 16-bit bus for memory access".
>
>> How many times do you think the CPU needs to be able to completely redraw
>>  the screen in a second?
>
> It's not as simple as that. You need to multiplex the video with CPU
> accesses, which cuts into your bandwidth - for both CPU AND 'accelerator'
> access. You also need to manage video addressing via bank-switching of the
> CPU, which adds overhead. Any video memory pointers are now 24-bits,
> difficult and costly for a 6809.
>

this makes me wonder, should a "coco 4" just use a different or
additional processor?
since our targets are fpga and emulators, we aren't really tied to
processors that exist in silicon.  we could add a 68000 or create some
sort of hybrid 6809/68k type of thing.
probably a lot of work, but sounds like it would be difficult to see
significant improvements to graphics if we don't change something in
the architecture.


> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>