/vr/ - Retro Games

>>2000536
Other than the complexity, Saturn only had a minor hiccups - but there were too many of them and they added up a lot.

- The main SH2 design can stay, it was one of the most powerful cpus they could get at the time, plus Hitachi was already manufacturing like half the Saturn anyway.
- SCU DSP should be changed or enhanced so it can function the same way as the GTE in the Playstation. If it can do that easily (it could do it fast, just not easily), then it can take off a huge load from the SH2.
- the YM292 should be changed to something that can use sample compression. FM portion may be sacrificed for this (the Dreamcast synth was exactly this anyway).
- VDP1 needs native triangle ability, elimination of pixel overdraw problems, a texture cache, some more transparency modes, and perhaps make the palette entries stored in the VDP1 instead of the VDP2, making it possible for paletted sprites to use transparency and gouraud shading. It couldn't match the PS1 gpu in speed even with this, but it could at least match it in features. However the extra cache and palette would raise its costs significantly.
- VDP2 was fine, but remove the external video input from it. It was never used and it increased the pin count a lot, which raised costs. This would also make the cart port more reliable, and remove the MPEG port which was scarcely used. I think the normal cart port had enough bandwidth to transfer a screens worth of image data per frame, so mpeg decoding hardware could be still possible as an expansion.

And also, make the machine had 2mbyte sdram main memory, instead of 1mbyte sdram and 1mbyte regular dram.

This would make it much easier to develop 3d stuff on the machine, and enhance both sound and 2d games. It still wouldn't be as powerful for 3d as the Playstation, but it could hold its own much better, wouldn't piss off developers so much, and would still be a huge 2d powerhouse.

make it gooder

>>2000536

Are you keeping both SH2? What did the SCU DSP do on the Saturn and the GTE in the Playstation do? Would your design be much more expensive to manufacture than the original?

>>2000639
>What did the SCU DSP do on the Saturn and the GTE in the Playstation do?

Playstation and Saturn both did 3d graphics in software, and then translated all the 3d coordinates into a 2d plane, then used a 2d plotter to draw all the polygons basically as deformed sprites. Look up affine mapping.

This transformation is computationally expensive. The Playstation had the GTE in it which was a co-processor designed to do this task on its own, freeing up a lot of cpu resources. The Saturn just brute forced it on the SH2s.

The DSP in the SCU was... a DSP. It was a fixed instruction co-processor that could do 4-5 things in parallel. If you could keep it fed with instructions that it could process in parallel, then it could outperform the SH2s in stuff like matrix computations (necessary for 3d math). This however was difficult and required a lot of optimization, so few games used it at all, let alone use it properly.

>>2000662
Isn't this what the early 3d cards like the voodoo did? I thought that on the Saturn VDP1 was the responsible for that because I read that it did 3d via manipulation of the sprite engine (which was in the VDP1).
So the DSP in the saturn was able to help with calculating 3d stuff but the Playstation had the edge because it had a chip specifically designed to aid in the last (compulsory) step of 3d rendering?

>>2000536
>Propose an alternative hardware design for this alternative past so the Saturn gets a better chance.
Take it out back and shoot it. Concentrate on 32X.

>>2000673
Voodoo was a real perspective-correct 3D texture mapper, but yes the vertex transformation was done in software. PCs had much, much faster CPUs though - Pentiums by that time.

>>2000693
32X was not powerful enough to compete against playstation and n64 anyway. It would've been trounced. To say nothing of how stupid an idea a console add-on is anyway.

>>2000696
Sega had a huge install base with the Genesis, that they basically lost to SNES in the later years. 32X was simple to program, could pull arbitrary video frames out of a coprocessor in the cartridge, and was nearly integrated with the Genesis into a combo already when it was discontinued.

>>2000673
3d engines ran in both Saturn and Playstation entirely on the cpus, with the polygons then transformed to 2d coordinates. There was no perspective correction, nor Z depth. The only difference was that the Playstation had extra hardware for doing the affine mapping, which made it significantly faster at it.

Saturn VDP1 and Playstation GPU were both the exact same thing: they took commands and textures from VRAM, and plotted those to framebuffer. Only difference was in the VRAM design (Saturn had fixed vram and fixed framebuffer, due to VDP2, while Playstation had 1 single chip for vram and framebuffer and you could partition it any way you wanted).
Playstation GPU was also way faster and had more features. But, both were strictly 2d parts, no 3d anywhere.

