Some questions about Saturn HW

For hardware talk only (please avoid ROM dumper stuff)
Post Reply
danibus
Newbie
Posts: 1
Joined: Sat Feb 03, 2018 12:41 pm

Some questions about Saturn HW

Post by danibus » 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! :wink:

- 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
Saturn 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.
I didn't understand this explanation. Someone could clarify? Thanks

Chilly Willy
Very interested
Posts: 2533
Joined: Fri Aug 17, 2007 9:33 pm

Re: Some questions about Saturn HW

Post by Chilly Willy » Fri Apr 13, 2018 11:17 pm

danibus wrote:
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! :wink:

- 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?
It has 1MB of 32 bit wide "fast" or "high" memory, and 1MB of 16 bit wide "slow" or "low" memory. The intended use of each is to put code and critical data into high mem, and general game data into low mem. You can put code into low mem, and general game data in high mem, but it won't be as fast as the other way around. You may see main memory labeled as 1.5M if it is considering both banks, but reserving some of the fast memory for "OS" functions, like all the Saturn libs.

- 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?
The DSP in the SCU is not terribly flexible. You have very specific ways to feed it data via the DMA, and to DMA the results elsewhere. There's a SEGA tool to assemble DSP code, but little in the way of examples. It got very little usage in the mainstream.

- 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?
Actually, the VDP and SH2s use the same clock, and it's either 26MHz for 320 wide screens, or 28MHz for 384 wide screens. The vram is actually split in two, with half being for VDP1 and half for VDP2. Both blocks of vram are 16 bit wide, and are timed for the amount of data needed to draw/fetch for display modes. It gets pretty complex - I suggest reading both VDP manuals a few times to get all the info.

- 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.
I'm not sure I remember it exactly, but VDP1 writes some of the display into a separate part of the frame buffer to make use of transparency (you have to be very careful on using transparency on the Saturn or it looks wrong due to the way quads are drawn by VDP1). It then draws the sprites in a completely different part of the frame buffer. VDP2 then combines the two along with the cell layers for the final output.

- 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?
Via software, like all old games. Same way the 32X does "hardware" scaling and rotation - with SH2 software. :wink:

But more games pretended the VDP2 didn't exist than the other way around. VDP1 is a pretty simple blitter, whereas VDP2 is a rather complex cell layer combiner. Most games setup VDP2 to just render a frame buffer, then use VDP1 as a blitter, along with common drawing algorithms run on the SH2.

- 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?
I think so, but not 100% on that.

- 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
Saturn 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.
I didn't understand this explanation. Someone could clarify? Thanks
VDP1 does bowtie drawing. It steps down both sides of the quad, drawing a line from one point of the quad side to the other point on the other side, where the two points are often not on the same y coord. It does NOT (necessarily) render a raster line. Because it isn't rasterising the line, pixels in the middle tend to be overdrawn, which is why transparency tends to come out wrong when drawing quads.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest