NTSC Video Example

Designing hardware and software that uses the VS23S0X0 family of ICs as a 8-bit or SPI SRAM memory or as a Video Controller for generating Composite Video (TV-Out) or driving other kinds of displays.
Posts: 13
Joined: Wed 2016-01-20 19:33

Re: NTSC Video Example

Post by JimDrew » Wed 2016-02-03 3:29

Thanks for your answers!

You should consider having a 14.31318MHz input with a 2x PLL option. That is a common oscillator, and more importantly, it is available in 2520 and 3250 package sizes. A 3.579545MHz oscillator is extremely rare in a small package. It's even worse if you are using a crystal instead of an oscillator as the package size is even larger.

VLSI Staff
Posts: 15
Joined: Tue 2015-11-24 12:31

Re: NTSC Video Example

Post by IsoPasi » Wed 2016-02-03 9:46

Thanks for great questions and answers.
What happens to the state of the parallel port lines while the SPI mode is enabled? Do these lines go Z state? We have wired the microcontroller hardware SPI to the same parallel port lines that it needs, and enable/disable those lines with the state of the XCS or XCSPAR - so no bit-banging is required.
The lowest four lines are controlled by the XCS and XCSPAR. On page 42 of the datasheet is a table showing how the upper lines, PIO7-4 are controlled.

To sum up, if both XCS and XCSPAR are high, then the four lowest bits are Z-state (XWP and XHOLD pins have weak on-chip pull-up resistors). If XCSPAR is low then upper bits are reserved for parallel bus use. Otherwise the upper bits are controlled by the GPIO Control register. After power-up they are inputs or Z-state (they have also weak on-chip pull-down resistors) and stay so unless set else by the user.
Also, what voltage/current requirement is there on VXTALIN if driving this line from an external source (like a microcontroller pin, programmable oscillator, etc.)? What tolerance is required for the crystal (+/-50ppm or better)?
Good questions, I'd imagine that the levels would be IOVDD levels, but I'll have to get back to you on that.
That is correct.
The device works at the standard NTSC/PAL frequencies even with the PLL has not yet been enabled? Is that all correct?
The previous version of VS23S010 (VS23S010A) required an external 28.636 MHz crystal oscillator, which (and especially its PAL counterpart) proved to be a very rare component. So we added the 8x PLL and internal oscillator circuitry so that you can generate the required clock with a cheap and common crystal and not having to source the special oscillator. If you have the 28.6 MHz oscillator, don't enable PLL. If you have the 3.58 MHz crystal, enable the PLL.
I would like to add here that the video output DAC uses some analog bias signals which are generated by the PLL. So, if analog video output is used, then PLL has to be enabled also. The PLL clock switch can be used to select the clock source for video generation logic as directly from the clock oscillator pads or from the 8xPLL.
You should consider having a 14.31318MHz input with a 2x PLL option.
That is a good point. We will consider this for the possible future versions of the IC.

Best regards,
Pasi Isotalus, VLSI Solution Oy

Posts: 13
Joined: Wed 2016-01-20 19:33

Re: NTSC Video Example

Post by JimDrew » Sun 2016-02-07 1:04

Perhaps a real world example would be helpful for those looking at this chip. I would like to recommend explaining exactly what is necessary for generating the standard SMPTE NTSC color bars test pattern.

Showing the setup of the chip, and the contents of the SRAM should be very easy to follow. Most people are not going to care about "what picks what", they just care about being able to take standard RGB data and displaying it. Nobody uses YUV data in modern computer systems. So, this example would be perfect. If your chip would accept 8 bit or 16 bit RGB data directly, it would be a huge success just in the DIY home video game industry (like UZEBOX).

User avatar
VLSI Staff
Posts: 2446
Joined: Tue 2010-06-22 13:43

Re: NTSC Video Example

Post by Panu » Mon 2016-02-08 9:46

Perhaps a real world example would be helpful for those looking at this chip.
I wholeheartedly agree, and we're working on the examples, and Pasi has already made a lot!
Nobody uses YUV data in modern computer systems.
Right... well, not in the desktop, but video uses UYV colors; take any AVI (xvid, mp4,...) file and it uses YUV colors because television uses YUV colors and YUV is a natural color format for video and especially for video compression.

Let's try to get past this one issue so we can focus on the solution. The reason we don't have RGB to YUV conversion on-chip is that we wanted to make an affordable TV-Out chip and adding an RGB conversion matrix would have made the chip a lot more expensive (easily double the logic complexity).

I agree it would be convenient to have that conversion on-chip, but we can't add it now and there's many ways to work around that limitation. Following Pasi's advice and examples, you can set up quite nice 256-color palettes and use colors from those. And if you need full color, a microcontroller function can be used to convert from RGB to the colorspace you have on the VS23S with much less cost than to have that circuitry inside the VS23S.

Example palette picture from Pasi's examples at viewtopic.php?f=14&t=1751

You are correct that after the video mode and palette on the VS23S has been set up, it's not important anymore to care about "what picks what". "what picks what" is just what makes the palette. When you have that set up, you can have a linear framebuffer where you can just poke pixels in and then it's business as usual. Sorry that it's not RGB. But after 3-4 years of revisioning, this chip is now ready for production. We may do further revisions of the IC, but making new IC's takes years. So now, let's try and see what we can make of the circuitry that we now have on the VS23S.

Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

Post Reply