How exactly LCDOUT statement works?

[HenrikOlsson]

Well, LCDOUT is designed for 44780 compatible controllers. A quick look at the ST7920 datasheet seems to indicate that it's sort of compatible but with extended functionallity. It may or may not work with LCDOUT.
Do you have it connected with 4-bit or 8-bit interface?

I would let the compiler do the initial initalization, setting 4/8-bit interface etc. Then I would make two manual writes enabling graphics mode and extended function set mode, making SURE I don't change the 4/8-bit mode flag when doing so. See the note in the datasheet that you can't change DL, RE, and G at the same time, hence the multiple writes. Provided 4-bit interface is used I would try:

LCDOUT $FE, %00100100   ' Enable extended instruction set, keep 4-bit interface.
LCDOUT $FE, %00100110   ' Enable graphics mode, keep 4-bit interface and extended instruction set.

[CuriousOne]

Yes I have it connected via 4 bit interface. This is a special kind of ST7920 module, which has physical dimensions and pinout of standard 1602 LCD module, and in most cases, just works as drop-in replacement.
So far, I've figured an easy ways how to use LCDOUT to display all extended characters and features for this display. The graphic mode remains a mystery. My idea is to develop a PBP code, which will allow to use this module with existing 1602 LCD codes with as less modification, as possible.

I will try your solution today later and will write back.

[CuriousOne]

Just a note to myself or anyone else having same situation - the recommended approach works. While I have not tested it with ST7920, I do tested it with PT6314 for adjusting the VFD brightness and it does works.

[mpgmike]

This thread illustrates why I use maybe 80% of the PBP commands, but manually work with SFRs for the other 20%. I don't use LCDOUT (and several other commands), as they occasionally don't work with the PIC I'm using, or I can't get them to do what I want. If all else fails, PBP does an excellent job of enabling the programmer to manipulate SFRs manually. I create Subroutines to do what certain PBP commands are supposed to do. In fact, I don't even use ADCIN anymore after it failed on one of the PICs I worked with several years ago (forget which one).

This thread has brought forth what I consider to be valuable questions that lead to knowing what actually goes on in the background. The PBP Commands that I still use (most, actually) are ones that after discovering what they do, I like-endorse-value the PBP approach. Those I have abandoned are ones that I feel I can do an adequate job (perhaps even better for my application) than the PBP approach. Hobbyists appreciate the simplicity of the PBP Commands. Those of us that NEED absolute functionality may decide to manipulate the SFRs instead of using convenient PBP Commands. This thread has been educational.

[CuriousOne]

Well it's about knowledge.
For me it would be great if there were commands which directly work with WS2812, DHT22 and a huge list of other hardware, which is not supported right now....

[Ioannis]

... In fact, I don't even use ADCIN anymore after it failed on one of the PICs I worked with several years ago (forget which one)...

Well in contrast when I fail to use an ADC, I turn to ADCin and works first time! Taking more code space I guess and time...

Well it's about knowledge.
For me it would be great if there were commands which directly work with WS2812, DHT22 and a huge list of other hardware, which is not supported right now....

Then it would be Arduino and not PBP...

Ioannis

[CuriousOne]

lol ok, let's remove LCDOUT, OWIN, ADCIN, SEROUT and others too?
Instead of adding something useful like NEOPIXEL $ADDR,$BRIGHTNESS,$R,$G,$B