Highest res composite video?

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a small AVR project in development that can generate a rock-steady 400x256 bit-mapped monochrome composite video graphic display using one 74ls00.

It works on any MegaAVR with >=32K external ram. It even has enough ops left over for features or even useful work.

This system currently produces a text resolution of 40x32 characters in 10x8 cells for fastest rendering given the frame buffer layout (not linear). It could easily do better depending on need.

Has anybody achieved better video resolution on the AVR without the use of special/expensive chips? What other AVR composite video generator projects are out there people know of?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look for posts by AtomicZombie and Barnacle about video generation. I think there may be something in "Tutorial" too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With an AVR at 20MHz, you only have about 635 cycles per scan line, and only a portion of that is active scan line. So if the AVR itself is putting out the video directly, then no, you can't get more than ~400 pixels wide (unless you go with an xmega at 32MHz). It does not take a whole lot of external hardware to output video directly from the external memory (with synchronization handled by the AVR). For that you could get better resolution, but you have to drive it at a faster rate than the AVR, which could be problematic.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

He might be blowing 8 pix out at a time using double speed spi. Also, 20MHz will have a 50ns cycle time.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I managed more than that, can't remember the exact numbers off the top of my head but it was over 50 characters per line.

The secret is to use SPI to pump out pixels. The maximum speed it can do that is 1/2 clock speed, but there is an annoying limitation where the last bit is always repeated for an extra clock cycle. For text it isn't too bad as that pixel is usually blank to allow for a gap between letters anyway, and you can be creative in hiding it in graphics.

One big advantage of using SPI is that you have loads of free CPU cycles to do other stuff. My code is has to pad things out with NOPs during the scan line draw. I included some hardware to change the background colour and select the foreground character from one of two fonts on a per-character basis too.

Memory usage was low enough to fit on an 8k AVR easily because of the character mapped display.

When I get home I'll try to remember to dig out some code. It was going to be GPL anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually I did have one other idea. Use a parallel load shift register to clock bits out at the CPU clock speed or perhaps even 2x CPU clock speed.

Or just use an XMEGA with a few megabytes of RAM and 32MHz clock for full colour bitmapped graphics. Or some dual-port RAM... There are lots of options.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I managed more than that, can't remember the exact numbers off the top of my head but it was over 50 characters per line.


Read Neil's article - he chose 40x16 because that will fit in the 1K internal RAM of a small AVR.
Quote:
for full colour bitmapped graphics

Something like this you mean?

(that from AtomicZombie's site).

This seems quite impressive too:

http://tinyvga.com/avr-sdram-vga

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I managed more than that, can't remember the exact numbers off the top of my head but it was over 50 characters per line.
Getting more characters per line than the 40 that the OP stated is easy. 10 pixels wide for a character is a waste. With a 5x7 character set, you can get away with 8, 7, or even 6 pixels wide.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In thinking about what I had posted earlier, the 635 cycles includes a factor of 2 for the output from the AVR (the fastest SPI speed is 2 cycles per bit). For the external RAM this factor is not there, so you could get twice that with that method. You then have 8 clocks per byte to output the correct memory address and clock the latch, which is doable.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My TellyMate project (3 current board variants - source code and schematics available) does a comfortable 38x25 text characters using just a lowly Mega8 and a few components. It even manages to squeeze in serial communication in the non-display areas.

This uses the SPI peripheral and has to work hard to get around the '9th bit problem' that mojo-chan mentions above (I wrote an article that mentions this 9th bit problem).

An easier solution is to use a modern AVR's USART in SPI mode - this can shovel out bytes contiguously at CPU-clock/2. It even has a 1-byte buffer to help with the timing.

Using a USART in this way, I have managed 80x25 characters on a 32MHz XMega (640x225), but it's pushing what's sensibly usable onscreen.

I'm currently tidying up some XMega code that runs an entirely interrupt-driven 40x25 text screen on NTSC/PAL (interlaced or progressive) - I'm hoping to release it in the next week or so. It's just an XMega and two resistors - add a crystal if you want non-wiggly output.

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

prickle wrote:

Has anybody achieved better video resolution on the AVR without the use of special/expensive chips?

Is it perhaps possible to achief something like 320x200x8-bit compressed images? by using a timer (OC) and 10-bit DAC (as 8-bit DAC) AT90PWM316 @ 16 MHz?

RES

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great responses. Thanks people!

[Koshchi] I could overclock the micro but that seems like cheating :-) Yes 10 pixels for an 8x8 character cell is a waste but due to the framebuffer layout it renders fastest.

[bobgardner] Good pick! got it in one. Yes, I use 2x SPI with two extra pixels glued in the reload gap. I think I am getting an 8MHz dot clock. The framebuffer uses 20Kb.

[clawson] Thanks for the links. Just what I wanted.

;------