>>2000696
32x could have been way more powerful if they put a Saturn VDP1 in it. As it was, it had to do nearly all graphics operations in software!

>>2000536
Make it Genesis, Sega CD and 32X compatible. The Saturn already has lots of the necessary hardware, the two SH-2 processors for the 32X and the 68K for the Sega CD / Genesis. The missing logic could probably have been emulated or done by a replacement IC. This would have doubtlessly added a few months to the development time, but as we now know, being the first never really did Sega any good.

>>2000719
Sega CD actually has two 68000 CPUs, and there's a Z80 in there too.

>>2000723
Yeah, that's right. There would have been added cost and development time, but I think it would have been worth it.

>>2000726
Let me make sure I understand you. You look at this, and think "yes, add more"?

>>2000719
Making a machine backwards compatible isn't just "it has a sh2 in there already". 32x, SCD and MD all had totally different video hardware, bus systems, memory mappings and timings, etc.
Going by that route would have made the machine even more complicated, and much less powerful.

A Megadrive converter may have been possible with the existing Saturn however.

Sega CD and 32x compatibility would've been impossible due to how those systems operated.

>>2000747
As I said, most of the stuff is already there. Also, this isn't really a super complicated diagram for a complete system.

>>2000752
I don't see why it would have been less powerful. I know that it would have been more expensive to develop and taken longer, but it would have been a great way to consolidate all the stuff that Sega had been doing up to that point and have a great game library on launch.

The Wii U right now essentially does compatibility with the Wii and Gamecube in the same way, by having mostly the same hardware. I know that the GC/Wii are much similar than the Sega consoles, but I think it would have been possible to do at least Sega CD with reasonable effort.

My idea has good intentions but is sure to have setbacks. Enjoy.

Instead of two Hitachi SH2s, there is only one now clocked to 40mhz. Programmers can sweat less with games tied to one SH2.
>Hitachi SH1 controlling the cd drive is swapped in favor of a Z80 (think Z80+SN76489)
From what I understand a controller just tells another device when to do something and when to stop. The controlled device has its own rate of transferring data. This could have slower load times depending how the Z80 is clocked but I want to cut costs and makes things easier to use.
Yamaha DSP is removed and Motorola DSP stays. The two VDPs are unchanged.
Memory is increased from 1MB to 4MB. No aftermarket option, all games run straight out of the box.

Replace the card slot with a standard one that isn't prone to bend out of place.

>>2000856
>Also, this isn't really a super complicated diagram for a complete system.

>>2000856
>Also, this isn't really a super complicated diagram for a complete system.

even the ps2 is simpler

>>2001308
https://www.youtube.com/watch?v=TMXehqqR8J8

>>2000662
>>2000695
>>2000709

So if I understand it correctly it would go like this:

PSX/Saturn

3d coordinates and transformations in software(in case of the Saturn helped by the DSP if coded)>Affine mapping to a 2D plane (in case of the PSX, helped by the GTE)>Fed to the GPU, converted to sprites, deformed and overlapped according to 3d coordinates>Printed to the framebuffer

3D Accelerated PC

3d coordinates and transformations in software>Info fed to GPU>GPU understands 3D and texture maps, lights and does all the fancy effects using 3d calculus already>Prints to framebuffer

Is that right? I thought that in the case of the PSX the GTE was the final step, but then I looked at this
>>2001308
And asked myself which use would the GPU have if it is connected to the video output but has everything already processed? Just print the framebuffer? Then I remembered that in the Saturn the sprite engine is in the VDP1 so in the PSX might be the same. So I figured out, affine mapping goes before any texture is set right? Or is it a colaboration on per polygon basis?
Please correct me if I am wrong.

>>2000709
>32x could have been way more powerful if they put a Saturn VDP1
Could this have been enough to get a 32xCD system up into the performance range of the Saturn or PlayStation?

Because I think more people would have bought a 32x+ console around that time than bought Saturn

https://www.youtube.com/watch?v=pOWZbydnlZE

>>2001441
32x has two Hitachi CPU like Saturn (albeit clocked 5mhz lower) and can be used in conjunction with Sega CD. Sounds very promising but I feel like the RAM of both units would hold intensive 3D games back.
I often forget about the 32X PWM and Sega CD Ricoh PCM. They could go to some use I guess for sound mixing.

32x seems to be a young Saturn that never should have been sold.

>>2000719
Isn't that what the PS2 did for PS1 emulation?
The PS1 CPU was being used for something else and they decided to use it for playing PS1 games.

