64 x 128 Graphics LCD

This project features the Optrex DMF-50427NYJ-SLY 64 x 128 LCD display. The idea is not so much the LCD display itself, but its use as a development platform for coding a large NEOPIXEL display. Now, you may think that these two things are not related. An array of NEOPIXELS (or WS2812) does not have much in common with an LCD such as this. But if you think of each dot on the LCD as an LED, then maybe you might see some similarity. It is my hope that figuring out how to move a small graphic icon of some sort around on the LCD might translate to the LED array. Crazy? Might just be. I hope this works out.

So lets just list some advantages and disadvantages.


  • “Bits” or “pixels” are arranged in a vertical layout on both the LCD and LEDs.
  • Even though the bits of the LCD are contained in bytes, it should be just a computational adjustment to handle individual LEDs. Hopefully it will be fairly easy to drop the byte sized “container”.
  • A massive construction project to put together the actual LED array can wait until later.
  • I will not have to display a large array, consume loads of power, and take up valuable space just to do simple software testing.


  • The conversion from byte-of-pixels orientation to straight array-of-pixels.
  • Even numbered columns will be wired (the serial data bus) from top to bottom of the array, while odd numbered columns will be wired from bottom to top.
  • One pixel on the LCD is represented by a single bit in a byte, while each LED “pixel” is a 24-bit word.
  • It will likely be necessary to split driving a large array between multiple outputs of one MCU or even between more than one MCU.
  • Other stuff I haven’t thought about yet.

I usually have an optimism about things like this. It usually turns out to be a totally unwarranted optimism. But the overriding idea is to avoid doing the coding on the actual LED array. If I get somewhere with the code on the LCD, I’ll have more confidence that I can move on, build the physical LED array, and start converting the code. I certainly do not want to use a library. For one thing, it probably will not work the way I want it to. For another, I wont be able to call this project “mine” if I rely on some other person’s code.

The alternating direction of the LED strips is of course required by the necessity to keep the data line short from the end of one strip to the start of the next strip. This may turn out to be relatively easy. Might just require more processing time. The other big problem is the division of strips among multiple outputs or multiple MCUs. That could get really hairy. Perhaps I should look at other projects out there, but I want to see what I can come up with on my own.


Originally the hardware consisted of the PIC, Optrex display, an M99512 serial EEPROM, and 2 FRAM boards from Adafruit. The memory is being changed to a 25AA1024 for the EEPROM, and to a 23LCV1024 for the serial RAM. There is no change in software for this hardware change. The EEPROM is basically a character generator. The current software can upload an ASCII character set. It’s assumed that it will also hold basic, permanent images for display. The new SRAM is larger than the FRAM and will hold all pages of display data. One page can be updated/referenced while the other is displayed. Anyway, here is the new, updated schematic:

Graphic Display Schematic

Here is a really quick overview of the operation of the DMF-50427NYJ-SLY LCD graphics display. The entire display has a memory of 64×128 pixels. You write 8-bit bytes of display data at a time:

  • One row on the display is 64 8-bit bytes: 8 * 64 = 512 pixels
  • There are 8 rows per screen: 512 * 8 = 4096 pixels
  • There are 2 screens: 4096 * 2 = 8192 pixels
  • So: 64 * 128 = 8192 pixels

All bytes are displayed in a vertical column, with the LSD at the top of the column and the MSD at the bottom of the column. There are 64 bytes per row. When each byte is written, an internal address is automatically incremented. The internal address will count from 0 to 63 as each byte is written, and will roll-over to 0 after 63. This means that if you do not specify a new X/Y position, you can only write to the row that you are currently on.

You can change row (or position on a row) by changing the X/Y address. This is accomplished by writing two instruction bytes to the display. See the documentation for the PosXY( ) function.

Finally, the two “screens” are selected with the CS1 and CS2 pins. The screens are arranged as 2 64×64 bit blocks, adjacent to each other horizontally. It should be noted that you can enable one or the other individually, or both simultaneously. An example of using both CS lines active together would be when clearing the display of all pixels. Just by writing 512 bytes, you can clear all 1024 bytes of display memory.


The video is being held up until the required new parts arrive. New parts are required for the following reasons:

The video is being held up until there are some actual graphic functions to demonstrate.

I had planned to have this project page out by the middle of June, 2015. Everything that could go wrong, did go wrong. I could go into a rant about it, but I’ll just list the highlights. It all started with a very nice vector board. I thought that this would be a semi-permanent set-up so I decided not to do it on a jumper-wires type of breadboard. This board had Vcc/Gnd rails on each side. There was a grid of fine etches running between all of the holes to provide sort of a power plane on each side.. This would have been great for a wire-wrapped board. But I soldered adapters and sockets to it and wired point to point with 30ga for signals and 14ga for power. To make a long story short, there was a power/ground short of 5 ohms “wired-in”. Since my power supply had no problem with the extra current, this situation went undiscovered for over a week.

  • First symptom was that the Hold and Lock pullup was only about 1V.
  • Next was one of the FRAMs had its CS stuck low.
  • Then the M95512 was burning up.
  • Another FRAM had SPI signals of only about 1V. Inputs and outputs
  • I was another one of my white jumper-wire breadboards to program with my PICKit3. (for some reason I did not want to put the programming header on the “permanent” board.) I eventually discovered that the PICs being programmed were cooking. A poor connection from the 5th to 6th hole in the GND strip caused a ground loop. I ended up loosing 2 PICs and toss that board.
  • More odd voltage levels on the M95512, and I finally discovered the 5v short on the vector board itself.
  • And, finally, when I got the new circuit on the jumper-wire breadboard, I forgot to connect power/and ground from one rail to the next. More ground loops, lost another PIC, and damaged (it sorta works) M95512.

It was two days before I gave up trying to find the short. I rebuilt the circuit on a white breadboard (a quality one) and got on with my life. I think my M95512 is flaky! Time to re-order parts.

  • Do not solder very many connections on a vector board with “power planes”. I suspect that’s where my problem lies, but I’ll never know for sure.
  • Always, always, always check you power/ground for shorts as you work on a proto board. A problem can arise and get buried under your sea of connections.
  • Never, never, never buy cheap Chinese white breadboards. These usually have round instead of square holes. They are usually from Pro’sKit.

I guess I need to write up a little editorial about overcoming problems and perseverance when working in electronics. It’s true what they say about failure. If you don’t fail, you’re not learning anything. I learned a lot last month. But all these problems are things I learned long ago. It’s frustrating to have problems, but having patents and not getting upset goes a long way to overcoming problems. Anyway, that’s for a later time.


Some basic code (updated 8/24/15) is available for download. (Download also has a PDF of the new schematic). It’s for a PIC 16F886 and it was originally written in assembly language but has now been updated to C. (I know, I should have started out in C. There is going to be too much computational code to try to work it all out in assembly.) It has the basic functionality that demonstrates the creation and use of the character generator. A display function, (dstring( )), displays a string in program memory (using the DA directive, for example). In the start-up code (sset( )), there is an explanation of some minimal tests and how to enable and use them.


The download includes the C source code and a PDF of the new schematic with the Microchip memory. They unzip into your current directory.

Download Graphic LCD Tests (now in C) - ZIP: basic_graphics_code_0-4.zip

©copyright 2015 pretzelogic LLC. All rights reserved.
No part of this page may be reproduced without permission.
Software, schematics, and text are presented as reference works only.
No claim as to useability, suitability, or correctness for any application is made.