Does anyone else find the screen tearing unbearable?

[stormy]

I just finished setting up the device, flashing latest firmware etc etc - loaded some games and to my horror, they feel really stuttery with lots of screen tearing. I don't think I could enjoy playing any games on it. I've looked through the whole forum and can't find any complaints which I find odd. I did see on a post that vsync isn't supported, so I guess this issue can never be fixed? Damn that's such a shame.

edit: it isn't as bad in pixel perfect mode (not stretched) by pressing start and right. But it still feels like it's running at 10-15fps.

[lordhardware]

It really depends on the system.
Master System feels like perfect 60 for some games.
GBC seems to be the worst for tearing, however the emulators are early builds though.

This is the first (real) device based on the esp32 build for games so be aware that as you bought into a dev platform, it will take some time to settle.

[crashoverride]

The game emulators all run at 60fps. The display runs at 30fps.

[lordhardware]

The game emulators all run at 60fps. The display runs at 30fps.

Is this an SPI limitation or a display limitation?

[stormy]

So the perceived low Fps is due to there being screen tearing/jittering which is down to the machine not supporting vsync. So basically from what I gather is no matter how much development happens, it's always gonna play and feel like crap.

[lordhardware]

So the perceived low Fps is due to there being screen tearing/jittering which is down to the machine not supporting vsync. So basically from what I gather is no matter how much development happens, it's always gonna play and feel like crap.

ESP32 does support VSYNC, it's documented in the release notes.

[stormy]

But apparently the screen doesn't.

[lordhardware]

But apparently the screen doesn't.

?? no screens (apart from ones with a microprocessor like G-Sync or Freesync I guess) 'support' V-Sync.
VSYNC just syncs the visual output via the driver with the reported frequency of the display.

[stormy]

Read for yourself, very first post from crashoverride, number 5: viewtopic.php?f=158&t=31271
"The LCD is connected via SPI. There is no VSYNC control over this interface so tearing will sometimes be noticeable"

[lordhardware]

Read for yourself, very first post from crashoverride, number 5: viewtopic.php?f=158&t=31271
"The LCD is connected via SPI. There is no VSYNC control over this interface so tearing will sometimes be noticeable"

@crashoverride does this mean that there's no bits running back from the display?
If so, can't we still sync the display by logging the startup ms delay at runtime, and offsetting the VSYNC against that and the documented refresh freq' of the display? or are there variations in the display frequencies that make this impracticable/impossible?

I'm sure I had full screen refresh and freq information on my odroid-w via SPI, so is it a limitation of the documentation?

[briansm]

I'll throw in my own two cents as a third-party programmer... This might be ill-informed and wrong, but it's what I've figured out from playing with the ORDROID-GO.

The ili9341 controller for the LCD is pretty dumb. It has no double buffering, you send a 16-bit pixel to it and it displays it. Also the communication between the esp32 and the LCD is over a 1 bit SPI bus running at the maximum speed the LCD can handle, 40HMz. The theoretical maximum frame rate therefore (320x240 pixels, 16 bits per pixel) is

40,000,000 / (320x240*16) = 32.5fps.

This is just enough that you hopefully won't notice tearing when the next frame is half way through replacing the previous one.

The next problem is that the RAM in the esp32 is very limited. You can allocate precisely _one_ 8-bit frame buffer (320x240 = 76800 bytes) in RAM, so esp32 based double-buffering is out. Full 16-bit buffering is also out, so you need to convert your 8-bit buffer to 16 bits on the fly when feeding the LCD.... which brings other problem.

The esp32 has no native ability to feed a buffer to the LCD, what is normally done is the whole second CPU core is dedicated to feeding a frame buffer to the LCD, doing the 8-to-16 bit pixel data conversion as it goes.

There is 4MB of external RAM available in the esp32, but it is accessed over the same SPI bus as is being saturated by the display updates, so is effectively useless.

The SD card also uses this SPI bus, so you have to stop display updates when doing SD card read/writes but this is a minor point.

(sorry if any of this is wrong, but this is my current understanding of how the ORDOID-GO works internally).

In summary - the ORDOID-GO is a PITA to work with, it's frankly a miracle the exiting emulators work well, hats off to Crashoverride for the coding.

[crashoverride]

Is this an SPI limitation or a display limitation?

It is a LCD display limitation. The maximum stable speed is 40Mhz. The ESP32 can operate at 80Mhz, but very few of the display modules can tolerate it.

does this mean that there's no bits running back from the display?

Communication with the display is one-way: from ESP32 to LCD.

can't we still sync the display by logging the startup ms delay at runtime, and offsetting the VSYNC against that and the documented refresh freq' of the display? or are there variations in the display frequencies that make this impracticable/impossible?

The ESP32 and LCD have independent clock generators. This means they will never be synchronized and will "drift" over time.

There is 4MB of external RAM available in the esp32, but it is accessed over the same SPI bus as is being saturated by the display updates, so is effectively useless.

The ESP32 has 3 SPI controlelrs. The internal flash and PSRAM share a SPI bus. The LCD and SD card share a different SPI bus. In 80Mhz PSRAM mode, the third SPI controller is used to generate the clock signal for PSRAM.

The SD card also uses this SPI bus, so you have to stop display updates when doing SD card read/writes but this is a minor point.

This is explained here: https://github.com/espressif/esp-idf/is ... -365364458

[JoshS]

Aww, this is disappointing. When I read that the ODroid-Go had 4 meg of ram I assumed it was directly connected to the processor.

Although I read that the ESP32 should have 520k of RAM, so I can imagine it being theoretically possible to have multiple screens buffered, and to average the colors on two of them so that at least you're not skipping screens. Also if the display is being kerneled (as we used to call dumping the data with a processor rather than with hardware), then it's also possible to sync that dump with emulator - though even that won't guarantee no tearing as I imagine that we still would need some way of knowing how the hardware at the LCD end uses that data (it has it's own buffer and it's own scanning?).

All of this brings me to my questions.
Does each emulator have it's own custom ram layout or is there a standard one?
Is that documented?

[crashoverride]

When I read that the ODroid-Go had 4 gig of ram

It has 4MB (not GB) of external PSRAM contained in the ESP32 WROVER module. This was later increased to 8MB (not GB) using the ESP32 WROVER-B module. Due to hardware limitations, the ESP32 can only address 4MB of PSRAM at a time and requires bank switching to use the extra memory on WROVER-B. Currently, nothing makes use of this extra memory.

Does each emulator have it's own custom ram layout or is there a standard one?

Each emulator originates from different authors at different periods of time. Therefore, they have little in common architecturally, and there is no standard for memory use. The GBC emulator is probably the most unique in that it performs page based demand loading of memory from the SD card and alters its memory map if "large SRAM" support is needed.

Is that documented?

As with most open source projects of this nature, "the source code is the documentation". The NES emulators is probably the most challenging to 'follow'. It was authored (not by me) with 'spaghetti' call paths.

[JoshS]

Yeah. I fixed that to 4mb then saw your response >.>

But wait, if the 8mb of ram is on a serial interface isn't that different from bank switching?

How do you access it? I assumed that serial interface meant that you have to very slowly stream that memory in or out and store it in the actual ram.

Am I right that the ram that's actually addressable directly is only 520K?

I used to do graphics programming for video games, so if the emulators need the graphics kernelling loop improved to scale more smoothly or to do time filtering that would be kind of similar to code I've written before.

So, for instance, if the emulator is generating 60 frames per second and the screen can only display 30, then one thing you could do is keep two frames in memory at a time and send an average of the two to be displayed.

Similarly if the emulator is expecting a different sized screen than the native one, then smart code could do some filtering on the fly to make the scaling not look blocky.

It might help if those things could be written in assembly language.

A quick division shows that at 240 mhz, that's 125 cycles per pixel with 320x200 pixels 30 times a second, that sounds like it could be enough time to be pretty fancy.

[JoshS]

Also what do you mean by "spaghetti call paths"?

[crashoverride]

But wait, if the 8mb of ram is on a serial interface isn't that different from bank switching?

How do you access it? I assumed that serial interface meant that you have to very slowly stream that memory in or out and store it in the actual ram.

Am I right that the ram that's actually addressable directly is only 520K?

