Looking for help with UG-32F01 320x240 LCD display

[plasmo]

UG-32F01 is a 5.2" 320x240 display WITHOUT a controller. They used to be quite inexpensive on eBay and you still can get it around $25 each. I've acquired a box of 20 several years ago and wanting to build a 6502 or Z80-based controller for it. The datasheet is very sparse, probably makes perfect sense for people experienced in LCD, but I can use a few hints. Anyone has experience with UG-32F01 LCD, or controller-less LCD display?
Bill

[8BIT]

I did a driver of an optrex 320x240 LCD display on an ATMega8 several years ago. It used a similar interface. Let me know if you would like to look at that code.

Daryl

[plasmo]

The optrex 320x240 LCD is also without a LCD controller? What model number was that?

My limited understanding is the LCD controller must run in very tight loop generating the necessary line pulses, pixel pulses and associated data in tight loop. It is similar to what a CRT controller does except it is controlling a LCD display. LCD controller function is typically done with dedicated hardware. I'm trying to replace that with CPLD and CPU.
Bill

[GARTHWILSON]

It has a bunch of ICs on it, so it has a controller for handling the strobing of the dot rows and so on, just maybe not any character generator or the ability to take in commands to draw a segment from point A to point B, circles, ellipses, etc.. You'll have to do those in software. But if you feed it the dots, it will keep them in the display until you overwrite that information. There should not be any need to constantly babysit it. I have working code for a 128x64 LCD at http://wilsonminesco.com/6502primer/Dis ... Acode.html , but that was SPI, not 4-bit parallel. The driver IC said it had an SPI mode. The LCD manufacturer said it did not, so they weren't any help getting it going. I did finally did get it going though, in SPI. IIRC, there was one bit in a setup byte that I had wrong for the longest time.

[plasmo]

This is picture of the ICs at the back of UG-32F01. They are 4 MSM5299 80-dot segment drivers for 320 dots and 3 MSM6598 80-dot common drivers for 240 rows of 320 dots per row. My limited understanding is collectively they shift data to locations on the screen kinda like raster scan of CRT. It is unclear to me how long the LCD screen retains the data. The datasheet mentions a minimum frame frequency of 70Hz, implying the screen need to be refreshed 70 times a second, minimum? I did find a paper describing UG-32F01 in conjunction with SED1351 graphic controller. That is my best hope of reverse engineering the LCD display, a rather arduous process...
Bill

[GARTHWILSON]

plasmo wrote:

That is my best hope of reverse engineering the LCD display, a rather arduous process...

Is that to say you haven't found a datasheet for the panel, only the ICs? (I found datasheets for the ICs, but they didn't have the information you'd need for writing your software, and I have not found a datasheet on the completed LCD module.) I'm pretty sure however that the ICs take care of all the scanning, and I expect that after you've fed it a screen of data, it will maintain it until you write new data to it, and even then, it probably has scrolling functions so for example if you have a screen of text and want to scroll it all up a line and feed it a new line of text at the bottom, you only need to tell it to scroll that far and then give it the new line, not give it all the data again in different positions. That's the way my little 128x64 graphic LCD is. It does not have a controller in the sense of generating characters and so on, so you have to feed it data about which dots to turn on and off; but then it keeps those data indefinitely, until you feed it new data. Your LCD module's ICs might scan the whole LCD 70 times per second, but that does not mean you have to feed it the information 70 times per second. It has its own memory that it scans from.

[Martin A]

My guess looking at the "datasheet" is the panel expects to be driven by a HD64646F or MSM6255.

