TV output wing


ben

Recommended Posts

Nice !

Just a detail : the 7 bits of the dac are not related to the number of colors that can be displayed. The colors are phased coded so you can output virtually any number of colors even with fewer bits. To be more technical, the number of bits limit the resolution of luminance and  saturation, but not hue (the Papilio clock does)

The given vhdl code holds a table of coefficients for 64 'colors' (6 bits rgb) but you could do more. I guess 512 colors (atari st style) would be reasonable: any finer details would be drowned in the noise of the color carrier digital generator.

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

There is no 'formula', the colors are just coded in YUV format. See pp 267-268 of http://www.deetc.isel.ipl.pt/analisedesinai/sm/downloads/doc/ch08.pdf for more details.

The principle is simple: do nothing fancy for sync and Y, and generate two square (+1/-1) signals at the color carrier frequency (one in phase, one in quadrature). Add  sync and Y to get a monochrome image, and add the square signals multiplied by U (resp. V) to get color. As I use square signals (instead of sine), the multiplication is actually trivial (+U/-U, +V/-V)

The actual number of colors that can be output is limited by the resolution of the DAC, and by the precision of the color clock. As I use square signals and a (good but not perfect) approximation of the color clock, and because Y interferes with the color signal, the output is far from perfect. That's why I say that 512 seems a reasonable maximum: beyond that, my guess is you won't see the differences, because the will be hidden by the noise resulting from these approximations.

You could make the signal better by:

- using a better approximation of the sine for the U/V carriers (store values in rom and pipe through a hardware multiplier), but this shouldn't make much of a difference: the harmonics created by the square signal should be filtered out by the TV demodulator. Perhaps this could help the TV catching up  on the phase swings (to get rid of the dark pixels on blue=>yellow or green=>magenta frontiers)

- using an external, crystal clock, or improve the precision of the digital clock. This should remove some of the dot crawl (it scrolls down fast so it looks like a blur, but tht's not much better for the resulting image) An external oscillator would not allow a software PAL/NTSC switch, though.

- filter the Y signal to cut the high frequencies that mess with the color carrier. not easy to do digitally (you still have those nasty steps), so you would have to use two DAC (one for Y, one for UV) with a low-pass filter on Y, and an analog adder.

I haven't tried any of these, but my guess is that the last problem (Y interfering with U/V) is the biggest issue, and the harder to solve while keeping the wing simple and passive. If you really wanted a better picture and were ready to invest in a wing that really does some work, you'd be better off switching to a dedicated chip to convert RGB (e.g. AD725).

My initial target  was more of a proof of concept, anyway, and the results are actually far beyond what I dreamt of... But any suggestions to make it better are still welcome !

Link to comment
Share on other sites

  • 4 weeks later...

Hello Ben,

So I was thinking it would be really cool to see if we could output games like Pacman using this TV Wing. I started looking at the code and I see that we would need to feed RGB into the encoder in [222 RGB (r1r0g1g0b1b0)] format. I also see that the Pacman source code has a NTSC mode which I'm assuming, maybe totally wrong, that the hsync signal could drive the sync signal of the ntsc_encoder module. But I start to have questions about what to do with line_visible and line_even.

Do you have any words of wisdom to get us on the right path with NTSC/PAL output for the Arcade games?

I also remember that you mentioned you made some changes to the code to get the demo working, do we need those changes to make the color bar example work for NTSC?

Thanks,

Jack.

Link to comment
Share on other sites

So I was thinking it would be really cool to see if we could output games like Pacman using this TV Wing.

That would indeed be very cool.

I started looking at the code and I see that we would  need to feed RGB into the encoder in [222 RGB (r1r0g1g0b1b0)] format.

 

  You might want to reverse B and G if the colors come out wrong -- I spent quite a while trying to figure that out, and I'm not sure the comments are right in the version I posted.

I also see that the Pacman source code has a NTSC mode which I'm assuming, maybe totally wrong, that the hsync signal could drive the sync signal of the ntsc_encoder module. But I start to have questions about what to do with line_visible and line_even.

line_visible should be set only outside of vbl (you'll want to check the spec, but I'd say lines 25-230 sould be ok) -- otherwise you end up with a colour burst in the way of the sync signal. It might be harmless, but it's definitely not in the spec. What would be nice would be to write a vbl detector... it was overkill for a project where I actually knew if the line was visible or not, but it might come handy in adapting other designs.

line even is for pal. you just need to set it every other line, to get the 'phase alternated lines' (that's where 'PAL' comes from). Again, I had it for free in my SMS (it's the low bit of the line counter) but it would be handy (and very easy) to make that automatic.

  I also remember that you mentioned you made some changes to the code to get the demo working, do we need those changes to make the color bar example work for NTSC?

check the code on github for the latest version, the one I posted initially was buggy (errors in the pal implementation, wrong frequency for ntsc):  https://github.com/ben0109/Papilio-Master-System/tree/master/vhdl/src (color_encoder and yuv_table)

I also attach the color bar demo, so you can see (in the *_video.vhd) files what signals should be fed to the color encoder.

please let me know if you can get it to work.

Ben

tv_output.zip

Link to comment
Share on other sites

I got the color bar working with your updated code now.

I included your ntsc encoder and we are passing synthesis. When I connect to the tv there is definitely output but the timing is off and it just looks like lines. I guess my next step is to read up on ntsc and vga specifications to better understand what timing changes need to be done.

jack.

Link to comment
Share on other sites

I got the color bar working with your updated code now.

great.

When I connect to the tv there is definitely output but the timing is off and it just looks like lines. I guess my next step is to read up on ntsc and vga specifications to better understand what timing changes need to be done.

I recommend http://www.deetc.isel.ipl.pt/Analisedesinai/sm/downloads/doc/ch08.pdf. A bit long, but everthing you need to know about PAL and NTSC is in there. You'll want to check timings for 'M' (525 lines, 30Hz) for North America TVs.

BTW, you can skip the whole "color encoding" thing at first, just adding bits from the rgb output to the sync signal. You'll get a monochrome image with wrong luminance values, but this is very useful to make sure you've got the timings right as the image is easily recognizable if it's right, a a big mess if it isn't. Then you can switch on the colors, and solve the new issues (hopefully: none) without wondering whether you got the basics right or not.

[url=http://www.gadgetfactory.net/gadgetforum/

]
Link to comment
Share on other sites

Ben: you're not attending ISEL, are you ? Just asking because it's rare to see links to portuguese universities. :)

