2x16 LCD Graphics :)

[Art]

Hi Guys,
I know the odometer effect has been done, also the bargraph,
but both use single isolated custom chars as up to eight screen buffers drawn all over the place.

Has anyone considered making a frame buffer array in RAM, and then copying out
the bytes to all of the eight custom characters for every frame?

http://img.photobucket.com/albums/v186/ArtArt/5b783edc-1f01-47c1-bd70-fc91290d6838_zpsced6cefd.jpg

It's probably five years too late with the price of gfx LCDs now,
but I think a nice exercise, and think the rotating 3D cube is doable.
I was thinking do a real 23x17 frame buffer, and just accept that the
inbetween lines are invisible pixels, so long as the display is animated.

http://www.youtube.com/watch?v=rM166m7uWvM

Most of the points on the cube are duplicates of another with different initial 2D offsets.
I can't do the point rotation without trig, but can use another program to generate the
pre rotated list of points of 36 or so different angles around each axis.
The lines should be right to draw locally since they only need square root.
Also proper balls bouncing off walls at inverted angles should be ok locally.

Pixel resolution horizontal scrolling should be also possible on an 8x1 display.

Any ideas suggestions? Has someone done this?

[Art]

Having to send the command to change lines halfway though the drawing is a tragedy,
and so is setting the LCD home, but the latter doesn't interrupt drawing halfway through.
It would be better to waste the same amount of time between sending every character.

[Art]

Ok, now I can set pixel coordinates, and no longer have to think about custom characters :)

...

It was hard because each line for a custom char is still a byte, but only five bits of it are used,
and the LCD wants them in the least significant bits, but my framebuffer is a continuous stream of bits.
I'll try the line drawing, and calculating proper angles for balls.
A smaller (single pixel) ball works better in the small space, but didn't make for a good video.

[Art]

Line drawing (almost) :

...

[Art]

One more:

....

[srspinho]

Impressive ! .... Really.

[Demon]

Very!

Robert
:)

[Art]

Thanks Guys,
I am having some trouble with diagonal lines and circles.
When you use a real gfx display with PBP, is it usually the display that
handles the lines and circles, or is it done in PBP?

I'm finding the algorithms are usually in C, and all seem to want to look
for values below zero (signed integer variables), where one of these
variables would wrap back to 0xFF if you decremented from zero using PBP

For the only diagonal lines in the video, I was able to do a trick and
check a value is above #128, pretending that value is zero.
This is so far only working if the destination point of the line has higher
x and y coordinates than the start point..
(ie. I can draw a line at any angle from x-0,y-0, to anywhere).

Here is the difference in the code.



x0 = 3 : y0 = 3
x1 = 21 : y1 = 11
gosub drawline





drawline:
stepx = 0
stepy = 0
frac = 0
'a line is x0,y0 to x1,y1.
dy = y1 - y0
dx = x1 - x0

IF dy > 128 THEN
dy = dy - 1
stepy = stepy - 1
ELSE
stepy = 1
ENDIF

IF dx > 128 THEN
dx = dx - 1
stepx = stepx - 1
ELSE
stepx = 1
ENDIF

dy = dy << 1
dx = dx << 1

'draw pixel
px = x0 : py = y0
gosub setpixel

IF (dx > dy || dx > 128) THEN

frac = dy - (dx >> 1)
WHILE x0 != x1
IF (frac < 128) THEN
y0 = y0 + stepy
frac = frac - dx
ENDIF
x0 = x0 + stepx
frac = frac + dy
'draw pixel
px = x0 : py = y0
gosub setpixel
WEND

ELSE

frac = dx - (dy >> 1)
WHILE y0 != y1
IF (frac < 128) THEN
x0 = x0 + stepx
frac = frac - dy
ENDIF
y0 = y0 + stepy
frac = frac + dx
'draw pixel
px = x0 : py = y0
gosub setpixel
WEND

ENDIF

return



... and the original C