The ESP32 has a MMU that transparently integrates and caches the external PSRAM into the memory map. This MMU is limited to 4MB.
https://docs.espressif.com/projects/esp ... himem.html
Note that "himem" support is relatively new and requires upstream esp-idf and is not currently available in my forked esp-idf.

Similarly if the emulator is expecting a different sized screen than the native one, then smart code could do some filtering on the fly to make the scaling not look blocky.

A new scaler is currently being tested for the NES emulator. It is based on a floating point linear blend.

It might help if those things could be written in assembly language.

There is no assembly language reference officially/publicly available for ESP32. "Leaked" versions of a document assumed to apply to ESP32 (LX6) can be found with a search engine.

Also what do you mean by "spaghetti call paths"?

It means that GBC and SMS emulators both have a traditional main loop. The gamepad state is fed to the emulator, the emulator is stepped by a frame, and the frame and audio are presented. By contrast, the NES emulator does not have a clearly defined main loop making call tracing difficult.

The GBC main loop:
https://github.com/OtherCrashOverride/g ... #L601-L697

The NES "main loop":
https://github.com/OtherCrashOverride/g ... ain.c#L192

[JoshS]

That's still very vague.

Ignoring the bank switching beyond 4 mb as not very important:

Is the 520k attached directly to the cpu all cache? Is it all locked down in and there's a separate cache for external memory - and if so what's the address range for locked memory and how big is the separate cache?
How big are the cache lines? What's the cache replacement algorithm? How long does it take to load a cache line? How long does it take to flush a cache line? Is the cache write through? Does any of that happen in the background during other processing? Is there any prefetching? Is the cache shared between cores?

Etc etc etc

[JoshS]

I think I found that the answers are in the ESP32 technical reference manual.

Reading.

I see there are three banks of internal SRAM, and 64k of bank 0 can be configured to be cache for external ram.

[crashoverride]

I would refer you to the ESP32 official documentation for those questions:
https://docs.espressif.com/projects/esp-idf/en/latest/
https://espressif.com/sites/default/fil ... ual_en.pdf
https://espressif.com/sites/default/fil ... eet_en.pdf

[JoshS]

As far as I can tell, in none of the documentation does is say what the block size for the cache is.

All it says is that it's a two way set associative cache that's broken into two 32k caches, one for each processor BUT the diagram shows both processors connected to both caches, so the diagram seems to contradict the documentation that has an enable bit for each processor having it's own cache. And of course the meanings of each of the combinations of control bits is not explained.

Basically I suspect that it will be impossible to figure out what this all means to real time programming or throughput without some contact with an engineer from the manufacturer to explain what the bad documentation means.

Or maybe we're supposed to deduce that since the cache is shared between PSRAM and flash ram that the block size is set by the flash memory?

Should I assume that the channel to the PSRAM is as slow as the one to the screen?

[JoshS]

Hmm, @crashoverride, you wrote "The maximum stable speed is 40Mhz. The ESP32 can operate at 80Mhz, but very few of the display modules can tolerate it."

Does this mean that PSRAM is read and written at 80MHz which is twice the speed of the screen?

That probably would be too slow to hold a screen buffer, even at a byte per pixel. If you saved ram buffer out to PSRAM and read it back in once per display, you'd used up half of the RAM channel bandwidth on that.

This post implies that's possible on an esp32 https://esp32.com/viewtopic.php?t=7158

In any case there's 456k of internal SRAM that isn't cache that's available for use in programs AFAIK.

[Cwiiis]

Updating the screen at a higher refresh (the current default is 70Hz, though obviously the actual updates are much slower - the screen can update at any rate from 61Hz to 119Hz) and doing intelligent partial updates would alleviate tearing and increase the screen refresh markedly - have a look at the conversation and links in this post: viewtopic.php?f=158&t=32844 - FWIW, my Odroid Go is scheduled to arrive next Wednesday and I plan on spending time on this. I really want to play NES games at full refresh!

[JoshS]

Oops just replied in the wrong thread, that other one Cwiiis linked.

Just pointing out that to do what I suggested, time filtering, the bandwidth of keeping a buffer in external memory might not be so bad since the NES had such slow memory in the first place.

I don't have any good answer for the LCD having an actual asynchronous scan from it's own memory at 70 fps, though.

[JoshS]

Hmm

https://github.com/juj/fbcp-ili9341

"Given that the SPI bus can be so constrained on bandwidth, how come fbcp-ili9341 seems to be able to update at up to 60fps? The way this is achieved is by what could be called adaptive display stream updates. Instead of uploading each pixel at each display refresh cycle, only the actually changed pixels on screen are submitted to the display. This is doable because the ILI9341 controller, as many other popular controllers, have communication interface functions that allow specifying partial screen updates, down to subrectangles or even individual pixel levels."

"Other optimizations are also utilized to squeeze out even more performance:"
(things to do with registers, threads and falling back to interlacing)

But it also says "All the ILI9341 displays work nice and super fast at ~70-80MHz."

Another search turned up someone who said that he could write to an ILI9341 at 80mhz with a few write errors, but couldn't read at that speed.

Is "a few write errors" ok?

[Cwiiis]

But it also says "All the ILI9341 displays work nice and super fast at ~70-80MHz."

Another search turned up someone who said that he could write to an ILI9341 at 80mhz with a few write errors, but couldn't read at that speed.

Is "a few write errors" ok?

Most of my searching for results with the same chipset had it topping out at around ~74Mhz for a stable display, so 80Mhz sounds like it'd be pushing it. Maybe worth a shot, but I don't imagine @crashoverride hasn't already tried that (because if you could run it at 80Mhz that would basically solve all these problems without needing to be clever about anything!) The real shame is that there isn't any fine-grained control over the clock as far as I can tell - if you could downclock by around 10% or so, likelihood is you could have a much faster, stable display (of course at the cost of CPU, but 10% seems sounds manageable to me)

[JoshS]

Just to make things more complicated, I found the ILI9341 datasheet
https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf
at page 139/140 there's a Set_Tear_Scanline command which makes some kind of signal when gets to a specific scanline, no idea if we can detect that
and
Get_Scanline command which we can use to tell which scanline is being updated.

I also don't know what direction it updates in, top to bottom, left to right etc. I hope you update the screen in the same direction it scans so you have the maximum time to run behind the update line.

If we're really clever we might be able to improve the image by syncing our updates to the 70 HZ scanning rate, but this would be VERY hard.
Imagine getting an optimized NTSC update rate to 70HZ scanning taking into account that you can't actually update every pixel in 70th of a second, skipping areas that are similar in color to what's already in the buffer, interlacing what you want to update but don't have time for, dithering down to 65536 colors from what? 16 million... And can we assume on an NES that there are no more than 256 colors per 60th of a second? Or how do palettes work? And time averaging what we can on some cycle that takes into account the interplay between 70 updates per second on the screen and 59.94 updates per second on the source.

And we'd need enough memory to buffer the screens for that, and tack that onto the existing emulator.
Sounds like a huge huge job.

[crashoverride]

hould I assume that the channel to the PSRAM is as slow as the one to the screen?

The internal flash and PSRAM share a single SPI bus. This bus is currently operating at 80Mhz. It was previously limited to 40Mhz in older esp-idf versions (pre 3.1). The ESP32 executes instructions "in place" (XIP) from the flash. The implication is that while fetching instructions from flash and data from PSRAM, there is effectively half the bandwidth since they share a bus.

Does this mean that PSRAM is read and written at 80MHz which is twice the speed of the screen?

The LCD and SD card share a single SPI bus. The LCD operates at 40Mhz and the SD card operates much slower (around 25Mhz if I recall correctly).

That probably would be too slow to hold a screen buffer, even at a byte per pixel. If you saved ram buffer out to PSRAM and read it back in once per display, you'd used up half of the RAM channel bandwidth on that.

The accumulated bus traffic of fetching instructions, writing to PSRAM, and reading from PSRAM makes external PSRAM unsuitable for high performance framebuffer use in testing I performed. Currently, all emulators use internal RAM for their framebuffer.

In any case there's 456k of internal SRAM that isn't cache that's available for use in programs AFAIK.

In practice the main issue I have encountered is memory fragmentation. Although there may be enough free memory, it is often too fragmented to allow a single large allocation. I recently addressed this issue by developing a scatter/gather technique where framebuffers consist of many small allocations rather than a single large one.

Is "a few write errors" ok?

80Mhz sounds like it'd be pushing it. Maybe worth a shot, but I don't imagine @crashoverride hasn't already tried that

You can experiment for yourself by changing the following line in code:
https://github.com/OtherCrashOverride/g ... play.c#L31
As mentioned before, there are no usable values between 40000000 and 80000000. While a value in the range will not cause an error, it will be rounded to either 40Mhz or 80Mhz by the esp-idf SDK.

[JoshS]

"The internal flash and PSRAM share a single SPI bus. "

1) Wait, so we have a 240 MHz processor running off a program that's coming from 80 MHz SERIAL bus memory, so, for instance, if instructions are 32 bits on average then that's 2.5 MHz instruction fetch? Is that it?

2) I see an 384k internal ROM and 64K internal ROM banks listed. Are those ACTUAL ROM, ie that's not where we put any of our own code? Or is that the internal flash that's for user applications? Maybe 64k is boot code and 384k for user? And that's on a 80mhz serial connection? That makes no sense if it's internal.

3) Where is "internal flash", how big is it, and is there an instruction cache? Is that unified with the PSRAM cache? (once again remember all my questions about that?) If you want to run a loop fast, do you have to explicitly copy code into internal RAM and run it from there?

This is beginning to sound so slow, I'm amazed it's running what it does! I'm feeling a lot of disbelief.

[crashoverride]

Sorry for the use of 'bad' terminology. The SPI flash is indeed 'external' to ESP32. My use of 'internal' refers to 'internal to the module'. Early prototypes had an external flash placed outside the module.

The image shows 3 chips: ESP32, flash, and PSRAM.

With that clarification:
1) The external flash uses the MMU to transparently map and cache it in memory. Code can execute from the memory mapped flash or instruction RAM (IRAM). Consult the ESP32 documentation for details on IRAM and data RAM (DRAM).
2) The internal ROM is Read Only Memory. It is factory programmed and can not be altered. The internal ROM does not use the SPI bus.
3) "internal flash" is internal the module and is 16MB in size. I do not have any details on cache usage or arrangement in ESP32. For "fast loops" or code that needs to execute when flash is disabled, it should be placed in IRAM. This can be accomplished using the "IRAM_ATTR" compiler attribute:
https://github.com/OtherCrashOverride/g ... cpu.c#L354

Code: Select all

int IRAM_ATTR cpu_idle(int max)

This is beginning to sound so slow, I'm amazed it's running what it does! I'm feeling a lot of disbelief.

The ESP32 is an embedded micro controller. It shares many of the constraints of similar products in this class such as ARM Cortex-M0.

[JoshS]

The code in the emulators' loops, is it all IRAM_ATTR? If it's not and the emulators aren't running too slow, then there must be good code caching.

How about the screen kernelling loop?

Though that sounds unlike as there are only 2 32K caches mentioned.

[crashoverride]

he code in the emulators' loops, is it all IRAM_ATTR?

Only a few sections are in IRAM. This can be seen by running 'grep' for the term "IRAM_ATTR."

How about the screen kernelling loop?

The display driver code is bottlenecked by the LCD's SPI so it is not in IRAM.

which has the advantage of a touch screen, a fast 4 core processor and a gig of RAM. But the parts for that run $140.

The ESP32 was never intended for game devices. It does not have any support at all for graphics. It is actually quite a complement that ODROID-GO is constantly compared to much larger (architecturally) and costlier devices.

[JoshS]

I know it's lazy as hell for me to ask this here, but ok, I'm lazy.
I've done Ardiuno development before.
What do I need to download if I want to play with rebuilding the NES emulator (and the rest of the emulators), enable an FPS display on each (there IS one already, I hope), build it into the full game firmware etc.?
Including dev tools and libraries etc. Ie, just say I'm impatient and I want to jump into this without spending a hours Googling.

I got my ODROID, I love it. But I suspect that a faster display would help with harder games like Ghosts & Goblins (my nemesis)

[Cwiiis]

I know it's lazy as hell for me to ask this here, but ok, I'm lazy.
I've done Ardiuno development before.
What do I need to download if I want to play with rebuilding the NES emulator (and the rest of the emulators), enable an FPS display on each (there IS one already, I hope), build it into the full game firmware etc.?
Including dev tools and libraries etc. Ie, just say I'm impatient and I want to jump into this without spending a hours Googling.

I got my ODROID, I love it. But I suspect that a faster display would help with harder games like Ghosts & Goblins (my nemesis)

If you're on Windows, install WSL from the Windows store (I use Ubuntu, but any distro should do really) and follow the instructions for Linux. This works fine on Mac too.

First, you want to install the esp32 toolchain: https://docs.espressif.com/projects/esp ... -toolchain

Then you need to install esp-idf, but you want a particular branch of it. You want to follow the instructions from here: https://docs.espressif.com/projects/esp ... setup.html but you want to download esp-idf from here: https://github.com/OtherCrashOverride/esp-idf

At this point, if all has gone well, you should be able to build all the various odroid-go projects. The emulators are here: https://github.com/OtherCrashOverride/go-play - you can run make in any of the emulator subdirectories and then run the flashapp.sh script to flash it on the device, assuming it's already got the emulator menu installed (you may need to edit it and change the serial device, depending on your setup. For me on Windows/WSL, for example, it's /dev/ttyS4).

You may also be interested in my branch of go-play that has improved screen update code (but only unscaled on the NES right now) here, but it's very work-in-progress: https://github.com/Cwiiis/go-play/tree/ ... al_updates

You'll need a reasonable working knowledge of Unix terminals and git for this all to be easy to follow.

[JoshS]

cool cool cool
what about an FPS display?
I can't use WSL because I use VMWare and the Microsoft hypervisor system doesn't allow 3rd party hypervisors to run once the driver is even enabled (they should be sued for locking out competition this way), but that means I already have linux on my computer.
I'm looking forward to this.

[JoshS]

@Cwiiis when I got to the step where the instructions say to run:

Code: Select all

git clone -b v3.1.1 --recursive https://github.com/espressif/esp-idf.git

I substituted:

Code: Select all

git clone --recursive https://github.com/OtherCrashOverride/esp-idf

but that returned this error:

Code: Select all

user@ubuntu:~/esp$ git clone --recursive https://github.com/OtherCrashOverride/esp-idf
fatal: destination path 'esp-idf' already exists and is not an empty directory.

...
Apparently the previous stages had already created that directory.
So I'm going to rename the existing directory and try again... I guess that's the thing to do.

[millim]

Dear all,

I agree with all your statements and I want to share my view on this. Still, I think I am two years to late to provide here more relevant information for the OG. However..

I think to eliminate tearing there are a couple of things to consider. I had a bit deeper look to the ILI9341 datasheet to check what can be done. I think two things need to be achieved:

1.) First the SPI writing speed to the display needs to be at least half the refresh frequency of the display. The datasheet reads values between 61Hz and 119Hz on the refresh rate. The maximum SPI writing speed is linked to the clock frequency of 40MHz what gives maximum programming speed : 40MHz/(16*320*200) = 40Hz. This assumption would fit when the refresh rate is set to values below 80Hz.

2.) Programming and refresh need to be synchronized. Here the Get_Scanline (45h) command can be used to detect the refresh cycle state of the display. In case the ratio of refresh rate to programming speed is close to 2 (80Hz/40Hz=2).Let's call this tearing ratio. It will be difficult to synchronize because there is a jitter time lag between reading the Scanline position and the actual instant the programming will start. I think this jitter is difficult to control.

3.) Display update directions need to be inline in geometry. The display refresh cannot be changed. it is always from left to right on the OG meaning in portrait display direction top-down. In case programing update is done in landscape direction (top-down on the OG). One will always see diagonal tearing effects. There is a setting on the ILI9341 to change to programming direction.

So what can be done to get it done?

1.) First finding a way to decrease the tearing ratio.
A.) increase the programming speed to 80MHz and/or
B.) reduce the display refresh rate down to a certain value without creating visual effects.

