graphics

[mister_e]

AS IS.. no. The main problem is always the same, there's no real standard LCD Graphic controller... but some model are more popular. You may find few example here and there in Basic, Asm, C etc etc etc

The following have been refered few time here
http://www.compsys1.com/workbench/

[skimask]

AS IS.. no. The main problem is always the same, there's no real standard LCD Graphic controller... but some model are more popular. You may find few example here and there in Basic, Asm, C etc etc etc

The following have been refered few time here
http://www.compsys1.com/workbench/

I've got some fairly decent code for the 122x32 (SED1520) type LCDs.
It ain't the best, but it's always worked for me.

[mister_e]

Well, at least once you have something working, it's just a code challenge to modify it or totally rewrite the whole thing.

I agree it could be interesting for many user if Melabs would integrate 2-3 popular controller in PBP as some already do.

[skimask]

Well, at least once you have something working, it's just a code challenge to modify it or totally rewrite the whole thing.

I agree it could be interesting for many user if Melabs would integrate 2-3 popular controller in PBP as some already do.

->Well, at least once you have something working
Are you doggin' me...again?

I'm wondering if a GLCD add-on couldn't end up as some sort of library file add-on.
A define at the top of the code (i.e. DEFINE GLCDTYPE = 1 or 2 or 3 or whatever), then a few commands for text, points, etc.etc. The code I've got for the SED1520 does all of the background work, sets points, clears points, and does text, along with some simple shifting...and I'm sure other folks have got fully working code for other controller types.

Jist of the story, MeLabs had better get on with an upgrade of some sort and better do it soon; something to be a bit more competitive with the likes of mikroelectronika (or whatever they're called) and others. I like the product and all, but like everything else in life, if something out there is better, for a better price, I'm probably going to end up going that route (much as I hate to say it)....

[mister_e]

Are you doggin' me...again?

ME? Nah, no way!

I'm wondering if a GLCD add-on couldn't end up as some sort of library file add-on.

Yup perfect application for INCLUDE and conditional assembler IF/IFDEF/IFNDEF. but on the other hand, it make the INCLUDE file too big. I prefer to use ONE/Controller type... but it's me. Using PBP DEFINE in your code will may set the I/o assignment, tell to store Text fonts in the code space or in a external EEPROM, etc etc etc. There's tons of different structure you could use. As always...

and I'm sure other folks have got fully working code for other controller types.

possibly true And i feel they work on many hours/days/weeks to make them 100% bug free and easy-to use/expand. This said... i doubt they will trash them away for free... even if they are really often here and always willing to help. Maybe one day they could place them and sale them on their website...

I like the product and all, but like everything else in life, if something out there is better, for a better price, I'm probably going to end up going that route (much as I hate to say it)....

Depending what you call better, all good point. Let's say with more built-in feature ;-}

What happen is that many new user now compare built-in feature, and sometimes they buy the one with all needed feature... but ends-up with daily/weekly update to do to fix some obvious stuff that shouldn't be messed up at first. too bad.

[jcleaver]

see how complicated this gets trying to get a glcd command set in pbp
others are doing this fine sure there must be some sort of standard graphic display that could be supported. some of us are more interested in building some nifty project than trying to learn high level programing thought thats what pbp was supposed to do really think it could use a update in simplicity

[skimask]

see how complicated this gets trying to get a glcd command set in pbp
others are doing this fine sure there must be some sort of standard graphic display that could be supported. some of us are more interested in building some nifty project than trying to learn high level programing thought thats what pbp was supposed to do really think it could use a update in simplicity

You're right, others do have GLCD commands built into them to use with standard graphic LCD's, as long as it's THEIR standard graphic LCD.
Off the top of my head, there's about 4 totally different types of graphic LCDs that I've worked with, and of each of those 4 types, there's various different dialects amongst those. Much as I hate to say it, I believe the trick is to get yourself a half a dozen GLCDs (same type of course), build yourself a library of commands, and keep using those same routines for each project.
And if you're still having problems with a particular GLCD, post 'er up here. Again, I am 100% sure somebody would try to help...

[T.Jackson]

see how complicated this gets trying to get a glcd command set in pbp
others are doing this fine sure there must be some sort of standard graphic display that could be supported. some of us are more interested in building some nifty project than trying to learn high level programing thought thats what pbp was supposed to do really think it could use a update in simplicity

PBP is a high level language where as ASM is a low level one. And, I think the biggest disadvantage of having support for graphics displays is going to be the bloated output. Better to write your own routines because there may be certain functions that you don't require which will only cost you code space. One of PBP's strong points is that it compiles to a highly optimized small output, most others don't. If PBP did have support for graphics displays - you have to remember that the entire library would need to be included in your code, even if you use all, some or none of its functions. Not worth it.