Where to buy VS23S010-L? How to make NTSC picture?

[JimDrew]

I am looking for pricing and availability of this part. Is this part going to have a future? I would hate to build this into a new design to find out it is discontinued in a year's time.

Can you provide examples for NTSC output like you did for PAL output? Can you give an example for a 160x120 display?

[Henrik]

I am looking for pricing and availability of this part.

For that information, please contact sales@vlsi.fi.

Is this part going to have a future? I would hate to build this into a new design to find out it is discontinued in a year's time.

Nothing can ever be 100% guaranteed, but if you look at VLSI Solution's history, we have a pretty good track record of keeping our ICs in sales for years and years. Our oldest products on sale (e.g. VS1003) have been in full production for over a decade.

Can you provide examples for NTSC output like you did for PAL output? Can you give an example for a 160x120 display?

I'll have to ask our VS23S010 specialist engineer for that.

Kind regards,
- Henrik

[IsoPasi]

The NTSC video example will be added next week.

Best regards,
Pasi

[JimDrew]

Thank you. We received samples today.

Can you provide a simple step-by-step procedure for initializing the chip and setting various video modes. A flow chart with SPI commands/values would be helpful.

There are some things left unclear in your datasheet, such as if anything is required to keep the display showing video data after filling the frame buffer. Does the display refresh by itself without any external sync requirement? If that is the case, how do determine the raster position so that a tearing does not occur if filling the buffer in the middle of the refresh?

[Panu]

Hi!

The VS23S010 chip is amazingly flexible, allowing you to set up countless different frame/resolution/color formats; scroll vertically or horizontally, duplicate lines, set up background pattern, adjust colors, and copy rectangular areas within the memory. We have made a lot of example applications for the IC during the past couple of years, when the chip has been in the making, to test various possibilities. Those examples are helpful, but not nearly all code is published at the moment and much of it needs cleaning so it can be published if need be.

The applications of the chip are quite complex to explain... although everything about the operation of the VS23S010 is explained in the datasheet, the information is in a very concise form, basically explaining what the hardware does. It would be impossible to describe in the datasheet what all the visual applications of all the hardware functions would be...

I'm one of the engineers who designed the video pattern generator's principles of operation and I would like to offer you guidance here at the forum on how to get the chip alive and working as you want. Please ask me any questions you would like to have answered and I will offer you answers.

Is anything required to keep the display showing video data after filling the frame buffer.

No, you set up the frame and the VS23S010 will keep displaying it until you switch off the video generator.

Does the display refresh by itself without any external sync requirement?

Yes. All it needs is a color crystal (3.58 MHz for NTSC) or a 8x3.58 MHz external clock source.

How do determine the raster position so that a tearing does not occur if filling the buffer in the middle of the refresh?

Two options:
1) You can read the current line counter and current phase count registers to get a real-time location where the CRT beam is currently drawing.

2) You can output an interrupt or sync signal by forcing low and high level on a digital output pin (data bus bits 4, 5, 6 or 7 can be used for this purpose). This is done by inserting an output operation into any prototype line, e.g. during horizontal or vertical retract (a few unlikely color values in the prototype/background line are reserved for changing the output state of those 4 pins). I wrote a VGA demo that creates VGA syncs using this method.. do you think it might be useful for you?

-Panu

[Panu]

Is this part going to have a future?

Yes, a bright and shiny future I should hope. We've only just started production on this IC and it should be available for years and years.

Can you provide a simple step-by-step procedure for initializing the chip and setting various video modes. A flow chart with SPI commands/values would be helpful.

I think the software examples are a good way to start. A flow chart would be rather large... the example code is already written in a "step by step" basis, like this clip from the PAL example:

// 1. Select the first VS23 for following commands
SpiRamWriteByteRegister(WRITE_MULTIIC, 0xe);

// 2. Set SPI memory address autoincrement
SpiRamWriteByteRegister(WRITE_STATUS, 0x40);

// 3. XReset & XCSPar pins of VS23 to high on the testcard
GpioSetPin(0x20, 1);
GpioSetPin(0x21, 1);

// 4. Write picture start and end
SpiRamWriteRegister(PICSTART, (STARTPIX-1));
SpiRamWriteRegister(PICEND, (ENDPIX-1));

// 5. Enable PLL clock
SpiRamWriteRegister(VDCTRL1, (VDCTRL1_PLL_ENABLE) | (VDCTRL1_SELECT_PLL_CLOCK));

// 6. Clear the video memory
for (w=0; w<65536; w++) SpiRamWriteWord((u_int16)w,0x0000); //Clear memory

// 7. Set length of one complete line (unit: PLL clocks)
SpiRamWriteRegister(LINELEN, (PLLCLKS_PER_LINE));

// 8. Set microcode program (color bit format) for picture lines
SpiRamWriteProgram(PROGRAM,(OP4 << 8) | OP3,(OP2 << 8) | OP1);

// 9. Define where Line Indexes are stored in memory
SpiRamWriteRegister(INDEXSTART, INDEX_START_LONGWORDS);

