Not sure historically but at least doing some OLED programming these days it's often the case they support changing where the pointer starts (in terms of rows o

Not sure historically but at least doing some OLED programming these days it's often the case they support changing where the pointer starts (in terms of rows or columns) and allowing the behavior of wrapping the cursor around, meaning that when you'd do a full scroll the rows simply wrap around. If you don't overwrite anything in the video memory, then you just see the content from the top/bottom show up at the bottom/top, but if you did (e.g. to implement efficient whole-screen scrolling) you just had to re-paint the lines that were offset, instead of the whole screen. NES (a 6502, if it matters) had a different approach, where you had four sections with their own memory regions for tiles and sprites. You'd then tell the NES how to lay them out, e.g. if they were next to each other, how they'd wrap, if one was duplicated to another slot, etc and then the scrolling was handled by hardware. This is how Super Mario implemented the long sprawling levels (and I believe why the first wouldn't let you go back). As for e.g. VGA buffers on x86 for example, as far as I know there's no (standard) way to have them shift. I could be wrong. However I've had to write a few vertical scroller rasterizers before for VGA buffers and I've always done them manually, usually with some cleverness to avoid actually writing to the buffer when it wasn't necessary (since that hit a memory mapped region and thus was much slower than RAM).