static void drawLine(int x0, int y0, int x1, int y1, int color, Color* destination, int width)
{
int dy = y1 - y0;
int dx = x1 - x0;
int stepx, stepy;

if (dy < 0) { dy = -dy; stepy = -width; } else { stepy = width; }
if (dx < 0) { dx = -dx; stepx = -1; } else { stepx = 1; }
dy <<= 1;
dx <<= 1;

y0 *= width;
y1 *= width;
destination[x0+y0] = color;
if (dx > dy) {
int fraction = dy - (dx >> 1);
while (x0 != x1) {
if (fraction >= 0) {
y0 += stepy;
fraction -= dx;
}
x0 += stepx;
fraction += dy;
destination[x0+y0] = color;
}
} else {
int fraction = dx - (dy >> 1);
while (y0 != y1) {
if (fraction >= 0) {
x0 += stepx;
fraction -= dy;
}
y0 += stepy;
fraction += dx;
destination[x0+y0] = color;
}
}
}


I wonder what of the C compilers that are for 16F pics.
Maybe they don't do signed integers either?
If I could compile the original C source in a pic C compiler,
and then disassemble it, I could have the result in RISC asm.

[Jerson]

I am having some trouble with diagonal lines and circles.
When you use a real gfx display with PBP, is it usually the display that
handles the lines and circles, or is it done in PBP?

In a real graphic LCD, it is the user who draws the lines / circles using Bresenhams algorithm or a variant. PBP, C or ASM is just a matter of choice.

I am curious to know why you want to use a character lcd this way other than for the thrill of doing it. You only get 8 programmable characters which is about a 4th of the 16x2 display. Your demos too show repeated patterns. It is much more challenging and fun to get a graphic lcd come upto video speed (20fps and more).

[Art]

It is for the thrill.. and I figure the work is not wasted, because these LCDs do still get use.
I already did an LED matrix display with games, scroller etc., and I don't think it is getting any faster.
Also, I have not written for pics in some time, and needed something to get going.
There is room to duplicate the graphics screen, but for a practical application,
I figure the rest of the screen would have some text on it.

I have solved the line drawing, but if you have a way to draw circles in PBP it
would be appreciated :) At the moment my circles are perfect squares of the
correct radius, but I'm keeping that for squares since it beats defining all the corner coordinates :D

I would not buy a gfx LCD if I couldn't do the graphics, so it's a good way to come up with
the routines now. I would still like to do my own hardware/software mapping GPS one day.

I do plan to give it away when it's finished and cleaned up.


ps to mods, it would be great if you could delete every video posted here
(can seem to delete/edit my posts)
I've done the C-64/Amiga style Megademo :D

[Demon]

Videos removed.

Robert

[Art]

Thanks Robert, I combined everything into one retro demo:

http://www.youtube.com/watch?v=1xq8xJqbkNA

I robbed the circle drawing from a GLCD code sample here, and added a bit more.
There are 10 sections to the demo, but they only last a few seconds each.
The trick at the end is what I should have started with to trick people to thinking
I had the entire display ;)

It is almost ready to go, I just have to make sense of the source for others.
Last time I released a project, there were three different revisions of matching
hardware and software improvements with schematics,
and although others got it working, it caused confusion, and years of follow up for me.
Being mindful of that this time round, the schematic is in the PBP manual :D

http://farm5.static.flickr.com/4037/4380942549_1f81336dd6_o.jpg

The only differences are this is a 16F628A (instead of 16F84/A in the manual),
the LCD backlight is powered by the pic (RB6) for the strobe effect in the video,
and the pic is driven with an 8MHz crystal to match the speed in the video.
The clock speed is not critical though.
The serial Rx pin in the familiar looking diagram is not implemented.

If you make a board for this, it's still tentative.
LCD R/W pin may need to be accessed later, so it might pay to wire
it to somewhere accessible before wiring it to ground to mod later
(I heard you can rip all of the character graphics from the LCD itself).
It should also get a couple of buttons.
Cheers, Art.

[Demon]

