- Joined
- Jan 31, 2016
- Messages
- 1,343
- Likes
- 2,882
- Portables
- 6
LumaDoub is a community project with the goal to create an open-source, low cost line doubler and transcoder solution. The vision for this project is not to create a specific product, but a framework and toolkit to be integrated in many other projects.
In its most basic state, LumaDoub should be able to:
Input:
-Accept Composite/Svideo/Component video
-Accept 240p or 480i (no 480p or greater)
-Auto detect NTSC, PAL, SECAM, etc.
Output:
-Component YPbPr
-Analog RGB (RGBS, VGA, etc)
-Simultaneous Composite and SVideo
-Line doubled 480p or passthrough 240p/480i
I expect the board should be quite simple, compact, with a low BOM and low power consumption.
I hope the output stage can be modular. For example, individuals may be able to add a second encoder chip for simultaneous video output of the lag free line doubled 480p to both an internal VGA screen, and a video-out port (like HDMI or possibly USB C).
I have yet to test this, but I hope we could process RGsB as YPbPr on both input and output to line double 15khz RGB to 31khz VGA. Will have to see how effective this is in time.
Once we get the basics working we can then see how far the project can be pushed.
Let's discuss where we are, and why it is needed...
In an ideal world, every portable would use direct drive for video. Direct drive FPGA boards are the endgame for video signal chain in portables. However, they must be custom designed for both for the individual console itself, and for the specific screen. For many builds, a direct drive solution is neither feasible nor practical.
For builds where direct drive isn't feasible, analog video is usually our only option. For the ever popular Wii portable, it's 480p output combined with the VGA patches yield some pretty good results.
But once you dive into 240p consoles, things start to get rough. The Nintendo 64, for example has 3 options for video output: Composite, Svideo, and RGBS. RGBS would be the ideal choice of the three (assuming you have the right revision and perform a mod), but almost no screens accept 15khz (240p) RGBS. Svideo is a step above composite, but suffers the same compatibility issue: almost no screens accept it. This leaves composite as our only viable option for video on most N64 portables. This is applicable for most 240p consoles, like the PS1, SNES, and Genesis.
Composite video is sophisticated under the hood, but in summary, the brightness information (luma) and color information (chroma) are mixed and squished down a single wire. They then need to be separated on the other side, usually through a comb filter. This process is not lossless, and results in a significant loss in fidelity. How much fidelity is lost is also dependent on the quality of the composite encoding and decoding circuitry. In this regard, you are at the mercy of the composite video decoding circuitry of your display, and results can vary.
Your screen has decoded your 240p composite video signal, but the problems don't end there. The standard for composite video is 480i, not 240p. To oversimplify, 240p takes advantage of trickery in the analog domain to send an off-spec video signal to display a progressive, lower resolution image. On old school CRTs, the timings were within tolerance, and the images was blasted onto the screen. For modern digital displays, most screens are not designed to recognize this off-spec 240p signal, and will instead interpret it as 480i. This means the image will be incorrectly processed, and the screen will attempt to deinterlace the image. This can result in persistent visual artifacts as the image is incorrectly scaled, as well as add latency (lag, usually over 1 frame) to your signal chain.
This solution is built using 3 primary chips: a decoder, an encoder, and a microcontroller to control them.
ADV7280A (Analog decoder and line doubler)
This inexpensive and versatile chip is capable of accepting and digitizing Luma-based video signals (Composite, Svideo, and Component) from every region (NTSC, Pal, SECAM, etc). It can pass through the signals as 240p/480i, or line double it to 480p with effectively zero lag (I have played duck hunt on a 480p crt using an ADV7280 based line doubler). The older version of this chip, the ADV7280, is the primary engine under the hood of many products such as the RetroTink 2x line of products. This chip is extremely versatile, with so many settings to tweak and tune through registers.
ADV7391 (Video encoder)
The ADV7280A spits out a digital video signal into the ADV7391. The ADV7391 is capable of converting that digital video stream to either analog RGB, or Component (YPbPr), depending on which register you set. Hsync and Vsync are available as well. The result is you have access to lag free, line doubled 480p Component or VGA output to connect to screens.
Microcontroller (tbd)
Both of the Analog Devices chips are configured using an i2c bus. Therefore, we need a microcontroller to configure them. The chips only require a few commands to get up and running, but have lots of customizability. For early testing and development, my bench setup will be using an RP2040, but it is likely overkill.
This exact same "ADV7280A + ADV7391 + Microcontroller" setup is utilized on Analog Device's evaluation board.
The evaluation board includes schematics that seem pretty simple and straightforward. This could easily be replicated on a custom PCB.
ADV7280A Schematic (input/decoder/adc)
ADV7391 Schematic (output/encoder/dac)
The eval board is almost $200, but I have found an alternative. The McBazel ODV2 looks like a retrotink 2x clone from the outside, but on the inside, it's far closer to the original evaluation board. While both use a 7280 for the analog decoder, the ODV utilizes a 7391 for component video output instead of HDMI, as well as a different microcontroller.
Here is my bench setup.
For now I have lifted the i2c pins of the onboard mcu and run them to a switch. This allows me to switch back from the pico to the onboard MCU to do a "sanity check" and make sure the board is still functional.
For now, the goal is to figure out i2c communication with the chip. Once we can take control and get video output, we can start to experiment with registers, and design a new PCB layout.
In its most basic state, LumaDoub should be able to:
Input:
-Accept Composite/Svideo/Component video
-Accept 240p or 480i (no 480p or greater)
-Auto detect NTSC, PAL, SECAM, etc.
Output:
-Component YPbPr
-Analog RGB (RGBS, VGA, etc)
-Simultaneous Composite and SVideo
-Line doubled 480p or passthrough 240p/480i
I expect the board should be quite simple, compact, with a low BOM and low power consumption.
I hope the output stage can be modular. For example, individuals may be able to add a second encoder chip for simultaneous video output of the lag free line doubled 480p to both an internal VGA screen, and a video-out port (like HDMI or possibly USB C).
I have yet to test this, but I hope we could process RGsB as YPbPr on both input and output to line double 15khz RGB to 31khz VGA. Will have to see how effective this is in time.
Once we get the basics working we can then see how far the project can be pushed.
Let's discuss where we are, and why it is needed...
In an ideal world, every portable would use direct drive for video. Direct drive FPGA boards are the endgame for video signal chain in portables. However, they must be custom designed for both for the individual console itself, and for the specific screen. For many builds, a direct drive solution is neither feasible nor practical.
For builds where direct drive isn't feasible, analog video is usually our only option. For the ever popular Wii portable, it's 480p output combined with the VGA patches yield some pretty good results.
But once you dive into 240p consoles, things start to get rough. The Nintendo 64, for example has 3 options for video output: Composite, Svideo, and RGBS. RGBS would be the ideal choice of the three (assuming you have the right revision and perform a mod), but almost no screens accept 15khz (240p) RGBS. Svideo is a step above composite, but suffers the same compatibility issue: almost no screens accept it. This leaves composite as our only viable option for video on most N64 portables. This is applicable for most 240p consoles, like the PS1, SNES, and Genesis.
Composite video is sophisticated under the hood, but in summary, the brightness information (luma) and color information (chroma) are mixed and squished down a single wire. They then need to be separated on the other side, usually through a comb filter. This process is not lossless, and results in a significant loss in fidelity. How much fidelity is lost is also dependent on the quality of the composite encoding and decoding circuitry. In this regard, you are at the mercy of the composite video decoding circuitry of your display, and results can vary.
Your screen has decoded your 240p composite video signal, but the problems don't end there. The standard for composite video is 480i, not 240p. To oversimplify, 240p takes advantage of trickery in the analog domain to send an off-spec video signal to display a progressive, lower resolution image. On old school CRTs, the timings were within tolerance, and the images was blasted onto the screen. For modern digital displays, most screens are not designed to recognize this off-spec 240p signal, and will instead interpret it as 480i. This means the image will be incorrectly processed, and the screen will attempt to deinterlace the image. This can result in persistent visual artifacts as the image is incorrectly scaled, as well as add latency (lag, usually over 1 frame) to your signal chain.
This solution is built using 3 primary chips: a decoder, an encoder, and a microcontroller to control them.
ADV7280A (Analog decoder and line doubler)
This inexpensive and versatile chip is capable of accepting and digitizing Luma-based video signals (Composite, Svideo, and Component) from every region (NTSC, Pal, SECAM, etc). It can pass through the signals as 240p/480i, or line double it to 480p with effectively zero lag (I have played duck hunt on a 480p crt using an ADV7280 based line doubler). The older version of this chip, the ADV7280, is the primary engine under the hood of many products such as the RetroTink 2x line of products. This chip is extremely versatile, with so many settings to tweak and tune through registers.
ADV7391 (Video encoder)
The ADV7280A spits out a digital video signal into the ADV7391. The ADV7391 is capable of converting that digital video stream to either analog RGB, or Component (YPbPr), depending on which register you set. Hsync and Vsync are available as well. The result is you have access to lag free, line doubled 480p Component or VGA output to connect to screens.
Microcontroller (tbd)
Both of the Analog Devices chips are configured using an i2c bus. Therefore, we need a microcontroller to configure them. The chips only require a few commands to get up and running, but have lots of customizability. For early testing and development, my bench setup will be using an RP2040, but it is likely overkill.
This exact same "ADV7280A + ADV7391 + Microcontroller" setup is utilized on Analog Device's evaluation board.
The evaluation board includes schematics that seem pretty simple and straightforward. This could easily be replicated on a custom PCB.
ADV7280A Schematic (input/decoder/adc)
ADV7391 Schematic (output/encoder/dac)
The eval board is almost $200, but I have found an alternative. The McBazel ODV2 looks like a retrotink 2x clone from the outside, but on the inside, it's far closer to the original evaluation board. While both use a 7280 for the analog decoder, the ODV utilizes a 7391 for component video output instead of HDMI, as well as a different microcontroller.
Here is my bench setup.
For now I have lifted the i2c pins of the onboard mcu and run them to a switch. This allows me to switch back from the pico to the onboard MCU to do a "sanity check" and make sure the board is still functional.
For now, the goal is to figure out i2c communication with the chip. Once we can take control and get video output, we can start to experiment with registers, and design a new PCB layout.
Last edited:
