Sega Super Scaler sprite rendering information?

Haven't been able to find this information anywhere; does anyone know how the Super Scaler series of arcade systems (Hang On, Outrun, X Board, Y Board, System 32) actually drew the scaled sprites? I would guess the systems are framebuffer (not just linebuffer) based, but System 16 gives information about how the X Board is capable of displaying at maximimum 256 sprites, which I think would debunk this. Things like the smoke trail clouds in Afterburner scaling up to fit about the whole screen confuse me then.

I'm pretty sure it's still just-in-time.

If you look at the 315-5196 sprite table, it's 10 bytes per entry, including:
Top scanline
Bottom scanline
X position
16 bit dY/dy ("p") — specifies the stride from one scanline of source pixels to the next; also could be used to shrink things.
19 bit "start", not clear what units it's using. Maybe words = four 4-bit packed pixels?
6 bits of palette number
6 bits of "zoom"

Similarly, in drivers/segaorun.cpp, it doesn't mention anywhere near enough memory on the video board for a framebuffer—just 10 or 12 KiB of SRAM.

MAME still emulates the sprites here as a framebuffer, but MAME's not known for its accuracy. It is possible that the framebuffer is inside the chip, rather than external, though.

There's also a quote from the person who designed it, mentioned here:

My designs were always 3D from the beginning. All the calculations in the system were 3D, even from Hang-On. I calculated the position, scale, and zoom rate in 3D and converted it backwards to 2D. So I was always thinking in 3D.
— Yu Suzuki

Wow, thank you for compiling that information! It's mildly unfortunate a lot of this information isn't available outside of source code anywhere.

And I'm really impressed that it's in time (segaretro actually specifies line buffers and pixels per scanline), as I've never seen any sprite pixel per line dropout..

Yeah, God damn, the X Board has 3200 sprite pixels per scanline...

I wonder how expensive it would've been to implement sprite scaling hardware on the SNES or Genesis. I know it's still a lot cheaper than hardware sprite rotation, because rotation takes per pixel VRAM access, and scaling doesn't. I think most of it would come from having a bigger sprite table.

There was gonna be sprite scaling on MD but it was one of the things that got axed. Horizontally it shouldn't take much effort but vertically there's some extra state to store. There's no room left for VRAM accesses and silicon shots show that there's no space for any extra memory in the VDP either.

But it was eventually implemented in the Sega CD, right?

Scaling without rotation can be done in real time in software, even on an NES. If I had an application, I'd make a tech demo of doing so on Super NES.

MCD has a setup with a framebuffer that can do blits and whatnot between the RAM banks, completely different from what the VDP would have had in it.