Questions about Sega Saturn

Liandry

Regular
Good day!
Have some questions about Sega Saturn. Actualy I have a lot of them, but I will not ask all already.

1) What advantage was to have two CPUs in Sega Saturn?
2) How big really was the problem with two CPUs with one memory bus?
3) Why did main RAM was split in two parts SDRAM and DRAM?
4) How high was frequency of main RAM?
5) I found info what SCU chip was not only memory buses controler but also could calculate geometry? Is it true?
 
I was waiting for this thread ;p

1) What advantage was to have two CPUs in Sega Saturn?

Two CPUs are better than one, right? Saturn definitely would have been a lot worse off if you kept everything the same but took out the second SH2. 3D games at least probably did tend to use both CPUs to a decent extent, I assume they had the traditional game code run on one CPU and the 3D scene setup (geometry transformation, lighting if present, perspective division, depth sorting) on the other one.

I guess the question we could ask is why PS1 and N64 did not have two CPUs, or at least not in a conventional way that Saturn did. The thing with Sega consoles is that they tend to throw more off the shelf or at least externally designed and manufactured chips on their PCB than their competitors. I think they didn't have the chip design resources that Sony and Nintendo had. In some ways this made the design process cheaper and faster. Sometimes it worked out really well too, like with Dreamcast. In Saturn's case, the result was a ton of chips and a lot of general purpose computation where Nintendo and Sony integrated more special purpose parts. So Sega had a second CPU and maybe intended the SCU DSP for 3D T&L, separate chips and a lot of memory chips at that. Sony instead designed the GTE for 3D T&L and integrated it into the CPU chip.

You can look at some schematic comparisons between Saturn and PS1:

https://segaretro.org/images/4/4e/Sega_Service_Manual_-_Sega_Saturn_(PAL)_-_013-1_-_June_1995.pdf page 12
https://drive.google.com/file/d/0B_GAaDjR83rLa0JHVmhyeTEtQ1E/view page 4 (service manual 1)

Just look at how many more ICs are on the Saturn.

2) How big really was the problem with two CPUs with one memory bus?

I never coded for it so I can't say exactly, it'd depend a lot on how the particular code worked. But I would guess that generally speaking it brought down the total performance to far less than twice what you'd get with one CPU, even if you kept both as busy as you could.

3) Why did main RAM was split in two parts SDRAM and DRAM?

That's a good question. This is going to be pure speculation. SDRAM chips only first came out in 1993, so when Saturn was released (November 1994) they were super cutting edge. It may be that the design started with the 1MB of asynchronous DRAM and then they realized later on that they needed more to stay competitive and threw in an SDRAM controller. But SDRAM may have been significantly more expensive, which would explain

4) How high was frequency of main RAM?

Same clock as CPU, 28.6364MHz

5) I found info what SCU chip was not only memory buses controler but also could calculate geometry? Is it true?

SCU has a DSP that can do whatever it's programmed to. But programming it effectively is very hard. And it only has 1KB data and instruction RAMs. So it can only store 256 instructions at a type. It's not really that powerful anyway,

I think geometry in particular would be really hard to do in a way that was worth it. I just can't think of a very effective way to calculate reciprocals on it, which are needed for perspective projection.

From what I've heard, the games that use it to do so for video decoding.
 
From everything I've read, the choice to split main memory between sdram and dram ultimately did come down to cost.

In terms of the hardware overall, I've read that Yu Suzuki didn't think the Saturn hardware was right, and thought Sega shouldn't release it. He wanted Sega to develop a 3D focused system based on the experience of their arcade divisions.

An interesting story on late MD / build-up to Saturn Sega and the way Sega Japan hated Sega America:

Sega-16: So could that have perhaps caused them to exert more authority over how things were done? The inner rivalry that existed between the American and Japanese branches of Sega is legendary, and most believe that this, rather than any hardware decision, is what caused the company to lose its focus. Would you agree? How much do you think SOJ’s treatment of its U.S. branch hurt business?