WARNING: Video may trigger epyleptic seizure in some viewers.

Use 3D glasses under welding goggles as protection.

:D

Awesome stuff Art.

Robert

[Art]

Here it is:
http://www.freewebs.com/defxev/LC2D.zip

Interestingly... I realised this is one of the two LCDs I bought off Melanie here ages ago:
http://www.picbasic.co.uk/forum/showthread.php?t=632&p=2298#post2298
Funny that. There was not much fancier at the time, but now the options are endless.

I always get that last little nice feature working AFTER the distribution :rolleyes:

[Archangel]

Pretty fancy stuff there Art, He He Imagine that display on the bank's ATM machine, make a good video.

[Art]

Forgot this:
http://farm3.static.flickr.com/2359/4507139195_78df688175_o.jpg
Credit to Centrex of Whirlpool forum (Australia).
Suitable for this, and whatever logging LCD circuit based on the PBP manual LCDOUT example circuit.

I will do a more bare source code, more intended for people using their own programs,
and am also getting an 8x1 or 8x2 LCD so I either get a whole line or a whole display to work with.
The reason being, I hear by connecting the LCD R/W line to an IO pin, you can access the
LCD's CGROM, and rip the character set. That would be great for the pixel perfect text scroller.

Up until now, the character data has been stored on EEPROM or on-chip EEPROM for these sort of tricks.

[Ioannis]

You are kidding me, right?

Unbelievable graphics on this LCDs!!! Wow, Art. Supercalifragilisticexpialidocious (http://en.wikipedia.org/wiki/Supercalifragilisticexpialidocious)!

Ioannis

[Art]

You are kidding me, right?

Unbelievable graphics on this LCDs!!! Wow, Art. Supercalifragilisticexpialidocious (http://en.wikipedia.org/wiki/Supercalifragilisticexpialidocious)!

Ioannis

Thanks :)



I always get that last little nice feature working AFTER the distribution


Happens every time on every platform.
I suggest, if you would like some cool new feature in a program you write,
that you upload a distribution, and give it away to the public.
Then within a day or two, you have changed the way you think about it,
and have a moment of insight :rolleyes: Oh, and the implementation is a breeze also.

[Archangel]

CONGRATULATIONS ART:
You have been featured on Hackaday
http://hackaday.com/2013/10/16/teach-an-old-lcd-new-tricks/#more-105170

[Demon]

Congrats Art!

[andywpg]

Been following this thread with interest. Congrats on an awesome job AND your HackaDay feature!

[Art]

Thanks Guys :)
I finally joined their forum, they would have got it from that.
I've been watching H-A-D for years... certainly some interesting stuff.
My 144 LED game ended up there too back when I was doing that.

Anyways that'll be some nice traffic for ya!

It makes me wish I'd waited tho :D
I'll have to do a version 2.

[Art]

http://www.youtube.com/watch?v=HugwQ4b9iBU

Changes for LC2D Version 2 - 18/10/13

Base code:
Reduced program memory, and RAM consumption
(approximately ten more bytes of RAM are freed).
This leaves more RAM in BANK0 for the user program.
Performance win on base code
(first version is still on the site for comparison).
When the demo program is removed,
there's much more resource for your program.

Demo User Program:
Extra resource freed by improved base code is consumed
by the new demo. Now has fifteen demo sections!
The first demo sections are identical, except that the first
demo section inverts the LCD on it's first cycle for LCD test.
The new demo sections expand on a trick appearing to
control the entire LCD display when run on a 2x16 LCD.
Fixed graphic invader animation frame B sprite (legs).

Classic Rolling Odometer Effect :)
One of the new demo sections is the rolling odometer
effect that also moves around the display.
It looks like a penalty, but is not. It's delayed because it
is the most prone to messing up the display with lag trails
when run on slow LCDs such as the one in the video.
The user program doesn't have to move it around,
or delay any sprite drawing routines.
I ran out of memory in the process of making it able
to reverse direction properly for counting backwards.
Currently, the variable must be incrementing by one.

