[Coco] "VideoPak" hardware question

[Mark McDougall]

On 10/11/2014 12:23 PM, tonym wrote:

> But wouldn't the graphics chip handle offloading the bulk of the
> graphics operations, freeing the CPU to do what it needs to do?

You would still require movement of significant amounts of data between 
Coco memory space and the graphics processor - it needs to get graphics 
data from somewhere! How often you'd need to do that would depend on the 
nature of the software you're writing. Otherwise you'd have to develop 
some DMA engine to suck the data across, which would still impact 6809 
performance due to memory contention.

> I guess you could ask why the MicroC video board for the kaypro was
> made, or why the SecondSight was made for the A2GS, or the gfx card
> for the model IV. Or, the WordPak and other 80 column PAKs for the
> CoCo.

The graphics card for the Model 4 is all-but-useless. The port-mapped 
graphics registers allow access to hires video memory during VBLANK 
only. You don't even get enough bandwidth to emulate a handful of small 
sprites using hand-tuned Z80 assembler, let alone moving anything on the 
background. It's not useful at all for games, only for static displays 
like charts & graphs. It says something that not a single game for it 
was ever developed, aside from what amounted to little more than an 
interactive 'demo' written by the graphics card vendors themselves.

> Wouldn't it be a matter of a driver, and then expanding the gfx
> capabilities of OS-9, but via the driver, still support the previous
> modes? I mean, if a WordPak or other 80 col pak can work, why
> couldn't a higher-res PAK with proper drivers work?

Anything is possible, not everything is practical. You need to look at 
the architecture of early video arcade games and consoles as an 
indication of useful features and practical capabilities. They all had 
custom graphics circuitry, but still none had high resolution, deep 
colour bit-mapped displays, nor did they have 3D engines in that era. It 
was pretty much tiles and sprites across the board, because that was the 
only architecture that the 8-bit CPU's could manage. Interestingly a few 
6809-based boards did have bit-mapped graphics (Williams, Stern & Konami 
come to mind) but they had limited colour depth, were comparable in 
resolution to the Coco 3, and yet all had custom graphics enhancements 
(blitters & scrolling) to assist the CPU (a notable exception being 
Defender).

I've said it before, and I'll repeat it here. If you want bang-for-buck, 
a (scrolling) tilemap and sprite system overlaid on GIME graphics would 
be the way to go. It minimises CPU load, is suited to a very wide range 
of retro-style games, is easier to program, and would open up the 
possibility of ports from other platforms - lowering the barrier to 
entry for new software being developed. It's also relatively simple to 
implement in an FPGA.

Regards,

-- 
|              Mark McDougall              | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug> |   with less resistance!"