Please recommend a VGA to parallel LCD board or IC

[DC1MC]

Hi Albert, there is no github (as it was practically no interest to make a community project out of it and build an 'universal" analogue display replacement    ).
Also the Keil C51 tool is mandatory, SDDC will not do it and most of the TEA here want to have their CRTs,  because "period authenticity" 
And while the code in some of these collected attempts is organized OK, it does need some programming dedication and effort, no many having the knowledge and interest to contribute.

But if you can get the Keil uVision C51 FULL environment and want to spend some time digging and organizing the code, I may come out of my slumber.
Here in DE is not even possible to torrent the pirated version, or the specialized copyright lawyer firms will dezintegrate you.

So basically that would have been my e-mail content.

 Cheers,
 DC1MC

[Tantratron]

The most cost effective board to play with, is IMHO this one:
https://www.ebay.de/itm/HDMI-VGA-AV-Control-Driver-Board-8-inch-HE080IA-01D-1024-768-IPS-LCD-Display/353127261573

There are a lot of sellers for this configuration, the 8" display is 4:3 and it will definitely fit nicely to my first victim experiment subject: a Tektronix AWG520 on its way to me. Also in many other TE with CRT displays and VGA interface.

Could you provide a clear description of this board, reference, picture because your ebay.DE link has expired ?

Merci, Albert

[DC1MC]

That's the board:
https://www.ebay.de/itm/126507610141

and that's the panel:
https://www.ebay.de/itm/387084300831

And that's a board with panel, that is still the most cost effective complete option  :
https://www.ebay.de/itm/145293201205

IMHO, if you have some existing LCD and good soldering skills it's worth taking the board only first and see how you deal with the software, even if you just print over the UART the signal parameters and if it is synced, also one can look at the TTL outputs as well (they're pretty distinctive) or even LVDS.

BTW, a kind, but anonymous, soul shared some Keil stuff with me (to my happiness and surprise it works quite well in Linux under Wine  ), so if there is enough interest and partners in "crime" we can un-burry the project and do an affordable and configurable multi-input driver board for LCD panels to replace these old tired or dead CRTs and early LCDs that expired.

Also if you go on this path, don't waste any time, or effort, with the stupid I2C master programmer over VGA EDID port, this is the least of your concerns, you need one of those el cheapo SPI flash programmers for direct programming of the flash, there will be A LOT of tests and attempts, I can tell you that. We can put this software module back for the final version.

Cheers,
DC1MC

[DC1MC]

So, rummaging tough my boxed I've found two of the boards I've used for testing, I'm posting here the actual pictures (and maybe latter ad a schematic if I can find it) of the one suitable for the AWG and another member put it in a TDS series cope.

Strangely enough  the board seems to still work OK and it uses @5V 500mA in operation and 130mA in stand-by, I think that the power supply can go up to 12V but 5V is a safe option.

Cheers,
DC1MC

[DC1MC]

So here's someone using this board:

The blog post:
https://www.mattmillman.com/info/lcd/pcb800099/

The source GIT hub:
https://github.com/avtehnik/RTD2662
(Which BTW compiles properly !!)
GENERATING STANDARD (UN-BANKED) OBJECT FILES
  OBJECT FILE FOR BANK 0:  .\OUTPUT\RTD2662.B00
  OBJECT FILE FOR BANK 1:  .\OUTPUT\RTD2662.B01
creating hex file from ".\Output\RTD2662.B00"...
creating hex file from ".\Output\RTD2662.B01"...
User command #1: Merge128K.bat
".\Output\RTD2662" - 0 Error(s), 13 Warning(s).
Build Time Elapsed:  00:00:12

Some VERY important resources:
https://www.kolins.cz/share/index.php?dir=RTD2662/


Some HW related stuff on this repository:
https://github.com/a-c-t-i-n-i-u-m/lvds-firmware/blob/master/documents/Specification%20of%20PCB800099%20Controller%20Board_V1.0.pdf
(pinouts, voltages and some electric parameters - it does indeed accept 12V supply)
https://github.com/a-c-t-i-n-i-u-m/lvds-firmware

And finally if someone from China or with a CSDN subscription the full kit could be downloaded, including schematic:
https://download.csdn.net/download/weixin_42118770/16084415?ydreferer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8%3D