not at all... this links just happens to be on the wikipedia page, and it's indeed a great reference. even better for me, it's not in portuguese !

Link to comment
Share on other sites

Sweeeet! It's working now!  ;D

After doing some more reading I realized that I needed to be using a composite sync signal, not just the hsync. And finally, I needed a little code that drove line_visible when the vcount was between 25-230.

Once I got those sorted out the ntsc video popped up in full color! Of course it was really simplified by the fact that the Pac-man code was already written to generate ntsc timings and the composite sync signal. So in reality there was not much I had to do besides understand what was going on. :)

I think it would be really great to set up this NTSC/PAL core so that you can connect either NTSC RGB (with  composite sync or separate hsync and vsync), or VGA RGB with hsync and vsync at twice the speed of NTSC. I think it will be pretty common for people to have VGA output in existing projects and it would be very nice if people only have to make the connections and not worry about anything else.

Jack.

Link to comment
Share on other sites

Sweeeet! It's working now!  ;D

Once I got those sorted out the ntsc video popped up in full color

I think it would be really great to set up this NTSC/PAL core so that you can connect either NTSC RGB (with  composite sync or separate hsync and vsync), or VGA RGB with hsync and vsync at twice the speed of NTSC. I think it will be pretty common for people to have VGA output in existing projects and it would be very nice if people only have to make the connections and not worry about anything else.

Great. How does the image look, as compared to vga ?

About the 'plug and play' core: this is something I had in mind too, but I'm not sure you can use the same signals. What would be easy to do is an equivalent of the ad725, that takes care of the composition of h and v sync and of the line counter for you: you provide h sync, v sync and rgb, and it outputs pal or Ntsc, or vga (doing nothing then). You would 'only' need to adapt the length and the number of lines according to the output.

Link to comment
Share on other sites

