GLCD VEE question

[ilmenator]

Hi all,

I am having severe roblems with the graphic LCDs I would like to use with my Midibox project. I have tried various models from different manufacturers with the Toshiba T6963C controller on it.

The one I am fighting with at the moment is a Wintek WM-G2406D, some info on the pinout can be found here: http://zing.com.tw/WINTEK/wm-g2406de.htm As it is the D version, it only requires 5V input voltage. As far as I understand, VEE is generated on board of the display unit and should be a negative voltage which is supplied via a pot to VO like shown here: http://www.ucapps.de/mbhp/mbhp_lcd7_t6963c.pdf

So far I have connected VSS to J15 pin Vs, VDD to J15 pin Vd. VEE is connected via a variable resistor (10k) to VO. The other "end" of the variable res is connected to VSS. Now, if I measure at VEE I would suspect a negative voltage there, but it is in fact 3.xV POSITIVE (measured against VSS). VO against VSS measures a plain 5.0V also POSITIVE. This must be wrong, right?

But, what is it that I am missing here? Is there any tutorial on GLCDs on the web somewhere so I can dig a bit deeper? Or is my reasoning wrong?

The Power supply I am using is able to deliver 1.4A at 5V, there is nothing else but the core module and the GLCD connected - should be enough. So what else?

Thanks for looking (and commenting), ilmenator

[TK.]

It could be, that the FGND pin has to be connected in order to get the internal DC converter running. I would try a direct connection between FGND and Vs (both are ground in your case).

If this doesn't help, just start with two 9V batteries in order to get -18V. A DC converter chip can be ordered later...

Do you still own the other LCDs? Something which is not explicitely mentioned in my schematic are the connections to chip select and reset line. Even if the negative voltage is available, the display has to be initialized before you will see anything on the screen. Reset must be deactivated (for Wintek: RES=0), and the bus must be selected (Wintek: CE=1).

