Electronic – What’s the point of DMA in embedded CPU’s

I vote for DMA. It's really flexible in Cortex-M3 and up - and you can do all kind of crazy things like automatically getting data from one place and outputing into another with specified rate or at some events without spending ANY CPU cycles. DMA is much more reliable.

But it might be quite hard to understand in details.

Another option is soft-cores on FPGA with hardware implementation of these tight things.

One thing that used to be common for video graphic controllers is Video RAM or VRAM.

VRAM has two sets of data output pins, and thus two ports that can be used simultaneously. The first port, the DRAM port, is accessed by the host computer in a manner very similar to traditional DRAM. The second port, the video port, is typically read-only and is dedicated to providing a high throughput, serialized data channel for the graphics chipset.

Internally, VRAM reads an entire DRAM row and shifts it out sequentially to the video circuitry. This leave the DRAM available for use by the MPU. VRAM has largely been replaced by the use of SDRAM, "even though it is only single-ported and more overhead is required".

A technique I have used in the past is to use interleaved access to memory. It's a bit complex to explain (the devil is in the details), but I will outline the basics:

Basically the MPU accesses video memory in between pixel accesses by the video-controller. If this timing gets too tight, there are a couple things you can do that will greatly relieve the timing (usually only 1 of these is necessary):

1. You can use 2 RAM chips (or banks) and interleave those using each chip for every-other pixel. In your case, this would effectively slow your pixel clock to 80ns per chip allowing MPU and video-controller access to have windows of 40ns each. This could be extended to more banks interleaving more pixels if necessary. This technique is called Interleaved Memory.
2. You can increase the data-bus size of the video memory. The video-controller would read multiple pixels in a single access and use them sequentially. The MPU would either have a larger data-bus, each access would be directed to the appropriate byte (or word) and byte-selects would be used on the video memory, or a read-modify-write would have to be performed to write to the larger data size. In your case, it would probably be simplest to increase the video memory data bus to 16 or 32 bits (2 or 4 pixels), and probably then use an MPU with the same bus size.

If you interleave video accesses, you may want to consider the use of an FPGA or CPLD for your video memory controller.

Another method is to have 2 separate video memories and use bank-select. The MPU writes to one bank while the other is being used by the video-controller for display. When the MPU is finished writing, the bank accesses are swapped (usually during a sync pulse).