[Coco] CoCo 3 FPGA?
Joel Ewy
jcewy at swbell.net
Tue Jul 31 13:54:56 EDT 2007
Mark McDougall wrote:
> Shain Klammer wrote:
>
>> Is a full GPU needed? Having some 3D abilities would be nice, but
>> even simple(?) hardware sprites, player/missile graphics in any
>> high(er) colour mode could help. With the resolution, perhaps an
>> Amiga style HAM (Hold And Modifiy) mode would speed things up (at
>> least for pictures, movies)?
>
> Hardware sprites, even with collision detection, is quite trivial with
> almost negligible logic requirements - just a bit of (internal?) RAM
> depending on the number and size of the sprites.
>
> HAM would also be trivial to implement, though perhaps more
> challenging to shoe-horn into a backwards-compatible GIME implementation.
>
> Regards,
>
Why not a real 12-bit 4096-color mode as a less memory and (possibly)
CPU intensive alternative to 15- or 16-bit modes?
Or how about including a special palette-stuffing co-processor that can
re-load some or all of the palette registers automatically on each scan
line (or even within a scan line) without involving the CPU?
Or what about automating the screen swapping procedures we already use?
So in a certain mode it will automatically cycle between 2, 3, or 4
screens to produce the flicker-vision color mixing we all know and
lo[ve|athe], but without all the interrupt acrobatics for the 6x09.
While the resulting quality would still be less than perfect, it would
be easy to implement (I think), would be a relatively simple,
straightforward addition to the existing GIME architecture, and would
require less extensive modifications to existing software.
Changing existing flicker-vision graphics display programs to work with
such a scheme would actually involve reducing the complexity of the
present code, stripping out all the timing and interrupt stuff, and
adding only a bit of very straightforward code to set up the screen
swapping registers, start the process, and stop it. And by putting that
logic in hardware, it wouldn't be hard to have programs other than
simple image viewers using a high-color mode. After set-up, the
processor would be free to execute game code (or whatever) and, of
course, stuff 12 bits of graphics data into memory -- but we are talking
about a somewhat faster CPU, after all. If we're using modern SVGA
monitors, we could run the refresh rate up to 120 Hz, which would make
an effective refresh rate of 40 Hz with a 3-screen display -- surely
easier on the eyes.
Also see this Wiki page of next-gen CoCo video display ideas gleaned
from an earlier discussion on this list:
http://www.coco25.com/wiki/index.php/Video
I really like some of James' and Sockmaster's ideas there.
JCE
More information about the Coco
mailing list