What's new

Yet Another RTD2660 Quest

Legend

.
Joined
May 10, 2019
Messages
130
Likes
246
Location
Canada Boi
Portables
2
As some of you may know, I’ve been pretty invested in a project im doing on the PS2 side of the forums called PS2V. Without getting into too many specifics as its outlined in my worklog, the project has been brought to a halt while I figure out the lcd screen side of things. TL;DR I wanted to make some modifications to the RTD2660 firmware to add a few features and bypass some things that I was originally going to add in.

Disclaimer:

I am very much a beginner and my idea for this specific worklog is to show any other beginners wanting to do something like this the process of going through it so you can take my mistakes and not make them. I think It will also be nice to have something like this out there as there is not too much information on the RTD2660 out there and searching around for 50 different things is not ideal. I also want to preface that as a beginner, i'm going to possibly say things or make some dumb decisions along the way that are not correct, so please take what I say with a grain of salt.

With all of that aside, my thoughts were doing all of this in 3 main phases, but ultimately there's still a lot of work that needs to be done aside from my 3 main phases. They are as follows:

Phase 1 - Establish a connection with the RTD2660 and be able to read and write firmware to it.

Phase 2 - acquire a firmware source and be able to compile it properly as well as convert it to a binary file if needed for flashing

Phase 3 - Modify, test, and debug the firmware as I go to be able to achieve the goals I set out to achieve in the first place.

I ended up getting the exact same screen and driver board combo that you can buy on the 4layer website which includes the 800x480 5” IPS screen and the blue driver board that has both AV and VGA connections. The meat and potatoes of all of this is the RTD2660H of course, but also the 8 pin SPI NOR flash connected to it. The RTD doesn't have dedicated memory in the chip so the firmware for it is stored in the SPI flash and the RTD reads the firmware from it in order to be able to function. The RTD pcb’s over the years have had many different types of SPI flash on them and if you do your research, you'll find that the most common type was a winbond SPI flash. In this case, my driver board has the Zbit 25VQ40 on it. I'll include the datasheet for it as well.

Meat&Taters.jpg


PHASE 1

Phase 1 started with doing a bunch of research and finding the best and most painless way of connecting to and programming the RTD, but a lot of the writeups etc. that I’ve seen were heavily based on earlier versions of the PCB that housed the RTD such as PCB800099. While searching, I ended up finding out that the SPI flash can be programmed through the RTD using the I2C DDC lines on the VGA port connector (pins 12 and 15 on the connector itself), and upon looking at my newer revision driver PCB, I found the 2 pins on the VGA connector labeled SDA, and SCL. These pins are already connected to their own respective 4.7k pullup resistors to 3.3v. Being a relative beginner, my searching brought me to a writeup by Matt Millman about programming the RTD and he actually wrote a nice windows software with a GUI for this called ROVA tool. There are a few different types of programmers you can use with ROVA tool but the best option for me was using an Adafruit FT232H FTDI board. This seemed like a really viable option for me as it had a nice windows GUI and all I needed was a FTDI board to get it working, so I picked one up.

ROVA Tool
https://www.mattmillman.com/rovatool-2-0-released/

Using ROVA Tool with a FTDI FT232H Based Board
https://www.mattmillman.com/info/lcd/rovatools/ftdi-ft232h/

FTDI.jpg


This is where I started running into issues (and I want to clarify that its not rova tools fault). I got my FTDI board in and recreated the setup in the writeup as best as I could with the only exception being that I had a newer driver board than the one he used but I could not get it to connect and send an ACK bit back. I played around with it for a long few days and tried many different configurations like changing the pullup resistor values, trying 5v logic instead of 3.3v logic and so on but I could not for the life of me get any response. I chalked it up to maybe the FT232H + ROVA Tools just wasn't going to work for me so I hit the internet again in search of another method. Upon searching, I found ghent360’s solution and what was great about that was that he had a bunch of the forks people made for different methods linked in the readme of his repo.