I think that actually for most of the stuff a board schematic is not really necessary, most of the stuff is on the same pins and the FW source code refers them.


So this is what I have for you, the PCB800099 is a venerable but still going strong design and the chips are still available, so I think is still future proof for a number of years and someone can stock on them, they're really cheap.

Cheers,
DC1MC

[Tantratron]

Hello DC1MC,

Many thanks for all the information, pictures, analysis and suggestions.

For the moment, I've few boards based on RTD2660 (Realtek), one with RTD2280 (Realtek) and one with MST703 (MStar) plus 3 models of LCD displays, see attached pictures.

The PCB800099 you mention seem to come through different root version where they limit either to LVDS drive or TTL drive. One of my board is PCB800196 (LVDS output only) which is then transformed by TCON to make TTL. I'm waiting for another board with RTD2660 which does only TTL, this board should PCB800808.

I was not happy to test and run the board with MST703, it is not clear if this processor does on same chip LVDS and TTL but looking for files or Github repo, it seems almost not documented. So I think your wisdom advice to only focus on PCB800099 is the right path except this model seem to report some issues from the russian website you mentioned before. In my opinion, maybe it is best to rather think in terms of panel processor, for instance RTD2660 then the rest is really PCB trace routing, voltage, signals, firmware loading. The key point would be to focus and master how to program this RTD2660 (generate a BIN firmware for our chosen application) then the rest should follow quite easy.

The RDT2280 does not generate LVDS and again the MST703 seems more esoteric. There are much more information about the PCB800xyz (schematics, bin files) plus the chip really does hybrid possibilities: the pics can be configured to LVDS or TTL including modes of 6 bits or 8 bits per channel.

As for the 8051 development tool, if can we program say in C then compile, no idea because I'm learning this RTD2660 path and what is required. So far I use MacOS to program my other stuff but my plan is to install either Windows or best go after Linux. Most compilers do not exists for MacOS so I need to open these SDK possibilities.

As for my soldering skills, it is no problem (i.e. flux, quikchip) neither an issue. In fact I plan to physically hack the traces, connectors of one RTD2660 driver to make it work with the 5.7" display.

The real difficulty seems so many github with partial information on HW, SW so that could be serious task to make it simple and global.

Warm regards, Albert

[DC1MC]

So, just a couple more words, mostly all that I want to beat this    TL;DR at the end:

- The PCB800099 that I've posted has BOTH TTL (at the FPC connector) and LVDS outputs (at the pin header), there is nothing intrinsically limiting to only one option in the SW, is just nobody wanted to bother doing a flexible LDC interface, both parallel and LVDS, they usually generate a FW for a specific LCD panel sold with it and that's it, the input signal module remains the same and maybe they fiddle with the i2c loader to hinder "foreign" FW loading and the  localization of OSD.
One of my ideas was to add service menu to select settings for different models of LCD and have a passive adapter board between interface board and whatever FPC different panels have, a simple JLPCB project that could accommodate a a lot of FPC connectors, but this is actually of low interest, mostly nobody cared.

- The firmware from the git is pretty close to the original Realtek SDK, just customized for a vendor panel, actually inside there are lot of predefined LCD panels, very easy to select in the source code by a simple #define ...

- The same firmware builds and creates a runable binary that should just be copied in the flash and that was it. It does have to be build with the Keil IDE, because is full of their proprietary extensions and to be honest SDCC and other OSS tools are not holding a candle to it, Nuvoton for example decided to make a deal with them for a custom version supporting their MCUs, one because the generic version is freaking expensive and two is also is the best, and they are not the only vendor doing it. So is either the Keil uVision, or the existing source code is(almost) useless, no reasonable effort possible to port to OSS toolchain.

- The only "research" that needs to be done is to build a "pseudo-composite" analogue signal following the standard blank and sync levels for mono CRTs (I think it can be done with a mostly passive resistive summer for B/W) and use the VGA input for the analogue color signal, of course with suitable levels and polarity.
Other think is to set the frame geometry in the SW, along with the pixel clock, so a non standard frame is not discarded as defective, but forwarded to the LCD driver block.
In the happy situation that the frame geometry can be mapped to an existing LCD panel directly, with only some borders for centering, we are gold.
In case scaling needs to be done the situation may become more hairy or fuzzy  , in case of fractional scaling.