Tom Kalinske: I think so. I don’t know how many different instances you know about, but what basically occurred (and I’m probably going to be a little fuzzy on the timing. Joe Miller could probably help you on that one) was that we all knew that there would come a day when the Genesis would no longer have a life, and we’d have to move on to the next technology. There was of course, a big debate as how best to go about that. When we started the CD-ROM efforts, clearly those were the early days of using optical discs for video games, and it was very rudimentary (a lot of it was even done in black & white back in those days), and the combination of live-action and real program software was very difficult.

I remember Joe Miller and I were talking about this, and we had been contacted by Jim Clark, the founder of SGI (Silicon Graphics Inc.), who called us up one day and said that he had just bought a company called MIPS Inc. which had been working on some things with some great R&D people, and it just so happened that they came up with a chip that they thought would be great for a video game console. We told them that in the U.S., we don’t really design consoles; we do the software, but it sounded interesting and we would come over and take a look at it. We were quite impressed, and we called up Japan and told them to send over the hardware team because these guys really had something cool. So the team arrived, and the senior VP of hardware design arrived, and when they reviewed what SGI had developed, they gave no reaction whatsoever. At the end of the meeting, they basically said that it was kind of interesting, but the chip was too big (in manufacturing terms), the throw-off rate would be too high, and they had lots of little technical things that they didn’t like: the audio wasn’t good enough; the frame rate wasn’t quite good enough, as well as some other issues.

So, the SGI guys went away and worked on these issues and then called us back up and asked that the same team be sent back over, because they had it all resolved. This time, Nakayama went with them. They reviewed the work, and there was sort of the same reaction: still not good enough.

Now, I’m not an engineer, and you kind of have to believe the people you have at the company, so we went back to our headquarters, and Nakayama said that it just wasn’t good enough. We were to continue on our own way. Well, Jim Clark called me up and asked what was he supposed to do now? They had spent all that time and effort on what they thought was the perfect video game chipset, so what were they supposed to do with it? I told them that there were other companies that they should be calling, because we clearly weren’t the ones for them. Needless to say, he did, and that chipset became part of the next generation of Nintendo products (N64).

So that’s an example of how, partly due to our success in America, Japan just didn’t want to do the things that we suggested.

http://www.sega-16.com/2006/07/interview-tom-kalinske/

Sega Japan did no favours for the far more successful Sega America. Or for themselves, come to think of it.
 
In Saturn tech documents there are some registers listed to configure how much RAM is installed. There are two options to configure how much main RAM and sound RAM are available. For main RAM, you could have either 512 KB or 1 MB of SDRAM, and for sound you could either select either 128/256 KB or 512/1024 KB. So the "low RAM" options where never used in any released system.

It's pretty clear that Sega originally intended to release the Saturn with less RAM and add extra memory to arcade or dev. systems, but they probably increased it in response to the PSX. I remember reading somewhere that the PSX was originally going to have 1MB of main RAM, but it was increased to 2MB...
 
Wasn't Sega also mooting a cart version of the Saturn at one point to bring down build costs? That would have probably worked okay with the "low ram" configurations you mention.

512KB SDRAM and 256KB sound ram would have seemed okay if you were sat in 1992/1993 thinking about a single CPU, 2D focused cart based machine.
 
I was waiting for this thread ;p
You welcome! :cool:
3D games at least probably did tend to use both CPUs to a decent extent, I assume they had the traditional game code run on one CPU and the 3D scene setup (geometry transformation, lighting if present, perspective division, depth sorting) on the other one.
This was done on CPU? I thought what VDP1 did that.

In Saturn's case, the result was a ton of chips and a lot of general purpose computation where Nintendo and Sony integrated more special purpose parts.
Yes, and that was great! Amazing machine! :D

So Sega had a second CPU and maybe intended the SCU DSP for 3D T&L, separate chips and a lot of memory chips at that. Sony instead designed the GTE for 3D T&L and integrated it into the CPU chip.
We can count SCU as third CPU at least in some cases? And wasn't PS1 GTE on a separate chip?

WOW! Thanks, that is amazing info! I've found full devs docs but there wast many things what is here.

