It is currently Mon Dec 18, 2017 2:10 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 127 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9
Author Message
PostPosted: Tue Aug 02, 2016 6:15 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 228
Quote:
This is from an old part of the conversation, but I really can't let it slide. The Saturn has multiple weaknesses that stem from atrocious design decisions. The SNES, on the other hand, has only one true weakness - the inexcusably slow CPU.


For me the SNES has some other important flaws in the PPU design: splitted OAM, constrained sprites (size, tiles capacity), VBlank only accesses for VRAM... compared to predating systems as the Megadrive or the PCE it really hurts to meet that kind of design in 1990, even more when the CPU is definitely not strong (to not say weak).

Quote:
Let's start with the Saturn's two main Hitachi SH-2 CPUs, clocked at 28.6 MHz. Not dual-core, it's two separate chips, and they couldn't both access the memory bus at the same time.


Of course it is not dual core, back in time dual core were not existing (except for very specific purpose).

Quote:
As individual chips that were not intended for multiprocessor systems, they had no bus snooping or cache-coherency. Without cache coherency, changes made to memory on one CPU are not guaranteed to be visible on the other CPU until the software running on the writing CPU flushes its relevant cache line and the software running on the reading CPU invalidates its relevant cache line. That's a weakness that practical dual-CPU systems don't have, including systems that predate the Saturn.


Back in time again dual CPU systems were quite rare, i would say that even cache in CPU was a recent addition, specially if you consider video game system.
Of course they couldn't use real SMP design that only very costly servers owned back in time. But in fact the SH-2 was designed with SMP approach in mind, it has many features to make SMP architecture easier, for instance it allow you (directly from the memory map) to read/write through the cache or directly from/to memory, exactly to take care about the cache coherency issue between CPU.

Quote:
Compared to the Playstation's single MIPS R3000A at 33.9 MHz, the Saturn's CPUs are individually both slower and more obscure. MIPS is and was a popular and well-understood CPU architecture, in the same way that the 6502, Z80, and 68000 were popular architectures when designed into the NES, Game Boy, and Megadrive, respectively. The SuperH architecture used in the Hitachi SH-2 really only saw use in microcontrollers and some mobile phones, aside from the Saturn and Dreamcast.


Did you already tried to develop with the Super-H CPU ? It's a very straight forward RISC based CPU very similar to ARM / MIPS architecture. It used a smart 16 bit length instruction set to allow better code density and better performance on 16 bit BUS systems. ARM actually copied it for its Thumb instruction set.
The CPU by itself is very powerful and i would say probably better than the R3000A on a same clock basis.
It includes a powerful MAC (Multiply and Accumulate) instruction allowing fast 3D computation without requiring a special DSP for these operations, it also integrate many features as a DMA controller, watch dog timer, dedicated communication canals to communicate with a second CPU (it was used to communicate between CPU without hogging the main data bus). Also i really liked the fact you could split the cache so you use one part as a very fast scratch pad RAM. All these features made the CPU very efficient. Honestly i think that a single SH-2 at 33 Mhz would have been a better choice...

Quote:
Being hard to program for is not "complexity", it's a weakness. If you can't turn theoretical performance into real performance, it might as well not be there.


I do agree with that, a complex system is generally not a good system as you won't be able to exploit all the performance but what i meant is that the Saturn system by itself is very powerful for what it was initially designed (a super 2D system) and has not any specific performance weakness.

Quote:
Now, let's talk about the Saturn's two Video Display Processors (VDPs). The VDP1 is really just an nVidia NV1 chip. You might have warm, fuzzy feelings about nVidia nowadays, but the NV1 was frankly bizarre. It couldn't do translucent polygons. It used quadrilaterals instead of triangles to build 3-D scenes, contrary to pretty much every 3-D accelerator before or since. The Playstation, on the other hand, only needed 1 chip to be competitive. (Of course, both Saturn and Playstation pale in comparison graphically to the N64, but that system came out almost two years later, so that comparison is unfair.)