TL;DR:
- Select suitable panel (close to an integer multiple of signal resolution that needs to be displayed),
- Obtain&install Keil development IDE
- Set or define the LCD parameters and build a FW, testing it with standard input signals.
- Build adapters for either composite (B/W) or VGA (color) levels depending on the instrument output.
- Try first with the default settings and fiddle with the input block until the frames are accepted and forwarded to the scaler.
- Fiddle with the scaler until frames are nicely centered and/or scaled.
- Fiddle with the OSD functions (if needed).
- Fiddle with the FW downloading over the I2C pseudo-device.

Simple, no  ?

All we need now are enough people interested to sponsor the project, either donating their time and expertise, or money to buy that time and expertise.
And this is where I've stopped initially, because this is not really a "one man project", or if it is, I'm not this man, it looks very like real work and a 20K+ multi-mode consultant project with a bit of a niche application and I'm not that full of cash and time to donate it all, I need serious actual support if leading such a project, but I can still contribute a bit of expertise for free or low-cost if some one else decides to take it.
Who ever is willing to sponsor/support this project, or start a successful Gofundme has my full respect and if needed my cooperation.

Cheers,
DC1MC

[Tantratron]

So, just a couple more words, mostly all that I want to beat this    TL;DR at the end:

- The PCB800099 that I've posted has BOTH TTL (at the FPC connector) and LVDS outputs (at the pin header), there is nothing intrinsically limiting to only one option in the SW, is just nobody wanted to bother doing a flexible LDC interface, both parallel and LVDS, they usually generate a FW for a specific LCD panel sold with it and that's it, the input signal module remains the same and maybe they fiddle with the i2c loader to hinder "foreign" FW loading and the  localization of OSD.

You use few acronyms, I'm not native english speaker, what does it mean TL DR ?

As for the PCB800099-V9 it is strange because your version seems similar to mine (see attached pictures) but in my case, there is a 11 jumper which allows by HW jumping to select different LCD's model (allocation table I've found on internet). The problem I have with this specific board, first the panel processor chip marking has been sanded, probably a RTD2660 no idea BUT the real big problem, it really overheat in no time.

Do you know why both boards (yours and mine) have the same name and version, this is wierd ?

What is the reason of sanded or removed chip marking ?

Any idea of its overheating, how about yours ?

When I mentioned my PCB800099-V9 could be a problem, this is the russian or ukrainian post after translation http://pccar.ru/showthread.php?t=22851, see end post #1

People, take it as a warning. From 10/22/2021
On Aliexpress, when ordering a people's controller, almost all sellers send its new version. I even heard that it is now very problematic to find the usual version.
The new one looks like this: It differs in the organization of the power supply reduction (+3.3V - now DC/DC does not heat up, as it was with LM2576ADJ), the presence of a jumper comb, with the help of which the required resolution is selected and the ability to power the matrix with a voltage of +12V. The +5V power supply is not provided on the board - there is no such source on it. Here is a table of jumpers with the correspondence of resolutions: The jumper positions are written on the back of the board and each position looks like this: "A, 1, 2....9, 10". As you can see, not all resolutions are available. At least I did not find the most common 1366*768 8 bit 1 channel (S8 - single 8 bit). I tried on the corresponding matrix - there is no such. THE CONTROLLER NO LONGER REQUIRES FIRMWARE!!!

Since the controller version has the same name as the old one, I tried to upload the firmware from a regular user. Unfortunately, the controller does not start and goes into a bootloop. Connecting a capacitor with a capacity of 220-470 μF to the existing place for filtering +3.3 V helped. However, this only helps when using matrices that are connected to the "TTL" connector. When connecting matrices to the LVDS connector, the startup level at the BLON backlight control output simply jumps once a second. When accidentally touched with a metal object, I can't even say what exactly, the controller comes to life, but after going through sleep mode, it falls into a stable bootloop upon awakening.
So if anyone plans to use the ancc firmware, this version of the controller will definitely not suit you (unless, of course, Andrey studies this board and writes his own software for it).
Moderator, please put this in the header.

[Tantratron]

- The only "research" that needs to be done is to build a "pseudo-composite" analogue signal following the standard blank and sync levels for mono CRTs (I think it can be done with a mostly passive resistive summer for B/W) and use the VGA input for the analogue color signal, of course with suitable levels and polarity.

