Hey, nice movie, but too short! David Barry Michels wrote: > 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" > To: > 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" > > To: > > 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 -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu