Somewhat related question

Hello, let me start by saying that my question is only tangentially related to your project, so I'll understand if it's deemed inappropriate here.

In short, I bought a PCB800099 V.9 LCD controller on AliExpress, but it turns out the firmware that comes with it doesn't readily support the screen I'd like to drive. The screen's resolution is 1600x1200 and it has 2 channel, 6-bit color LVDS interface (30 pin). The PCB800099 version that I got has configuration jumpers, with options that can be seen e.g. here. Unfortunately, 1600x1200 is not listed. The closest resolution is 1600x900(jumpers A+6+2 as listed in the table). As expected it sort of works, but of course the image is compressed into the top 3/4 of the screen.

I also tried this alternative firmware. There are probably subtle differences between the boards because while the vsync is now correct, the colors are wrong. There is some sort noise/glitching too, so something is definitely off. You can see how it looks here.

As far as I can say from your public repos you seem to have long standing interest in RTD2662, so I decided to ask for your advice. Do you know if there is an easy fix for this issue. Or if I decide to take the long(er) road do you know if there exists any tutorial on how to set toolchains for compilation. I read about some proprietary Windows-only compiler that can be used to compile leaked firmwares, but I'm not sure what firmware and which version of the tools(assuming they are even freely available) can be used. And then I wouldn't know where exactly the modifications should be applied.

From your Makefile, you are apparently using 'sdcc' which I see is available in Ubuntu's repos already. What do you think would be the path of least resistance to solve my issue? Do you think your free firmware can serve my purposes? I'd like to have access to at least basic controls like color temperature, contrast and brightness, even if that means recompilation/re-upload.

Also do you know of any forums where people interested in hacking these chips/boards gather?

Thank you!

Hi, 'The path of least resistance' to get your display to work would probably be:

Try out ALL the available firmware images.
If that fails, find the EDID data (search for 00 FF FF FF FF FF 00 header) for 1600x900 mode in the dump of your original firmware and patch it for 1600x1200 timings (you can use AW EDID Editor).
Compile the leaked firmware using Keil uVision (which is freely available... on the high seas), though I did not have much success using the resulting firmware.
Finally, you can attempt to use this firmware, but it's mostly incomplete only managing a basic HDMI/DVI picture output (no temperature, contrast or brightness, not even automatic backlight shut off) with manual adjustments, you will also need to manually fill out the pins of PCB800099 in board_config.h (from leaked sources or by using a multimeter) and edit the panel_config.h with your panel timings (from datasheet or by trial and error).

As far as I know the colour issue is due to either VESA vs JEDEC bit-order difference, or 8 vs 6 bit misconfiguration, or maybe something else. You can try to manually change the configuration of the scaler to figure what it is, by using scripts/i2c_iface.py:

git clone https://github.com/KerJoe/RTDMultiProg.git
RTDMultiProg/rtdmultiprog.py -i i2cdev -l # Find on which I2C port the RTD2662 is
git clone https://github.com/KerJoe/ORTD2662.git
cd ORTD2662/scripts
nano i2c_iface.py # device = <i2c port>
python
>>> import i2c_iface
>>> i2c_iface.scaler_write(0x29, 0b00000000) # S_VDISP_SIGINV = 0
>>> i2c_iface.scaler_write(0x29, 0b00010000) # S_VDISP_SIGINV = PANEL_SWAP_BIT_ORDER
>>> i2c_iface.scaler_write(0x29, 0b01000000) # S_VDISP_SIGINV = PANEL_SWAP_ODD_EVEN
>>> i2c_iface.scaler_write(0x29, 0b01010000) # S_VDISP_SIGINV = PANEL_SWAP_BIT_ORDER  | PANEL_SWAP_ODD_EVEN

As for the community, I don't seem to find anywhere where there is much discussion about this controller. The only place I know is this Discord server and even that is pretty dead.

Personally, I am pretty much burned out from working on RTD2662, so don't expect much from me. I do, off course, welcome any good contribution to the firmware development, and would gladly share what I know.

P.S. Notes for Makefile in ORTD2662:

Run make firmware to create a flashable bin file
Run make program to flash firmware using RTDMultiProg on path ../RTDMultiprog/rtdmultiprog.py
Run make native to compile a program running on your computer and communicating with the scaler via I2C (for full featured debugging).

Thank you very much! I didn't even dare to hope for such a detailed answer- really appreciate it!

Try out ALL the available firmware images.

Unfortunately I couldn't really find any other 1600x1200 image except for one that is supposedly for 8-bit LVDS. You are right though, I could still try it- even if it's really for 8-bit color, it may still work if it uses the LSBs-on-the-4th(JEIDA I think) pair format.

If that fails, find the EDID data (search for 00 FF FF FF FF FF 00 header) for 1600x900 mode in the dump of your original firmware and patch it for 1600x1200 timings (you can use AW EDID Editor).

From what little experience and observations I have, it seems to me that EDID is not really the problem. As usual, it just instructs the video source about the timing it should use. At least in Linux there are other means to achieve this, so having the right EDID is a nice convenience but not strictly necessary to configure source's timing.

The problem with the original firmware that came with my PCB800099 seems to be caused by the mismatch in scaler's config. Take, for example, the screenshot I posted yesterday: it shows the original 1200 lines squeezed into the first 900 lines of the display, then some black lines(likely for the vertical blanking, according to the scaler, but not to the source) and then again the upper part of the input video for the remaining portion of the screen.

I don't have any idea about the internals of RTD2662, but what I see seems to be consistent with the following hypothetical architecture (pure speculation on my part):

the incoming video is interpolated by the scaler subsystem and writen to some sort of frame buffer
the LVDS output subsystem reads from that buffer, going to row 0 in 2 cases: a) when the configured max row count(in this case 900) is reached or b) when it receives VSYNC from the video source. That is it seems to me that the output-to-LVDS is synced according to the input signal, and because in this case I'm using the xrandr method from the link above with 1600x1200 CVT, the vertical sync is fine. Not the scaler's output, though. If there is no input signal, only the first 900 lines of screen are used(no duplication in the last lines), e.g. when OSD menus are rendered.

As I said this is pure conjecture at this point, do you know if that's right? Are there alternative explanations for that screenshot?

Compile the leaked firmware using Keil uVision (which is freely available... on the high seas), though I did not have much success using the resulting firmware.

This doesn't sound too encouraging :)

Finally, you can attempt to use this firmware

I may as well at least try it. In fact I tried to compile it yesterday the compilation went fine and the firmware image was produced. Haven't tried to modify it yet, because I don't have much time today.

As far as I know the color issue is due to either VESA vs JEDEC bit-order difference, or 8 vs 6 bit misconfiguration, or maybe something else. You can try to manually change the configuration of the scaler to figure what it is, by using scripts/i2c_iface.py:

Thank you for pointing this out. I didn't realize the settings can be changed at runtime, and this may prove to be very helpful. By skimming the only doc I managed to find about RTD2660/2662 internals I see for example various options for changing the vertical scaling parameters. I wonder if it would be possible in addition to your suggestion on trying to transpose colors etc, to try and fix the scaler's output for the original firmware...

As for the community, I don't seem to find anywhere where there is much discussion about this controller. The only place I know is this Discord server and even that is pretty dead.

A pity- I wasn't able to find any such forum as well.

Personally, I am pretty much burned out from working on RTD2662, so don't expect much from me. I do, off course, welcome any good contribution to the firmware development, and would gladly share what I know.

If I decide to work on driving LCDs I may opt for something FPGA-based, instead. The situation with these scalers is pretty depressing, I find. I tried 3 scalers so far (different chips):

the first one shows a few frames, then freezes and first the corners and then the whole screen starts to fade to completely black. Perhaps some sort of (temperature) protection is triggered ... who knows
the second one shows the OSD alright, but as soon as you plug the cable it likely overheats and shows nothing. The chip is very hot despite having passive cooling radiator.
and now we are thinking hard how to trick PCB800099 to do something useful :)

In summary, as I understand it, we have chips that tend to easily overheat, are poorly documented at chip level(thanks to leaks) and not documented at all at board/schematics level, with not too flexible default firmware, weird proprietary Windows-only compiler, update process shrouded in secrecy, and virtually non-existent community. I wonder why anything better hasn't emerged so far... Or perhaps it exists, but I'm just no aware of it.

Anyway, I'll try stuff and if there is any progress or anything interesting to share will do so here.

Thanks again!

Yes, you are correct changing EDID and thus the incoming signal would not fix the squishing problem. Sorry.

I also want to warn you that changing scaler registers at runtime locks up the MCU, so no backlight shutdown or video restore after signal loss.

I do still look forward to you trying the i2c_iface.scaler_write commands I've written in the first comment.

Hi again, happy to report that following your suggestion I now have a workable solution.

At first I've tried the VDISP_SIGINV tweaks, but unfortunately it seems that there is something else going on too, because while the color pattern changed the colors were still not right. At least these experiments made clear that the "noisiness" I observed with the 6-bit firmware is due to temporal dithering being turned on, while the bit order was reversed. Toggling of the LSBs may not be noticeable for most people, but for MSBs it would be hard to miss.

I tested a few more settings, but decided that before going overboard with that, I may as well try the 8bit image. And to my surprise it actually works perfectly fine. Haven't had much time to probe how these firmwares differ, but there is not much point spending time on this too.

It's still a pity that the MCU shuts down when you make manual changes, though that's perfectly understandable and indeed natural from design point of view when someone is making changes "behind your back". I guess there is no way to turn it back on, after you do your changes? Is there at least a way to turn the panel/backlight off programmatically(that could be helpful in case one would like to tweak something, and is willing to manually handle sleep/wake-up events from the operating system).

BTW when you said you weren't successful with the compilation of the leaked firmware, what didn't work exactly? Did it fail to boot at all, or it was 'just' not working quite as expected?

The MCU seems to always reboot the moment you leave the ISP mode, and it's not the Watchdog timer as it's disabled in ISP mode.

The extended GPIO ports (A, 9, 8, 7, 6, 5) can be freely changed via I2C interface:

python
>>> import i2c_iface
>>> i2c_iface.xsfr_write(0xCB, 1) # Extended I/O # Set Port 6 Bit 4 to 1

But the output value of GPIO ports connected to 8051 MCU (3 and 1) cannot be altered via I2C. You can however change PIN_SHARE_CTRLxx registers to indirectly change the output state (e.g. changing open collector output with low state, to high by going from open collector mode to input mode).

I can't quite remember what the problem with the firmware was, maybe it didn't compile, maybe it didn't setup the scaler correctly, probably the latter.

Thank you very much for all your help!

This info about the GPIOs can come very handy at some point.

Closing this issue...

KerJoe / ORTD2662

Somewhat related question #1