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