New Notes:
Pic run at 8MHz telling PBP compiler it's running at 4MHz
results in only 600ms pause time for LCD start up delay.
PBP manual suggests PAUSE 1000 delay to accomodate
slower starting LCDs. If your LCD doesn't start, change to
PAUSE 2200 before compiling the program, or insert the
pic into the socket after powering the circuit with the LCD.

Sloppy bounds checking on demo user program demonstrates
crash proofing in base code. The user program is allowed to
draw off screen. Base code does not check bounds on the
individual X,Y coords, rather that their calculated destination
in the first frame buffer is within bounds of the array.
Crazy shape or line drawing could still have consequence.
I don't know what those routines will do in unusual circumstances.

http://www.freewebs.com/defxev/LC2D.htm

Enjoy :)

[Art]

I had to write an iPhone simulator App to do the vector rotation on the 3D cube but got it:

http://www.youtube.com/watch?v=480cCDS6WVQ

It takes sixteen bytes per frame to store a list of coordinates in lookup tables
not compressed in any way. The pic still has to look up the points, and draw lines between them.
This makes a more simple to understand user program.
Now it's produced, it's very simple. The pic program just looks up sixteen bytes and
draws lines between those coordinates for every frame. I took out anything fancy.

If you calculate vector rotation on another platform is it still 3D graphics? :D

[Art]

3D Point Rotation Demo:

http://www.youtube.com/watch?v=EwsiDabipmA


Who said you only get eight custom characters? :)

LCD Freedom - World's First HD44780 POV!

http://www.youtube.com/watch?v=8qd3EqZ15Jg

[spcw1234]

Wow, awesome job Art! Quite impressive!

[Art]

Thanks :)
It took a 20MHz clock to control the entire display, with all four cubes different,
but I could make videos forever :D
Since the video framerate is not synced to the pic's clock in any way,
and therefore the LCD backlight strobe frequency, it looks better here than the video comes up.

[Art]

Normally, Noritake will provide you with a dot matrix VFD sample to play with,
but only if you live in US or Canada:

http://www.noritake-elec.com/evalkit-sample.php

That's really quite nice, so ppl should be aware of that.

Suspecting that POV will work great with VFD, I promised a great demo including
their logo, in return for them sending me some 2x16 character modules.
They have replied with a suggestion display which is a HD44780, so it looks good :)

I don't think I'm finished with them.
I think it's possible to do greyscale graphics on a monochrome dot matrix VFD.

[sougata]

I didn't find the source for your AWESOME 2D LCD Graphics on the link you provided. I do not do PBP much nowadays but your demo is so cool, I want to try it out.
Cheers

[Art]

Freewebs canned my free web hosting.
If you pm me an email address I’ll send it.
Cheers, Art.

[sougata]

If you pm me an email address I’ll send it.
Cheers, Art.
Your Forum Inbox seems to be full. PM not going through.

[Art]

Sorry, it should be ok now.

[sougata]

https://www.youtube.com/channel/UCTc...EQ-LRACW8CRh-w
Cool, great videos :)

[Art]

Email sent...
Also trying attachment on this forum.

7749

[Art]

I’ve been having another play with it, in C, but nothing that can’t be done the same way in PBP.
For example to push the cubes off the screen, just count every six movements of a cube and increment the number of spaces following it.
Then you also have the value of the screen position to follow the graphics with text.
The graphics is slowed for debugging. It’s something I don’t want to have to wait for when it’s done.

I don’t like to reuse code without adding something to it, so I’m going for a wall of cubes that the LCD window can move around in.
They only have to move up and down as well as sideways.
Also, for the project, I would like to display practical information with graphics (such as a Moon phase), and be able to slide the
graphics area into the display in a fluid motion from any direction.

I scrolled the text vertically to begin with, but am now thinking toward scrolling in two fields sideways
with the graphics display in front and stopping for a while when everything is in position, and then scrolling off again.