A cursory glance at the 6255 sheet (I found it here https://www.pjrc.com/tech/eg64e00bcwu/msm6255.pdf does seem to show it has the right outputs to suit the 14 pin connector on the display.

Whether there's enough info there to construct a replacement ...

[John West]

GARTHWILSON wrote:

I'm pretty sure however that the ICs take care of all the scanning, and I expect that after you've fed it a screen of data, it will maintain it until you write new data to it, and even then, it probably has scrolling functions so for example if you have a screen of text and want to scroll it all up a line and feed it a new line of text at the bottom, you only need to tell it to scroll that far and then give it the new line, not give it all the data again in different positions.

That's the job of a controller, and this display doesn't have one. It only has the drivers. There's no memory, except for the shift registers that can only hold a single row or column. If you want the display to keep displaying, you have to feed it an entire frame of data every frame. If you don't, it will stop displaying and you risk damaging the LCD.
A bare LCD needs funky waveforms at funky voltages. The drivers provide these, giving the rest of the system a nice digital interface. But that's all they do.

[plasmo]

GARTHWILSON wrote:

Is that to say you haven't found a datasheet for the panel, only the ICs?

I have not found much electrical spec about UG-32F01 other than the one posted at the beginning of the thread. I do have experience interfacing to modern 128x64 OLED display over I2C bus; like you've said, it takes in pixel data and continuously update them by itself so no need for constant refresh. The UG-32F01 does not appear to have the self-refresh capability

Martin A wrote:

A cursory glance at the 6255 sheet (I found it here https://www.pjrc.com/tech/eg64e00bcwu/msm6255.pdf does seem to show it has the right outputs to suit the 14 pin connector on the display.

John West wrote:

That's the job of a controller, and this display doesn't have one. It only has the drivers. There's no memory, except for the shift registers that can only hold a single row or column.

That's my understanding of UG-32F01 as well. The easiest solution may be getting a controller like the MSM6255 Martin A mentioned, but I was wondering whether anyone has built his own controller out of 6502, FPGA, CPLD, or even TTL logic.


Edit: A LCD controller needs additional memory to hold display data plus interface logic to work with a microprocessor, so replacing LCD_controller+memory+interface_logic with a processor+memory+CPLD is not entirely illogical.

[8BIT]

plasmo wrote:

The optrex 320x240 LCD is also without a LCD controller? What model number was that?

My limited understanding is the LCD controller must run in very tight loop generating the necessary line pulses, pixel pulses and associated data in tight loop. It is similar to what a CRT controller does except it is controlling a LCD display. LCD controller function is typically done with dedicated hardware. I'm trying to replace that with CPLD and CPU.
Bill

It has the LCD scan controller, as Garth described, but not a higher level controller with built in buffer. I did have to feed pixel data to it similar to a composite video. I actually just modified my ATMega8 composite video display code to refresh the LCD vs. a composite display. It generated the 3 clocks needed and provided the 4 bit data. It included a 8x8 font and the ATMega8 has enough RAM to feed a 40x25 character display. This allows for a serial or parallel connection to a 6522 and and the host only needs to pass updates. The AVR does all the refreshing.

An ATMega1284 has enough RAM to drive 320x240 pixels if you wanted to have graphical capabilities.

Look here. if you want my LCD-specific code, I can provide that.
https://sbc.rictor.org/vid2c.html

Daryl

[plasmo]

Your Optrex 320x240 sounds very similar to UG-32F01. It must have a frame pulse to mark the beginning of a frame, line latch pulse to latch a line of 320 dots, and a dot clock that scan in 4-bit of data. There is probably also a display_on and possibly an alternate LCD drive that needs to change polarity every frame. Yes, I love to know the model number of the Optrex and your ATMega code. I actually have designed a Z80-based controller for UG-32F01, but was not able to turn on the display.
Bill

[8BIT]

Yes; frame, line and bit clocks with 4 bit data. I do not recall having to provide the other signals, but will double-check.

I'll dig up the datasheet for the display and zip up the AVR code later tonight.

Daryl

[8BIT]

Attached Zip has datasheet for Optrex display and the AVR code. it's been a long time and I cannot vouch for the readability of the code. Ask any questions you have and I'll try to refresh on the info and get you an answer.

Also added image of the working schematic.

Daryl

[drogon]

8BIT wrote:

An ATMega1284 has enough RAM to drive 320x240 pixels if you wanted to have graphical capabilities.
Daryl

When I first started my Ruby project I did similar - outputting composite video though. It worked great:

https://www.youtube.com/watch?v=09zhGUbVxdU

But it consumes some 60-70% of all CPU cycles )-: leaving little left to do line drawing, talking to the 6502, etc.

Using it to drive one of these LCDs may a marginally easier but it's still going to be a lot of CPU cycles maintaining the image.

The new Pi Pico is going to the worthwhile looking at for things like this - have a register type parallel access to the 6502 bus and driving a composite, vga, dvi monitor at the same time - so working in the same style as maybe some of the Propellor type VGA interfaces or the old TI 9900 (?) video adapter chip.

-Gordon


-Gordon

[plasmo]

8BIT wrote:

Attached Zip has datasheet for Optrex display and the AVR code. it's been a long time and I cannot vouch for the readability of the code. Ask any questions you have and I'll try to refresh on the info and get you an answer.

Also added image of the working schematic.

Daryl

Daryl,
Thank you, this is exactly what I'm looking for. The Apollo module is very close to UG-32F01, the negative bias voltage of -26V is quite a bit more than -16V of UG-32F01; the alternate DC bias required by UG-32F01 is generated internally in Apollo. Your ATmega code should help me find out why I can't get my display to work.

This is my attempt at LCD controller using Z80. Z80 works and I throw a big CPLD at the problem, but still can't get the LCD screen to respond beyond gibberish.
https://www.retrobrewcomputers.org/doku ... smo:z80lcd

drogon wrote:

But it consumes some 60-70% of all CPU cycles )-: leaving little left to do line drawing, talking to the 6502, etc.

With a keyboard added, I had a vision of standalone Z80 with LCD as the display, but consuming 60-70% of CPU may be problematic.

Bill