I do know all that, but in fact the VDP1 was a reasonable choice if you think the system was preliminary designed to be a "super 2D" system (Gigadrive) with a bit of 3D features but definitely not a real 3D system as the PSX. Drawing quad (sprite) with many hardware capabilities (deformation, rotation, lightning...) was a real strong feature to make great looking 2D games. The problem is that we always compare it the the PSX which was designed to do 3D (and the PSX was really good for that), the Saturn can hardly compete in this domain as it was not intented to do that initially. They boosted the VDP1 (fill rate, lightning feature..) so you could use quad (sprite) as polygon for 3D games, changed the main CPU for 2 SH2 and they added the SCU DSP to improve the 3D computation capabilities but well, that was a quick and dirty addition. The problem is the PSX bring the 3D and Sega tried to follow with its Saturn instead of concentrating on the system strengths: doing nice 2D games. I would said the best was mix of 2D/3D games as Clockwork Knight, i think Sega should have stick on that kind of game...
And the Saturn can actually do translucent polygon, as Sik explained they just rarely use it as the way quads are rendered lead to some duplicated rendered pixels (and so transparency is applied twice in some part), also "mesh transparency" was a hardware feature and it was faster so almost developers used it.

Quote:
Finally, let's talk about FMV. FMV was much better on the Playstation, which had a dedicated video decoder chip. You'd think that Sega would have learned from the Sega CD debacle, but FMV had to be decoded in software on the Saturn, unless the add-on Video CD Card was installed. And how many gamers bought that?


Honestly i really don't care about FMV, it's nice the PSX integrated a video decoder chip (not surprising from Sony) but why spent more bucks in that when you already have 2 SH2 CPU which are more than enough to unpack movies. The difference is that video quality was almost always the same on the PSX (and it was great) as the hardware decoder fixed the codec where on Saturn it was really dependant from the software codec used. Still the best FMV on Saturn (thinking about Panzer Dragon Saga for instance) are imo almost on par with the best FMV you had on PSX.

Quote:
So yeah, the Saturn deserved to lose to the Playstation.


Again for me the goal wasn't to compare Saturn versus PSX. The PSX is stronger in 3D, there is no debate... but the Saturn was not preliminary designed for that. I think Sega should have stay with their initial plan instead of trying to change at last minute the architecture and having something so convoluted and expensive in the end. That was a big mistake for sure...

Quote:
The VDP1 predates the NV1. It is similar in design and features, and that's why a lot of Saturn PC game ports used it.
The similarity is interesting, but I know of no documentation that clearly indicates nVidia designed the VDP1, let alone that it's actually just the NV1's GPU in disguise.


In fact it looks like the NV1 (STG-2000) was based on the Saturn VDP (and not the contrary). Don't know exactly how this happened... really difficult to find good information about it.

Quote:
Surprised you didn't mention the fact the Saturn had to do all 3D calculations in software in your rant - I presume this is the reason why there's a second SH2 on the system, especially since their devkit seemed to default to using it to do all the sorting and 3D math. The PS1 had dedicated hardware to do all the 3D math instead (albeit separate from the GPU which still only saw 2D triangles).


In fact the Saturn also has a dedicated hardware to compute 3D math (the SCU DSP) but a very few game actually uses it. Probably because it was not easy to use it (lack of documentation) and also because the SH2 are already quite capable to process 3D math (thanks to the MAC instruction).


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 6:26 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
My understanding of what you said so far is that the Sega Saturn and Nintendo 64 have two CPUs, one to run the game and one to run the vertex shaders. On the Saturn, these are the two SH2s; on the N64, these are the CPU and RSP. The PlayStation is the odd man out, with T&L on a fixed-function GTE chip.

How far off is this?


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 6:53 am 
Offline

Joined: Sat May 04, 2013 6:44 am
Posts: 22
Bregalad wrote:
Quote:
The SNES, on the other hand, has only one true weakness - the inexcusably slow CPU.

Once again, this statement complete and utter bullshit.
Since this thread seems to be inspiring fanboi rage, let me start by saying that the SNES is my favorite console of the 16-bit generation, by a very long shot. My frustration with its slow CPU is out of love, not spite.

With that out of the way, let's honestly compare the SNES to its primary competition, the Sega Genesis.

Excluding the CPU, the SNES is more powerful than the Genesis in every way. It could display many more colors at once, had very advanced sprite rotation and scaling (Mode 7), had better digital sound samples, more sophisticated music synthesis, more RAM, and had more buttons on its original controller with shoulder buttons.

The Sega Megadrive was released on October 29th, 1988, with a 7.6 MHz Motorola 68000 CPU. When released in the US as the Sega Genesis, it cost $190. The Super Famicom was released over two years later on November 21st, 1990, with a 3.58 MHz 65816 CPU. When released in the US as the SNES, it cost $200. That's why I say the slow CPU was inexcusable - it was later, slower, and came in a more expensive box.

