Generating video signals with a microcontroller or old CPU is hard if you haven’t noticed. If you’re driving even a simple NTSC or PAL display at one bit per pixel, you’re looking at a minimum of around 64kB of RAM being used as a frame buffer. Most microcontrollers don’t have this much RAM on the chip, and the AVR video builds we’ve seen either have terrible color or relatively low resolution.
Here’s something interesting that solves the memory problem and also generates analog video signals. Yes, such a chip exists, and apparently this has been in the works for a very long time. It’s the VLSI VS23s010C-L, and it has 131,072 bytes of SRAM and a video display controller that supports NTSC and PAL output.
There are two chips in the family, one being an LQFP48 package, the other a tiny SMD 8-pin package. From what I can tell from the datasheets, the 8-pin version is only an SPI-based SRAM chip. The larger LQFP package is where the action is, with parallel and SPI interfaces to the memory, an input for the colorburst crystal, and composite video and sync out.
After looking at the datasheet (PDF), it looks like generating video with this chip is simply a matter of connecting an RCA jack, throwing a few commands to the chip over SPI, and pushing bits into the SRAM. That’s it. You’re not getting hardware acceleration, you’re going to have to draw everything pixel by pixel, but this looks like the easiest way to generate relatively high-resolution video with a single part.
Thanks [antibyte] for the tip on this one.
About 10 years too late. While the 2 resistor hack on a microcontroller is interesting because of the low parts count, this isn’t going to be that cheap. Small LCD screens are available at not much more than the cost of a composite one, and for going into a TV or similar, the problem is that the RCA inputs are disappearing from TVs. My last one came with an adapter lead to get composite and component video into it, which I have now gone and misplaced.
If there was something like this that did HDMI out, then that would be useful.
Make that 20…
Too late for much of the western world, but maybe there are poor regions where they still rely on the old analog stuff?
Did a quick search and found this on a satellite site::
Analog Channels in all satellites Found 46 channel.
One of which oddly enough is “C-SPAN (Legacy Analog)”, and quite a few appear to be Brazilian.
I don’t know where you guys are buying your TV’s from, but I see composite, S-Video and even RF (co-ax) on modern TV’s all the time…in 2016….rows of them at Walmart, Best Buy, etc.
First pixel!
It looks OK for micro controllers but it would be a pain to interface to a CPU. Correct me if I am wrong, I only had a quick look at the spec sheet … The 8 parallel interface is a port to the SRAM *only* – you *have* to use the SPI interface to set up the video side of things. It’s also 3.3 Volt and *not* 5 volt tolerant so old CPU’s would need a level translator / bus transceiver.
It will do lot’s of other video standards and not just PAL / NTSC. It will do VGA, HVGA, QVGA (and others) but as soon as you need separate SYNC signals you loose the 8 Bit bus. (Not entirely sure on this one).
Definitely useful for a modern micro controller for reasonable graphics and speed if you are happy with PAL/NTSC. If you want a *VGA standard with separate sync then your RAM update bandwidth drops so it would be more useful for things like information displays but not so good for high bandwidth graphics like games etc.
What’s the framerate if you are drawing everything pixel by pixel?
Entirely dependent on the speed of the micro and how often your data is ready and how fast you can push it out up to the 24 or whatever limitation of ntsc
Entirely dependent on the speed of the micro and how often your data is ready and how fast you can push it out up to the 24 or whatever limitation of ntsc
Take this FPGA implementation of the TMS9918A Video Display Processor, which has some issues fixed but still doesn’t have a full bitmap mode, and build on it to have an FPGA implementation of the Yamaha 9938 and 9958 Video Display Processor.
Those chips have a full bitmap mode, higher resolution, more colors. The 9938 had lightpen and mouse support, which was removed from the 9958 while more video modes were added. There’s one video mode from the 9918A not in the 9938 or 9958. With FPGA it should be possible to have *everything* from all three chips in one.
http://codehackcreate.com/archives/30 It’s a direct drop in replacement for any computer or game console that originally had a 9918A (composite 60Hz) 9928A (YPbPr 60Hz) or 9929A (YPbPr 50Hz). The composite or component video out is no longer available, the F18A has a VGA output. Dunno what computers or consoles had the 9928A, the TI-99/4A NTSC version would’ve been much nicer with component video like the European PAL/SECAM version had.
One major limit of the TMS99xxA VDP fixed in the F18A is the four sprites per scanline limit. In the original chips only the lowest 4 sprite numbers with their upper left pixel on the same line would display, others would be invisible. This was sometimes used as a “feature” in game descriptions, calling it “invisibility” that made games like Chisholm Trail harder. The F18A does away with that.
Not fixed is not having a real bitmap mode with every pixel’s color individually settable. The screen is mapped into 32×192 8×1 pixel stripes, each of which can have one foreground and one background color. Any such mode added would require new software written to take advantage of it. I’d say the best choice would be to take the G4 mode from the 9938 and default it to the stock 15+transparent colors and 192 lines. Adding the full 512 colors, with software able to select any 16, while still keeping the resolution at 256×192 would keep things simpler for writing new software for old systems to take advantage of real bitmap mode. Adding the higher resolutions of 9938/9958 and the 19268 colors of the 9958 would require putting much more RAM on the FPGA board or somehow adding it to the host hardware.
Host system limitations wouldn’t be a problem with a new design since there’s nothing old to be backward compatible with and the new computer or game console can be designed to take full advantage of the video chip – without WTF? limitations like the TI computer’s paltry 256 bytes of RAM directly accessible by the CPU.
TI’s Home Computers mainly used the fancy 16 bit CPU as a data shuffler for the 16K of video RAM. Only assembly language was truly able to utilize the full power of the CPU. Just one of the reasons why TI BASIC and TI Extended BASIC were so slooooow. Some 3rd party BASICs worked around the hardware limitations for significantly faster speed.
Don’t need stinking RAM for video. Atari 2600 has no dedicated video RAM and only 128 bytes of RAM for game use. Yet there were many great games out of that ancient system, even today.
I was thinking along the same lines. As a kid I played around on and programmed a number of computers with less than 64K or RAM, some with as little as 4K. None of these had any trouble outputting NTSC signals, and they certainly weren’t using their system RAM for video buffering.
I’m curious what the solution was that was so readily available in 1979, but is somehow not available in 2015.
hardware sprite engine/ blitters vs framebuffers. much more limited than a framebuffer, but you can do cool tricks on low power hardware.
indeed. Character map displays can fill a whole screen from one 8×8 character. Most older hardware had a video processor that pulled the characters from ram and pushed them out to video. Even Arcade games mostly worked this way for a while.
On the 2600, it took months to code relatively simple games. In part because there was so little RAM, video was almost entirely generated on-the-fly, with meticulous attention to timing necessary. Few are willing to do that today.
You got that right. Real men shy away from frame buffers. 3D hardware and HDMI are for pansies. :-D
Wow I actually feel bad for the people who made this … Composite is dead in most major markets and in the markets where it might have a use like in cheesy little video game consoles the dependence on a high speed main cpu to push data constantly to the chip will loose out to already designed and implemented solutions that date back years that handle most of the processing for you … If it was even vga I would think about playing with it but … Damn
Then again, composite monitors are basically free.
Composite and VGA may be dying (along with S-Video which is rarely offered these day) but they still have some use. I have yet to see a 6502 that can directly drive HDMI. Arduino can barely handle composite and VGA, I doubt it can do HDMI without extra parts.
For people that want to use low end CPU and minimal support logic, composite and/or VGA is still the best way.
You will never see what we currently think of a microcontroller that can do HDMI, unless it has a native onboard HDMI driver. Why? Because the native shortest clock period you need in order to drive HDMI at its slowest possible speed is still 250MHz: the 8b/10b encoding in combination with a minimum pixel clock of 25MHz basically means you can’t bit-bang it with anything less than an FPGA/a 250MHz+ ARM or MIPS core.
I would LOVE one of these for making in-car computer stuff.
You can just hook it into the reversing cam input on your built in monitor that almost ALWAYS has composite input for the camera and then display whatever you want.
On one hand, this seems premature. No price. No availability other than a limited number of engineering samples. It’s not dual port SRAM, so SPI/parallel access rate should drop when the video generator is active; the datasheet at least confirms that, but by how much it doesn’t specify, it’s TBD.
On the other hand, this seems late. NTSC/PAL are becoming relics. VGA is not far behind them. And if all you want is better VGA graphics but drawing speed is not an issue, you don’t need a special chip at all. Put as many quad-SPI SRAMs in parallel as you want to achieve the desired bit depth. CS and SCLK can be tied together on all of them. Fill them with data during vertical/horizontal blanking intervals. When it’s almost time to output a line, the MCU sets up a sequential read, then merely has to output a signal at the appropriate frequency to clock out the entire line. 4x 23LC1024 cost $8.88 total and gives you 4Mbits to play with. That’s almost enough for 640×480 with 16 bit color depth. Add two more chips if you want full 24 bit color. And they’ll work at 3.3V or 5V. The only other parts needed are a few resistors for simple DACs.
Some variations:
1) You can clock out the entire image without interruption if you prefer, by using one memory bitplane as hsync.
2) If you’re clocking out individual lines, you can implement scrolling by changing the start address of each line. Or lines could be duplicated for tall text, without having to fill multiple lines of memory. For those old enough to remember display lists on the Atari 8-bit computers, you’ll no doubt get some other ideas.
3) If your memories are big enough, you can implement multiple framebuffers. Combined with #2, you could do transition effects for a slideshow.
Agreed Chris C.
However I would also add some means to isolate (or at least pull to GND) the video signals to the VGA monitor during the blanking intervals, as well as buffer the output drivers (optional). In any case, what you propose has been done, albeit using a measly 8051 as a host CPU ;-) https://youtu.be/6pOH1-zRuoc?t=1m
In my ‘fleatiny’ design I used a 74HC157 to route four RGBI lines between the MCU’s UART (for VGA text-only mode) and Quad-SPI SRAM for color graphics as well as blank the screen where appropriate. My design was/is capable of either two pages of 256×192 or one page of 512×192 @ 16-colors as well as do horizontal or vertical scrolling. I even wrote a sprite engine for it – unfortunately that is written mostly in optimized 8051 assembly… :-/
Cheers Valentin
Cool.
Yes, I recall seeing your Fleatiny before! It’s a good example of using a Quad-SPI SRAM for video. The Lunar Lander demo also makes it clear how the various techniques might fit together. The entire landscape can be preloaded then h-scrolled simply by altering beginning addresses for each scan line, and the score strip at top handled by 3xUARTs, leaving only one sprite to be animated in the framebuffer.
Although I haven’t yet seen a project that parallels SRAMs for large color depths. There is however one that employs a reverse scenario. The MCU sets up a sequential read on paralleled SPI SRAMs, then upon receiving a trigger signal provides a clock to bring in external data, functioning as a high-speed logic analyzer. Hang a parallel ADC off the inputs and drive it from the same clock (possibly with some phase shift), and you’d have a fairly inexpensive high-speed oscilloscope.
Actually, I use simplified 2-color bitmap sprites to handle the score strip too. My lunar lander demo doesn’t use the additional UART-generated textmode thing at all – that is reserved for other demo programs like TinyBASIC.. :-)
Then again,
– a microcontroller alone has enough oomph to output VGA by itself (a micro with a DMA is <1$), bitbox (disclaimer : own project) can output 800×600 @ 15bits.
– microVGA is a nice solution for text output
– NTSC / PAL is an entirely different beast, is more difficult to generate but composite will be of lesser quality and might be more and more difficult to find anyway.
– you don't need a framebuffer for text or games
– Quad SPI rams are a nice solution for a framebuffer based video, but you need to be able to balance writes with reads, for bandwith and timings.
– sure, TFT screens with integrated controllers are very cheap.
– this chip seems to be made of unobtainum, even on the site itself it doesn't seem available for sale so the price is not known ..
– a EVE800 could also be used to generate (lowres) video on VGA
People are building new custom parts for NTSC video generation?
These days I am finding it more and more difficult to find devices that even have 15 pin VGA inputs!
searched Digikey for VS23s010C-L , not found.
searched Newark for VS23s010C-L, not found.
searched findchip for VS23s010C-L, not found.
This is a dead part…
NO, it’s a NEW part. Not available yet.
Who sells that?
I can’t find anyone selling that.
hasn’t been released yet, you can only get it in engineering samples.
Try to tell all of us that do First Person View flying that NTSC/PAL is dead, because analog video signals are still the only viable solution acceptable for real time fly by video. But even with that this part is not available, and even beyond that I haven’t look into seeing if it supports syncing so you can use it as an OSD.
You would have to use a camera that supports external sync and manually mix the video signals.
Apart from the requirement for a specific camera it would make a VERY nice OSD chip. That said, do we really need that much graphics for OSD? MinimOSD works fine for me.