BocuD
.
TLDR: Ahrlad and me have been working on a custom firmware, look at features for the memes. Currently its not ready for release yet.
Introduction
@ahrlad and me have been working on some spicy memes for RTD2660 / RTD2662 based lcd driver boards. After a few months of work, we have it to a point where its useable rn, but not exactly great yet. A few months ago he mentioned working on the firmware and how he had something that was compiling. I was intrigued, so I started working on it as well. We screwed around for a while longer, slowly getting to know the codebase, which was shitty to say the least lmao. Everything was in one way super portable, made to run on at least a few different scalers / configurations. This is good in one way, but the implementation is kinda shitty with a bunch of defines everywhere and #ifs in every file. Other then that everything was in crappy English. Some neat examples: LANGUGAE, Emluator, Virutal_screen (yes this is actually copy pasted)
After first trimming a lot of shit from the at that point working firmware, we started working on fixing things like VGA inputs (we only had composite working from the working source). This turned out to be harder then expected, so we went back to dark corners of the internet searching for leaked firmwares.. And well, we found like 10 more incomplete sources, but a bit later, we found a firmware that was perfect to start from.
This one had VGA and Composite already working, with SVideo and the rest being broken. The nice part however though, was that someone seemed to have already cut out a bunch of crap that was in the other sources. This one already had most language and TV stuff removed, with us nuking the rest in the next few days. The OSD was much more barebones and simple to modify. So at this point, after removing the last traces of TV support and different languages (these would just take up space that we can't afford) we started a github repository, adding a number of features in the next few weeks.
Currently supported board / panel configurations
Panels:
- HSD050xxx and equivalents (for example the panel in the Eyoyo and pretty much every 40 pin panel under 7" on buydisplay)
- AT070TN9x and equivalents
Boards:
- PCB800050
- PCB800099
Features
Currently the supported features from the original firmware are:
- VGA input
- Composite input
- 16:9/4:3 switch
- Brightness / contrast adjustment - the usual stuff
There are also some new features that weren't in the firmware we are basing this on:
- SVideo input
- Independent VGA H/V position adjustment from the OSD
- Fixed VGA auto adjust - it doesn't suck anymore now
- GPIO access - PWN outputs on most GPIOs and 6 bit ADCs on all of them, 10 bit ADCs on a few
- Improved OSD - No blue screens, no source dialogs unless switching sources
- Support to add a custom startup logo - so for example a splash screen with a nice icon or an Eyoyo logo (hehe)
Features that are semi working / planned:
- YPbPr support (we're pretty close to done here)
- Interlaced VGA support (also pretty close here)
- Independent VGA H/V scaling - Currently works, but not yet from the OSD
- Transform features for other inputs - This makes it possible to adjust the image perfectly to your case, as long as the bezel slightly covers at least one pixel of the visible area.
- Acting as an i2c master - Currently the mcu can act as a slave, which is used to program the eeprom and for debugging. If it can act as a master as well it could be used to control for example an audio amplifier directly from the lcd driver, eliminating the need for another separate mcu and simplifying volume control and a HUD for this.
And now the main meme, support for Wiihud like elements. This could include things like a volume hud, battery status, charging notifications, things like that. Currently there's just the changes necessary in the code to support it and not really any finished UI stuff, but it does work, so there's that.
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.
Limitations of the OSD
Color: The bitmaps are limited to 1, 2 or 4 bit color. A color in the pallete can be any 24 bit color, so any color can be used. There can only be 16 colors at the screen at one time though, one of them being used for transparency. So choices will have to be made here. Given that the pallete can be swapped there isn't a limit of possible images, but you can't have a volume indicator with 8 different colors if the OSD configuration menu thing uses 10. Colors in the pallete need to be dedicated for certain functions as well, as you can't rearrange the color info in the bitmaps. If the bitmap specifies that color 12 is #9859e6 in one case, that means as long as you have an element on screen using color 12 as that color, you can't use it for anything else.
Space: A 4 bit bitmap can get pretty large in no time if you only have 16.5K. Usually only about 10K of this is even useable as its used for other things as well, not just storing the fonts/bitmaps. This means you can't just have a bunch of large images on screen. A full ascii font for example (parts of this can be used for other purposes) contains 128 characters. Thats about 27000 pixels, so about 4K to store just that one font, if you store it in a 1 bit color. Luckily there is compression to the rescue, as the scaler natively supports a form of VLC compression which usually cuts the size about in half, depending on the content of the bitmap. This brings us down to ~1.7K for a full 1 bit font. This is where choices have to be made as well, as a 2 bit font would give you a bit of anti aliasing, but use part of your precious palette. Even worse would be a 4 bit font. This would look nice, however.
Transparency: The scaler supports a limited form of transparency. One color in the palette is always reserved for this purpose. There is no such thing as opacity though, so its always either opaque or transparent. So to use any sort of anti aliasing you will need to know what you are drawing the bitmap on, or dynamically adjust the palette depending on the background. Keep in mind that there are still only 16 colors, and the OSD has no idea what is drawn below it by the input source (eg a VGA input) so you can only draw on other OSD parts.
Windows: This is less of a limitations and more of a nice feature to make everything better. This feature can be used to draw rectangles on the screen on the background layer of the OSD, behind the bitmap layer. Some neat functions of this are: It supports actual opacity. The window layer is "mixed" with the framebuffer of the actual scaler, making "blending of color" (yay chinese datasheet) or opacity a thing. There can be 8 windows at any given time, each with its own color and opacity. The color sadly needs to be one from the main color palette, but given the opacity control its not as bad. This will allow to create "switch like" notifications with a semi transparent background, and it makes it possible to create semi transparent windows for the settings OSD as well. You can then use it to create windows on top of each other and cool shit like that. Other then this it supports primitive shadows and 3d borders and stuff.. Well its from 2004, what did you expect lol.
Obligatory video:
This demonstrates the VGA H/V position adjustments on a scaled VGA input. That panel is broken btw, it has a few fucked lines in the FFC and the lcd is broken as well, so the image is less stable. It looks really good on the panel I'm using in my portable:
No releases for now, but once the firmware is complete enough to be a usable in a portable there will be at least binary releases. It will all eventually be open sourced as well, though we're still thinking of a good way of doing this with minimal risk of Realtek lawsuits lmao.
Introduction
@ahrlad and me have been working on some spicy memes for RTD2660 / RTD2662 based lcd driver boards. After a few months of work, we have it to a point where its useable rn, but not exactly great yet. A few months ago he mentioned working on the firmware and how he had something that was compiling. I was intrigued, so I started working on it as well. We screwed around for a while longer, slowly getting to know the codebase, which was shitty to say the least lmao. Everything was in one way super portable, made to run on at least a few different scalers / configurations. This is good in one way, but the implementation is kinda shitty with a bunch of defines everywhere and #ifs in every file. Other then that everything was in crappy English. Some neat examples: LANGUGAE, Emluator, Virutal_screen (yes this is actually copy pasted)
After first trimming a lot of shit from the at that point working firmware, we started working on fixing things like VGA inputs (we only had composite working from the working source). This turned out to be harder then expected, so we went back to dark corners of the internet searching for leaked firmwares.. And well, we found like 10 more incomplete sources, but a bit later, we found a firmware that was perfect to start from.
This one had VGA and Composite already working, with SVideo and the rest being broken. The nice part however though, was that someone seemed to have already cut out a bunch of crap that was in the other sources. This one already had most language and TV stuff removed, with us nuking the rest in the next few days. The OSD was much more barebones and simple to modify. So at this point, after removing the last traces of TV support and different languages (these would just take up space that we can't afford) we started a github repository, adding a number of features in the next few weeks.
Currently supported board / panel configurations
Panels:
- HSD050xxx and equivalents (for example the panel in the Eyoyo and pretty much every 40 pin panel under 7" on buydisplay)
- AT070TN9x and equivalents
Boards:
- PCB800050
- PCB800099
Features
Currently the supported features from the original firmware are:
- VGA input
- Composite input
- 16:9/4:3 switch
- Brightness / contrast adjustment - the usual stuff
There are also some new features that weren't in the firmware we are basing this on:
- SVideo input
- Independent VGA H/V position adjustment from the OSD
- Fixed VGA auto adjust - it doesn't suck anymore now
- GPIO access - PWN outputs on most GPIOs and 6 bit ADCs on all of them, 10 bit ADCs on a few
- Improved OSD - No blue screens, no source dialogs unless switching sources
- Support to add a custom startup logo - so for example a splash screen with a nice icon or an Eyoyo logo (hehe)
Features that are semi working / planned:
- YPbPr support (we're pretty close to done here)
- Interlaced VGA support (also pretty close here)
- Independent VGA H/V scaling - Currently works, but not yet from the OSD
- Transform features for other inputs - This makes it possible to adjust the image perfectly to your case, as long as the bezel slightly covers at least one pixel of the visible area.
- Acting as an i2c master - Currently the mcu can act as a slave, which is used to program the eeprom and for debugging. If it can act as a master as well it could be used to control for example an audio amplifier directly from the lcd driver, eliminating the need for another separate mcu and simplifying volume control and a HUD for this.
And now the main meme, support for Wiihud like elements. This could include things like a volume hud, battery status, charging notifications, things like that. Currently there's just the changes necessary in the code to support it and not really any finished UI stuff, but it does work, so there's that.
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.
Limitations of the OSD
Color: The bitmaps are limited to 1, 2 or 4 bit color. A color in the pallete can be any 24 bit color, so any color can be used. There can only be 16 colors at the screen at one time though, one of them being used for transparency. So choices will have to be made here. Given that the pallete can be swapped there isn't a limit of possible images, but you can't have a volume indicator with 8 different colors if the OSD configuration menu thing uses 10. Colors in the pallete need to be dedicated for certain functions as well, as you can't rearrange the color info in the bitmaps. If the bitmap specifies that color 12 is #9859e6 in one case, that means as long as you have an element on screen using color 12 as that color, you can't use it for anything else.
Space: A 4 bit bitmap can get pretty large in no time if you only have 16.5K. Usually only about 10K of this is even useable as its used for other things as well, not just storing the fonts/bitmaps. This means you can't just have a bunch of large images on screen. A full ascii font for example (parts of this can be used for other purposes) contains 128 characters. Thats about 27000 pixels, so about 4K to store just that one font, if you store it in a 1 bit color. Luckily there is compression to the rescue, as the scaler natively supports a form of VLC compression which usually cuts the size about in half, depending on the content of the bitmap. This brings us down to ~1.7K for a full 1 bit font. This is where choices have to be made as well, as a 2 bit font would give you a bit of anti aliasing, but use part of your precious palette. Even worse would be a 4 bit font. This would look nice, however.
Transparency: The scaler supports a limited form of transparency. One color in the palette is always reserved for this purpose. There is no such thing as opacity though, so its always either opaque or transparent. So to use any sort of anti aliasing you will need to know what you are drawing the bitmap on, or dynamically adjust the palette depending on the background. Keep in mind that there are still only 16 colors, and the OSD has no idea what is drawn below it by the input source (eg a VGA input) so you can only draw on other OSD parts.
Windows: This is less of a limitations and more of a nice feature to make everything better. This feature can be used to draw rectangles on the screen on the background layer of the OSD, behind the bitmap layer. Some neat functions of this are: It supports actual opacity. The window layer is "mixed" with the framebuffer of the actual scaler, making "blending of color" (yay chinese datasheet) or opacity a thing. There can be 8 windows at any given time, each with its own color and opacity. The color sadly needs to be one from the main color palette, but given the opacity control its not as bad. This will allow to create "switch like" notifications with a semi transparent background, and it makes it possible to create semi transparent windows for the settings OSD as well. You can then use it to create windows on top of each other and cool shit like that. Other then this it supports primitive shadows and 3d borders and stuff.. Well its from 2004, what did you expect lol.
Obligatory video:
This demonstrates the VGA H/V position adjustments on a scaled VGA input. That panel is broken btw, it has a few fucked lines in the FFC and the lcd is broken as well, so the image is less stable. It looks really good on the panel I'm using in my portable:
No releases for now, but once the firmware is complete enough to be a usable in a portable there will be at least binary releases. It will all eventually be open sourced as well, though we're still thinking of a good way of doing this with minimal risk of Realtek lawsuits lmao.