VGA is much nicer, there is a bit of flickering of the lines that make up the maze walls. I'm wondering if that is maybe from using 5% resistors instead of 1% resistors.

Wrong resistor values produce exactly the same errors on every frame, so they shouldn't cause flickering. I'd say the approximations of the color carrier (square instead of sine, jitter) and the interferences between luminance and color are much more likely. Indeed, I once tried to reset the color clock at every line : it stopped much of the flicker, but then the other interferences are very much more annoying... (I found out later that the color clock frequencies are indeed chosen precisely to avoid this)

I have a few ideas to make the image better, which I could not find the time to test yet:

1) use better approximation of sine waves (0, +/-0.5 and +/-1 instead of just +/-1)

2) insert a low pass filter on luminance, to simulate the "luma trap" that can be set up with analog converters (careful with that, though, as it could blur the image if it is not tuned very precisely)

3) make the color clock more precise: reset it on every frame ? use a higher clock frequency to reduce jitter (I tried 128 MHz, it made the p&r process much slower without any visible improvement, but that my be worth another try with other tricks)

Link to comment
Share on other sites

  • 1 month later...
Guest CaScAdE

There are a lot of projects doing this on AVR and ARM µCs... But overlay only in black/white AFAIK...

Like:

http://code.google.com/p/super-osd/

http://www.ulrichradig.de/home/index.php/arm/pal_video

Maybe looking at the code and understanding their basic sync-stuff would be an idea...

Would be my plan for the next free-time, but maybe someone has got some time left for such stuff :)

Link to comment
Share on other sites

You can get that 3v comparator with differential IO inputs. Or eventually with an external fast opamp (rail-to-rail).

The other ones are trickier. Suggestions ? Would a ADPLL work in this scenario ? Or eventually use the internal PLL with an external comparator/diffIO to generate the appropriate timings ?

Alvie

Link to comment
Share on other sites

Hmmm, maybe finding a chip that does all the heavy lifting and making it into a Wing would be the path of least resistance here.

obviously. you could use a stock pal/ntsc encoder too. but where would be the fun ?

For HDMI this is much, much easier!

Actually, SCART is designed to handle  overlays : around the composite signal wire, you've got rgb and source (to choose between composite signal or rgb). Using that, you "just" need to read the sync signal, and output an rgb overlay (using 3 r-2r ladders, for instance) and the switch signal (digital io is just fine for that).

thinking again, i'd say that you only need a fast comparator (one that can handle ~5MHz precisely). tune it at the right level (0.2V ?) and you can spot :

  • sync at 0V: low for a long time
  • back porch at 0.3V: high
  • color burst, that is a sine around 0.3V: square signal, but not symmetrical (depending on the comparator, duty cycle from 0% to nearly 50%)

as the timing are precise, you know when to look for the color burst, so you can get a phase.

But :

  • you are assuming that the frequency of the color carrier is exactly the one you expect: as it's most probably not, be prepared for hue errors at the right of the screen ;
  • the switch level of the comparator changes the phase of the digital signal: you can try and correct it by adding a constant phase but, again, expect some hue errors (on the entire screen)

  of course, as the color burst last for 10 cycles, you could try a linear regression to get the exact frequency and phase, to get rid of the first issue. perhaps the internal pll can do that -- I have to admit I don't know the first thing about it.

Link to comment
Share on other sites

  • 8 months later...

So I built an 8-bit version of the TV Wing this morning and after a day of sweating out some VHDL with the correct timing I was able to pipe live video from my tracking system to the TV :D Now I don't have to solve the bandwidth issues with trying to pipe live video over USB, I can just watch it on any TV or even transmit it to a remote monitor.

If anyone is curious about why I changed the values of the DAC to 100/200ohms, I can post some details about that with the calculations I made vs the NTSC specs.

Ben: Thanks for the write up and making the related info easy to find!

Jack: Maybe the TV Wing could have a jumper to pipe bit 7 to the TV DAC vs the Audio Output so one could choose between full 8 bit color and mute or 7 bit color with audio. Not sure if this has value this early into playing with it but it's a thought.

post-12751-13431627650703.jpg

post-12751-13431627650778.jpg

post-12751-13431627650809.jpg

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.