Another topic regarding the RTD2660, it seems its datasheet says de-interlacing is possible (see attached screenshot of both RTD2660 and MST703 datasheet).
Do you know if this chip can really de-interlace RGBS signals to avoid using an CGA/EGA Arcade converter ?
I ask because this converter (see attached picture) does a well job to transform an old RGBS interlaced but obviously uses an additional memory besides its MS1820 core processor.

[Tantratron]

- The firmware from the git is pretty close to the original Realtek SDK, just customized for a vendor panel, actually inside there are lot of predefined LCD panels, very easy to select in the source code by a simple #define ...

- The same firmware builds and creates a runable binary that should just be copied in the flash and that was it. It does have to be build with the Keil IDE, because is full of their proprietary extensions and to be honest SDCC and other OSS tools are not holding a candle to it, Nuvoton for example decided to make a deal with them for a custom version supporting their MCUs, one because the generic version is freaking expensive and two is also is the best, and they are not the only vendor doing it. So is either the Keil uVision, or the existing source code is(almost) useless, no reasonable effort possible to port to OSS toolchain.

Could you remind or show exactly which GIT web link points towards that specific software ?

Thank you, Albert

[DC1MC]

-  TL;DR Too Long; Didn't Read

- The repository is the one from reply #29 - https://github.com/avtehnik/RTD2662 - this is the one that I've recompiled, get the source and have some fun with it , look inside at the directory Panel where there are defined A TON of different LCDs (TTL and LVDS) and one can get an insight on how is done.

- Your board seem to be an "enshitified" version, in the Chinese world the PCB800099 is the gold standard (most likely based on the  SDK reference design), all the other crap with lasered ICs is most likely something using dodgy reject parts, RTD2660/2 is a venerable IC there is no competitive advantage in hiding it.
I have tested my board from 5V to 12V, no overheating problems, so I suggest finding one that looks the same. Or also very likely, is a "castrated", low-cost versions of the full chip, why put the analogue block when no one uses it and get extra 0.3 cents per chip.
This is why I've said, if it's not a "one-time project", a suitable vendor should be found, verified and a stock of "real" boards with real chip shoul be made.

- De-interlacing: here I have to look in the data sheet, a quick grep in the source code found this in core/ext_device/video.c gives:
   #if(_DE_INTERLACE_SUPPORT == _ON)
so it seem to be a  build option that can be enabled.

As I've said, get the source code and read a bit trough it, even if no programmer, a lot of comments and explanations (rather rare in a Chinese project) and a rather OK modular organization.
Of course, ideal would be to get the archived from the CSDN link I've posted but until some Asian member jumps to help, is a bridge too far away .

- CVBS signal: yes, seems to be supported as well, looked in the source code, is there, just have no idea where to connect for it, could it be the pins are common with the VGA input ?!?

Cheers,
DC1MC

[Tantratron]

Many thanks, wievel danke, merci beaucoup DC1MC for shedding light and one possible path.

One of the reasons I've got interested in this quest, in advantest yahoo forum there is a brilliant converter kit made by a norvegian called Askild, see the green board in the attached picture. This modification or simple HW hack is about to replace old mono-color CRT found explicitly in R3261/R3361 and R3265/R3365/R3271/R3371 spectrum analyzer by a color LCD-TF display. They share the same old video card, GPU and mono-CRT but thanks for the green converter and some soldering into the logic board, we can actually create a RGBS with 4 different colors (Trace A, trace B, Grid&Text, Markers).

For the moment, the only way to de-interlace the 15 KHz generated RGB is using the red chinese Arcade converter board shown in my attachement. Note that testing with another model called GBS-8200 does not offer a good stable image, only the other model does a good CGA/EGA to VGA conversion. This red chinese RGBS to VGA votes convert at 60 Hz 1024x768 which is probably due to the Advantest GPU firmware (pure 1264x525 driving the CRT electronic board).

With R3261/R3361 then CRT is smaller hence my attempt to test both the 5.6" by Innolux and the 5.7" by AUO, both TTL driven but not the same WLED voltage and driver connector.