Megahertz can be deceiving, so was the Megadrive / Genesis CPU really faster then the Super Famicom CPU, despite being two years older and costing less?

Yes. Yes it was.

The Motorola 68000 has 8 general purpose data registers, while the 65816 has 1 true general purpose register (the Accumulator) and 2 less flexible registers (X and Y). More registers means being able to do more calculations right on the CPU without having to incur the penalty of going to main memory. (Don't try to tell me that the 65816's zero-page is like having 256 registers; they're still slower than register-only instructions.) The two CPUs have similar cycle costs for their arithmetic instructions, so it's not like the 65816 has a higher IPC (instructions per clock).

Rumor has it that the Super Famicom was originally going to get a 10 MHz 68000, but combined with the leading-edge graphics and sound, it would have cost too much money. Therefore, Nintendo switched to the 65816. It wasn't a bad decision in some other ways, since it was very similar to the 6502 in the NES, and developers would hit the ground running with the new system. It's a pattern for Nintendo, actually.

SNES CPU - cheap, slow, slightly improved version of predecessor's CPU.
Wii CPU - cheap, slow, slightly improved version of predecessor's CPU.
Wii U CPU - cheap, slow, slightly improved version of predecessor's CPU.


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 7:54 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Bregalad wrote:
(Agruably, any multiple of 300 Hz fits that criteria so I don't know why they picked this instead of any other multiple of 300 above 40000 Hz).
Apparently to give some headroom for the cut-off point in the analog side of the circuit:
Wikipedia wrote:
In addition, signals must be low-pass filtered before sampling to avoid aliasing. While an ideal low-pass filter would perfectly pass frequencies below 20 kHz (without attenuating them) and perfectly cut off frequencies above 20 kHz, in practice a transition band is necessary, where frequencies are partly attenuated. The wider this transition band is, the easier and more economical it is to make an anti-aliasing filter. The 44.1 kHz sampling frequency allows for a 2.05 kHz transition band.


Stef wrote:
In fact the Saturn also has a dedicated hardware to compute 3D math (the SCU DSP) but a very few game actually uses it. Probably because it was not easy to use it (lack of documentation) and also because the SH2 are already quite capable to process 3D math (thanks to the MAC instruction).

The only thing I saw was a division unit that takes up 37 cycles (although the CPUs can go do other stuff in the meanwhile).

I need to look up again but I think multiplication on the SH2 is not single cycle. A quick look in this SH2 doc says (number in parenthesis is cycles contention, no idea what the 3/ means though)

  • "Executed in 1–3 states" for 16×16 MUL
  • "Executed in 2–4 states" for 32×32 MUL
  • "Executed in states 3/(2)" for 16×16 MAC ← (gap = 1-3?)
  • "Executed in 2–4 states 3/(2~4)" for 32×32 MAC

And on top of this there's extra cycles involved in bit shifting because it uses fixed point for non-integer calculations, and it's using matrices so there are quite a lot of these operations. I need to take a look at the PS1 again but I think the vector processor can do several of these operations all at once.

The Saturn still had other problems anyway, like the complete inability to do texture modulation (only addition and substraction, much like color blending on the SNES - this is why lighting on the Saturn is so different from the PS1 for anything textured, although whether it looks worse or not when you don't go realistic is a different matter =P).

tepples wrote:
My understanding of what you said so far is that the Sega Saturn and Nintendo 64 have two CPUs, one to run the game and one to run the vertex shaders. On the Saturn, these are the two SH2s; on the N64, these are the CPU and RSP. The PlayStation is the odd man out, with T&L on a fixed-function GTE chip.

How far off is this?

Not that off as far as I know.

LightStruk wrote:
Since this thread seems to be inspiring fanboi rage

The thread was fanboy bait by definition, what did you expect? =P

LightStruk wrote:
Rumor has it that the Super Famicom was originally going to get a 10 MHz 68000, but combined with the leading-edge graphics and sound, it would have cost too much money. Therefore, Nintendo switched to the 65816.

http://forums.sega.com/showthread.php?4 ... -processor

Sadly their source is gone, so I can't check to see if there were any links backing it up. Mentioning a name makes it sound like this is something you'd find in an interview. That said, the SNES address space really makes it look like NES games would have been directly intended to run on it instead of having a separate mode like Genesis vs Master System, so I find it really hard to believe it could have ever used anything that wasn't compatible with the 6502.

Then again apparently parts of Sega wanted the Saturn to have a 68020 (or 68030, sources disagree on this) but it was very obvious the engineers never considered that as an actual option. An overpowered Mega Drive with a faster CPU and 3D tacked on top (and probably CD drive and more RAM) may have fared better than the Saturn, honestly (even if just because it'd have been cheaper), but again Sega was too busy sabotaging itself anyway.


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 8:49 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3166
Location: Nacogdoches, Texas
LightStruk wrote:
(SNES) had very advanced sprite rotation and scaling

Nope.

I'm really not getting the whole system sabotaging thing going on here, when it's obvious that the people slamming on the other systems by using as many negative adjectives (that all mean the same thing) as possible have never even programmed for said systems.

Sik wrote:
LightStruk wrote:
Since this thread seems to be inspiring fanboi rage

The thread was fanboy bait by definition, what did you expect? =P

Exactly, which is why this is deserving of a lock about now. Also, LightStruk, don't act all high and mighty like it isn't in you, because it is in me right now. It makes me angry, frustrated, and slightly upset.


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 9:03 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 228
Sik wrote:
The only thing I saw was a division unit that takes up 37 cycles (although the CPUs can go do other stuff in the meanwhile).


http://koti.kapsi.fi/~antime/sega/files ... 042795.pdf
The DSP can be programmed and work independently as it has its own memory and even DMA capabilities. Normally it was used to compute matrix multiplications but a very few game uses it. As you can see the documentation is minimalist...
The division unit was external as you pointed but SH2 could compute them faster (1 bit division in 1 cycle if i remember correctly).

Quote:
I need to look up again but I think multiplication on the SH2 is not single cycle. A quick look in this SH2 doc says (number in parenthesis is cycles contention, no idea what the 3/ means though)

  • "Executed in 1–3 states" for 16×16 MUL
  • "Executed in 2–4 states" for 32×32 MUL
  • "Executed in states 3/(2)" for 16×16 MAC ← (gap = 1-3?)
  • "Executed in 2–4 states 3/(2~4)" for 32×32 MAC

And on top of this there's extra cycles involved in bit shifting because it uses fixed point for non-integer calculations, and it's using matrices so there are quite a lot of these operations. I need to take a look at the PS1 again but I think the vector processor can do several of these operations all at once.


I guess the vector processor in indeed more efficient to do that, but still the SH2 by itself is already quite capable. 32x32 MAC in 2-4 states is damn fast. Also you have quick 2, 8 and 16 bit shift (1 cycle) which is very convenient for fixed point math.
Really i was really please when i discovered this CPU, really nice and efficient design :)

Quote:
The Saturn still had other problems anyway, like the complete inability to do texture modulation (only addition and substraction, much like color blending on the SNES - this is why lighting on the Saturn is so different from the PS1 for anything textured, although whether it looks worse or not when you don't go realistic is a different matter =P).


In fact as far i remember it does support only 0.5 + 0.5 blending for sprites but background has more available blending operation.
Still on Saturn you can create crazy effect by abusing the gouraud shading on sprite (yeah, the VDP1 support gouraud shading). In fact you could apply the gouraud shading with paletted texture in which case the palette index was interpolated (not the color) and you can obtain some weird, i remember some people doing cell shading using that trick but you can probably do much more :p

Quote:
Then again apparently parts of Sega wanted the Saturn to have a 68020 (or 68030, sources disagree on this) but it was very obvious the engineers never considered that as an actual option. An overpowered Mega Drive with a faster CPU and 3D tacked on top (and probably CD drive and more RAM) may have fared better than the Saturn, honestly (even if just because it'd have been cheaper), but again Sega was too busy sabotaging itself anyway.


I heard they planned to use a 16 Mhz V60 cpu (as in system 32 and model 1) but quickly discarded it as it was judged too weak.


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 9:07 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
An "overpowered Genesis with CD and 3D tacked on" would have been more like a 32X. The Saturn stuff is interesting; feel free to continue it in a new topic in in Other Retro Dev.

But this topic has run its course, and we've got a vote to lock (koitsu), a second (Espozo), and a motive (derailed into flamebait).

Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 127 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group