I never coded for it so I can't say exactly, it'd depend a lot on how the particular code worked. But I would guess that generally speaking it brought down the total performance to far less than twice what you'd get with one CPU, even if you kept both as busy as you could.
But if in Saturn would been only one CPU it would've been less performance than two of them? But if there were one big CPU tht would've been better?

That's a good question. This is going to be pure speculation. SDRAM chips only first came out in 1993, so when Saturn was released (November 1994) they were super cutting edge. It may be that the design started with the 1MB of asynchronous DRAM and then they realized later on that they needed more to stay competitive and threw in an SDRAM controller. But SDRAM may have been significantly more expensive, which would explain
How they worked together? They very different, or not so much? Can't imagine what today's PC would have two different RAM. :confused:

Same clock as CPU, 28.6364MHz
And do you know about other RAMs in Saturn. Same as chips they connected to?

And it only has 1KB data and instruction RAMs. So it can only store 256 instructions at a type. It's not really that powerful anyway,
1KB for data and 1KB for instruction or 1KB for both? :)

From what I've heard, the games that use it to do so for video decoding.
Video decoding on SCU?

From everything I've read, the choice to split main memory between sdram and dram ultimately did come down to cost.
Thank you for answer. Very interesting info in that interview!
 
Thank you for answer. Very interesting info in that interview!

Reading TapamN's post above, it appears there may be another factor in the memory split - the system may have been configurable only to a maximum of 1 MB SDRAM. Adding another MB of DRAM on a separate bus might have been both cheaper and easier to implement!
 
This was done on CPU? I thought what VDP1 did that.

VDP1 renders quads and interpolates lighting for them (with a pretty bad technique). It doesn't do anything to calculate the coordinates or the colors of the quad vertexes.

Yes, and that was great! Amazing machine! :D

I strongly disagree. Production costs for Saturn must have been much higher than they were for PS1, and it didn't really translate to better games. Certainly didn't translate to better demand. Surely this was a big factor in the system's poor performance and Sega's rush to replace it with a successor.

We can count SCU as third CPU at least in some cases? And wasn't PS1 GTE on a separate chip?

If you count anything that runs instructions as a CPU Saturn has like 6 of them at least. When I say CPU here I really mean central processing units, eg stuff that runs the core game code and not some highly specialized subsystem.

No GTE wasn't on a separate chip. Look at the schematic I linked, there's no GTE chip.

But if in Saturn would been only one CPU it would've been less performance than two of them? But if there were one big CPU tht would've been better?

I'm sure they didn't screw things up to the point where just having the second CPU there decreased performance. That's more of a Jaguar thing. I doubt "one more powerful" CPU was much of an option.

How they worked together? They very different, or not so much? Can't imagine what today's PC would have two different RAM. :confused:

It's not exotic at all for a processor to talk to multiple kinds of memories. Think ROM chips, that's just another memory type.

And do you know about other RAMs in Saturn. Same as chips they connected to?

I don't know, but it's not really that interesting. They VDP1/2 RAMs were fast enough to where they presumably didn't introduce stalls into the fixed functions of the chips.

1KB for data and 1KB for instruction or 1KB for both? :)

1KB each.

Video decoding on SCU?

Yes.
 
I'm sure they didn't screw things up to the point where just having the second CPU there decreased performance. That's more of a Jaguar thing. I doubt "one more powerful" CPU was much of an option.

SH2's were developed that ran at up to 40 mHz, but whether that was on the same process and/or passively cooled I have no idea. If Sega had been able to slap in a 40 mHz SH2 at the cost of a heatsink and fan I do wonder if it might have been worth it ...


I think some later codecs were developed that ran on the two CPUs, as Saturn video did improve markedly over early games. Couldn't swear to it though, one's memory gets confused with what the DC was doing on its SH4 (320 x 240 mpeg took 50% CPU time iirc, could run in parallel with all normal game operation e.g. Space Channel 5).
 
SH2's were developed that ran at up to 40 mHz, but whether that was on the same process and/or passively cooled I have no idea. If Sega had been able to slap in a 40 mHz SH2 at the cost of a heatsink and fan I do wonder if it might have been worth it ...