https://www.youtube.com/watch?v=0vglTtYc1vw

[Art]

Whoops.. the video above is deleted and I can’t edit the post.

https://www.youtube.com/my_videos?o=U

[Demon]

LOL

I see my own videos with that link.

[Art]

whoops!

http://youtu.be/iiU9kIh8CrI


LOL

I see my own videos with that link.

[Art]

The current thing I’m working on with it is a transition from one text screen to another.

http://img.photobucket.com/albums/v186/ArtArt/Transition_zpsxoadb2qa.png

In the next frame or two when the A is completely gone from the screen,
it can be replaced by either a space or the new text, and doesn’t need to be
using a custom character location anymore. Then that location freed by the A,
can be used by the G, or whatever the next character to move is, until all text is gone or replaced.

It does mean I have to type a lot of crap to define all of the character set in program memory tho.
So far I’ve done the symbols and up to the numeral 0 :(

Here’s a demo I did with dsPic... much of it is a little too much for the display to look good, but I still wanted to see it ;)
https://www.youtube.com/watch?v=pqv48FtHm0E

[Art]

Got it :D It works a little differently to the graphics library.
A little harder then I thought, but maybe it can be guessed how it’s done.

https://www.youtube.com/watch?v=RZVvYpLRzqM

[Demon]

I have no clue.

You realize now you have to do a slot machine right?
:)

[Jerson]

Sweet ! Interesting use of the custom character RAM!!

[longpole001]

prity cool art

[Art]

Thanks Guys :) It took far too long for a frivolous thing :D
It can run faster than the video, and looks much better, but then also difficult to see each frame.

The worst part of it is the whole character map has to be stored in the pic.. unless it can be read from
the display itself which I have never tried, and am not using the signal line to read back from the LCD.

It’s not in BASIC, but the transition easily could be. Just a bunch of while and for loops and if statements.
Something I learned, at least with the module I’m using, it takes three times longer to use the 0x02
command to return to the first line than addressing the memory space for it with he 0x80 command instead.
I would not ever use 0x02 to send the cursor to the first line again.
If the delays are too fast that is the first command to choke the display module.
I am not using any clear screen command to have tried that.

A poker machine Robert, I think could be done, but you don’t get multiple pay lines like modern slots.

[richard]

according to my lcd data sheet the 0x02 does more than home the cursor , it says it also returns a shifted display back to original pos (execute time 40uS-1.64mS)
seems its best to avoid it if timing is an issue

[Art]

That would explain it. I’d expect the clear screen to take more time too, but I’m overwriting everything instead.
So it seems fastest to jump from 0x80 to 0xC0 in a loop for a two line display.
This means you can make your delay times the shortest and LCD the fastest.... or most reliable for faster delay times.

[Tabsoft]

Pretty cool!

It must have been a drag to create the character map.
I assume you used the custom character feature of the controller?

[Art]

Yes rather a drag :D I had the character map from a data sheet printed,
and hand drew them all into an online custom character generator to get the byte values for each line.
I didn’t bother with any lower case characters, so that saved a bit.

This makes it easy to do more types of transitions.
When any custom character is printed, both input/output characters are in a buffer,
so there exists a good opportunity to make changes to them there, like disintegration, etc.

One more video coming soon, sped up and in a real program :)

[Art]

Ok, here is the result in a program.
I’ve yet to reverse the direction of the existing effects which I would like to do.

https://www.youtube.com/watch?v=wv65HhqQnlU

[Ioannis]

Amazing what a character LCD can do with creative programming!

5 *!

Ioannis

[Art]

Thanks :) I got another Hackaday feature out of it... kinda by surprise.
I’d have preferred they waited because it will be easier now to come up with some variety.

[Art]

One more vid with two more text effects. The sideways spinning one I like.
I’ll try to get these back to PBP, the spinning and mechanical odometer ones.
Both require some program space for an entire character array,
but you wouldn’t believe the size of the routines that run the display.

https://www.youtube.com/watch?v=bN-XRXLx88Y