Questions about Sega Saturn

Discussion in 'Console Technology' started by Liandry, Jun 7, 2016.

  1. Liandry

    Regular Newcomer

    Joined:
    Feb 26, 2011
    Messages:
    319
    Likes Received:
    37
    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?
     
  2. Rikimaru

    Veteran Newcomer

    Joined:
    Mar 18, 2015
    Messages:
    1,014
    Likes Received:
    395
    Recently I saw a very good video about graphics capabilities of Saturn (enable subtitles):
     
    Akumajou, rockaman, Starx and 2 others like this.
  3. Liandry

    Regular Newcomer

    Joined:
    Feb 26, 2011
    Messages:
    319
    Likes Received:
    37
    I saw that video some days ago, but anyway thank you!
     
  4. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    429
    Location:
    Cleveland, OH
    I was waiting for this thread ;p

    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.

    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.

    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

    Same clock as CPU, 28.6364MHz

    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.
     
  5. function

    function None functional
    Legend Veteran

    Joined:
    Mar 27, 2003
    Messages:
    5,135
    Likes Received:
    2,248
    Location:
    Wrong thread
    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:

    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.
     
    Cyan and Liandry like this.
  6. TapamN

    Newcomer

    Joined:
    Jan 10, 2008
    Messages:
    47
    Likes Received:
    20
    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...
     
  7. function

    function None functional
    Legend Veteran

    Joined:
    Mar 27, 2003
    Messages:
    5,135
    Likes Received:
    2,248
    Location:
    Wrong thread
    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.
     
    Liandry likes this.
  8. Liandry

    Regular Newcomer

    Joined:
    Feb 26, 2011
    Messages:
    319
    Likes Received:
    37
    You welcome! :cool2:
    This was done on CPU? I thought what VDP1 did that.

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

    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.

    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?

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

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

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

    Video decoding on SCU?

    Thank you for answer. Very interesting info in that interview!
     
  9. function

    function None functional
    Legend Veteran

    Joined:
    Mar 27, 2003
    Messages:
    5,135
    Likes Received:
    2,248
    Location:
    Wrong thread
    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!
     
    Liandry likes this.
  10. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    429
    Location:
    Cleveland, OH
    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.

    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.

    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.

    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.

    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.

    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 each.

    Yes.
     
    Liandry and bunge like this.
  11. tuna

    Veteran

    Joined:
    Mar 10, 2002
    Messages:
    3,139
    Likes Received:
    356
    Really good and interesting video! I should go buy Rockman X4!
     
    Liandry likes this.
  12. function

    function None functional
    Legend Veteran

    Joined:
    Mar 27, 2003
    Messages:
    5,135
    Likes Received:
    2,248
    Location:
    Wrong thread
    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).
     
    Liandry likes this.
  13. corysama

    Newcomer

    Joined:
    Jul 10, 2004
    Messages:
    175
    Likes Received:
    122
    Liandry likes this.
  14. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    429
    Location:
    Cleveland, OH
    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)
     
    Liandry likes this.
  15. Liandry

    Regular Newcomer

    Joined:
    Feb 26, 2011
    Messages:
    319
    Likes Received:
    37
    You say what on Saturn all geometry calculations done on CPU? :shock:

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

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

    Ok, I'll check second link, for now I just saw only first.

    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?
     
  16. HTupolev

    Regular

    Joined:
    Dec 8, 2012
    Messages:
    936
    Likes Received:
    564
    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.
     
    Liandry likes this.
  17. milk

    Veteran Regular

    Joined:
    Jun 6, 2012
    Messages:
    2,989
    Likes Received:
    2,560
    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?
     
    Liandry likes this.
  18. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    429
    Location:
    Cleveland, OH
    Yes.

    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.

    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.

    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.

    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.

    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.
     
    Simon F, Grall, Shifty Geezer and 2 others like this.
  19. Liandry

    Regular Newcomer

    Joined:
    Feb 26, 2011
    Messages:
    319
    Likes Received:
    37
    Ok, hen big par if not biggest of those days CPU performance was used for stuff that oday do GPUs?

    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?
     
  20. msxyz

    Newcomer

    Joined:
    May 5, 2006
    Messages:
    112
    Likes Received:
    46
    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.
     
    #20 msxyz, Jun 9, 2016
    Last edited: Jun 9, 2016
    Cyan, Liandry and milk like this.
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...