Some questions about Saturn HW

For hardware talk only (please avoid ROM dumper stuff)
danibus
Very interested
Posts: 135
Joined: Sat Feb 03, 2018 12:41 pm

Re: Some questions about Saturn HW

Post by danibus » Tue May 01, 2018 9:41 pm

Huge wrote:
Sat Apr 21, 2018 10:06 pm
The Saturn works "backwards". It samples every pixel of the texture and determines whether it needs to be written to framebuffer or not. So if you have a 64x64 texture but only write 32x32 of it, then you waste a fourth of your fillrate checking texture pixels that don't end up being drawn. There are some mitigating factors like texture end codes that can be used to reduce the amount of pixels sampled, but it's still bloody stupid either way.

One thing to note though is that while it samples every pixel of the texture, it doesn't write multiple values per line to the framebuffer. So you don't actually get pixels written multiple times (in one line, anyway); the speed is wasted when reading the texture. When you DO get overwrites, is when lines intersect, ie. when the polygon is not a perfect square (4-point transformations, the manual calls these "Distorted Sprites").

I don't know if you get overdrawn pixels when you draw a poly where the right side is larger.... logic would dictate that you get dropouts here, but the VDP1 does some aliasing to get around this, but I don't know how.
Hi there!

Talking about polygon+texture, non-regular polygon, not a perfect square

When reading doc and forums, I understand VDP1 will adapt texture to polygon. It polygon is 32x32 and texture 64x64, I understand will shrink texture to 32x32 and then change shape to adapt to polygon shape.
But you wrote that will "show only 32x32 and then waste time checking pixels that don't end up being draw" (?), then part of texture is not showed (??)

I think is not possible just select which part of texture to show, this is what GameHut said in this video
https://www.youtube.com/watch?v=WDJgeuoaSvQ

That takes me to endcodes, I read doc again (no! I just saw figures as Chilly Willy told me XD ).
I understand we can avoid showing parts of texture using textures, making this pixels 100% transparent and "jumping" in sampling, faster in some way , but again, VDP1 follows until the end of texture, so no part of texture to select, just all texture.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Some questions about Saturn HW

Post by Sik » Tue May 01, 2018 10:14 pm

I mean, if the polygon is smaller than the texture then it'll inherently skip texels.

What happens though is precisely that when it should skip a texel (because of shrinking), what it does is read the texel from VRAM anyway but then does nothing with it. That results in a waste of time and hence VDP1 being slower than it could have been.

Actually... if the VDP1 is shrinking a texture, and there are transparent and opaque texels "overlapping" in a given place, does the opaque texel always get drawn? (i.e. does it write to the same pixel on the framebuffer multiple times within a line?)
Sik is pronounced as "seek", not as "sick".

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Tue May 01, 2018 10:17 pm

danibus wrote:
Tue May 01, 2018 9:41 pm
When reading doc and forums, I understand VDP1 will adapt texture to polygon. It polygon is 32x32 and texture 64x64, I understand will shrink texture to 32x32 and then change shape to adapt to polygon shape.
But you wrote that will "show only 32x32 and then waste time checking pixels that don't end up being draw" (?), then part of texture is not showed (??)

I think is not possible just select which part of texture to show, this is what GameHut said in this video
https://www.youtube.com/watch?v=WDJgeuoaSvQ
The part in the gamerhut video is UV texturing. That one has the system processing a polygon first, and then stretching a texture onto the polygon. So for example you can keep the polygon in position but move the texture. The Saturn doesn't have that; texture and polygon is one and the same.

And because of that, it wastes time sampling the texture even when it doesn't get drawn.

For example on Saturn if you have a texture like
abcd
abcd
abcd
abcd

4x4 = 16 bytes size

and you draw it at half size, you get this on your screen:
ac
ac

2x2 = 4 bytes size

but the VDP1 still reads all "abcd" rows, so 16 bytes, it just doesn't draw half the pixels in the end.

Of course you can draw single coloured or single color + gouraud shaded polygons, those are much faster as there is no texture to sample.

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Tue May 01, 2018 10:30 pm

Sik wrote:
Tue May 01, 2018 10:14 pm
Actually... if the VDP1 is shrinking a texture, and there are transparent and opaque texels "overlapping" in a given place, does the opaque texel always get drawn? (i.e. does it write to the same pixel on the framebuffer multiple times within a line?)
I think it is different in each mode.
With Scaled sprites it will definitely skip writing unnecessary pixels. But it may write the sidemost pixels twice for some reason if the part of the sprite is off screen.
With Distorted sprites it looks like it writes the unnecessary pixels, both within a line and when lines overlap each other.
With non-textured filled polygons, it only writes unnecessary pixels when lines overlap, but not within the same line.

I'm basing these observations on how VDP1 semitransparent polygons look in games, mind you.

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Re: Some questions about Saturn HW

