Pixel To Tv Hdmi

[Lisbeth Balsiger]

Im currently designing a monitor solution for HDMI/DVI (no audio). I would have to support both 1280x800 pixel single-link LVDS display and 1920x1080 pixel dual-link LVDS display with the same electronics.

Since TI doesn't have single-chip solution, I was planning to use TFP401A for receiver and then DS90C3201 for LVDS serialization to display. For dual-link this seems quite straightforward, just connect TFP401A odd pixel outputs to DS90C3201 odd-pixel inputs and the same for even pixels. However, TFP401A uses even-pixel outputs in 1-pixel/clock mode, but DS90C3201 uses odd LVDS ports (odd-pixel TTL inputs). This would mean that I would need to design two different boards: one with direct odd-odd and even-even connection (dual-link) and one with even-odd connection (single-link). Have I understood the specifications correctly? Is there any way around this?

If I have understood correctly, DS90UB949/DS90UB948 combination might do what I'm looking for, but the ICs are much more expensive, you can get even single-chip Analog Devices ADV7613 HDMI to LVDS bridge with less.

However, in 1-pixel/clock mode (PIXS low), TFP401A outputs data on even pixel outputs only, odd pixel outputs are not used in 1-pixel mode. Now, TF401A even outputs are still connected to 387A even inputs starting from B20 (same PCB). Configuring DS90C387A for single pixel panel by grounding DUAL pin disables A4-A7 and CLK2, which get their input from even inputs. To clarify this, I've attached the table 4 from app note and crossed out the not used outputs and inputs.

So the problem is TFP401A, which outputs data on even outputs in single pixel mode, not on the odd outputs, which the 387A uses as inputs in single pixel mode. Everything would be ok if TF401A would use odd pixel outputs in single pixel mode, but it doesn't.

TFP401A can support up to 165MHz in single pixel output mode which can support both of the above configurations. So you can simply connect the EVEN (single link) outputs of TFP401 to the single link inputs of DS90C189 (odd inputs). But it won't matter because the link between TFP401 and DS90C189 is always single link.

DS90C189 and similar DS90C187 (about half the price) can both support SIDO. Unfortunately, they both use 1.8V Vdd and are not 3.3V tolerant so I would need to add fast level shifter or try if plain voltage divider in each signal would work.

3.3V DS90C387 can also be configured to SIDO mode with DUAL pin. The datasheet is a bit unclear about max clock frequency. In the description there's mention "32.5 to 112/170MHz clock support", but at the same time "the maximum pixel clock rate is increased to 112 MHz".

In the electrical characteristics there's TCIP (TxCLK IN Period) parameter. Minimum for SISO and DIDO modes is 8.928ns (112MHz) and for SIDO 5.88ns (170MHz). Can you confirm that is it ok to operate DS90C387 with up to 170MHz input clock in single-in/dual-out configuration as this would save me from using level shifter and also the 1.8V regulator?

Here are some colored lines. These are 1.5 pixels wide. The anti-aliased line draw has 8 sub-bits for each X, Y, and diameter. So, lines can be placed in X and Y at offsets of 256ths of a pixel. Line diameter is similar, but gets halved to make a radius in 256ths of a pixel. The minimum diameter is $100, or 1 whole pixel.

Is there a simple way to get it to build with flexspin or does it need to be PNut only? I was hoping to run this demo on my Mac however I immediately encountered two problems when I tried to build with flexspin...

Maybe I'll just have to wait to get some form of Windows running again...I am planning a dual boot MacBook Pro setup in time with a newer larger SSD fitted once I get to opening the thing and installing it.

Looking at LineDrawAntiAlias.spin2 I see a large DAT section starting with ORG with all RES declares then everything else is ORGH. I'm not sure what Flexspin will make of a DAT section like that but if it compiles that section then it shouldn't be hard to then make a SETREGS like function to match.

PS: I've got it working via Wine. The no-picture had me scratching my head for a while though. Had to double check each part of of the setup before discovering you had the horizontal blanking at only 16!

Will need to make a VGA patch... Though the monitor I've been using is kinda dying. I got a fancy new capture card that could do HDMI, but ran into some medium driver issues. So bad monitor situation currently.