With R3265/R3365/R3271/R3371 the CRT is bigger but same analogy video signals as R3261/R3361, this is why the choice of 6.5" by AUO which happens to be the same the TDS500/700 retrofit kit LCD display.

Then of course one challenge to get rid of the CGA/EGA to VGA red board by directly changing the RTD2660 firmware if possible then of course, allocating the right pin out because there no fixed standards to interface with LCD (RGB part, WLED...).

As I've learned at my own expenses with claimed coll PCB8000-99-V9 going hot, as you wrote before a suitable vendor should be found, verified and a stock of "real" boards with real chip shoul be made it is really crucial to find a good LCD driver company because so many copies or issues.

Again many thanks, i'll read, review and try to understand the software in the github repo you suggested as the most  potentially way to go.

BTW. Note that one reason I have now the PCB800196-V6 is it design to offer with humpers a dedicated WLED voltage 3.3V or 5V or 12 V to match the LCD model.

Attached one proof of concept I've done in my lab, another way to go would be FPGA but this requires lot of work as well versus mastering the RTD2660 SDK

Amicalement, Albert

[DC1MC]

Your mod looks pretty neat  , and I think is also doable with the RTD2660 board as it is, no (too much) extra HW (mostly level adjustment), I wish you luck in your endeavor and PM me if you encounter some issues or need support.
Too bad that we can't make it (yet) a project that will bring some cash and/or community, is a bit of a too niche thing and as long as there is an exiting working solution already, there will be even harder to find some supporters  or interested  willing to put work into it .

Cheers,
DC1MC

 

[Tantratron]

Hello DC1MC, to go back on the special case of RGBS 15 KHz (probably interlaced, not progressive).

This webpage https://www.jagdroid.org/video-board-programming-and-modification/ mentions it was done with specific BIN file generated by a russian person whoobsviously cracked the all SDK suite. The same article allows to download the specific BIN file for RGBS 15 KHz so old format, see here https://drive.google.com/file/d/1pCIaI5JJoGDTkbelM74nhIG_RgeddRHQ/view

Do you know if it is easy or doable to direct change or edit the BIN file content to make it 640x480 instead of 800x480 then I'd try to flash one RTD2600 board to see if it works with my Advantest converter output (15 KHz interlaced) ?

Thanks for any guidance and suggestion, Albert

[DC1MC]

Hi, there is NOTHING open on that Russian site, except the name, it is also dead since 4 years, so I assume they're not open for customizations anymore  .
You really need to have the EXACT type of board for which the ROM was made, it seems that I was right in my assumption, the component signal goes over the VGA pins with this white connector, was expecting it.
So, to answer your question, IMHO there is totally not feasible to binary patch the ROM, there are a lot of parameters that are in need of change.
My suggestion is to get the original version of the HW and LCD, flash the ROM and see if the signal is de-interlaced properly, even if the image may be a bit skewed or reduced in size, then as painful as it may be, one needs to do a proper FW, there are no easy shortcuts  .

 Cheers,
 DC1MC

[Tantratron]

Hello again, I've started to read the github repo you suggested before but there is something which I still do not understand.

The description in the github https://github.com/avtehnik/RTD2662/blob/master/README.md says it was created from http://tech.mattmillman.com/lcd/rovatools/
Does this means Matt Millman actually had complete Realtek software dev tool, that he was able to fully compile with C51 development tool any application ?
I did write to Matt Millman but no answer for the moment, my real question is to know if actually Matt succeeded to compile, write, modify a complete SDK able to generate any firmware then the pogrammer (RovaTool). If yes, this would mean that actually the reverse engineering was done in UK and probably done before in Russia https://openrtd2662.ru/

The other question, which person or which company initially designed the RDT2660 based board like PCB800099 ?
Was it chinese company or european or USA company then other chinese stole or copy-cat the design with its variants ?
Are we in an unsual situation say in Europe trying to reverse engineer something designed by China ?

Cheers, Albert

[DC1MC]

Well, in the

https://www.kolins.cz/share/index.php?dir=RTD2662/RTD2660_PCB800099-master

and it seems the most complete set including datasheets and even some information about the PCB designers, the rest of stuff spread around are mods for specific LCDs and input signals, or some other ideas (no blue screen at startup and so on), that doesn't makes them less valuable tough, nowadays when even the most anemic MCU has an HDMI output, or direct LCD interface, there is very little need for these boards anymore and people and knowledge disappears, ROVAtools was last updated in 2014 or so !!!

