So, the 128k framebuffer is available for every mode and that's it?
Looks like if it's the 16 bit mode, you get one buffer of 320 x 204.
Well there are two independent 128K framebuffers that you flip between on alternating frames. So in 16-bit mode each one can hold a 320x204-pixel image. In 8-bit mode there's enough to hold a 512x256-pixel image.
That's why the line table is useful in 8-bit mode, so you can scroll around the large framebuffer and see a portion of it through your regular 320x224 window.
Also if you mask part of the screen with the Genesis video layer, you could do other sizes like 256x512, etc and just hide the repeating part. ;D
If it's an 8 bit mode, you get double buffering at 320 x 240? But that still takes 150k for both buffers. Or you just have 320 x 204 as double buffer?
Oh, it's not like you have to split the 128K of a single framebuffer in half for double buffering, since you have two 128K framebuffers already.
In 8-bit mode, you do have enough RAM to hold two 320x204 screens _per_ framebuffer, so in theory you could do four-frame buffering:
1. Show framebuffer 1's first 320x204 area
2. Show framebuffer 2's first 320x204 area
3. Show framebuffer 1's second 320x204 area
4. Show framebuffer 2's second 320x204 area.
A bit like DOOM does.
What's the "overwrite" framebuffer for? I thought it was used as the second framebuffer for double buffering.
The overwrite area is a copy of the frame buffer where zero-value pixels aren't written. So if you have a sprite padded with zero value pixels, you can write the whole thing to the frame buffer without doing a read-modify-write operation to only plot the opaque pixels.
It's sort of a nice way to blast irregularly shaped objects to the framebuffer quickly.
About your original question, yes, there isn't enough RAM for the NTSC 320x224 or PAL 320x240 displays in 16-bit mode, so you have to letterbox the display slightly to 320x204 or smaller. Kinda sucks, but there you have it.
EDIT: Chilly said it better.