Worklog LumaDoub: An Open Source Line-Doubler and Transcoder

Shank

Moderator
Staff member
.
.
Joined
Jan 31, 2016
Messages
1,324
Likes
2,834
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)
-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.
EVAL-ADV7280AEBZTOP-web.png


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)
JMQOelM.png


ADV7391 Schematic (output/encoder/dac)
epdxCqJ.png


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.

PXL_20240906_003829867.jpg

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:
Joined
Dec 29, 2016
Messages
98
Likes
36
Super excited for this, looking a cheap way to hook Wii’s to VGA for a video game literacy unit in the media arts class I teach
 

Shank

Moderator
Staff member
.
.
Joined
Jan 31, 2016
Messages
1,324
Likes
2,834
Portables
6
Super excited for this, looking a cheap way to hook Wii’s to VGA for a video game literacy unit in the media arts class I teach
This would be a suboptimal way to do so, as it will only accept 480i/240p for the input. You would want a YPbPr to VGA transcoder.

Additionally, the plan for now is an open source project to be integrated and reused elsewhere, rather than a complete product to sell. The primary goal here isn't to make something to sell, but to put some tools out there to push the scene forward.
 

Shank

Moderator
Staff member
.
.
Joined
Jan 31, 2016
Messages
1,324
Likes
2,834
Portables
6
Exciting progress today.

After several days of troubleshooting, we finally have control of the chips through the i2c bus. (We had a very weird issue with the reset pin and command). Once we got the first example script working, and video on the screen, we could finally experiment with flipping registers.
Here we have 480i RGsB output, using the internal color bar test pattern output. This is one of several configurable options for output when no input is recognized.
PXL_20240910_195757634.jpg

RGsB, also known as "Sync on Green" or "SoG" is RGB video, where the sync is, or course, on the green line. This is similar to how, for YPbPr, sync is on the Luma (aka "Y", aka "the green plug") line. This is done because DAC only has 3 outputs. The chips also have a HSync and VSync lines running between them, which can be tapped for RGBHV, also known as VGA. The separate, composite sync for RGBS could be created in a number of ways; such as extracting it from the green line, or combining the separate H and V sync lines.


Flipping a few more registers, we get composite input, RGsB output.

PXL_20240910_202609157.MP.jpg


Neato, what about composite output?
PXL_20240910_211339615.jpg

Trippy! Here's what I think is going on here. When the ADV7391 (DAC, output chup) is outputting 240p composite, something with the chroma phase/timings messes up. 240p component/rgb output are fine. 480i composite output is fine. It's just specifically the output combination of composite output and 240p output.

This can be fixed by flipping a specific register for progressive SD. However, doing so also has the consequences of forcing all 15khz outputs to be 240p. So you would want to only enable this mode specifically when outputting 240p composite signals. I will say, this "forcing 240p" is a feature I have wanted on devices before, so it would be a cool thing to integrate.

We got composite and component inputs working. Also confirmed composite, component, and RGB outputs. Haven't tested svideo yet, but should be no issue.

Excited to mess with the line doubling and the internal anti-aliasing filter that looks like vaseline smeared on the screen. Seems that aa filter works differently than what's documented, so I'll need to look into that.

We have also set up a (private for now) git repository, and I have begun work on a custom dev board for this project. As for why I'm saying "we" for many of these projects, that's because I have a secret weapon working on this project with me. I'll discuss that in a future post.

Super exciting. So much potential in these little chips. Excited to keep working on this.
 

1hedu

.
Joined
Sep 21, 2024
Messages
2
Likes
0
Incredible. Stars really aligned I've been working on this same thing for about as long as this thread. It's kind of shifted and evolved but I'm looking for

-Accept Composite/Svideo/Component video/RGsB/RGBS(csync)
-Accept 240p or 480i (no 480p or greater)
-Auto detect NTSC, PAL, SECAM, etc.

Output:
-Line doubled 480p

I'm pretty much learning as I plan, and have ordred a few versions of BOMs for this, none have arrived, but realized where I thought for a while maybe I could try to just kick up hsync 31khz to make 480i display over vga, I should give up on that. Even if somehow it could work, the uncertainty isn't worth it.

Anyway I'd considered these chips, glad to see you've thought of an elegant solution. Ordered some How can I help?
 

Shank

Moderator
Staff member
.
.
Joined
Jan 31, 2016
Messages
1,324
Likes
2,834
Portables
6
Appreciate the interest! I will likely need help once I get the ball rolling.

For now, I'm finishing up the design of a custom development board. It'll have lots of switches and solder jumpers to test and change all sorts of features and options. Primary pico and dev pico on board, lots of switches, RGB to YPbPr transcoder, regulators with shunt resistors to measure power consumption per rail... Lots of fun stuff. Will be super useful for testing.

RJKJ6NA.png
 

1hedu

.
Joined
Sep 21, 2024
Messages
2
Likes
0
Roger that, I'll be here.

Love the pico. Looking great, very exciting!
 
Top