Main Site Documentation

Graphical 128x64 Display Update Speed


I have been working with the domino and one of these displays. This is by far the easiest time I have ever had working with a micro controller. Pats engineers on the back I am wondering if there is a way to boost the speed I can update the display.

I am having troubles figuring out at what speed all my code is actually moving. In traditional micro controllers it was easy to just divide the system clock by 4 or whatever the case may be and that was a line of execution, but I am just not sure how to picture it on this device. Does it even fall into a micro controller class?

Sorta just going on a tangent. My primary question is if there a way to speed up this displays response, like increase the SPI speed or something?



Serial drivers/interpreters on a graphics displays are always painfully slow. It’s almost always much faster to talk to the display directly.

As far as speed goes, the FEZ isn’t realtime so there isnt a way to know how fast/when your instruction will be executed because you don’t know when another thread will run code on the processor.


The code we wrote is very generic so it is easy to use and also covers most uses. You can speed up the display much by doing all kind of tricks.
For example:

  1. we always update the whole screen but you can only update the region you want.
  2. we draw everything pixel by pixel. You can change that so you are drawing regions.

Again, the goal was “make it Freakin’ Easy to use” and it wasn’t make it as fast as possible :slight_smile:


Did anybody test, how many Flush()-es can it do per second ?

            static public void Flush(byte [] vram)
                for (int i = 0; i < 8; i++)
                    Locate(0, i);
                    Array.Copy(vram, i * 128, one_line, 0, 128);

I think we can optimize it by having the vram declared as a 8x128 2-dimensional byte array and so eliminating the Array.Copy

Also, we could do partial flush-es : only flush the dirty rectangle/bytes

Seems like there is some room for improvement while keeping it “FEZ”


Afaik multidimensional arrays are not supported on NETMF, and either way it will be much faster to make a struct holding the values you need and then making an array of that.


Multidimensional arrays, no. Jagged arrays, yes. You might test to see if a jagged array is faster than an array of structs.


Indeed, I meant jagged array (byte[][])
A struct with 8x byte[] arrays could be faster but much more difficult to use


I feel asleep after I posted that yesterday, sorry.

Ok, for my application I am displaying a list of files from a drive. Then i use a button to make it scroll up or down the list of files. This scroll is working fine but a little slow on the update. So if the user was pressing the up or down button fairly fast it would cause lag. I only display 7 files at a time, using the small font (7 pixels high) so there is room for the directory bar at the top and a few buttons on the bottom, a really common interface style. In my current configuration i have to redraw the directory bar and the button bar each time I scroll, which I guess could be slowing it down a bit but I’m not sure how drastic it really is.

Do we have a manufacture datasheet for the LCD? I checked at “” but no dice. I would mind trying to write a few functions to just partially update it but I dont know the command set of the LCD.

Might be on the back of the display itself ( model #), but I just did the double sided sticky thing to the board so I don’t to pull it off.




I notice the driver uses a spi clock speed of 1mhz, it makes sense that this can be increased to enhance the displays response time. Has anyone done this before? I’m going to read through some data sheets to find what the max sip clock speeds are for the domino and LCD screen.


I think 4mhz will work