Perhaps it is worthwhile to ask your opinions what value a framebuffer library may have to the community?

For example, something with GLIB compatibility for use as a budget replacement for large graphic LCDs.

Or perhaps, wrapped in C, it could be made an Arduino library? Do or will any Arduinos exist with enough RAM to run it?

What I actually did is give it a keyboard and Basic interpreter to re-create an authentic 80's style home computer. It is outrageously effective at generating old-timey nostalgic sensations even if it is not entirely practical. It took me ages to make, I may even finish it one day.

This video generation really is a neat trick. So what would be best use? Well, cheap graphic displays. Cheap because video monitors are everywhere, often even unwanted. The hardware is absurdly simple. My design uses a 74LS00 to mix and buffer the output, it may even prove unnecessary.

Desirable resolutions have already been achieved. Specific applications have been written to take advantage of particular implementations but they all seem to vary in accessibility, adaptability and price in such a way as to leave no first choices for the simple weekend hack. I mean if there was, I would have a full graphic display in all my good gadgets instead of HD44780s everywhere. Wouldn't you?

For example my framebuffer library is not in the slightest bit user-friendly. To have a tv framebuffer means application code can have no interrupts (everything polled), not many ops and long pauses in execution. Time-critical interfaces are difficult and require close cooperation with the framebuffer code. This is no place for the faint of heart.

Now I want to make a new device with a nice graphic display for as little money as possible. The effort of imply porting my framebuffer to a bigger AVR made me realize the unwieldiness of my system.
What then of the people who just want to draw? They might want to use:

1) A generic/specific(Arduino) software library. Not good for reasons listed above. Can it be improved? For instance, by providing peripheral and I/O access functions that can cooperate with the running framebuffer. I think this is best as it is the most efficient even if it proves the hardest to learn and use.

2) An external video device. Make the fastest practical I/O interface on the framebuffer and allow it to be issued high level graphics commands. In fact, go all out and make it a high-speed graphic terminal. Practically ideal but for the high microcontroller count. Possibly the easiest way to get a professional result.

3)An intermediate language. Code a new execution unit within the restrictions of the framebuffer library and provide co-operative peripheral and I/O functions as part of a language. This method is working surprisingly well for my interpreter but a bytecode would be likely to be much better.

What if it had fancy sprites and page flipping? The lack of color kind of limits gaming appeal. A windowing UI? I dig the idea of a GEOS-style OS with mouse or touch-screen input, perhaps my next project should have one.

What would you say?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What would you say?

It'd be nice to see another one added to the list.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Video overlay capability.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd say the Arduino community would love a bitmap video output device - maybe in-between the capabilities/costs of the Game Shield (the arduino does the heavy-lifting) and the Gameduino (an FPGA does the heavy-lifting).

Adding overlay capability would definitely help. I'm often asked if the TellyMate Shield can do this (it can't).

You might be in the same arena as the $25 Raspberry Pi soon though. I suspect that this'll prove to be a very useful TV-out solution in many situations.

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

condemned wrote:
An easier solution is to use a modern AVR's USART in SPI mode - this can shovel out bytes contiguously at CPU-clock/2. It even has a 1-byte buffer to help with the timing.

Using a USART in this way, I have managed 80x25 characters on a 32MHz XMega (640x225), but it's pushing what's sensibly usable onscreen.

Great minds think alike :)

You could use DMA and the event system to render the scanlines, and the CPU would hardly have to do anything at all.

Does the USART have the "9th bit" issue?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Video overlay capability.

I experimented with this but came to the conclusion that quality will be difficult to achieve. You need a PLL synced with the video signal to avoid wobble, for a start. To add some contrast you need to be able to produce both white and black for the overlay, meaning that the circuitry is much more complex and I was using RGB video.

But certainly for basic data overlay onto a B/W or composite signal it works pretty well.

In the end I went with a dedicated overlay generator IC. Not easy to find these days.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
In the end I went with a dedicated overlay generator IC. Not easy to find these days.

Maxim have one that's pretty good. MAX7456.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should have pointed out that I am working with RGB video and almost all of the available chips are for composite.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@mojo-chan, Using the USART in SPI mode definitely gets rid of the 9th bit problem. The 8-bit bytes are output without gaps in between.

This evening I've just tried using the DMA controller to throw data at the USART. It works flawlessly. I'm building a single scanline worth of pixels from flash-based font data on-the-fly whilst the DMA transaction is running! It's halved the time I spend in the scanline interrupt routine :) Very pleasing.

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@condemned, nice work! Reducing CPU and freeing IRQ usage makes video generation way more user-friendly in a general-purpose library. What is the lowest-end AVR with DMA and ext mem?

To do a good video overlay would be hard, I reckon.

I wanted this but my thoughts went thusly- Surely trying to capture line sync with interrupts is doomed to fail on anything less than perfect input signal. Any interference would play merry havoc.