// 10. Enable the PAL Y lowpass filter
SpiRamWriteBMCtrl(BLOCKMVC1,0,0,BLOCKMVC1_PYF);

// 11. Set all line indexes to point to protoline 0 (which by definition is in the beginning of the SRAM)
for (i=0; i<TOTAL_LINES; i++) {
SetLineIndex(i, PROTOLINE_WORD_ADDRESS(0));
}

// At this time, the chip would continuously output the proto line 0.
// This protoline will become our most "normal" horizontal line.
// For TV-Out, fill the line with black level,
...

Here's a quick introduction to some basics so you can get ideas rolling in your head...:

Basically to draw a TV picture, you need to set up (numbers are for NTSC format):
- Length of one horizontal line in 28,636 MHz clocks
- Number of horizontal lines
- YUV Color bit format ("microcode") for foreground picture
- Draw Background picture lines ("prototype lines") in memory. They are in 16-bit YUV844 format, with 3.58 MHz pixel clock and contain sync, burst, and background for the line.
- Draw Foreground picture lines in memory (or fill with zeroes at this point).
- Set line pointers in memory to tell the VS23S010 where to find the pixel data (prototype or prototype+foreground) for each line.
- Set up the foreground start position and length - the rest of the line will be drawn from the background prototype line.

You'll notice soon that by using the Line Pointers (Line Indexes), you can have a wider and/or taller picture in the memory than what you are displaying on the screen and you can use the Line Pointers to select which part is shown. If you set up a color format that has 8 or 16 bits per pixel (so that all pixels are aligned in byte addresses) you can freely scroll horizontally. For smaller resolutions, you can have the same Line Pointer for multiple lines - those lines will be drawn many times.

Please ask more!

-Panu

[JimDrew]

We need a 320x240 NTSC display (if possible). I know that is close to the line limit for NTSC. We might be able to reduce the resolution and interpolate the data so a 320x200 display can be used.

We have a RGB16 (R=5:G=6:B=5) 16 bit value for each pixel. We could use an 8 bit value (3:3:2) if necessary, but we would prefer the full color range. We only need store the data to the SRAM and display it. No manipulation of the display, no scrolling, just a simple picture displayed. We want to be able to do animation by writing to the SRAM as fast as possible (hopefully 15 fps or faster). We are using a microcontroller with a parallel port that has DMA for the storing of data, and standard SPI for the control. Is this device going to do what we need?

Thanks!

[Panu]

We need a 320x240 NTSC display (if possible). I know that is close to the line limit for NTSC. We might be able to reduce the resolution and interpolate the data so a 320x200 display can be used.

That's possible, but you can't use more than about 120 kilobytes for the frame buffer, which limits your color options somewhat. 320 x 200 x 16 bits per pixel is 128 kilobytes, a little too much. Something like 320 x 196 is possible with 16 bits per pixel. If you want to keep individual pixels addressable, you can use 8 bits per pixel. If that is not necessary for you, you can use any number of bits per pixel.

TV screen's color resolution is less than the black-and-white (luminance) resolution, and VS23S010 fully supports this by allowing you to select how many adjacent pixels share the same chrominance. For example, you could have a pixel format of 4 bits U and 4 bits V followed by two 8-bit luminance (Y) values, which means that 24 bits are used to describe two pixels. That way a 320x240 pixel picture would use 320*240*3/2 bytes = 115200 bytes, which nicely fits in the SRAM.

We have a RGB16 (R=5:G=6:B=5) 16 bit value for each pixel.

TV systems use YUV format for color.. there's no circuitry inside the VS23S010 to convert from RGB to YUV but we use C macros to convert from RGB565 to, say, YUV844 in the host microcontroller.

We want to be able to do animation by writing to the SRAM as fast as possible (hopefully 15 fps or faster).

That's interesting. I have written my own video encoder for libavcodec and ported mencoder to encode video for various TFT and VS23S displaying purposes. It works on the principle of selectively updating 8x8 blocks of the picture where there are changes in the picture. There are various command line options for adjusting the thresholds and bandwidth. I'll attach the howto-pdf here to give you idea. I've used that encoder to actually watch movies with the VS23S010 (or at least TV shows) for test purposes.

15 fps with 1 megabit frame buffer roughly translates to 15 mbps if the whole picture is updated. It looks like it should be achievable with single-bit SPI, but I'm not 100% sure. Your other options are to use dual or quad-bit SPI or the 8-bit parallel bus. The parallel bus is the best option for updating the frame buffer contents, but then you'll probably want to bit-bang the SPI register writes using software SPI, since the SPI and the Parallel bus share the pins.

Is this device going to do what we need?

Yeah, basically it looks like a good fit. You could benefit a lot by shifting your mindset a little away from RGB and towards YUV, when you are preparing data for displaying on screen.

I'll attach my mencoder pdf, just in case you might find it interesting. I've written a NTSC and PAL video player apps for VS1005, and I can give you the source code if you want.

-Panu