A video shield could be a popular item. However to be really Arduino useful and friendly it would nice to have a lots of on-board non-volatile memory so that screens could be preloaded and the Arduino application sketch would only have to update data fields or other low memory intensive items.
I also think it must offload most of the video work to an external chip (CPLD, FPGA or a more powerful MCU) and add SRAM for video memory. Some sort of an Arduino friendly, low-cost Picaso chip.
I hate to suggest another micro but have you guys checked out the propeller chip?
We've had a couple of robotics teams look at it. Based on their observations and reports, I think it's crap. The thing doesn't even have a UART - everything has to be bit-banged.
I tried it when I built one YBOX2... the propeller chip can generate composite video, communicate using TCP/IP via Ethernet (you need an additional chip). It seems a very capable chip for multimedia projects and it has 8 cores
condemned, that looks awesome. I look forward to the shield version. Don't suppose there's any chance of compositing the output onto an incoming signal, right? Or at least getting a vertical blank clock to help synchronize?
Overlaying the text onto an existing signal is beyond its capabilities, but there is a chance I could get some sync signals out... What sort of thing might be needed?
It should be simple to generate a suitable field/v-sync pulse onto a spare pin, and then out (via a jumper?) to maybe Digital pin 2 of the shield.
An H-Sync pulse might be a little more tricky, but I'd have a stab at getting it out if needed.
Would you need a true interlaced signal? The TellyMate uses a technique copied from early games consoles and 'home computers' - it outputs a single TV field over and over again (rather than pairs of odd and even fields) - I've got a page of notes on composite video timing that shows this trick.
condemned, for compositing, it's more of a need to get a sync signal INTO your board, and you base your frame or field timing on that signal. I forget the vsync specifics now, but it's something like, on the falling edge of the input vsync, start drawing a field. When you're done drawing a field, the vsync should be high again, so wait for the falling edge to start the next field. It seems fine to draw two identical fields rather than interlacing... it's not a high-res device.
@halley: I was wondering how much use just sync output would have been!
I've since had a good look at what's needed for overlaying/compsiting, and it would need a sync separator (LM1881), some sort of analog switch (HCF4053 or similar) and a re-write of the code to sync to external V-sync and H-sync signals. I'm not yet clear on how I'd cleanly handle sync generation when there isn't an incoming video signal to overlay onto, but I believe it's all possible to do [even for a software guy like me].
Unfortunately, these changes wander significantly away from TellyMate's "very simple hardware" remit, so I'll put them onto the wish-list for TellyMate 2.
Other things on the wish-list for TellyMate 2 include colour output, but there don't seem to be any cheap RGB to composite chips around. MC1337's are hard to source now, and AD722-725's are expensive (certainly for the quantity I'd use). I was at least hoping for a chip that's cheaper than an AVR... I think I might have to settle for greyscale 'colours'.
As it stands, I should be getting some parts this weekend to put together a prototype TellyMate Shield. Hopefully I'll post some pictures next week...
OK, here's a picture of the TellyMate Shield prototype...
It's an offset stacking design - all the components sit well below the sockets.
I had to use a low-profile 3.5mm jack socket for the video output, as PCB mounted RCA/Phono connectors are just too tall.
