Originally Posted by byuu
I sincerely doubt it. The closest they have is a sort of pre-fetch line for OAM, to handle all the RTO stuff and sorting. That's why scanline 0 is black, OAM is preparing. And yes, modifying certain registers mid-frame will thusly throw off OAM rendering really bad.

Yeah, that's exactly what I meant by a "linebuffer". I meant a double-buffered setup for sprites--there's no reason to double buffer the BG layers!

When 2D arcade hardware is described as line buffered (e.g. Sega System 16A/B) or frame buffered (e.g. Sega X-Board) it refers to how the sprite generator works--BG layers are practically always rendered directly to the mixer. On a frame buffered system the fact that sprites, but not the BG, are double-buffered is what causes "sprite lag", where the sprites appear a frame or two out of sync with the BG if an emulator (or the original game code!) doesn't take the double buffering into account.

Originally Posted by Kale
About Seiken Densetsu 3, there's certainly a bug regarding that garbage at the top of the talk bar, surely there's a couple of bug in the current mode 5/6 implementation

I wasn't just talking about the garbage. Any time there's even a single visible scanline of hires anywhere on the screen you need to render the entire frame at 512 resolution, otherwise you're throwing ("half-")pixels away.