You may find some answers in the link above, I don't think that any of the existing source tree that compiles, compiles to anything that can't be loaded with ROVA tools or similar, because would have been useless.


 Cheers,
 DC1MC

[Tantratron]

nowadays when even the most anemic MCU has an HDMI output, or direct LCD interface, there is very little need for these boards anymore and people and knowledge disappears, ROVAtools was last updated in 2014 or so !!!

OK now I now see your point if any modern MCU does the job to direct drive any LCD-TFT display versus the RTD2660.

But how about these modern MCU, are they still able say to change resolution or spatial correlate, re-filter the after-effect of say frequency or resolution transform to adapt old 4:3 formats ?

Do you own any TDS500/700 and know about the SimmConn labs LCD retrofit which is really expensive and uses a FPGA. If yes, have you tried to re-use one RTD2660 board (i.e. PCB800099) to directly hack the RAMCDAC of the TDS500/700 then directly drive a 6.5" LCD screen ?

N.B. It is sad to see all these knowledge to disappear even though some old test equipment with CRT's are still looking for LCD retrofit replacement.

Albert

[DC1MC]

Well Albert, IMHO the RTD2660 is currently the best and most affordable solution for the use cases you've mentioned, the problem is no one actually wants to pay more than the cost of the board+LCD and then get the FW for free.
So all the nascent little initiatives to make a bit of cash practically died, and judging of the recent reactions they will stay dead. Or people will use some combination of already existing stuff like you did.
So until some interested person/company shows up with some "Blut des Kapitalismus", the development will be anemic 
I have archived the stuff and now and then give some advice, but that's it.

 Cheers,
 DC1MC

[Tantratron]

I plan to purchase Adafruit FT232H Breakout board then see how I can use it from my MacOS (challenge) so the idea would be to use it either via my programming in C or Python to emulate say a programmer, reader.

Regarding different schematics found on internet (see attached), I'm not sure to fully understand when comparing to my actual driver boards based on RTD2660H. Both clearly confirm the pins for programming via VGA interface, namely SDA (59) and SCL (58) then respectively pins 115 116 117 and 118 allocated to CLK (SCK) SDIN (MOSI) SDOUT (MISO) CE (CS). What I do not understand with the schematics, the chip would SPI serial flash with option of I2C Serial EEPROM. One schematics does not show any EEPROM, do you know what is the use or option for the EEPROM ?

As for the SPI serial flas memory, do you know if it is possible to directl read or program the firmware by attaching the 4 signals or are we obliged to program via the VGA I2C signals which I guess are processed inside the RTD2660 to correctly flash the external memory ?

Say I connect a logic analyzer to te SPI flash memory then boot the RTD2660 board, will I extract directly the actual firmware ?

[Tantratron]

- Your board seem to be an "enshitified" version, in the Chinese world the PCB800099 is the gold standard (most likely based on the  SDK reference design), all the other crap with lasered ICs is most likely something using dodgy reject parts, RTD2660/2 is a venerable IC there is no competitive advantage in hiding it.
I have tested my board from 5V to 12V, no overheating problems, so I suggest finding one that looks the same. Or also very likely, is a "castrated", low-cost versions of the full chip, why put the analogue block when no one uses it and get extra 0.3 cents per chip.
This is why I've said, if it's not a "one-time project", a suitable vendor should be found, verified and a stock of "real" boards with real chip shoul be made.

Regarding this specific board which I did purchase to an individual and instant overheats, today I've decided to scratch whatever was lasered or sanded. It urns out to be some kind of glue where the chip was probably hosting a heatsink glued then removed. No idea but then I did use some chemical, bit too much so it removed the silk marking (stupid of me). So no choice as a last ressource to use lateral spot lighting then best picture with lens, guess what it reads RTD2660 including the Realtek logo.

No idea what sis the difference between RTD2660 and RTD2660H, what is the H for but my other board purchased to serious company uses RTD2660H with no overheat.

