Please recommend a VGA to parallel LCD board or IC

[Tantratron]

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.

Wait so far when checking PCB800099-V9, I do not see any EEPROM but only the SPI NOR flash plus you wrote earlier the EEPROM was emulated or inside the RTD2660H chip ?

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

Thanks so I'll try to install Linux on my iMac, after all my son keeps telling me that I should go aftare Linux use so I might catch 2 birds here.

Another option would be to use one of my arduino DUE to establish the connection from this git https://github.com/ghent360/RTD-2660-Programmer pointing to this other git https://github.com/adafruit/Adafruit_RTD266X_I2CFlasher

Thanks, Albert

[DC1MC]

Found another programmer using C++ instead of Python, which is more my favorite:
https://github.com/static-void/rtd266x_programmer

Bonus, another firmware source repository:
https://github.com/danyaPostfactum/RTD2660

Reading this article about accessing programatically the monitors I2C bus on MacOS, I've vomited a bit of blood:

https://notes.alinpanaitiu.com/Decoding-monitor-EDID-on-macOS

and personally I'll not bother, an old Linux laptop is so much easier, costs nothing or is free and can be used for other things as well.

But I recon everyone has its favorites, so good luck with your project on MacOS.

Cheers,
DC1MC

[Tantratron]

Reading this article about accessing programatically the monitors I2C bus on MacOS, I've vomited a bit of blood:

https://notes.alinpanaitiu.com/Decoding-monitor-EDID-on-macOS

and personally I'll not bother, an old Linux laptop is so much easier, costs nothing or is free and can be used for other things as well.

But I recon everyone has its favorites, so good luck with your project on MacOS.

Thanks where one of my motivation or pleasure is to do things with MacOS since 1986, I hate Windows but willing to try Linux once installed in my iMac.

Maybe you have seen old posts early 2020 regarding TDS500/600/700 hack, firmware modification. The luck being that National Instruments is the only GPIB suite fully compatible with MacOS besides Windows and Linux. Check among many this specific post https://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2856510/#msg2856510

I did got lot of help from swedish ragge member who does three OS and made things easier in his MakeFile and C so the tekfwtool would be universal 

Albert

[DC1MC]

In the end the discussion reverted on how can I program the flash on the board, but that's OK, while I will stick with the the little clip programmer:
https://www.amazon.de/KeeYees-SOIC8-EEPROM-CH341A-Programmer/dp/B07SNTL5V6
(I think I've bought it pre-covid from Ali with something like 4.99€ on one of their sales promotions)

you'll most likely have your reliable programming solution ready and then the stages of denial will begin:

- weeee, I've programmed correctly my first FW.

- is not working  , but no problem I've got 144 more to try... 

- still not working, could anybody patch this Russian FW, it's almost what I need only this is missing, it should be an easy job...

- thanks, let me try it, carp  , I've bricked my board, where can I get this cheap EEPROM programmer...

- OK, fine, let's look closer in the source code...

So, I'm cheering here  and want to see what will come out of it 

Cheers,
DC1MC

[Tantratron]

Thanks for providing the reference of this USB clip programmer reference, I'll check some vendors plus verify if drivers and their CH341A software does exist for MacOS. Probably not so in that case, my plan is to rather migrate and compile on my iMac the actual source code from the git you suggested. I'd just need to purchase the Adafruit FT232H Breakout board hoping a MacOS driver exists then attempt programming the SPI NOR memory via I2C signal through the VGA connector (pins 12 and 15 for SDA and SCL obviously inverted from what i've read else where).

Do you think it is easier to brick the PCB800xyz board by VGA-I2C programming or direct clipping the SPI NOR memory ?

By the way, I've cleaned then checked the markings of the SPI NOR memory on both my boards (V196 and V099), it is 25V040 chip where each 4 pins are connected via 33R for protection from the RTD2660 pins:

• RTD2660-118 => Chip Select 25V040-1
• RTD2660-117 => Chip Out 25V040-2
• RTD2660-116 => Data In 25V040-5
• RTD2660-115 => Clock 25V040-6

let's see what will be the outcome

[DC1MC]

My boards have a 25X40 from Winbond and a 25D40 from ?!?, largely oversized, but both recognized by the clip programmer. I'm wondering if the chip has an A/B running and backup FW scheme or it was just cheaper to use bigger flashes ?

 Cheers,
 DC1MC

EDIT: What do you know, there IS software for the MacOS for the clip programmer:
https://github.com/YTEC-info/CH341A-Softwares

Now, for which version and how compatible, this question remains to be answered by fruit lovers  ?!?

[Tantratron]

Again many thanks to help the MacOS pathworking, the github link about CH341A.

Maybe a stupid question but why most git repo as well as Rovatool creator decided to VGA-I2C-flash via the adafruit since it seems faster and easier to directly clip flash the memory ?

This does not remove the real super challenge to 8051 code a change then generatee the BIN firmware but most reports have been mainly persons with the BIN  so only in need to program the SPI NOR memory.

[DC1MC]

IMHO it is because most of people are a bit shy of clipping stuff over ICs, not to mention the proper orientations and stuff, also the I2C path is useful also for cased monitors, where you don't want to to disassemble your expensive beauty  .
In anything that lab setting with a qualified person and the board on the table I will 100% recommend the monitor I2C path, way much safer for the end users, there is no argument and discussion here.
On the other hand, if I have the board in front of me and want to do quick testing of my newly generated firmware, or recovery in case of the screw-up, I will not stupidly stare at the actual chip while waiting for the cumbersome I2C to SPI transfer a quarter of an hour.
Not to mention that in case I've have an invalid FW is game over without an clip-on programmer, so in conclusion the ROVA tools and friends are most useful for end users that want to fiddle with the EDID and update some modded FW now and then and the clipon programmer is most useful for actual development and testing.

Cheers,
DC1MC

[Tantratron]

My boards have a 25X40 from Winbond and a 25D40 from ?!?, largely oversized, but both recognized by the clip programmer. I'm wondering if the chip has an A/B running and backup FW scheme or it was

The 25D40 might be from ZETTA http://www.zettadevice.com/upload/file/20150821/DS_Zetta_25D40_20_RevA.pdf where close look of the flash chip in my 2 boards shows first line starting with ZD

[Tantratron]

Quick update, I've now ordered via amazon business the programmer you suggested https://www.amazon.fr/KeeYees-SOIC8-EEPROM-CH341A-Programmer/dp/B07SNTL5V6 plus some other stuff. I will try on the overheat PCB800099-v9 victim different reading and writing scenarios with hopefully the MacOS software compatible with this programmer.

In the meantime, I will connect my SALEAE logic 16 channels analyzer directly to the SPI flash pins then SPI decode just to observe the data flow, see attached picture with my tektronix good old grabbers

[DC1MC]

Lovely setup  , I hope everything goes well, in any case when the programmer arrives, FIRST THINGS FIRST, make a backup copy of the original flash, we're entering now in the Brickland territory  !!!
Also, do try multiple reads and binary compare with MD5SUM or your favorite hashing algo the results and only stop when you get consistent reads, you may need to adjust the speed settings, the cheap clip will have issues being placed together with the mini-grabbers, so first get your back-up copy of the flash without them.
If you get a machine with Linux or even Windows, we can do sometime over the weekend a TeamView session if you encounter issues with the programmer.
Afterwards is "try stuff" extravagantzza  .

 Cheers,
 DC1MC

[Tantratron]

While waiting few days to receive the USB-CH341A programmer, I've directly probed the signals (CLK, CS MISO and MOSI) then recorded with Logic analyzer which does SPI decoding (see attached picture). No idea if this makes sense for the moment, what are the specific commands to read the content of the flash memory but just felt sharing for your review.

[DC1MC]

The SPI protocol for NOR flash is super good documented, let's see the video signal, H, V and composite with cursors to see if it may fit directly in the analogue input of the original FW.
I'll try to program sometimes the Rigol generator to emulate the signal and see if it synchronizes.

 Cheers,
 DC1MC

[Tantratron]

Regarding a direct NOR flash read/write and the CHR341 programmer, I've just found this article with warning (5V versus 3.3V issue) also pointing to EEVblog thread
https://libreboot.at/docs/install/spi.html
https://www.eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/

[Tantratron]

Here is another recording with my logic analyzer, this time on the PCB800196-V6 board which does fine (no over-heating) neither unstable behaviour of the image.

This time, we clearly see the READ command 0x03h followed by the 3 bytes adress (absolute 0x0000h so begin of firmware file) which will output the correct 4 bytes found in most BIN file, namely 0x02 0x10 0xC7 and 0x09

Then we see another reading command request, this time pointing at adress 0x0010C7h which does read correct content firmware

If really all firmware should start with 0x10 0xC7 and 0x09 then clearly my over-heating PCB800099-V9 is probably bricked

[DC1MC]

Regarding a direct NOR flash read/write and the CHR341 programmer, I've just found this article with warning (5V versus 3.3V issue) also pointing to EEVblog thread
https://libreboot.at/docs/install/spi.html
https://www.eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/

Mine has an 3V3/5V switch (actually jumpers) and I set it to 3V3 and it worked OK, I may need to modify it because lately more and more 1V8 devices show up.

[DC1MC]

I have compiled the first firmware source tree, the first bytes of my firmware are:

hexdump -n64 -C RTD2662.BIN
00000000  02 11 11 02 17 50 ff ff  ff ff ff 02 12 31 ff ff  |.....P.......1..|
00000010  ff ff ff 02 07 70 ec 4d  60 11 e8 49 70 17 ed 33  |.....p.M`..Ip..3|
00000020  ec 33 04 60 0d e4 fc ff  fe fd 22 e9 33 e8 33 04  |.3.`......".3.3.|
00000030  70 f8 02 01 c6 12 01 91  58 04 60 09 e4 cc 24 81  |p.......X.`...$.|

[Tantratron]

I've downloaded just a few firmware to compare with my logic analyzer reading, my logic analyzer SPI downloading seems to be correct and matching this firmware pcb800661-lvds640x480-d6bit. See attached picture where at least few bytes do match what my logic analyzer decoded

[timeandfrequency]

Hello DC1MC,

Did not read the full thread, but I sincerly hope you'll succeed.
In the negative , you may read below.

As far as I understand, you need a VGA scaler that allows to crop an zoom at the pixel level a 4:3 image to an LCD display.
Even though I'm not involved in that subject, I know that retro-gaming afficionados have similar predicaments because CRT production has completely stopped.
VGA signal is RGB, and I would say that for TE, you don't need thousand of different colors.
Maybe you can cobble something to convert analog RGB output to digital RGB (most of the case 16 colors, so 4 bits, or 64 colors : 6 bits) and then use an RGB2HDMI scaler to display on a vanilla HDMI LCD panel. Wiki here.

As you can see on this screenshot, H and V pixel span ('H & V range') and H an V zoom factor ('Scaling') can be adjusted, which would allow to resize the 4:3 image on a 16:9 LCD display without distortion.

[DC1MC]

Hello @timeandfrequency, couple of words:

 - I don't need anything for the moment, @Tantratron need such a thing for his instrument, I try to assist as good as I can.

- The RTD2660 doesn't have just VGA input, it also has analogue component inputs and composite. the best way to use a scaler is to not use it, at lest not for instruments display and fractional scaling, but the challenge is to find something with a similar size and aspect ratio as the old LCD and with a resolution that is close to a multiple of the original one, most fractional scaling sucks for text and lines.

- Scaling a 4:3 to 16:9 without distortion is IMHO a bit misleading, either a (small) piece is cut, or there are bars, or there is some new geometry that I didn't hear off to do this scaling  .

 Cheers,
 DC1MC

[Tantratron]

In my quest to see if it is possible to de-interlace the 15 KHz video signal from the Advantest R3261/R3361 spectrum analyzer, I thought to connect my LCD drivers to the composite video output.

The good news, the board using MST703 (Mstar) does sync with composite but its firmware does not offer possibilities to rescale the image (see attached picture).

Then I've tried the RTD2660 (Realtek) board but it does not work on composite interlaced video, at least with its actual firmware.

When reading the datasheets of MST703 and RTD2660, they do mention de-interlace so the question again to modify the firmware plus how to tell the MCU the rescaling to fit 640x480 display.

As a reminder, the legacy Advantest spectrum analyzer are CRT based, its GPU generates inside the video board 15 KHz interlaced 1264x525 resolution

[timeandfrequency]

Is the 'Keil uVision MCS-51' really compulsory ? Another compiler with I2C support wouldn't do it ?

@Tantratron As far as I understand, with the harware you own, you're pretty stuck and there seems to be no easy way for improvement. Would you aggree to try other solutions ?
I was poking the Internet and found this :
R2AH-200A : obsolete scaler/LCD driver card  Chip used : RTD2486. Probably no interlaced mode supported.

But there are other boards using the RTD2486 that offer more features.
...to marry perhaps with another suitable display ?

Or something like that ?



@DC1MC Please excuse me : as I did not read the whole thread, I thought it was you who asked. And I'm also pretty sorry to hear about your predicament. If you have some stuff to sell, I would for sure come this Saturday (16th of November) to your location to discuss a little bit with you and to see if some gear would hold my interest.

[Tantratron]

@Tantratron As far as I understand, with the harware you own, you're pretty stuck and there seems to be no way for improvement. Would you aggree to try other solutions ?

Bonjour et merci,

Maybe first to really understand where I'm coming from with this project, if i'm stuck or not, kindly check this post with its 3 pictures of my setup https://www.eevblog.com/forum/projects/please-recommend-a-vga-to-parallel-lcd-board-or-ic/msg5703193/#msg5703193 which sums out the sitaution, the boards and what I'd like to simplify (remove red RGBS to VGA board or directly use FPGA hence forget about RTD's and MST's asic panel controller)

I'll answer your other part later but I just want to make sure you understand first: de-interlacing from RGBS 15 KHz @ 60 Hz then LCD signaling (TTL or LVDS) with one chip

Amicalement, Albert

[DC1MC]

Is the 'Keil uVision MCS-51' really compulsory ? Another compiler with I2C support wouldn't do it ?
...

This one is a toy obsolete compiler, with a license that can't be obtained anymore (the author retired and on the website has an interesting demo, SFW    ), the demo license makes up to 8KB code, and over 4KB doesn't save the project, on mikrocontroller.net there is a relevant discussion. I've installed it and it shitted out something like 20 different icons on the desktop (luckily I run Linux and they were immediately collected . the fact that supports or not I2C is totally not relevant, in the end is all register access.
The RTD2660 SDK needs a modern optimizing compiler that is able to do code banking and extreme optimization (from 128KB available currently I've seen ca. 113KB used), absolutely no other compile can beat Keil (unfortunately), ah and it needs also to support customizable CPU instruction, mostly for banking.
So at least for the existing SDK that has close 100 files in the project, including customized linker scripts (remember them  ), there is no other option for development, as sad as it is, SDCC is not able to do it (I've tried) and most definitely not the long forgotten XP time experiments .

Regarding offloading the gear I've collected, your proposal is pretty interesting, unfortunately is too short of a time and my better half has already plans for this Saturday. I also need to inventory and check what and how it works and put them in a more accessible place, most likely in the spring if I survive the winter .
When I'm done, I'll post a list and if you're interested in something and could make a pick-up trip to Mannheim you may get some acceptable priced boot anchors that I don't want to ship at all as I have seen what DHL and Hermes uses now as personnel  and how they treat the parcels.

Cheers,
DC1MC

[Tantratron]

The RTD2660 SDK needs a modern optimizing compiler that is able to do code banking and extreme optimization (from 128KB available currently I've seen ca. 113KB used), absolutely no other compile can beat Keil (unfortunately), ah and it needs also to support customizable CPU instruction, mostly for banking.

I've looked with an HEX editor different firmwares, not all but tried to read more than 10 firmware corresponding to specific LCD case wether TTL or LVDS based on RTD2660, all assumed to have OSD function. Unless i'm wrong, most BIN file firmware are stored (i.e. github repo) in 256Kb but looking attentively, the real code is always less then 64Kb. If you read say from relative address 0x10000h or from 0x20000 or 0x30000 then the local code in the firmware is the same as the 1st block from 0x00000).

Do we really need banking for 8051 and if yes, what size because its seems the real firmware would be always less than 64Kb ?

So at least for the existing SDK that has close 100 files in the project, including customized linker scripts (remember them  ), there is no other option for development, as sad as it is, SDCC is not able to do it (I've tried) and most definitely not the long forgotten XP time experiments .

Maybe one eventual topic or work would be to drastically simplify after understanding exactly what the 8051 is demanding, communicating, pipelining with the core RTD2660. Who knows, maybe there would be a way to have much less than 100 files describing the project but just rewrite a dedicated simple core foundation which eventually could be compiled with SDCC.