Some questions about Saturn HW
Posted: Fri Apr 13, 2018 1:26 am
Hi all! I'm learning about how Sega Saturn works, just for fun, some questions I didn't found the answer.
Hope you can help me!
- Main RAM: I read 2MB in some places, but also 1.5MB in others (labelled as "work RAM"). Why?
- Main RAM: I read 2x1MB in total, 2 different RAM chips (slow+fast)... but SCU make all transparent for SH2, is that right?
- SCU DSP: SCU has to make his job to let SH2 "speak" with others, like VPDs and Sound block. But... is this working also when using DSP?
I mean, lot of people dreams about DSP power not use by programmers, but seems to much for DSP making 3d calculations (matrix) and at the same communicate SH2 with other chips. Is this possible?
- VPD1: works at @28MHz, but its VRAM? I read half speed, non-sense if this is true
- VPD2: works at @28Mhz, but its VRAM? I read double speed, why if this is true?
- VPD1 and VPD2: VPD1 writes in framebuffer. VPD2 reads this framebuffer and copy all this info to one of its layers. Then mix all layers and send result to TV: If this is true, then all "sprites" are in one layer. This seems usual way.
But when researching about "BURNING RANGERS" game, seems they make this 2 times.
First VPD1 put transparent elements (like fire) in framebuffer. VPD2 reads and put in a layer.
Second VPD2 erase framebuffer (is this possible) and put sprites. VPD2 reads and put in another layer.
Finally VPD2 mix everything.
- SH2 and VPD2: I read that is possible to use only VPD2 (avoiding VPD1) as draws faster. But if VPD1 is the one that make sprites/quads, how SH2 can draw?
- Virtua Fighter 1 vs Virtua Fighter REMIX: I see that floor is different. In VF1 seem to have poligons but in VF1 REMIX seem to be a big texture manage by VPD2. Is this true?
- VPD1: Some people say that VPD1 lose time when "writing" texture in poligon even if the poligon is smaller than texture. I don't understand why (if it's like this). Read this about texture rendering
Hope you can help me!
- Main RAM: I read 2MB in some places, but also 1.5MB in others (labelled as "work RAM"). Why?
- Main RAM: I read 2x1MB in total, 2 different RAM chips (slow+fast)... but SCU make all transparent for SH2, is that right?
- SCU DSP: SCU has to make his job to let SH2 "speak" with others, like VPDs and Sound block. But... is this working also when using DSP?
I mean, lot of people dreams about DSP power not use by programmers, but seems to much for DSP making 3d calculations (matrix) and at the same communicate SH2 with other chips. Is this possible?
- VPD1: works at @28MHz, but its VRAM? I read half speed, non-sense if this is true
- VPD2: works at @28Mhz, but its VRAM? I read double speed, why if this is true?
- VPD1 and VPD2: VPD1 writes in framebuffer. VPD2 reads this framebuffer and copy all this info to one of its layers. Then mix all layers and send result to TV: If this is true, then all "sprites" are in one layer. This seems usual way.
But when researching about "BURNING RANGERS" game, seems they make this 2 times.
First VPD1 put transparent elements (like fire) in framebuffer. VPD2 reads and put in a layer.
Second VPD2 erase framebuffer (is this possible) and put sprites. VPD2 reads and put in another layer.
Finally VPD2 mix everything.
- SH2 and VPD2: I read that is possible to use only VPD2 (avoiding VPD1) as draws faster. But if VPD1 is the one that make sprites/quads, how SH2 can draw?
- Virtua Fighter 1 vs Virtua Fighter REMIX: I see that floor is different. In VF1 seem to have poligons but in VF1 REMIX seem to be a big texture manage by VPD2. Is this true?
- VPD1: Some people say that VPD1 lose time when "writing" texture in poligon even if the poligon is smaller than texture. I don't understand why (if it's like this). Read this about texture rendering
I didn't understand this explanation. Someone could clarify? ThanksSaturn used a sort of "forward rendering", where it mapped lines from a sprite to stretched lines in screen space (the norm, "backwards rendering", maps pixels in screen space back to the texture, and marches through the screen one at a time). This technique suffered from a serious amount of internal overdraw, where pixels in the same quad are drawn on top of each other. This happens for two reasons. Because the line algorithm suffers from integer roundoff at the edges, adjacent lines would normally leave some gaps between them, so the lines are drawn thicker by inserting an extra pixel where they change slope. And, when the two control edges of the quad are not the same size, multiple lines from the sprite naturally overlap.
This overdraw results in wasted fillrate. Especially if you drew triangles (as degenerate quads) in the wrong way, resulting in a ton of overdraw as every line converged on the same point. It also makes the 50% blended draw mode very glitchy, because the overdraw pixels get blended multiple times. That's why very few 3D games use it, instead opting to use the garish mesh mode.