My research on the topic has actually led me to believe that doing higher convex N-gons directly can be faster than just triangles. The setup is somewhat more complex, but that gets made up for when you draw a quadliteral in one go (instead of two triangles drawing adjacent spans). That also makes clipping easier - when the tip of a triangle pokes outside the screen, clipping actually turns it into a quadliteral. I think the worst case is a hexagon when all three tips are copped by different clip planes. Of course clipping a quad can turn it into an octagon, but there really isn't a difference between rasterizing quads vs octagons. Just need to iterate through more vertices. Though interpolating values across the face is somewhat more complicated (need to recalculate scale factor per scanline) but would generally be nicer than an affine transform. I think perspective-correct interpolation needs per-scanline work, anyways, so maybe it doesn't matter there. I really haven't fully worked it out, either.

All this timing was carry-in from the analog era. It seems that most of it can be squeezed out in HDMI. Sorry it was too short for your TV. I don't know what the minimum really is. This resolution was standard on many cell phones 12 years ago, but has since been eclipsed by higher resolutions.

Yeah, it seems quadrilaterals would be fine. Even triangles typically get broken into TWO triangles at rendering, so that each begins and ends on a common Y. A section identical to the screen memory can be maintained in the PSRAM to act as a per-pixel Z buffer. Only nearer pixels get written to the screen memory and the corresponding location in the Z buffer is updated with the new distance. By alpha-blending the polygons onto the screen, I think it would look pretty good.

One can do it like that, but you end up splitting the long edge then. It's better to think of "which side will need a new vertex next" and then grab the next one up/down (depending on wether you're loading a right or a left vertex) and then recalculate that edge only. This all needs a bit of thought since you can go through multiple vertices without crossing an integer scanline boundary where you'd actually get to draw anything.

It's either or. Blending and Z-Buffer don't mix, because you can't meaningfully render behind something that's already been drawn with semi-transparency. So depending on how you do it, you'll either have weird occlusion effects (when blended geometry updates Z buffer) or a weird layering issue where further away objects seem to be on top of near objects (when blended geometry only reads Z buffer) This has always been the case. If you want to blend any pixels with the existing buffer (including edge AA), you need to draw in back-to-front order (or, with Z-buffering, draw all opaque geometry first and then the blended geometry in-order. This is slightly relaxed if the blend mode is cumulative, i.e. you're doing add/sub or XOR blending. In such cases the blended geometry doesn't need to be sorted with itself, only with respect to the opaque stuff (no dice if you want to have both additive and alpha blend in the same scene though).

Of course, if you can sort the entire scene you can just toss the Z-buffer entirely. Loads of ways to do this, all slightly fiddly (BSP trees say hello!). The most general is to just have a load of buckets (between 256 and 1024 or so?) that you sort each primitive into based on the Z value of it's vertices. Generally the average of them all, but for something like the walls and floors of a room that objects may directly rub up against, you'd rather use the deepest vertex's Z to avoid sorting issues. This is how loads of CPU-only and early hardware 3D (Playstation 1, SEGA Saturn, etc) did it. PS1 documentations calls this method/the data structure "ordering table". This requires that geometry processing and pixel drawing are done as two phases. But it's always somewhat imperfect, of course. You can very easily create a construct that defies any attempt at sorting:

A BSP tree would split up such a construct and provides perfect ordering (not neccessarily perfect depth sorting! things that don't overlap can be in any order...) in all cases, but is only good for fully static geometry. Of course, since the order that things get added to a single ordering table bucket is relevant in itself, one could combine BSP and OT to get perfect sorting within each static object and approximate sorting between objects.

tl;dr; approaches to 3D graphics are infinite in number and infinitely interesting. Haven't even talked about the Quake edge-sorting algorithm (unlike many believe, quake does not use BSPs for ordering).

Wuerfel_21, I didn't say what I meant quite right. I know that alpha-blending whole polygons is impossible without Z-ordering per pixel. I meant to say that I would blend the edges, as in anti-alias them. I don't think this would have any detrimental effect. All polygons would be considered opaque, but the edges might as well get blended to reduce jaggies.

Huh, never expected that. My TV is also fussy about the vertical back porch (top blanking lines). It needs a minimum of 9 lines there. I had been unsure about where to place the vsync, so.it looks like there's more leeway when it's at the beginning of the blanking.

EDIT2: Uh-oh, so the vblanking has more complexity here. It can go lower when the vres is lower, which means it probably also requires more when the vres is higher ... or not. The 640 vres didn't need any more blanking ... and 640x800 is fine too ... 640x1080 also good. That's the max vertical.

3a8082e126