On A.) I have tried 80MHz SPI, it does not work out of the box. Indeed it works to program the display with that speed, but I think my current driver is not capable to prepare the data on that high speed. Next, I will try to program in bursts of 5 lines, providing row and column address in every burst transmission. If this does not work, I see it as a dead end.

On B.) play with the clock divider settings DIVA (fc/2). My first test failed, display stays grey. I did not check on timing violations since here the programming speed is higher than the refresh rate. Or it is connected to the 61Hz and 119Hz spec data? I don’t know. Still I think the refresh rate can be influenced by the back/front porch settings (VBP, VFP). By setting this to higher numbers, I see different tearing patters on the display. So, according the datasheet, indeed it influences the refresh rate.

2.) Secondly, finding ways to synchronize programming with display refresh
A.) Add device reading to the display driver. There is idf_esp example available how to do it ( device ID reading) and. However, the OG has the SPI_MISO interface not routed to the display. There is basically no direct way to read display status or registers -> dead end.
B.) Measure, evaluate and compensate the timing jitter. Difficult, because on A.), display reading is not supported.

So before programming the next frame onto the display, the scanline is checked. In the simplest case let's assume zero jitter, when the scanline crosses zero (a new cycle begins) the SPI programming starts. The more jitter is measured the more the scanline number needs to be backoff.

I think all this will eliminate tearing on the OG, with some limitations on maximum framerate / refresh rate. But, as it looks like, basic functionality for this concept is missing on the OG.

Any remarks or suggestions?

millim

[lordhardware]

Hi,

Currently there is no way to compare scanline read to this display as the display is only one way.

Because you have no reporting FROM the display to the device, changing settings against the driver won't provide you with any more data.

What would be helpful is a way to tune the display hz in increments with some sort of pattern display, then you could find the best speed for your particular display panel (as there will be minute timing differences for all models) then if those interval settings could be setin a program you'd have a better experience.

That said, because the first read from the display, and the first write from the ESP are not synced, you'll still have tearing, you can only reduce the likelihood, not the event.

[millim]

Hi,

yes true, display is write only. So, basically there is no solution.

Still, I do not understand why the display reading was omitted by design? Ok, in case of limited pins it would have been possible to share SDI/SDO by proper hardware interface configuration on the display. These pins are not accessible, either.

However, reading the sync information is one thing, the other one is the emu synchronization to the display, what is also tricky. If not properly done, it puts additional burden on the CPUs hitting other problems.

millim

[crashoverride]

I do not understand why the display reading was omitted by design?

The LCD display never had read support because there was nothing to be gained from it at the time, and it would never be used (initially GPIO pins were very scarce for reasons not worth going into). The SD card was an "11th hour" feature. Originally, the device was intended to be re-flashed via USB-UART. At the time, esp-idf did not support sharing a SD card with anything else on SPI. So, you could have a display or an SD card, but not both. I managed to "hack" the SD card sharing functionality, and the SD card interface was added just prior to production. Therefore, when the SD card interface was added, the LCD read line was left unused.

ODROID-GO was "state of the art" at introduction. It pioneered the use of LCD+SD card SPI sharing for ESP32 as well as self-flashing from SD card. In retrospect, it seems unlikely that a LCD read pin would have changed anything during its product life.

It should be possible to test the theory that using "Get_Scanline" could be used to avoid tearing by using an ESP32 devkit and attaching an ILI9341 display. Both are readily available from multiple sources, and the ODROID-GO schematics and emulator source code are public.

[mad_ady]

Interesting history. The Go would have been much less successful without an sd card...

So, if a read pin is available from the lcd, presumably it could be wired to an exposed gpio pin on the header with a hardware mod, right?

[crashoverride]

So, if a read pin is available from the lcd, presumably it could be wired to an exposed gpio pin on the header with a hardware mod, right?

I do not know if the read pin is even exposed on the LCD cable. Somewhere on this forum @odroid made a post showing the original ODROID-GO design. It was very different from what would become the final product. The early version shows that the LCD was already selected, no SD card is present, and the mystery of where all the GPIO lines went is evident.