ghent360/ RTD-2260-Programmer
https://github.com/ghent360/RTD-2660-Programmer?tab=readme-ov-file

Given this is old, this method used an older FX2LP device for programming and required compiling the windows software to use with it, as well as download an ancient software to be able to program FX2LP to work with the software. I was fully ready to do all of this so I bought a FX2LP device and attempted compiling the windows software while I waited for it. I ran into issues because I was compiling it for a 64 bit architecture while it had 32 bit architecture library files that it depended on so as I was in the process of restarting from scratch to compile it and venting my frustration on the discord, Alex (supertazon) was saying that he programmed via an arduino uno using another method.

Floppes RTD266xFlash

Now I had overlooked this method in my searching because I was hyperfixiated on using ROVA tool but after taking a better look, it seemed perfect as it already had a windows GUI available and all I had to do was compile and upload a sketch to an arduino uno which was super painless. Given all of this, I ordered an arduino and boy am I ever glad I did just for the fact that it's super useful for a plethora of other things.

I had gotten everything set up with the arduino quite nicely but I still couldn't establish a connection to the RTD board. I ended up uploading a I2C scanner sketch that scans every possible slave address until it gets a response but I couldn't get anything from the RTD so I briefly shifted my focus to bypassing the RTD all together and reading and writing to the SPI flash itself. I did get somewhere with it but I don't think my sketch was sending the proper commands for reading and writing as when I flashed firmware to the SPI flash using my janky deadbugged setup, it just kept defaulting to the original firmware. I was reading the datasheet for my SPI flash but my brain was hurting trying to comprehend a lot of it so I ultimately went back to trying to figure out what was wrong with the i2c connection on the RTD.

Jank.jpg


I was glad I got that FX2LP device as I was able to use it as a logic analyzer with pulseview and figured out that the bus was just not doing anything. Then my beginner brain realized that an I2C slave does nothing until addressed by the master, so I set the arduino up again to be able to capture what was happening when trying to communicate with the RTD and figured out that it was just sending a NACK bit (not acknowledged).

Logic.jpg


I was just about to give up on the whole idea and either order an older driver board to work with or just buy a bare RTD2660 chip and a different SPI flash to start with a fresh setup when I decided to look harder at the RTD2660 Datasheet. Now I had been referencing the datasheet for info this whole time but I looked a little harder and found the “In System Programming” section to have a good look at it.

In system programming.png


Here it says that the RTD uses DDC channel (ADC/DDC2/DDC3) to communicate to IIC (I2C) host for ISP (in system programming) function. Now I had known there were other I2C lines on the RTD that were technically active (i.e. connected to pullup resistors) right beside the lines that go to the VGA port so I sniffed those out and scanned for slave addresses but got nothing.

Lines circled in red are the original I2C and the ones circled in yellow are unknown I2C lines.
I2C Pair.png



So I started looking for the other channels outlined in the datasheet and found the following:
DDC Pins.png


What sort of confused me about this was upon looking at the PCB I was working with, the DDC2 and DDC3 lines were left unconnected.
DDC2 & 3.png


I was desperate however to get something out of this given I had already put so much time and money into it so I harvested 2 4.7k resistors from a wii I had sitting around (thanks shank for the wii super thread), connected them to 3.3v and soldered some magnet wire directly to the DDC2 pins, plugged them into my arduino with the I2C scanner sketch and prayed to the lords of electronics.

Setup.jpg
Address.jpg


I was pretty pumped to say the least. A few different addresses showed up but it was 0x4A I was looking for (default slave address). I reuploaded the Floppes sketch to my arduino and opened the GUI and successfully connected the RTD to it. I had also tried ROVA tool again for the hell of it but it turned out my SPI flash isn't supported in the software and with no way to change it, it would have been a bust anyway even if it worked from the get go. The cheeky buggers over at buydisplay configured those pins for programming and left them unconnected presumably because they didn't want anybody tampering with it easily. They also grounded the WP (write protection) pin on the SPI flash so it couldn't be easily written to either.

