AVR Freaks

Cell phones use dual core 3GHz ARMs. 1000s of times faster than a 20MHz AVR. You could do RGB video but it would be a frame every 2 secs or so.

"Black and white" means continuously variable from black to white. Maybe 256 levels 8 bit. A KS0108 has off and on. Not the same.

That question makes no sense. In the same way that WAV is a "container format" that can hold one of about 50 different audio formats that in an almost identical way AVI is a container format for video that can hold about one of 50 (more!) video formats. It can contain MPEG or MJPEG or H.264 or AVC (which basically is H.264) or individual uncompressed frames or ....

(actually AVI=Audio Video Interleave - it might contain both MPEG video and MP3 audio for the same sequence with synchronising time stamps).

So you can't ask "which is better: avi or MPEG" because one might actually contain the other. You might have asked "which is better MPEG1, MPEG2, MPEG-TS, H.264, AVC, raw frames...?"

As an AVR will have no time whatsoever left to do any form of video decompression (it'll struggle just to keep on drawing raw uncompressed frames at 5..10 frames per second) you don't really get a choice. You have to use raw 128x64 (or whatever it is) blocks of data and just have the AVR spend all it's time blitting them to the screen.

Even if you added a chip that could do some kind of decode (like MPEG) you'd still probably spend most of the time feeding it the raw encoded data and retrieving the decompressed frames to blit to the display (there's no DMA here to do that for you as on more capable CPUs).

So, yes, AVR doing audio+video is an interesting intellectual exercise but it's never going to be a practical solution. If you want that spend $25 on a Raspberry Pi!

Do bear in mind that most KS0108 are connected to a Super-Twist Nematic LCD screen with a liquid crystal that has something like a 200ms switching time. So don't try to drive more than about 5 frames per second or it will blur. Whether you call this "realtime" or not is a good question.

What IS your purpose, then?

That sentence holds at least two contradictions:

1) FPGAs as such, and writing "firmware" for them, are not simple.
2) Audio is not simple.

If you really want to start with FPGA boards then start by implementing simple logic gates. An AND gate with two inputs, one output. This is the FPGA equivalent of "blinky" for AVRs. This will prove that you understood how to go from the very simplest source you can think of to a bitfile, and that the tool chain is in order and you have some knowledge about it.

You need to learn a language that superficially looks like any other programming language but actually is fundamentally different. You need to learn a hardware platform that is fundamentally different. You need to learn to handle the individual steps in a tool chain that is an order of magnitude more complex than e.g. the avr-gcc compiler. There is, AFAIK, not any case where you just start the FPGA development IDE, type in a few lines and press the "Burn to hardware" button. You need to have a decent understanding of the principally different hardware platform, both in structure and function.

It is true that an FPGA tool chain holds a lot of special tools but it is still significant that e.g. the installer for the Xilinx tools is over 4 GB.

I can say one thing though: If go down the FPGA route, then you will be cured from your aversion of reading thick data sheets. There is no way that I know of that you can handle FPGAs without reading a lot of reference documents and user guides.

And yes, if you think we are harsh - wait 'til you meet the gang at the FPGA forums. Any "please feed me" or "I cant bother reading documentation" will be amply met by getting slashed just above the feet.

All this from a fellow FPGA beginner. (When I find the time, that is. You can do a small AVR experiment in an hour or two. I never get the FPGA boards out unless I have a completely free week end.)