Legend
.
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.
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/
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
github.com
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.
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).
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.
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.
So I started looking for the other channels outlined in the datasheet and found the following:
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.
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.
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!
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.
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/
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
GitHub - floppes/RTD266xFlash
Contribute to floppes/RTD266xFlash development by creating an account on GitHub.
github.com
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.
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).
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.
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.
So I started looking for the other channels outlined in the datasheet and found the following:
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.
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.
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!