>>2001429
>Affine mapping to a 2D plane (in case of the PSX, helped by the GTE)
PSX GTE did coordinate transformations. "Geometry transformation engine". PSX GPU did the 2D affine texture painting.

>>2001429
>3D Accelerated PC
Most of them have hardware-accelerated vertex pipelines (basically starting with the GeForce 256).

In all of these systems, there is hardware accelerated texture mapping. The PSX and Saturn do it in 2D, while other systems do it in 3D (they have an extra set of per-triangle derivatives to do perspective correction). This is a separate issue from where the vertexes are transformed.

>>2001550
So the GTE moved the vertices around. (Kind of like how the vector processor of the Dreamcast was inside the SH4, right?) Did it also translate their positions to 2d so the GPU could paint the textures on top? Or was it the GPU who was doing the affine mapping?
Did they work with the full scene, polygon per polygon, or was it up to the programmer?

>>2001551
As far as I know before the GeForce 256 and the vertex shaders and T&L engines (so, basically all the accelerators that were around when the Playstation (Voodoo/2/3, Riva TNT, Rage 128, Savage, etc.)) all the vertex transformations and manipulation was done on the CPU. As I understand it after all the vertices are set on memory a "3D PC" would feed them to the GPU (which have the perspective correction features you mention) where it would get textured, lit and printed to the framebuffer; while the PSX/Saturn would feed it to a 2D GPU which would treat the polygons as sprites with their shape projected to a 2D plane (that this GPU can understand).
I think we are basically agreeing in that the vertices are already processed and the GPUs work with them via different methods.

>>2001537
Yes, the 68K in the Saturn is used for sound processing, but could have been used as the main processor for Genesis compatility.

>>2001632
>Did it also translate their positions to 2d so the GPU could paint the textures on top
Yes.
>Or was it the GPU who was doing the affine mapping
Yes.

After you transform the 3D vertexes to their positions on the 2D screen (with or without the Z depth coordinate left over), you still need to set up the triangle (find out which pixels it covers) and actually perform the texture mapping (paint those pixels with texture data).

The GTE transformed coordinates to find where each vertex of a 3D scene fell on the 2D screen. The GPU would then take commands to paint textured triangles, often using those coordinates.

At the lowest level, GPUs want arrays of vertex data (already transformed to screen-space in very old cards; still in 3D on newer cards). It's up to the programmer how large each of these arrays are, and what each represents.

>Modern OpenGL programming
https://open.gl/

>Arcade-style bare metal programming on the Voodoo chipset
http://darwin-3dfx.sourceforge.net/voodoo_graphics.pdf

>PSX programming
http://hitmen.c02.at/files/docs/psx/gpu.txt
http://hitmen.c02.at/files/docs/psx/gte.txt

>>2001467
>Sounds very promising
Yeah I feel like we're on the right track here. I'm imagining a world where SoJ didn't withhold development of 32x software and we saw actual AAA 32xCD games being released in '94 that no other consoles could have possibly hoped to match, and even in '95 at maybe Ridge Racer quality?

Then, in '96 after Sega allows Sony to make the first move and establish their system's specs. The Saturn/Neptune is then developed by upgrading the 32x to similar levels and comes with the same exact form factor we're familiar with but full compatibility with the entire existing Mega Drive/CD/32x library plus "Saturn/Neptune" titles that simply take advantage of the VDP and extra memory.

Would this have been feasible? Is Tom Kalinske telling us the truth about SoJ hating the 32x and killing it (and Mega Drive et all) out of anti-SoA spite?

>>2001945
Backward compatibility with something as convoluted as the 32xCD would be nearly impossible.

>>2001952
Even if the system was simply a 32x with the Saturn's ADP and more memory?

>>2001952
Even if the system was simply a 32x with the Saturn's ADP and more memory? I'm not talking about redesigning the Saturn here, I'm talking about if the Saturn had been an appropriately beefed up Genesis/32x/Sega CD integrated into one package that was shaped like the Saturn.

>>2001963
That would probably have been a better solution. It worked well for Nintendo with the Wii.

>>2001967
Oh wow yeah I didn't even think about how parallel that idea is. So our "Neptune" would have, like Wii, would have had a library of more traditional games and slightly scaled down versions of major cross-platform 3D games. Traditional 2D releases may have even run on existing 32xCD systems and come out for some years more. People who had been dragging their feet on buying 32x or Sega CD could have been seduced by the all-in-one package and the existing user base might have weathered the '95 Playstation blitz well enough to steal the 3rd party support.

Sega could have never matched the publishing deal Sony offered small 3rd parties but maybe their amazing in-house studio could have floated them long enough to win it.

>>2001945
Feasible is being generous. As a 32x owner I feel the biggest problem was that the software just wasn't there. If it had the VDP guts the Saturn had later and RAM to back it up then just maybe. Use that in conjunction with with the Sega CD and what do we have?

Darxide is the only 32x game I've seen that has nice textured models and it looks great.
https://www.youtube.com/watch?v=nPUCICkqd1U

stick model 2 hardware inside

>>2002532
Like I said, according to Tom Kalinske SoJ flatly refused to provide software support for 32x then canned it when it prefictably started to fail in sales. Take a look at the video I posted for a 32x 3D tech demo.

https://www.youtube.com/watch?v=pOWZbydnlZE

>>2002686
Seen this dozens of times and I believe you. If they had gone out their way to help all signed on devs achieve results seen in the video then we'd be lookin at a better situation.

All these interviews don't paint a bright picture of SoJ or SoA.

>>2002756
Sega America and Sega Japan hey were like an angry married couple that would have been happier divorced but stayed together because of the kids.

http://www.youtube.com/watch?v=YUZpF2JLF4s
http://www.youtube.com/watch?v=ahISpH1eMzg
intriguing

>>2003946
https://www.youtube.com/watch?v=KXRtAY5tUqM
http://www.youtube.com/watch?v=XLnpXkb8F_w

32x had zero right to live. They should've instead pushed the SVP a bit more.

>>2002686
That stuff in that video was 1. coded by wizards, and 2. has ZERO gameplay logic. There isn't even a single moving character or interactive item.
Plus, the framerate is pretty low as well.

>>2001963
If you put the the Saturn VDP1 into the 32x, it would have hardward capability to do polygons (the 32x in fact did NOT have that, it was all software).

That would make the 32x much more powerful, but still a long way off of the Saturn. And a joke compared to the Playstation.

>>2003946
>http://www.youtube.com/watch?v=ahISpH1eMzg

>all that cosine distortion

>>2001963
32x CD was gimped to hell by the slow 68000 bus in the Genesis. Getting data from the CD to the SH-2 RAM was a pain and locked up the 68000.

>>2004075
>32x had zero right to live. They should've instead pushed the SVP a bit more.
SVP was never going to look good or run well. You're still dealing with the pathetic bandwidth to the VDP and the 3-bit color palettes.

The 32x was originally going to be a relatively dumb framebuffer system to enable cartridges to render their own graphics quickly, for this very reason.

>>2004094
>SVP was never going to look good or run well.

In the end neither did the 32x; and it hurt the customers WAY more than the SVP would have.

>The 32x was originally going to be a relatively dumb framebuffer system to enable cartridges to render their own graphics quickly, for this very reason.

And it ended up just that, a dumb framebuffer system, with two SH2s bolted on.

>>2004089
>32x CD was gimped to hell by the slow 68000 bus in the Genesis. Getting data from the CD to the SH-2 RAM was a pain and locked up the 68000.

This. And don't forget that even getting data from the CD to the Megadrive was very difficult and required tight timing as well, due to the CD connector providing no CPU interrupts.

Both the Mega CD and the 32x were hackjobs bolted to ports that weren't meant for that task. Building a new system that is backwards compatible with either, would be either impossible or extremely wasteful.

>>2001664
>Yes, the 68K in the Saturn is used for sound processing, but could have been used as the main processor for Genesis compatility.

No, it could not. It was missing the entire rest of the Megadrive - VDP, PSG, YM2612, Z80, all the memory setup, all the I/O, and so on.

If they added all of that back and bolted on some new system next to it, then they would've had to settle for something less powerful but equally expensive. It wasn't until 1996 that Yamaha had a functional SoC solution for the Megadrive hardware.

Better solution would have been to keep the MD afloat until 1996 with strong support, then use that SoC to design a Megadrive lock-on cart for the Saturn (the Saturn had all the necessary inputs for such a system, the only difficulty would have been the power draw). Maybe even bundle such a cart with the Saturn.

>saturn shoulda been a superset of md,mcd,32x

lets not forget the md could also run mark3 software and the mark3 can run sg1k software