The particular CPU that Sega used, SH7604, did have a specified maximum frequency of 28.7MHz @ 5V: http://pdf.datasheetcatalog.com/datasheet/HitachiSemiconductor/mXwuttu.pdf

I don't have a timeline for their other SH2s, but it looks like 28.7MHz was the fastest they got at 5V; the faster ones were 3.3V max. I suspect they were available later, and/or were not easily integrated into the Saturn without major redesign.

http://datasheet.octopart.com/HD6417707RF60A-Renesas-datasheet-11766312.pdf (see page 5)
 
VDP1 renders quads and interpolates lighting for them (with a pretty bad technique). It doesn't do anything to calculate the coordinates or the colors of the quad vertexes.
You say what on Saturn all geometry calculations done on CPU? :oops:

I strongly disagree. Production costs for Saturn must have been much higher than they were for PS1, and it didn't really translate to better games. Certainly didn't translate to better demand. Surely this was a big factor in the system's poor performance and Sega's rush to replace it with a successor.
I mean from tech perspective idea was unusual. No other console or any different computer in the world was like Saturn. ;-)

If you count anything that runs instructions as a CPU Saturn has like 6 of them at least.
And those 6 are two CPUs, SCU, VDP1, VDP2 and SH-1? Or some different chips?

No GTE wasn't on a separate chip. Look at the schematic I linked, there's no GTE chip.
Ok, I'll check second link, for now I just saw only first.

I'm sure they didn't screw things up to the point where just having the second CPU there decreased performance. That's more of a Jaguar thing. I doubt "one more powerful" CPU was much of an option.
I mean if Satur had one strong CPU it coud be better than two less powerful? How much performance second CPU realy add?

Then why Saturn need VIdeo CD card with two MPEG decoders one for video and one for audio?
 
You say what on Saturn all geometry calculations done on CPU? :oops:
Doing transform and lighting on CPU was typical then. It wasn't until the very end of the 90s that moving all that over to dedicated graphics hardware started to become a big thing.

CPUs had support for the sorts of operations that you needed for T&L, and that functionality wasn't a natural addition to what existed in graphics hardware at the time.
 
I have question. Were the quads in saturn defined vert by vert as with polys, or was it done some other diferent way. What would happen if you handed the rasterizer some weird degenerate set of vertices, as in a "twisted" quad?
 
You say what on Saturn all geometry calculations done on CPU? :oops:

Yes.

I mean from tech perspective idea was unusual. No other console or any different computer in the world was like Saturn. ;-)

You can say the same thing about a lot of consoles. Like Jaguar. Especially unusual designs in this space were probably more often than not also inferior.

And those 6 are two CPUs, SCU, VDP1, VDP2 and SH-1? Or some different chips?

Two SH2s, SH1 (I think this runs off a ROM, not really sure), SCU DSP, SCSP DSP, and 68k. VDP1 has flow control in its display list commands but it's really hard for me to consider it a processor. VDP2 doesn't have that much.

I mean if Saturn had one strong CPU it coud be better than two less powerful? How much performance second CPU realy add?

Yes, and instead of 4 4GHz cores in our desktops it'd be better if we had one 16GHz core right? There's limits to what you can have in one CPU at any given time, and in particular there are limits to what Hitachi could give them when they locked down that part of the design.

Then why Saturn need VIdeo CD card with two MPEG decoders one for video and one for audio?

You mean the optional MPEG add-on card that very few games utilized? Just because there are some games (and not a lot) that used the SCU DSP to help with video decoding doesn't mean that it was the best possible solution, it was simply possible to get somewhat better performance doing it this way than on the CPUs. Or this way plus the CPUs, if the game is really optimized.

I have question. Were the quads in saturn defined vert by vert as with polys, or was it done some other diferent way. What would happen if you handed the rasterizer some weird degenerate set of vertices, as in a "twisted" quad?

They were defined vertex by vertex.

The way the Saturn rendered quads is by interpolating endpoints along the horizontal edges, then drawing textured lines between those endpoints. It had to draw the lines with an extra pixel where the slope changed, so all of the pixels had a neighbor to the left, right, top, or bottom. They did this to prevent gaps between the lines. When you account for this in the fact that quads weren't always parallelograms (so the lines converged on top of each other towards the shorter side) you ended up with locations inside the quad getting drawn with multiple pixels. That's what made the blending all glitchy and hence why little used it.

