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.
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.