i guess building expansion on top of expansion on top of expansion etc.. requires the original platform to be designed with future encapsulation in mind.
i also guess making a clean break from one convoluted legacy system to another convoluted non-legacy-well-not-yet-anyway system probably wasn't a good idea.

>>2004196
The Saturn was indeed meant to be a clean break, built on the experience (and problems) they had when expanding the Megadrive.

It is for that reason that the cart port on the Saturn had something like 140 pins. You could feed digital cd audio and (parallel) 24bit digital video through it.

>>2004206
Was it possible for a Saturn to work on cartridges (like all the previous consoles) instead of CD and did any game do it?

>>2006174
Perfectly possible, Action Replay boots like that as well.
Sega did not allow games to have code on the carts due to piracy concerns. Only other assets (gfx, audio, models, etc).

http://m.edge-online.com/features/20-years-after-launch-what-can-segas-segas-32x-teach-todays-console-giants/

>Inside the little lumpy thing protruding from the top of one’s beloved Mega Drive were two Hitachi SH2 processors – the same kit that drove the Saturn. Except, the 32X was better at handling three-dimensional visuals than Sega’s 32bit console ‘proper’.

>Sega of America’s then-senior producer, Scot Bayless, spoke to Retro Gamer in 2010: “[The 32X] was a coder’s dream. It was a wonderful platform for doing 3D. The Saturn was essentially a 2D system. Part of me wishes the Saturn had adopted the 32X graphics strategy.”

Is that true? What does he mean?
(Those sentences are above and below the Doom screenshot)

SEGA should have choosen either the 32X/Neptune or the Saturn in 1994/1995 but not both.

In case they had chosen to go the 32X route they could have waited until 1996/1997 to launch their next full console, so to have it more by the time of the N64 than the Playstation. We can call this console the Uranus today.

The Uranus could have had the Lockheed Martin's Real3D/Pro-1000 that they were using for the Model 3 arcade board (they were actually using two of them on the model 3) based around the PowerPC 603 (the same as in the Model 3), the dual SH2 (like in the 32X and Saturn, could have been good for devs already using the 32X) or the intel i960-KB (used in the Model 1). I am actually making these specs up looking at their arcade hardware, I don't know how much that machine would cost anyway. It would be most probably better looking than the PSX and the N64.

Meanwhile, the 32X/Megadrive could have gotten a lot of good stuff in those two years and still be getting after Uranus release. There could have been Megadrive cartdridges or CDs that executed enhanced stuff for the 32X if found (32x carts would have need to be made of the same shape of the Megadrive ones). The Neptune would have been sold as standard since the release of the 32X.

The 32X/Neptune could have also had Saturn's VDP1 but I don't know how much more expensive it would have been.

If it had worked we could have seen something like a (Sonic?) game released as a 32X cart with an SVP chip and a CD for enhanced content released just because.

If SEGA was going to release the Saturn anyway they should have never ever started to develop the 32X as I am sure it was a massive waste of resources. The thing is that the 32X made sense in the USA and Europe but the Saturn may have made more sense in Japan where the Mega Drive was nothing. Curiously enough, the Saturn was quite successful in Japan but a flop in the rest of the world.

>>2006501
>continued...
Still I think it would have been better for SEGA to look at the international picture. In the end the Saturn was successful in Japan but didn't overshadow the PSX, while when against the SNES, the Megadrive was toe to toe, winning in most places and before 1994. But at least, if they were going to focus on Japan and fix their Japanese situation they should have not bled money with the 32X.

>>2000610
>SCU DSP should be changed or enhanced so it can function the same way as the GTE in the Playstation. If it can do that easily (it could do it fast, just not easily), then it can take off a huge load from the SH2.

>>2000662
The DSP in the SCU was... a DSP. It was a fixed instruction co-processor that could do 4-5 things in parallel. If you could keep it fed with instructions that it could process in parallel, then it could outperform the SH2s in stuff like matrix computations (necessary for 3d math). This however was difficult and required a lot of optimization, so few games used it at all, let alone use it properly.

So if both of them (GTE and SCU) did 3D math operations the difference was that one was a co-processor and the other a DSP? The co-processor works in tandem with the CPU while the DSP takes an input and spits an output in parallel but kind of isolated from the CPU? Is that the difference?

>>2000747
Holy shit!

Is that accurate?
Replace "confidential" with "cluster fuck".

It looks like they designed each subsystem in a vacuum and stitched them together like frankenstein.

There was a table I saw floating around a while ago which /vr/ made that described the capabilities of each 5th gen console. Anyone still got it?