What is quite crazy, this board even if overheating partially works when I attach a LCD in LVDS mode (G065VN01-V2) but very unstable. It will not memorize the settings, sometimes will declare no HDMI, sometimes will find VGA then looks for other things, it will self-po the inetnsity meneu or contrast menu, self-change from 0 to 100... this seems similar to what the russian or ukrainian post reported (after translation http://pccar.ru/showthread.php?t=22851, see end post #1)

Anyway unless there is PCB reason explaining the overheat, I'd tend to conclude best to buy a board with RTD2660H instead of RTD2660, for sure not buy a board where we cannot read the chip marking.

[DC1MC]

Just a very quick reply regarding the FLASH situation:

- the flash itself is a SPI NOR, the chip has a SPI interface and it boots from and it can access 128KB using banking.

- the one and only interface of the driver board that can communicate with the external world is an I2C interface that was initially used for the monitor parameters identification (EDID - Extended Display Identification Data)
Full details here: https://www.extron.com/article/uedid
Basically in the beginning it was hooked to an actual I2C EEPROM, like 24L08 holding a few bytes of information. RTD2660 has an software defined "pseudo-EEPROM" for this purpose and to make firmware updates possible it implements another I2C virtual device that is actually and SPI bridge to the firmware, and this is where ROVA tools and all the other improvised "programmers" write their firmware image and is transferred to the SPI flash.

Cool tidbit: in Linux I was able to access it via the VGA connector using and old Laptop with VGA interface (no programming box needed) and I've heard is possible in Windows as well.
 
I hope this clears all the issues regarding the external I2C interface to the SPI NOR flash where the firmware is stored.

Cheers,
DC1MC

[Tantratron]

Thanks for your clear explanation about the I/O and boot memory architecture of the RTD2660/RTD2662. So I guess the first schematic which I posted yesterday with memories (SPI NOR and I2C EEPROM) was an old version, in fact the schematics shows a RTD3580D. I've just found this article by dutch man https://bitbuilt.net/forums/index.php?threads/worklog-documentation-rtd2662-custom-firmware.2841/ which provides anothe rgood explanation of how the RTD2660 works, what the MCU does, the RTD3580D being the scaler processor...

Extract How it works Then there's how the thing works. The RTD2660/2662 works in a specific way. Theres two parts to it: The 8051 micro controller, and the scaler. The mcu is what's running the firmware, where all the main routines / logic runs, and it manages all GPIOs. Then there's the actual scaler, the RTD3580D. There is a connection between the mcu and scaler over which the mcu sends commands to the scaler. The scaler is doing all the work, you could say, with the mcu "guiding" it. This is proven by turning off the mcu while the scaler is doing something. The scaler will continue to do whatever its doing at that point, for example displaying a composite source from whatever input its using. The mcu pretty much tells the scaler "this is the adc with the video signal, these are the output requirements, start doing the thing" and then its hands off. This would theoretically make it easier to write a new firmware from scratch, but well, it'd still take much more time then we'd like to spend on it to say the least. The OSD works in a pretty simple way, and it can be really powerful. There are limitations though, almost like working on an old console. The OSD can draw bitmap graphics, but only in 12x18 blocks. This is because the mcu doesn't actually give the scaler any bitmap data. Instead it points the scaler to what to draw, pretty much just an address in memory. The OSD has 16.5K of dedicated ram, which is where these bitmaps are stored. This means you can at one time only have a limited number of "fonts", or bitmap data. This is what's its meant for anyways, drawing text and primitive icons. There are a number of cool features making it perfect for these notification style hud items though.

So I guess later Realtek fused both the RTD3580D with a virtual EEPROM to make RTD2660 highly integrated ASIC as you explained. This would corresponds to the 2nd schematics which I posted yesterday where only SPI NOR memory is used.

As for initial search, it seems above article mentions doable to RGBS de-interlace, they wrote Interlaced VGA support (also pretty close here) back in 2019.

Cool tidbit: in Linux I was able to access it via the VGA connector using and old Laptop with VGA interface (no programming box needed) and I've heard is possible in Windows as well.

I'm not sure to understand, do you mean that through your old computer, you have used its own VGA port connected to one of your RTD2660 board then you wrote a program able to directly read or write without any adapter or interface (i.e. Adafruit FT232H Breakout board) ?

Albert

[Tantratron]

- Your board seem to be an "enshitified" version, in the Chinese world the PCB800099 is the gold standard (most likely based on the  SDK reference design), all the other crap with lasered ICs is most likely something using dodgy reject parts, RTD2660/2 is a venerable IC there is no competitive advantage in hiding it.
I have tested my board from 5V to 12V, no overheating problems, so I suggest finding one that looks the same. Or also very likely, is a "castrated", low-cost versions of the full chip, why put the analogue block when no one uses it and get extra 0.3 cents per chip.
This is why I've said, if it's not a "one-time project", a suitable vendor should be found, verified and a stock of "real" boards with real chip shoul be made.

Regarding this specific board which I did purchase to an individual and instant overheats, today I've decided to scratch whatever was lasered or sanded. It urns out to be some kind of glue where the chip was probably hosting a heatsink glued then removed. No idea but then I did use some chemical, bit too much so it removed the silk marking (stupid of me). So no choice as a last ressource to use lateral spot lighting then best picture with lens, guess what it reads RTD2660 including the Realtek logo.

No idea what is the difference between RTD2660 and RTD2660H, what is the H for but my other board purchased to serious company uses RTD2660H with no overheat.

What is quite crazy, this board even if overheating partially works when I attach a LCD in LVDS mode (G065VN01-V2) but very unstable. It will not memorize the settings, sometimes will declare no HDMI, sometimes will find VGA then looks for other things, it will self-po the inetnsity meneu or contrast menu, self-change from 0 to 100... this seems similar to what the russian or ukrainian post reported (after translation http://pccar.ru/showthread.php?t=22851, see end post #1)

Anyway unless there is PCB reason explaining the overheat, I'd tend to conclude best to buy a board with RTD2660H instead of RTD2660, for sure not buy a board where we cannot read the chip marking.

Early this morning I thought o use a trick to void my mistake yesterday to really read the marking of the chip in this PCB800099-V9 board which overheats, unstable LVDS outputs. So I've first applied white Tiip-Ex, waited it dries then I've fine carefully sanded. The white painted Tipp-Ex inside the laser etched marking stayed whereas the rest of the chip showed ahain dark and previous strong glue for whatever heatsink used to be there.

See an update of the pictures if this board (when purchased so no marking visible then now with my trick to photo reveal its real marking). No idea if the overheating is realted to the ASIC design of RTD2600 versus later design RTD2660H which would solve heating unless the firmware is corrupted leading to overheating.

Once I'll find a way to interface one of my iMac via USB into the I2C bus found on the VGA connector, I will probably use this overheating board as a victim for reading and programming the SPI NOT flash content.

In the meantime, I've ordered from eBay another RTD2660H board, its model is PCB800808 but it will take 10-15 days to arrive in France. As a reminder, I do have now PCB800196 board which works fine but only does LVDS output, the PCB800808 does only TTL output so i'll look for PCB800099 not overheating to benefit of its hybrid output mode (LVDS and TTL).

[DC1MC]

The quoted article is legit, this is exactly how it works, a mixed mode ASIC (scaler and all the interfaces) driven by a small MCU used for management. It's the same setup used for many other devices, from fancy pants FPGAs to other mix mode devices like USB bridges FX2 and FX3 and so on.

And yes, in Linux the I2C device on the monitor is exposed to the OS over a standard I2C device, where the PC/Laptop is the I2C master, the bus can be easily scanned with the standard I2C utilities and there are quite a lot of programs that do it for the EDID, the EDID device is a 0x50 (or 0xA0 depending on how you look at it , Linux uses 0x50 notation), and if I remember correctly the SPI bridge was on 0x30 or 34 0x4A, not 100% sure but it comes immediately at bus scan.

So is true, one doesn't need any kind of strange adapters, break-out or pass-tough boards, or any strange animals  , what it DOES need is to convince the existing tools to: 1) Work in Linux and 2) Discuss with the video driver I2C bus and not with the strange adapter driver.

To spare the pain here's an implementation for Linux, along with a collection of firmwares for our favorite board:
https://github.com/mushketer888/pyrtd2660i2c

Myself, during the short-lived development period, I've found out that even if the I2C access works, is slow and miserable, but keeping the MCU in reset while attaching the cheap programmer clip over the EEPROM accomplished the task way faster and better, but I guess for modifying now and then a firmware, or replacing the manufacturing delivered firmware with another one, the I2C access is OK.

Cheers,
DC1MC