(I don't know good tutorials on the web)

Best Regards, Thorsten.

[ilmenator]

Hi Thorsten,

I tried your suggestions on the Wintek display and I have a partly success. Here is what I did:

• connected FGND to VSS (ground)
  
• connected RES to VSS (ground)
  
• connected CE to VDD (+5V)
  
  
  Also, I have
  
  • connected WR to RW of J15
    
  • connected RD to E of J15
    
  • connected C/D to RS of J15.
    

  All data lines are connected directly.

  Now, if I load the 'lcd7_t6963c_v' test application (PIC 18F452, MIOS v1.8 ), I can see a static number of horizontal rows - it looks a bit like a bar code  :-\.

  MIOS Studio shows the following MIDI activity coming from the PIC (no other modules connected):

...
timestamp 228382000 us: [FD] Undefined
timestamp 228385000 us: [FB] Continue
timestamp 228392000 us: [80 41 7F] channel 1: note Off F4 velocity: 127
timestamp 228393000 us: [FF] System Reset
timestamp 228394000 us: [80 7F 41] channel 1: note Off G9 velocity: 65
timestamp 228403000 us: [E8 41 41] channel 9: pitch wheel change 8385
timestamp 228404000 us: [FF] System Reset
timestamp 228406000 us: [FF] System Reset
timestamp 228408000 us: [FE] Active Sensing
timestamp 228412000 us: [FC] Stop
timestamp 228415000 us: [E8 41 7F] channel 9: pitch wheel change 16321
timestamp 228415000 us: [FF] System Reset
timestamp 228420000 us: [FF] System Reset
timestamp 228426000 us: [FB] Continue
timestamp 228430000 us: [FF] System Reset
timestamp 228438000 us: [E8 41 7F] channel 9: pitch wheel change 16321
timestamp 228449000 us: [F8] Timing clock
timestamp 228454000 us: [E8 41 7F] channel 9: pitch wheel change 16321
timestamp 228454000 us: [FF] System Reset
timestamp 228461000 us: [FF] System Reset
timestamp 228470000 us: [FA] Start
timestamp 228461000 us: [E8 41 03] channel 9: pitch wheel change 449
timestamp 228471000 us: [FF] System Reset
timestamp 228491000 us: [FF] System Reset
timestamp 228497000 us: [E8 41 7F] channel 9: pitch wheel change 16321
timestamp 228498000 us: [FF] System Reset
timestamp 228506000 us: [80 41 41] channel 1: note Off F4 velocity: 65
timestamp 228506000 us: [FF] System Reset
timestamp 228507000 us: [FC] Stop
timestamp 228510000 us: [F8] Timing clock
timestamp 228515000 us: [E8 41 7F] channel 9: pitch wheel change 16321
timestamp 228536000 us: [C0 03] channel 1: program change 3
timestamp 228536000 us: [FB] Continue
timestamp 228541000 us: [FE] Active Sensing
timestamp 228549000 us: [80 41 41] channel 1: note Off F4 velocity: 65
timestamp 228552000 us: [FA] Start
timestamp 228552000 us: [FB] Continue
timestamp 228558000 us: [80 41 7F] channel 1: note Off F4 velocity: 127
timestamp 228558000 us: [FF] System Reset
timestamp 228559000 us: [FF] System Reset
timestamp 228563000 us: [FF] System Reset
timestamp 228570000 us: [FC] Stop
timestamp 228599000 us: [F8] Timing clock
timestamp 228601000 us: [FC] Stop
timestamp 228605000 us: [FF] System Reset
timestamp 228613000 us: [F8] Timing clock

Is there any pattern in this from which one could derive a cause for this behaviour?

And yes, I still have all of the displays; to be precise, I have two of each kind, which makes a total of six. And you gave me some hope of getting them to work after all  :D

Thanks, ilmenator

[TK.]

Hi Ilmenator,

the connections are correct (you can compare it against the pin definitions in app_lcd.inc), but I've no idea, why the core should send these strange MIDI messages, there is no MIOS_MIDI_TxBufferPut command within the app.

A lot of "FF", "F8" and "FA" indicate, that there could be spikes of 30..100 uS on the Tx line

It could be related to your power supply - is the backlight already in use? Try it without first

Best Regards, Thorsten.

[ilmenator]

Hi Thorsten,

the backlight is not in use.

In fact, I have thought about my power supply, because I have recently "lost" some PICs. They were either erased and I had to burn a new bootloader (which should be next to impossible under normal circumstances), or they were completely destroyed. I was using a 5V power supply which was connected directly to the 5V out socket of the core board - the 7805 voltage regulator and the capacitors are not stuffed on the board I was using. I will try it with another core board and another power supply tonight.

Also, the negative voltage schematic from http://www.ucapps.de/mbhp/mbhp_lcd7_t6963c.pdf seems to produce strange output with that power supply, in a sense that if I turn the pot I can change the negative output voltage up to a certain point (but not consistently the same!), then suddenly the output voltage gets stucked and turning the pot does not have any effect anymore.

Tonight I will see if another power supply will solve the problems!

Best regards, ilmenator

[ilmenator]

Hello,

I have exchanged the power supply and I am using a different core board with the voltage regulator installed, so power should be very smooth now.

I have no more random MIDI messages sent by the core module, but the display still shows horizontal lines of varying thickness (and actually the black lines do change, they are not always the same after switching on the core). I can reproduce this behaviour with two different core modules, and it is the same with both test applications (vertical 'lcd7_t6963c_v'  and horizontal 'lcd7_t6963c_h' mode).

I have double checked the connections, all are wired as described and I have also re-soldered them - to no avail. Maybe some of the display's pins voltages need to be the opposite (like being connected to ground instead of 5V)? But where to start looking?

Thanks, ilmenator

[TK.]

Hi Ilmenator,

this bar/stripe pattern sounds like the access to the display is partly working, but the RAM hasn't been initialized, and font's are not displayed.

Something like this can happen on a timeout (see app_lcd.inc, search for TIMEOUT). Either your display is slower than the one I've tested so far, or two data lines are swapped, so that commands are not forwarded properly.

But I just have noticed another thing: I just have hooked my own T6963C display (donation from d2k) on a MIOS V1.9 core and noticed, that the font is scrambled.

This is realted to a the "font location change" (font is now located at the end of flash memory). This means, that all LCD drivers need to be recompiled with the new mios.h file

This file can be found in the migration/ directory of the MIOS v1.9 source package

And there is another point for which you have to take care about when using a graphical display: the update_with_old_mios.hex and update_without_installed_mios.hex file don't contain the font, it's only part of the mios_v1_9_pic*.hex file.

For the case that this is too confusing, here some step-by-step instructions:

  - upload mios_v1_9_pic18f452.inc in order to ensure, that the font is available

  - copy migration/mios of the source code package into the directory of the LCD driver

  - rebuild the application and upload it to the core

Maybe this already helps before fixing the timeout mechanism. I will wait for an driver update until I know, that your GLCD is working

Best Regards, Thorsten.

[ilmenator]

Okay,

so I will make the switch to MIOS 1.9 tonight. I tried MIOS 1.9 yesterday, but then I had strange MIDI output, thought it was related to MIOS 1.9 and reverted back to MIOS 1.8 .

I'll write down my results here.

Thanks, ilmenator

[ilmenator]

Well,

I have MIOS 1.9 up and running now.

First I uploaded the 'update_with_old_mios.hex' file, to get the new bootloader into the PIC. Then I uploaded 'mios_v1_9_pic18f452.hex' from the mios_update_v1_9/pic18f452/midi folder to have the fonts in my PIC.

I copied all of the content of the mios_v1_9_src\migration folder into the lcd7_t6963c_v folder and built a new main file. Then I uploaded the main.hex file to the PIC, but I still get the same behaviour: bars/stripes all over the place  :(.

Could it be that the Command/Data input is inverted on my display? Just a wild guess, because you said

or two data lines are swapped, so that commands are not forwarded properly.

Okay, I admit I don't really know much about this stuff...

I searched all the files in the lcd7_t6963c_v folder for the MIOS_LCD_TIMEOUT0 string, it was only found in app_lcd.inc and in mios.h. Is it actually used in your demo application?

Best regards, ilmenator

[TK.]

The update procedure was complete, and if the display shows the same behaviour, it is propably related to the driver.

I just have uploaded the new driver versions - app_lcd.inc is still the same, the framework is based on the v1_9 skeleton. All drivers (beside of the IIC driver) have been tested with my own displays, so please use the most recent "lcd7_*_v1_9" versions -> mios_download page (maybe it's required to refresh the page)

Yes, app_lcd.inc is the right location, the driver is located there. There is a timeout loop, which you could disable (just remove the "bz USER_LCD_WaitUnbusy_Disable" branch) - if MIOS hangs up thereafter, you know that the issue is related to the busy state

Yes, you are right - different polarities have to be considered. I just had a look again into the datasheet of your GLCD, it lists "RD" and "WR", but no hint about low active signals, they could be high active!

Solution (try this before removing the timeout mechanism): search for "GLCD_RD_N" and "GLCD_WR_N". Each time a "bcf" is used, turn it to "bsf". And change each "bsf" to "bcf"

This could help! :)

Best Regards, Thorsten.

[ilmenator]

Hi,

I downloaded the latest 'lcd*v1_9' version from the MIOS download site.

I exchanged 'bcf' with 'bsf' for all combinations of "GLCD_RD_N" and "GLCD_WR_N", that means for either one of them and for both at the same time, but to no avail. I still have the same bars.

I also removed the timeout mechanism as you described, but I'm afraid I can't see if MIOS hangs up or not. The display is just showing me the bars, and that's it. Is there any way to recognize whether MIOS is still doing something (apart from looking at the display)?

This is getting rather frustrating - sigh. I just wish the displays were not so good - I mean the quality of these bars is excellent, sharp and high contrast  ;)

Best regards, ilmenator

[TK.]

Hi Ilmenator,

are there any new findings in the meantime?

There is a simple way to debug the driver: just use MIDI events as "log mechanism". When you add following code to USER_LCD_PrintChar:

USER_LCD_PrintChar
   movwf TABLAT ; save character
   movlw 0xc0
   call MIOS_MIDI_TxBufferPut
   movf TABLAT, W
   andlw 0x7f
   call MIOS_MIDI_TxBufferPut
   movf TABLAT, W

   ;; ...
[/code]
each character will send out a program change
Best Regards, Thorsten.

[ilmenator]

Hi Thorsten,

I included the code snippet as you suggested. MIOS does NOT hang, after switching on the core I get the following MIDI messages from the core (running the 'lcd7_t6963c_v_v1_9' example):

timestamp 290226000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 292201000 us: [C0 4D] channel 1: program change 77
timestamp 292202000 us: [C0 49] channel 1: program change 73
timestamp 292202000 us: [C0 4F] channel 1: program change 79
timestamp 292203000 us: [C0 53] channel 1: program change 83
timestamp 292204000 us: [C0 20] channel 1: program change 32
timestamp 292204000 us: [C0 56] channel 1: program change 86
timestamp 292206000 us: [C0 31] channel 1: program change 49
timestamp 292206000 us: [C0 2E] channel 1: program change 46
timestamp 292206000 us: [C0 39] channel 1: program change 57
timestamp 292208000 us: [C0 20] channel 1: program change 32
timestamp 292208000 us: [C0 20] channel 1: program change 32
timestamp 292208000 us: [C0 20] channel 1: program change 32
timestamp 292209000 us: [C0 20] channel 1: program change 32
timestamp 292210000 us: [C0 20] channel 1: program change 32
timestamp 292210000 us: [C0 20] channel 1: program change 32
timestamp 292211000 us: [C0 20] channel 1: program change 32
timestamp 292212000 us: [C0 28] channel 1: program change 40
timestamp 292212000 us: [C0 43] channel 1: program change 67
timestamp 292213000 us: [C0 29] channel 1: program change 41
timestamp 292213000 us: [C0 20] channel 1: program change 32
timestamp 292214000 us: [C0 32] channel 1: program change 50
timestamp 292215000 us: [C0 30] channel 1: program change 48
timestamp 292215000 us: [C0 30] channel 1: program change 48
timestamp 292216000 us: [C0 36] channel 1: program change 54
timestamp 292217000 us: [C0 20] channel 1: program change 32
timestamp 292217000 us: [C0 54] channel 1: program change 84
timestamp 292218000 us: [C0 2E] channel 1: program change 46
timestamp 292219000 us: [C0 4B] channel 1: program change 75
timestamp 292219000 us: [C0 6C] channel 1: program change 108
timestamp 292220000 us: [C0 6F] channel 1: program change 111
timestamp 292221000 us: [C0 73] channel 1: program change 115
timestamp 292221000 us: [C0 65] channel 1: program change 101
timestamp 295784000 us: [C0 20] channel 1: program change 32
timestamp 295785000 us: [C0 20] channel 1: program change 32
timestamp 295786000 us: [C0 54] channel 1: program change 84
timestamp 295786000 us: [C0 36] channel 1: program change 54
timestamp 295787000 us: [C0 39] channel 1: program change 57
timestamp 295788000 us: [C0 36] channel 1: program change 54
timestamp 295788000 us: [C0 33] channel 1: program change 51
timestamp 295789000 us: [C0 43] channel 1: program change 67
timestamp 295789000 us: [C0 20] channel 1: program change 32
timestamp 295790000 us: [C0 20] channel 1: program change 32
timestamp 295791000 us: [C0 21] channel 1: program change 33
timestamp 295791000 us: [C0 76] channel 1: program change 118
timestamp 295792000 us: [C0 65] channel 1: program change 101
timestamp 295793000 us: [C0 72] channel 1: program change 114
timestamp 295793000 us: [C0 74] channel 1: program change 116
timestamp 295794000 us: [C0 69] channel 1: program change 105
timestamp 295795000 us: [C0 63] channel 1: program change 99
timestamp 295795000 us: [C0 61] channel 1: program change 97
timestamp 295796000 us: [C0 6C] channel 1: program change 108
timestamp 295797000 us: [C0 21] channel 1: program change 33
timestamp 295797000 us: [C0 20] channel 1: program change 32
timestamp 295798000 us: [C0 20] channel 1: program change 32
timestamp 295799000 us: [C0 43] channel 1: program change 67
timestamp 295799000 us: [C0 75] channel 1: program change 117
timestamp 295800000 us: [C0 73] channel 1: program change 115
timestamp 295801000 us: [C0 74] channel 1: program change 116
timestamp 295801000 us: [C0 6F] channel 1: program change 111
timestamp 295802000 us: [C0 6D] channel 1: program change 109
timestamp 295803000 us: [C0 20] channel 1: program change 32
timestamp 295803000 us: [C0 20] channel 1: program change 32
timestamp 295804000 us: [C0 20] channel 1: program change 32
timestamp 295805000 us: [C0 20] channel 1: program change 32
timestamp 295805000 us: [C0 20] channel 1: program change 32
timestamp 295806000 us: [C0 4C] channel 1: program change 76
timestamp 295807000 us: [C0 43] channel 1: program change 67
timestamp 295807000 us: [C0 44] channel 1: program change 68
timestamp 295808000 us: [C0 20] channel 1: program change 32
timestamp 295808000 us: [C0 20] channel 1: program change 32
timestamp 295809000 us: [C0 20] channel 1: program change 32
timestamp 295810000 us: [C0 20] channel 1: program change 32
timestamp 295810000 us: [C0 20] channel 1: program change 32
timestamp 295811000 us: [C0 20] channel 1: program change 32
timestamp 295812000 us: [C0 44] channel 1: program change 68
timestamp 295812000 us: [C0 72] channel 1: program change 114
timestamp 295813000 us: [C0 69] channel 1: program change 105
timestamp 295814000 us: [C0 76] channel 1: program change 118
timestamp 295815000 us: [C0 65] channel 1: program change 101
timestamp 295815000 us: [C0 72] channel 1: program change 114
timestamp 295816000 us: [C0 20] channel 1: program change 32
timestamp 295816000 us: [C0 20] channel 1: program change 32
timestamp 295817000 us: [C0 20] channel 1: program change 32
timestamp 295818000 us: [C0 70] channel 1: program change 112
timestamp 295818000 us: [C0 6F] channel 1: program change 111
timestamp 295826000 us: [C0 77] channel 1: program change 119
timestamp 295826000 us: [C0 65] channel 1: program change 101
timestamp 295826000 us: [C0 72] channel 1: program change 114
timestamp 295826000 us: [C0 65] channel 1: program change 101
timestamp 295826000 us: [C0 64] channel 1: program change 100
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295826000 us: [C0 62] channel 1: program change 98
timestamp 295826000 us: [C0 79] channel 1: program change 121
timestamp 295826000 us: [C0 20] channel 1: program change 32
timestamp 295827000 us: [C0 20] channel 1: program change 32
timestamp 295828000 us: [C0 20] channel 1: program change 32
timestamp 295828000 us: [C0 20] channel 1: program change 32
timestamp 295830000 us: [C0 4D] channel 1: program change 77
timestamp 295830000 us: [C0 49] channel 1: program change 73
timestamp 295830000 us: [C0 4F] channel 1: program change 79
timestamp 295831000 us: [C0 53] channel 1: program change 83
timestamp 295836000 us: [C0 01] channel 1: program change 1
timestamp 295836000 us: [C0 05] channel 1: program change 5
timestamp 295836000 us: [C0 07] channel 1: program change 7
timestamp 295836000 us: [C0 0A] channel 1: program change 10

These messages come with a short pause in between them, so I guess the first 'wave' is the Copyright screen, and the second is the test screen?!?

Well, unfortunately I still only see these bars...

As I have a second one of these displays, I will be testing whether I already shot the display when having trouble with the negative voltage. This might need a few hours, as I will have to find some connectors for doing this first.

I'll keep you posted - and thanks for this rather lengthy support...

Best regards, ilmenator

[TK.]

Yes, these are the strings and the icons which are printed out. There could be another interesting check before you unsolder this display: according to the T6963C datasheet (I just had a look), the CE (chip enable) line is low active. But in the Wintek specs it's listed as high-active signal. However, I assume that this is an error, and that all three - RD, WR and CE - are low-active signals. This means: CE_N must be connected to ground in order to activate the bus. And you have to use the unmodified driver (no bsf/bcf change)

This could also explain, why there isn't a change regardless of the RD/WR polarity.

Best Regards, Thorsten.

[ilmenator]

Hi Thorsten,

I clamped CE (Pin 7 of the display) to ground, but I still have the bars. The app version was the original 'lcd7_t6963c_v_v1_9' example downloaded again from uCapps.

Strange enough, then it looked like the core did not react anymore.

Therefore I included the debug output and removed the "bz USER_LCD_WaitUnbusy_Disable" branch, and what I got was this:

timestamp 194141000 us: Sysex message: F0 00 00 7E 40 00 0F 48 F7
timestamp 194410000 us: Sysex message: F0 00 00 7E 40 00 0F 2D F7
timestamp 194680000 us: Sysex message: F0 00 00 7E 40 00 0F 78 F7
timestamp 199879000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 203767000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 207662000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 213322000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 217213000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 221113000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 225014000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 228914000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 232818000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 236721000 us: Sysex message: F0 00 00 7E 40 00 01 F7
timestamp 240622000 us: Sysex message: F0 00 00 7E 40 00 01 F7

The first three lines are the remnants of the SysEx upload, the rest is a periodical message, received every one or two seconds. PIC erased (?) or destroyed? So I uploaded MIOS again, inserted the "bz USER_LCD_WaitUnbusy_Disable" branch again, but left the MIDI debug output in USER_LCD_PrintChar. Now, the display shows the same bars, and the only MIDI output I get after powering on the core is:

timestamp 1297882000 us: Sysex message: F0 00 00 7E 40 00 01 F7

No program change messages any more. Huhhh?? In conclusion, the only thing I changed was clamping CE to ground...

Best regards, ilmenator

[ilmenator]

Hi Thorsten,

I did some more testing: I exchanged 'bcf' / 'bsf' for all "GLCD_RD_N" and "GLCD_WR_N", and now I get the program change MIDI messages after switching on the core again.

So what I have now is: CE clamped to ground, and WR and RD inverted. I still have these bars, but at least I get the MIDI debug output again.

Even if I delete the "bz USER_LCD_WaitUnbusy_Disable" branch, I still get the MIDI debug output. So MIOS does not hang. Only the screen output of the display is still bars...

Does all this make any sense?

Best regards, ilmenator

[TK.]

Hi Ilmenator,

yes, this makes sense. It seems, that the datasheet is totally wrong, because your observations indicate, that the CE input is low active. I think that RD/WR are low activate as well - and the reset, too!

So: use the original driver, clamp CE to ground and RESET to +5V. I think that this will work

You don't need to upload MIOS again if the core "hangs up", normaly this happens if the driver runs in an endless loop (e.g. due to a missing timeout). In this case, just upload a modified application via 1st level bootloader

Best Regards, Thorsten.

[ilmenator]

What else can I say?  ;D ;D ;D

There is still a little floating voltage problem (or so it seems), the display is only stable if I touch pin 19 (FS) - guess I will have to connect it to VDD or VSS, it should mean 'Font Select' I guess.

Thanks man, you absolutely rule!

Best regards, ilmenator

[TK.]

:)

Best Regards, Thorsten.

[ilmenator]

Now that one type of display is working - let's go try out the next one that I still have lying around.  ;D

This is about a Data Vision 24064-02, the data sheet (well, the pinout) can be found here: http://www.datavision.com.tw/english/table/dgtable/dg24064-2.htm It also has the T6963C controller and is 240x64 pixels.

Actually, it seems like these pinouts are never right. At least this one is giving me the same trouble again... so I should be able now to solve the problem on my own, I thought.

Here is the story:

When connecting it like described on the web page of Data Vision, as usually I get those bars. Now, I tried all combinations of CE / RES clamped to ground / to +5V and I inverted WR and RD. There is one combination (CE and RES both connected to +5V) when I do not get bars, but it looks like some random blocks of (roughly) character size get switched on and off with a frequency of about 0.5 Hz. One can clearly see that the display has eight character rows when held horizontally - the blocks vary in width but are always eight pixels high. And it doesn't seem to matter whether WR and RD are inverted or not... Is this any indicator to a solution of this problem???

Ahh, and sometimes the display just stays blank... though I changed nothing!?

I know that you may already have enough of these display problems. Well, I just thought you might have another idea of what could be wrong this time...

Thanks a lot, ilmenator