There's no trick to it, the Mega 80 uses a simple trick to achieve high resolutions.
The SPI interface already present on the microcontroller has a high-speed shift register that is re-purposed for video generation. With the addition of some extra signals a simple circuit generates the composite video directly.
The tricky part is the timing. Fortunately this is all done in software. On each video line a carefully crafted loop shifts out a SPI byte (8 pixels) while loading the next 10 pixels, checking for wrap-around and gluing on two extra pixels through X-Vid to fill the gap before the next SPI shift begins. All this in 20 ticks per cycle for an effective dot clock of 8MHz.
This small loop dictates many of the characteristics and limitations of the framebuffer.
The most distinctive feature is the memory layout. Each pair of bytes contain the first eight pixels and the next two pixels of a ten pixel run. So, even bytes in the framebuffer contain eight pixels, odd bytes only two pixels in the two least significant bits with the upper six bits not used. One line of 400 pixels requires 80 bytes and the whole 400x256 frame uses 20Kb.
The next limitation is the check for wrap-around. This brings the pixel pointer back to the start of the framebuffer when it runs off the end and allows for "hardware" scrolling. The current code requires the framebuffer to end on a 32K boundary (last two pixels @ 0x7999).
None of this prevents us taking full advantage of the high-res display. A graphics library has been developed for the framebuffer with mixed graphics and text, "hardware" cursor, "hardware" scrolling in single pixel steps, points, lines with dithering and more planned for the future.
Display swapping from multiple framebuffers would be simple to implement on microcontrollers with access to 64Kb of external ram.