Well, the 12 bit data I was talking about was a part of the character
generator data (the pixels that make up each scan line of a characters
image) so it would always be the same for each character. You could have a
red "A" and a blue "B" or a "C" with alternating green and red scan lines
 ...sounds pretty silly until you think about "sprites" and video games
 ...or if the characters are images on a playing field (like pacman or a
chess board) then hard coded character color makes sense.

And how would you find the processing time to display and move the pacman
and ghosts? You put out the board on the even frames and (only) the sprites
on the odd frame. Some tight programming there, but it could be done (I
think).

Now, you could take the top bit of each byte of character data (from RAM)
and put that out on a second pin to bias the character image a bit lighter
or darker
 ...or use a different scan line loop under each character row to do an
underline
 ...or invert the pixel data for reverse video.

---
James Newton
1-619-652-0593
mailto:jamesnewton@sxlist.com
SX FAQ: http://www.sxlist.com



-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Simon Nield
Sent: Friday, December 01, 2000 10:27
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and
Contest


>row stored in the lower byte of a 12 bit program memory word and that there
>are 256 characters (a kind of a waste but that could be fixed).

how about 4 bit colour ?
use msb used for "bright", and the other 3 bits for r g and b...

would be impressive to see a colour display from a PIC or a Scenix.

Regards,
Simon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body