But wait! Early TVs would use a "flywheel" sync circuit with a long timebase to overcome jitter. These would change frequency quite gradually or "pull" to match sync so short deviations are ignored and the system zeros in on the steady average. Effective enough until PLLs became available.

Could something similar be done in software? E.g. an external IRQ from a sync splitter alters the count of the video timer slightly to servo it ever closer to sync... maybe that would jitter even more as it oscillates around the set point. What then of a PID controller or is that just crazy talk?

Ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
An easier solution is to use a modern AVR's USART in SPI mode - this can shovel out bytes contiguously at CPU-clock/2.

How modern? Can you replace the m8 in the telemate with a m88 and get an easy improvement (to ?) (the m88 does claim to support SPI mode on the USART.) Or does it not matter so much till you add DMA?

What about LCDs? A typical AMLCD display is somewhat like video, though usually with some parallelism in the pixels; IMO it would be a useful thing to be able to drive the displays that are out there, even if it's done in "black and white" (tying any parallel pixels to the same signal.) They may or may not be somewhat more flexible WRT timing than real video (they're usually clocked, right?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Could something similar be done in software? E.g. an external IRQ from a sync splitter alters the count of the video timer slightly to servo it ever closer to sync... maybe that would jitter even more as it oscillates around the set point. What then of a PID controller or is that just crazy talk?

I played around with this idea a few years back, but didn't really get anywhere. However, if you have an AVR that runs quickly enough, I believe you should be able to reduce the jitter to half a pixel or so. Personally, I found the jitter more annoying when it was slowly creeping up or down the screen. When it was sweeping rapidly it was almost unnoticeable, and that was with a whole pixel of jitter.
Of course, when I was playing with this stuff the Xmegas weren't readily available. The idea of DMAing the entire scan line via the no-missing-bit SPI sounds brilliant. Who knows, it might be possible to use the run-time calibration of the internal 32MHz oscillator to lock to the sync pulse.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've not used the USART in SPI mode on the TellyMate for three reasons:
1. The M8 is my lowest-common-denominator in the code, and it doesn't have an SPI mode on the USART.
2. The USART is already being used for serial comms! there's only one USART on these chips :)
3. Now I've got a work-around for the 9th bit, it doesn't make much difference - the TellyMate does all I want it to. Making it more 'efficient' isn't a concern in a single-task adapter (that situation is obviously different for a device which will run other tasks).

The smallest XMega with an external memory interface is (I believe) the A1 series... which are 100-pin monsters. These have 8 USARTs!

[edit: I've just seen the XMega256A3 - it's got 16kb onboard... that's comfortably enough for 320 x 240 x 1bpp hmmm...]

There seems to be a lot of jitter on the XMegas internal oscillators. Whilst I can generate TV signals with these, they're not very pretty - it's like watching an old VHS tape. I doubt that they'd be suitable for syncing up to an external source.

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Awesome. I stand on the shoulders of giants.

Xmegas seem to start a bit too high end IMHO. It would be a waste of most of the chip if all I wanted was a fancy graphic voltage/current display on my bench supply or some such. It's a shame, I really liked the sound of the DMA/UART trick. Most nifty.

So let's think of something else for our genlock. Perhaps the humble 4046 PLL might be of use. It could lock to the sync signal and feed the controller nice, steady interrupts. I suppose it would it be best employed directly at the fundamental line frequency (15.625KHz) as it has no divider chain. The time constant filtering the error signal would want to be quite high no doubt just like the old flywheel circuits. Oh, and the price is right :-)

So, let's say a lm1881 sync separator into the 4046 PLL phase comparator with the it's VCO feeding straight to a microcontroller interrupt. Not too unreasonable?

I don't remember if the 4046 has a useable "lock" signal output. If it did, this could be used by the micro to switch to internal timing when lock is lost so as to never be totally illegible even with remote video senders like one might use on an UAV or other RC vehicle.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
What about LCDs? A typical AMLCD display is somewhat like video, though usually with some parallelism in the pixels; IMO it would be a useful thing to be able to drive the displays that are out there, even if it's done in "black and white" (tying any parallel pixels to the same signal.) They may or may not be somewhat more flexible WRT timing than real video (they're usually clocked, right?)

I totally agree. I have a handful of old panels on the bookshelf waiting for how to do it. They want to be fed data at too high a rate for my meager controllers, maybe the Xmega could handle it, perhaps with a separate USART for each colour pixel.

I wonder. Can the USARTS for each colour channel be loaded at exactly the same time? They would probably need to be staggered and the data pre-shifted or something equally awkward.

The issue with controlling LCDs as I see it is the vast variety of styles, depths, resolutions, pinouts, etc that can be found and the general lack of good information about panels recovered from domestic devices. How does one easily arrange a one-size-fits-all controller? That random LCD collection on my bookshelf will probably stay there a while longer.