This technique supported twisted quads. It also supported concave quads. However, those wouldn't always look quite right. What you'd end up having is the vertex with the obtuse inner angle would look curved because the lines would overlap a bit outside of the perimeter of the quad.
 
Doing transform and lighting on CPU was typical then. It wasn't until the very end of the 90s that moving all that over to dedicated graphics hardware started to become a big thing.
Ok, hen big par if not biggest of those days CPU performance was used for stuff that oday do GPUs?

You mean the optional MPEG add-on card that very few games utilized? Just because there are some games (and not a lot) that used the SCU DSP to help with video decoding doesn't mean that it was the best possible solution, it was simply possible to get somewhat better performance doing it this way than on the CPUs. Or this way plus the CPUs, if the game is really optimized.
So it was good what they incuded this expansion for Saturn, or it wasn't so needed?

Next set of questions.

1) VDP1 have two framebuffer chips, so it have two framebuffers. Did they work like regular back and front buffers?
2) As I understand VRAM of VDP1also is storage fo textures? And question connected with previous. Textures go from CD-ROM to VDP1 directly or they first go to main RAM and then to VRAM?
3) Main RAM is split to two pools, but are they use one bus?
4) What is stored in VDP2 VRAM? Framebuffer from VDP1 and backgrounds textures?
 
The SH2s inside the Saturn can address different pools of memory (also of different type) at the same time as they integrated a flexible memory controller. The SDRAM inside the Saturn was pretty cutting edge technology at the time; a single 4 Mbit Hitachi HM5241605-17 was used; at 28 MHz it operates at CL1 over a 16 bit bus. The Saturn CPU read data in burst of 128bits (thus 4 accesses with a 32 bit bus or 8 with 16) to update one cache line, while memory writes could be 8/16/32 bit. It took 12 cycles to read one entire line and only two cycles to write data to the RAM. That's all I can gather from the technical DOCs I've collected over the year.

My knowledge of the VDP 1/2 is more limited. I have the technical docs somewhere but I only gave them a superficial read once. Yes the Saturn was sort of capable of doing double buffering but not in the same sense we mean today. The VDP1 was a sprite engine that took square or rectangle bitmaps and placed it on a destination buffer using simple (but inefficient) forward rendering; the user could define the position of all the four vertex in the destination buffer, thus the bitmap could be scaled or warped, creating the illusion of having the surface projected in perspective. It was also able to apply per vertex interpolated shading akin to gouraud. The VDP2 created the actual screen picture by combining several pieces of data together; transparency and warping effects were possible. Certain Saturn games used VDP1+2 to obtain interesting effects such as the water reflections in Panzer Dragoon or translucent flames and explosions. Neither the VDP1 nor VDP2, unlike the GPU inside the Playstation, were capable of blending, so transparency or other fancy effect had to be done by superimposing two or more objects in the VDP2.

Many people call the Saturn the ultimate 2D console for this reason... There is no 3D capable hardware in the Saturn at all. If they wanted to build even a basic GPU, using quads, they should have adopted backward rendering to avoid wasting fillrate in small (relative size<1) polygons, allow free placement of UV coordinates instead of thinking in terms of rectanguar sprites and maybe give the VDP1 the ability to perform some basic blending ops. I'm not even considering 'fancy' functions such a proper Z buffer or texture filtering! Those come at a price which was outside the budget back in 1993-94; the Reality Engine compromises (texture cache, horrid fillrate with Z enabled) show that these two functions require more logic and bandwidth that was available at the time for a cheap, mass produced ASIC.

The sole contribution of the SCU to 3D graphics was doing a 'fast' interger dot3 between two vectors. it still took several clock cycles, so many developers preferred to use the SH2 multiply and accumulate instruction (one result every 3 clocks throughput).

I hope it helps and I hope not to have made any mistake. I had the SDRAM and SH2 datasheet ready at hand to check a couple of things. All the rest is written from memory.
 
Last edited:
Back
Top