Post by mickagame » Sat Sep 15, 2018 9:19 am

Hello everyone.

I'm taking benefits of this post to ask a a question about saturn hardware.
How is handle the SH2 clock?
The SH2 generates its own clock and output it to the vdp?
SH2 takes an input clock derived from a master clock (like the 68000 is Master Clock / 7 for a sega genesis)?

Thanks !

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Mon Sep 17, 2018 1:04 pm

The SH2/VDP1/VDP2/SCU clocks are generated by a PLL (IC20), which uses 14.318MHz * 2 = 28.6 MHz in 352px mode. In 320px mode, it runs the frequency through a 1708/1820 divider to get 26.8MHz. SCU DSP runs at half of that.
In PAL units it uses a 17,734 MHz crystal and it is run through a 910/1135 divider to get the same clocks.

The video encoder just takes (input / 4) signal form those main clocks, to get standard NTSC/PAL colourbursts.

The 68k and SCSP use 11.29MHz and 22.58MHz respectively. Their source is a bit more complicated, the CD Drive has a 33.8688MHz crystal, it sends 33.8688/4 = 8.4672MHz through the ribbon pin, and the PLL then does EXTCLOCK / 3 * 4 to get the 11.29MHz, and *2 that to get the 22.58MHz. I think.

The SH1 has its own 20MHz crystal.

Later models (VA10+) use a different PLL that also generate the 11/22/33 MHz clocks on the mainboard, and send them to the CD Drive.

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Re: Some questions about Saturn HW

Post by mickagame » Mon Sep 17, 2018 2:43 pm

Thanks for this complete answer ! So it could be possible to overclock the saturn but not without affecting video signal?

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

Re: Some questions about Saturn HW

Post by Chilly Willy » Mon Sep 17, 2018 5:15 pm

The SH2 isn't rated for higher than the "fast" Saturn clock. Any more than that may fail depending on the chips in the unit. I have no experience with how much the SH2 can be overclocked. Given the Saturn pushes the high end of the rating, I doubt many will overclock much if at all.

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Mon Sep 17, 2018 10:05 pm

mickagame wrote:
Mon Sep 17, 2018 2:43 pm
Thanks for this complete answer ! So it could be possible to overclock the saturn but not without affecting video signal?
No, the VDP2 generates the dot clock using the input clock / 4. If you over or underclock the system, it will display the wrong resolution and/or the wrong h/v sync and the image starts running around.

So if you try overclocking, you'll need to keep the VDP2 tied to the original clock and only set the new clock for the SH2/VDP1/SCU. And then hope that the system doesn't fall completely out of sync and crash on the first access miss.
Chilly Willy wrote:
Mon Sep 17, 2018 5:15 pm
The SH2 isn't rated for higher than the "fast" Saturn clock. Any more than that may fail depending on the chips in the unit. I have no experience with how much the SH2 can be overclocked. Given the Saturn pushes the high end of the rating, I doubt many will overclock much if at all.
If you invert the NPSEL pin of the PLL on a PAL unit, you will end up a unit that runs at 35MHz main clock since it won't divide the 17,734MHz input to match the NTSC units input. I don't remember exactly what happens and I don't have a PAL unit set up to test this, but I think it still runs, although with image rollovers since the VDP2 dot clock is out of whack.

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Re: Some questions about Saturn HW

Post by mickagame » Tue Sep 18, 2018 9:00 am

Huge wrote:
Mon Sep 17, 2018 1:04 pm
The SH2/VDP1/VDP2/SCU clocks are generated by a PLL (IC20), which uses 14.318MHz * 2 = 28.6 MHz in 352px mode. In 320px mode, it runs the frequency through a 1708/1820 divider to get 26.8MHz. SCU DSP runs at half of that.
In PAL units it uses a 17,734 MHz crystal and it is run through a 910/1135 divider to get the same clocks.

The video encoder just takes (input / 4) signal form those main clocks, to get standard NTSC/PAL colourbursts.

The 68k and SCSP use 11.29MHz and 22.58MHz respectively. Their source is a bit more complicated, the CD Drive has a 33.8688MHz crystal, it sends 33.8688/4 = 8.4672MHz through the ribbon pin, and the PLL then does EXTCLOCK / 3 * 4 to get the 11.29MHz, and *2 that to get the 22.58MHz. I think.

The SH1 has its own 20MHz crystal.

Later models (VA10+) use a different PLL that also generate the 11/22/33 MHz clocks on the mainboard, and send them to the CD Drive.
When you said the video encoder takes (input /4) it's 14.318MHz/4 for NTSC and 17,734/4 MHz for PAL?

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Tue Sep 18, 2018 12:33 pm

Yeah, 14.318 / 4 = 3.579545 MHz and 17.734 / 4 = 4.43361875 MHz, the NTSC and PAL colour bursts, respectively. The PLL outputs them to the video encoder.

Post Reply