I still have to do some modifications to do like code the Jedec ID of my SPI flash into the arduino sketch as its needed to be able to properly communicate with the SPI flash, and I need to lift the WP pin and connect it to VCC through a 10k resistor to ensure there's no trouble with writing to it but with that, phase 1 is complete.

To any new or advanced user trying to mess with this specific driver board or a RTD in general, I definitely recommend getting an arduino uno and using the Floppes method as it seems more configurable, modifiable, and easier to use rather than having to compile a bunch of stuff and mess around. On top of that, you’ll have a super versatile arduino left afterwards which can be used for a variety of things. Also be prepared to bring your own pullup resistors and have to solder directly to the DDC2 I2C pins.

Ive already been messing around with a firmware base but I still need to get it compiled properly which has already proven to be a pain, but ill update soon enough with the start of phase 2! Thanks for reading!
 

Attachments

Legend

.
Joined
May 10, 2019
Messages
130
Likes
246
Location
Canada Boi
Portables
2
Update time!

I didnt expect to get things figured out as quickly as I did regarding phase 2, but here we are!

Phase 2
So before I ever even got a programmer for phase 1, I was able to obtain a firmware base and try compiling it but its been giving me issues since day 1. The main software thats needed for compiling C code for a 8051 MCU (which is at the RTD2660's core) is Keil uVision 5 using the C51 compiler. I started off by downloading Keil and because there is a Keil project file within the firmware base, I was able to open it and it already had settings preconfigured for compilation which was great. Upon trying to compile the firmware, I immediately ran into issues getting a C129 error: missing ';' before 'sfr'. The issue with this was that the file in question having this issue was a Keil IDE include file, so you'd think that there shouldn't be any issues with files included with the IDE right? well there wasn't, and i'll get into that soon.

I searched the issue and tried a great many things but being a beginner, I didnt know what I was looking at to a certain degree, so I focused my attention on using any other method than Keil to compile the firmware and found SDCC (Small Device C Compiler). I messed around with SDCC for a while and I realized that there would have been a lot of modification needed to the code for it to work with SDCC, and I started down this path with a determination to get it compiled. I then realized that with the way the firmware was coded (meant for Keil) that the modifications needed for SDCC would virtually make the firmware unusable, and I wasnt about to even think about rewriting the full code just to be compiled with SDCC.

I turned my attention to a Github repository that had a firmware base as I assumed there may have been issues reported with people compiling and there was thankfully. I got a bit of information out of the issue reports and noticed that somebody posted an issue about adding a custom logo (one of the things I wanted to do) right around the end of 2024. This user said he was able to get the firmware compiled but couldnt figure out how to add a logo. As much as I didnt want to bump and older post in beginner fashion, I did and was able to have a quick back and forth with this user, and it really helped me out.

Before I continue, I want to let you all know that im in between a Mac and a really old windows laptop for working on my project, so my main issue started with Mac. it turns out that if you transfer files from a mac to a windows computer (in any way) for some reason mac messes up the files your transferring. I first found this out when putting files onto a usb for my PS2 and upon looking at the files in uLaunchELF, there was weird things like doubles of files etc. It turns out that I had first downloaded my firmware base on my mac and transferred it to my windows laptop to use with Keil, and thats why I was getting my C129 error.

I downloaded the firmware base again directly on my windows laptop, opened it in Keil, and was able to compile it no problem but there was one more issue that this user on Github pointed out. Keil is a paid software and it turns out when you download it, you only have an evaluation license but you need a professional license in order to be able to compile this firmware as it exceeds to file size limit when using an evaluation license. I want to say that I dont condone, nor encourage piracy in any form, but all I'll say is that I needed the professional license for Keil so I found a way to get it.

From there, I had zero issues with compiling and was able to successfully get everything working. I got home and lifted the WP pin on my PSI flash as mentioned at the end of phase 1 and flashed the firmware to my driver board, but there was another issue. Theres a pin on the RTD2660 (specifically pin 111) that drives the backlight circuit for the panel, and the settings of the firmware dont configure that pin to drive that circuit. I was a little bummed out at first and thought that the firmware didnt work until my light shined on my panel a certain way and I could barely see the "no signal" notification on the screen. I tested the circuit and found that there was no voltage going to the backlight pins on the panel, so a quick bridge from 3v3 to the backlight regulator was a quick fix for that until I get the proper pins configured.

Now that the backlight worked, this is what I got:
Wrong panel.jpg


The logo was disabled in the code so I enabled it but I was scratching my head wondering why it seemed like the "no signal" notification was replaced by the logo, then I found the code for it and had an "ahh that makes sense moment".
no signal.jpg


As you can see the panel was also weird and not configured properly, so I found the proper portion of code that enables my specific panel (800x480 40pin) and was able to get a solid picture:

right panel.jpg


I was able to play around with some stuff to find out what I was working with and got this all in a state I can work with!

configured.jpg


And with that, Phase 2 is complete!

Im pretty proud of myself for making it this far honestly! I knew nothing going into this and I'm still largely in the dark about A LOT of the code but aside from the PS2V specific features that I want to add, I would like to add the following to this specific worklog for others to use if they so please:

- Fix the backlight issues by configuring the right pin to drive the backlight circuit
- Strip out the other input sources aside from AV and VGA as thats all this driver board supports anyway
- Strip out any audio functionality as its still included in the firmware and there is no amp on the board
- Confirm that the right pins are configured for AV, VGA, Menu buttons etc.
- Get deinterlacing on the VGA input figured out and configured so we can use this panel with a PS2 (or any other 480i console)
- figure out any other issues or dependancies along the way

With all of this, somebody should be able to buy this specific driver board from 4layer (or their supplier of choice), flash the firmware, and be able to use it as normal but with added support for older consoles with 480i etc. without having to use an external scaler.

I am working on phase 3 right now and im not sure how long it'll take me to achieve this as there is a ton of testing required but were getting somewhere! That is all for now folks, thanks again for reading and ill update hopefully soon with a juicy solution for this board!

side note: ill also be updating the PS2V worklog with the features I want to add and the progress as it'll differ from what I plan to post here.
 

Nold

real emulation, no hardware
Staff member
.
.
2021 1st Place Winner
Joined
Jul 16, 2017
Messages
450
Likes
1,634
Location
EU
Portables
5 + 1*π
That's slick, dude! Any plans on adding additional input signals? IIRC the chip supports RGB or component or sth.
 

ShockSlayer

the real
.
ヽ༼ຈل͜ຈ༽ノ
.
Joined
Jan 16, 2016
Messages
1,522
Likes
4,023
Location
standing up
Portables
please do not ask!!!! I will NOT respond
This is pretty neat. I've long wondered about screwing with these boards like this, glad to see it's possible.
 

Legend

.
Joined
May 10, 2019
Messages
130
Likes
246
Location
Canada Boi
Portables
2
That's slick, dude! Any plans on adding additional input signals? IIRC the chip supports RGB or component or sth.
As far as I know, the code base I'm working with is pretty messy and a lot of things are broken, but I could look into adding YPbPr support! It would require either a custom PCB or getting an existing driver board with the inputs configured but it's definitely possible!
 

Shank

Moderator
Staff member
.
.
Joined
Jan 31, 2016
Messages
1,343
Likes
2,882
Portables
6
Wow this has a lot of potential here. Here are a few features I would love to see implemented:
-Native 240p support (rather than 480i, sometimes called weird names like double strike, progressive standard definition, and non-interlaced standard definition)
-RGBS (combined composite sync rather than h and v sync)
-YPbPr input
-S-Video input (sometimes an option using 2 composite input pins or 2 RGB pins)

These features could really open up a lot of doors for many console projects.
 

Legend

.
Joined
May 10, 2019
Messages
130
Likes
246
Location
Canada Boi
Portables
2
Wow this has a lot of potential here. Here are a few features I would love to see implemented:
-Native 240p support (rather than 480i, sometimes called weird names like double strike, progressive standard definition, and non-interlaced standard definition)
-RGBS (combined composite sync rather than h and v sync)
-YPbPr input
-S-Video input (sometimes an option using 2 composite input pins or 2 RGB pins)

These features could really open up a lot of doors for many console projects.

In my specific use case (for the PS2) I know that games tend to switch between 480i and 240p on the fly so ill most likely need to add support for handling that but with that, I could look into stand alone 240p support.

As far as supporting and fixing other inputs that you've mentioned, I'll need to upgrade my setup for testing so we can have a testing bench for all different setups. I'll also need to do my research to figure out how each input is handled so we can figure something out.

I sincerely have my work cut out for me lol, but I'm usually pretty determined so hopefully we can get a universal driver board out of this that can work with the full variety of panels, resolutions, and inputs.
 

Legend

.
Joined
May 10, 2019
Messages
130
Likes
246
Location
Canada Boi
Portables
2
Update time!

The Beginning of Phase 3

So I've been trying to prioritize the PS2V specific stuff for the screen before moving on to the other features the community wants to see and boy has it proven to be difficult so far.

First on my list of things to was to display a custom logo on startup so not long after my last update, I started diving into that whilst taking note of the parts of the code I wanted to look into after. Typically I treat this similar to doing a test, and by that I mean if I get stuck on a question, I'll move onto the next and circle back around but for this specific project, I really wanted to get whatever I was working on figured out before moving on.

Let's start with the OSD or "On Screen Display". The RTD2660 has an embedded osd that handles a variety of things in terms of displaying overlays, so when you see that "no signal" notification, or even the inputs in the middle or corner of your screen, that's the osd doing its thing. To save the trouble of explaining things, here is the information from the datasheet on the OSD.

1000012242.jpg


The osd is capable of displaying a logo, but it has to be formatted very specifically. Unfortunately it isn't like some screens where you can just convert an image into a C array and display it that way, the osd works with 12x18 pixel fonts (or characters) and also uses a sort of VLC compression method to save data. The OSD can use 16 colors total at one time with one of those colors being used for transparency and can use 1Bit, 2Bit, and 4Bit fonts. It only has 16.5K SRAM dedicated for the OSD and about 10K is actually usable, so your very limited on what you can do. On top of all of that, the RTD2660 uses a "small" memory model so when compiling the firmware, each file is limited to 64KB and under which i figured out the hard way.

Given all of this information, I started looking into how I could display my own logo and I spent a lot of that time stupidly not looking at the datasheet and trying to decipher the existing logos that were included with the firmware base I have. This whole thing was difficult for me as there's not a lot of information on the RTD2660 due to it being under NDA or something like that, so I thought I was on my own for a while. To sum things up, I spent a lot of time trying to interpret the code and going through the variety of image to lcd converters the internet has to offer. I felt defeated for the most part over something as simple as a logo as no matter what I used or tried, nothing was working.

Now at this point I thought that I had at least skimmed over everything related to the RTD2660 on the internet I could get my hands on, from forums, to writeups, to the few github repositories there are. I thought I was onto something when I found a python script on one github repository but it converted unifont.hex into a format the RTD could read and not convert an image like i wanted. I also looked into the program i was using to flash the RTD firmware as it has support for adding a logo, but it had specific limitations such as image size, the bit depth of the image (it would only support monochrome), and the fact that it was primarily for 3.5" screens using a specific firmware. It also only converted the image to a binary format and inserted itself into the firmware binary so it was no dice. Despite all of this, I was determined and my searching didn't stop there.

The other day I finally came across a tool that was specifically for my firmware base. This tool was exactly what I was looking for all along. The only caveat was that it was slightly broken, but I was able to import the bitmap image of my logo and have it convert it exactly to the proper format whilst generating my full logo.c and logo.h files. It took some messing around to get it to work properly and I had some issues where my logo wasn't converted right, or was too big, but it finally worked!

1000012238.jpg


Here is the tool as well:

The way it works is when the screen is turned on, the logo will display, then switch to the input, and if there's no signal, it'll show my logo as it essentially replaces the "no signal" notification. With this, I can finally cross 1 thing off my list and move onto the next. I may have also mentioned before that I was having trouble with the backlight as my firmware configured a different pin for turning on the backlight circuit than what the pcb had wired, but I was able to figure that out as well so no more bridging 3v3 to the backlight regulator.

Next on my list is de-interlacing support and adding support for 240p. I've been talking with some of the fellas about this and after looking at some things, we've determined that it isn't going to be as straight forward as we initially hoped, however I'm a very determined person, and with the help of some of the smart minds on here, I'm confident that we'll get somewhere with this. Right now I'm only sharing bits and pieces until we get things figured out and I find the best way to share the firmware.

That is it for now but rest assured, I'll be hard at work getting things sorted with this. Thanks for reading!
 
Joined
Aug 7, 2024
Messages
10
Likes
15
Would you be willing to share where you got the firmware source? Curious to see if it's worth trying to port it from Keil to SDCC.
 

Y2K

"The PS1 Guy"
Staff member
.
.
Joined
Apr 14, 2022
Messages
191
Likes
425
Location
Chicago, IL
Would you be willing to share where you got the firmware source? Curious to see if it's worth trying to port it from Keil to SDCC.
RTD2660 firmware & it's source code cannot be shared here since it's not supposed to be publicly accessible (This falls under our rules on intellectual property). You will have to locate a copy elsewhere in order to replicate what Legend is trying to do.

As for porting to SDCC, others have looked into it already, and the firmware source ships with a pre-compiled library that implements a standard set of functions for interacting with the rest of the chip. This library will either need to be fully reverse engineered and reimplemented to be compiled under SDCC, or a complicated workaround will have to be figured out.
 
Joined
Mar 8, 2025
Messages
2
Likes
1
Hello
As I am now solving a problem with a monitor that has an RTD2660 (RTD2662) in it. I bought a display for a CNC machine, I wanted to replace the old CRT screen with a new LCD. However, there was a problem. The image from the CNC is displayed on the new screen, but it is as if zoomed in and the edges are cropped. As I looked in the datasheet for RTD2660, it should be possible to set a border there, but I don't know if it will reduce or crop the image. Anyway, there are quite a few size settings that I could try.

My question is, is it somehow possible to edit the given parameters without uncompiled code? I bought the programmer with the FT232H, so I have the original binary saved. The question is, is there some code somewhere that I could modify myself and then compile. I would also like to know in which program the program for the RTD2660 can be compiled? I also looked at Keil, but there I am limited by the demo version.

The board in my display is labeled ZXD2660QC40 V1.7. It has 1x VGA, 1xHDMI, 1x AV + 2x audio and 1x BNC inputs. There is an RTD2660 on the board, but from what I have seen, it is said that it does not support HDMI. But RTD2662 already supports HDMI. I also forgot to mention, there is 128kB SPI FLASH (Pm25LQ010).
 

Legend

.
Joined
May 10, 2019
Messages
130
Likes
246
Location
Canada Boi
Portables
2
There may be settings you can mess with already in your driver boards specific firmware such as changing the aspect ratio and using auto adjust depending on the input but I'm not sure if your driver board has those settings as the firmware differs from each supplier as far as I know. That might be an option for you though!

As for modifying firmware, it's a little less straight forward unfortunately. You could technically modify the binary that you have but you would need that specific source code to know what your modifying, so that's unfortunately out of the question.

Even the firmware base I have for example is messy and a lot of things are either broken, or stripped out all together (like hdmi). You would also need a professional license keil to be able to compile it (which i have but had to jump through some sketchy hoops to aquire). I'm not able to upload the firmware base I have on the forums for legal reasons but if you have discord, you can find me on the bitbuilt or 4Layer discord and I may he able to share more information there for you if you want to look into the source code.
 
Joined
Mar 8, 2025
Messages
2
Likes
1
Hi
Thanks for the information. I contacted you on discord. We can disscuss there.
 
Top