Here's a video of the LCD up close:
http://www.barrymichels.com/lcd/Demo.mpg
It's 209kb

Also, a picture of it on the breadboard:
http://www.barrymichels.com/lcd/Breadboard.jpg
Not much to it.  :)  Oh, the batteries are dead ones I pulled off my battery
pile.  It's not pulling much power at all and it's been running on those
batteries for about 3 hours so far.


Barry

----- Original Message -----
From: "Barry Michels" <bmichels@EPIX.NET>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Sunday, March 17, 2002 1:30 AM
Subject: Re: [PIC]: Success! 16F628 -> Graphics LCD


> I just added a larger vector variable and 10 balls.  Now they can go
faster
> at a 45 degree angle or at 22.5 degree angles (-2 to +2 in either axis).
> The CPU usage is still pretty low.  Still around 1.5 - 2ms to just update
> positions and 9ms to re-draw all 10 balls.  That's about 25% CPU usage
> (12ms/48ms) and the program memory usage went up to 1144 bytes.  Mostly
> because I'm storing the initial values in program memory (about 80 bytes)
as
> a lookup table.  While optimizing, I'll move those into eeprom.
>
> One thought crossed my mind while doing this: I wonder how much would be
> involved in converting some of the old Atari or early arcade games into
> something that would play on a PIC?  Maybe something derived from MAME...
A
> library of game roms could be stored on a CF card and loaded as needed.
> PICBoy :)
>
>
> Barry
>
> ----- Original Message -----
> From: "Barry Michels" <bmichels@EPIX.NET>
> To: <PICLIST@MITVMA.MIT.EDU>
> Sent: Saturday, March 16, 2002 7:50 PM
> Subject: [PIC]: Success! 16F628 -> Graphics LCD
>
>
> > After 2 days of asking why, Why, WHY, WHY?!?!?!  I finally stepped back
> and
> > realized I forgot the pull-up resistor on RA4 which I'm using for the
> > Data/Instruction line.  So, it thought every bit of data I was sending
was
> > an instruction.
> >
> > Anyway, now I've got a 128x64 graphics LCD from CrystalFontz displaying
3
> > animated, 4-pixel balls bouncing around the screen.  The completely
> > un-optimized code takes up 783 words and runs at 20fps.  I had to slow
it
> > down because the 60fps speed was making it impossible to see the balls.
> It
> > still updates the positions 60 times/sec, but only re-draws the balls
> every
> > 3rd frame.
> >
> > So, on to performance testing...  I'm using the internal 4MHz clock and
> the
> > RTCC interrupt at DIV_BY_64.  This gives me approximately 61
> interrupts/sec.
> > I was curious how hard I was driving this little chip, so I had it turn
a
> > pin HIGH at the start of the interrupt and LOW when it finished.  Out of
> the
> > 16ms per calculation, only 3ms is used to update the positions and
redraw
> > the balls.  On a calculate only cycle, about 1ms is used.  So, that
> equates
> > to only 12.5% CPU usage!  (6ms used / 48ms per frame = 12.5%)
> >
> > Now for some paddles and a collision detection routine... :)  Oh, and
some
> > user input!
> >
> > Barry
> >
> > --
> > 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 hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu