No announcement yet.

uLCD-70DT Compatibility to uOLED-160-G2 and Speed

  • Filter
  • Time
  • Show
Clear All
new posts

  • uLCD-70DT Compatibility to uOLED-160-G2 and Speed


    I've two questions about uLCD-70DT, which is a nice display.

    1st: Is there a lot to do on coding to get the programms from uOLED-160-G2 running in the size 160x128 on this display. Code shell run in the upper left corner?

    2nd: I've 7 diffferent display codings. May they run together by adding offsets to the coordinates. The problem may the speed and sthe storage. Most of my Codings need most of the resources of the uOLED-160-G2.

    Click image for larger version

Name:	1843251.png
Views:	44
Size:	9.9 KB
ID:	39622

    Thanks and greetings
    Animated Scale Cockpit Displays at

  • #2

    Off the top of my head the main difference will be in the way Timers are used.

    Of course it also will be affected the way your code is written (eg gfx_Cls() will not just clear one 'window').

    But it should be too hard.


    • #3

      Ok, the timers. Do You mean such codes?
      HTML Code:
      if (peekW(SYSTEM_TIMER_LO) - m_prevTimeBrtQuader > 1500)
          m_prevTimeBrtQuader := peekW(SYSTEM_TIMER_LO);
          // ...
      gfx_Cls() may be replaced with a filled rec.

      But what will happen with the performance?
      Animated Scale Cockpit Displays at


      • #4

        That particular statement wont change, it's more about *TIMER0 -> sys_GetTIMER(TIMER0) and sys_SetTimer(TIMER0)

        As for the performance, it begs the question exactly what performance are you referring to.

        But, I guess you mean screen performance....

        Goldelox can draw an image at a rate of just over 200,000 pixels per second.

        Diablo can do just over 1,200,000 pixels per second.

        So, theoretically one Diablo could do the same frame rate as 6 Goldeloxes.

        But of course it's not that simple... Is the Goldelox flat out updating the screen? What other processing is Goldelox doing? Is there a large amount of comms data arriving that might overwhelm the comms port when multiplied by 7?

        So, it sort of looks good to me, but really the only way to know is to try it.