Fixing the Sega Saturn

[Anonymous No.10689689]

>programming the dual SH2 chips was a challenge due to bus contention to the main RAM, and programmers struggled with the tiny 4KB internal CPU cache, therefore give the second SH2 a secondary 128K DRAM for a secondary cache
>remove VDP2 to reduce cost, we don't need 2D background tiles
>256 maximum colors on screen instead of 32 thousand to speed up rendering and reduce VRAM requirements from 2x256KB to 2x64KB
>CD will now be handled by the SH2 "slave" chip instead of a third SH chip (SH1) to save costs
>sounds will be handled by the cheap and reliable Ensoniq OTIS
>now that it costs substantially less to manufacture, sell it $50 less than the PS1 and market it as the budget alternative
And there you have it. Sharturn is saved.

[Anonymous No.10690480]

>>10689689
you just invented the sega cd

[Anonymous No.10690490]

>it's another anon LARPs as a hardware engineer thread

[Anonymous No.10690494]

>>10689689
and where the fuck are the games?

[Anonymous No.10690515]

>>10689689
Nah, should've just waited a year and developed an unfucked vdp. Would've been just as much and better than ps1/n64 at both 3d and 2d. Sega was just a fucked up company, internally. It's so weird to see how it went down. They shouldve not released the 32x or Sega CD and put it all into the Saturn, make it backwards compatible and bam. All the 32x games and Sega CD games would've been excellent on a well cooked Saturn. Not the medium rare chicken breast we got.

[Anonymous No.10690525]

>>10689689
>256 maximum colors on screen instead of 32 thousand to speed up rendering and reduce VRAM requirements from 2x256KB to 2x64KB
Any 3D game would look like dogshit with only 256 colors, I guarantee you that.

[Anonymous No.10690529]

>>10689689
>Fixing the Sega Saturn
specs are irrelevant, the market was not interested in sega consoles anymore. they were only relevant for a brief period with the genesis because nintendo had no other competition. then they proceeded to ruin all their mindshare with their fucktarded add-ons. the sadturd was just a walmart ps1 and everyone knew it. but to be fair it wouldve failed regardless if sony entered the ring or not

[Anonymous No.10690548]

Saturn launches in September 1995 with Virtua Fighter Remix and Daytona USA Championship Edition.

There, I fixed it.

[Anonymous No.10690557]

>>10690548
>virtua farter
tekken but bad and with moon gravity
>gaytona usa
wow 3 tracks! look out gran turismo

[Anonymous No.10690595]

>>10690529
>the market was not interested in sega consoles anymore.
it was, they just fucked up tremendously which led to Sony taking over the teenager audience
list of Sega's major mistakes during 5th gen:
>failing to realize that 3D was the way forward in the early stages of Saturn's development
>underestimating Sony and overestimating Atari
>the stillbirth of 32X
>the early surprise launch of Saturn in the US
>Bernie blocking localization attempts to the point where the US Saturn library is 1/3rd of its Japanese library size

[Anonymous No.10690602]

>>10689689
It's so weird how Sega fanboys are unanimously stunted Peter Pans constantly imagining what could have been.

[Anonymous No.10690614]

>>10690548
>>10690595
I knew I forgot about something. Here it is:
>failure to release a mainline Sonic platform game in full 3D during 5th gen

[Anonymous No.10690617]

>>10690602
reality is sometimes too painful to just accept it

[Anonymous No.10690631]

>>10690614
>implying a 3d sonic on the saturn wouldve been good
it wouldve just been bubsy 3d with a run button

[Anonymous No.10690728]

>>10690631
All they needed to do was make a 3D Sonic platformer using Sonic R's engine and make sure it was ready for 1996. What did Sony have at that point? Crash Bandicoot? Sonic R is arguably more technically impressive than Crash.

[Anonymous No.10690748]

>>10690515
>backwards compatible
Why are you retards obsessed with backwards compatibility. Adding genesis backwards compatibility would basically be grafting on an entire genesis.

[Anonymous No.10690762]

>>10690728
Too bad in reality Traveler's Tales was working on Sonic 3D Blast in 1996

[Anonymous No.10690909]

>>10690525
Standard for 3D DOS games. Doom, Quake, Duke Nukem 3D, Tomb Raider, Descent, Magic Carpet, a shitload of driving games, flight sims, etc. It's only a problem if you want colored lighting. Quake 2 had a 256 color software rendering mode, but it disabled the colored lighting.

[Anonymous No.10690921]

>>10690525
PC games at the time stuck with 256 colors, also for 3D games.
It's not as bad as some people claim it to be (but 16bit color depth is a good step up still)

[Anonymous No.10690937]

>>10690909
>>10690921
They looked like SHIT. Software rendering SUCKS. Console games looked much better unless you had a Voodoo, which was very expensive. Consoles were actually superior to PCs for quite a bit of time back then.

[Anonymous No.10691028]

>>10689689
Saturn doesn't need fixing, here's the word from the big man himself (dated 1995)

[Anonymous No.10691063]

>>10691028
It's true that Saturn could have succeeded as it was if Sega was actually competent. Not that its design wasn't a mistake, but a single mistake can be easily forgiven. It's much worse when they pile up. Saturn used CDs just like PS1. It was more difficult to program, generally slower at drawing polygons and couldn't do transparency, but it also had its own advantages like the bigger VRAM size or more CPU processing power when used properly. I'd say that a future where they ended up in 2nd place and outsold Nintendo for the first time in their history was very possible, it's just that several more mistakes outside of the initial Saturn design were made that buried any chance for success.

[Anonymous No.10691159]

>>10690937
>They looked like SHIT.
Have you ever looked at a PS1 or Saturn game?
>Consoles were actually superior to PCs for quite a bit of time back then.
No they weren't. Even without 3D acceleration, Pentiums were enough to run PS1/Saturn looking 3D games. Games back in the day used lookup tables for non accelerated 3D and Pentium was great at handling that. You would only need a GPU to run N64 level stuff, but even the cheapest GPU outperformed the N64.

[Anonymous No.10693108]

>>10689689
>Fixing the Saturn
This is like saying "Fixing the Bush Administration" in 2024. It's broken, it was always broken and "Fixing" it is just daydreaming

[Anonymous No.10693839]

>>10691063
>I'd say that a future where they ended up in 2nd place and outsold Nintendo for the first time in their history was very possible
It sort of did, in JP Saturn was seen as a huge win for SEGA and it had a wide fanbase, I don't know how it could do so well there and yet flop so bad in other markets...

[Anonymous No.10694083]

>>10689689
Why not make good games? All everyone talks about is shallow shit that you beat in 30 minutes.

[Anonymous No.10695623]

>>10693839
A cult Japanese following does not equate to one elsewhere, especially when tons and tons of games simply aren't localized under incompetent direction.

[Anonymous No.10695921]

>>10690748
Everyone misses this somehow. In fact SEGA already had two backwards compatible consoles designed this exact way, the CDX and the Neptune, which obviously we never got because of the Saturn. If people want backwards compatibility and Genesis-style games, they should play those two instead of Saturn.

To me this is like Nintendo fans complaining about the N64 when the SNES already exists. It's a no-brainer but somehow everybody misses it

[Anonymous No.10697897]

>>10690490
Is that Alan Partridge?

[Anonymous No.10697943]

>>10689689
>programming the dual SH2 chips was a challenge due to bus contention to the main RAM, and programmers struggled with the tiny 4KB internal CPU cache, therefore give the second SH2 a secondary 128K DRAM for a secondary cache
This doesn't solve the problem of bus contention. If you want to solve that you need to design the system with 2 CPUs from the start.
>remove VDP2 to reduce cost, we don't need 2D background tiles
This is incredibly retarded. VDP1's fillrate is the main chokepoint of the Saturn. Removing VDP2 and dumping it's job on VDP1 pretty much would kill performance.
>256 maximum colors on screen instead of 32 thousand to speed up rendering and reduce VRAM requirements from 2x256KB to 2x64KB
WTF does this solve? You can already select from 4bpp, 8bpp, and 15-bit RGB on VDP1, and VDP2 can do 4bpp, 8bpp, 15-bit RGB and 24-bit RGB. You can already select those lower color depths to save VRAM.
>CD will now be handled by the SH2 "slave" chip instead of a third SH chip (SH1) to save costs
You're worried about bus contention and you want to have the Slave CPU hogging the bus for CD-ROM access?
>sounds will be handled by the cheap and reliable Ensoniq OTIS
How do you know this would be cheaper and what about the SCSP do you think is unreliable?
>now that it costs substantially less to manufacture, sell it $50 less than the PS1 and market it as the budget alternative
Saturn and PS1 already cost about the same to manufacture at launch. Saturn cost about $540, PS1 cost about $500. And Sega was already able to quickly reduce costs to get it down to costing about $200 to manufacture by mid 1996 and beat Sony to the $200 price point.

If you wanna fix the Saturn, you just need to cancel the 32X before it even became a napkin scribble. If you do anything with the hardware, go with a unified 2MB of SDRAM and give VDP1 more time in the oven to give it support for texture coordinates and additive blending without overdraw issues.

[Anonymous No.10698094]

>>10689689
Anyone know what happened to XL2? I followed updates for years. Their homebrew game Hellslave was looking really impressive then updates just.. stopped. A year passed and then they uploaded that Saturn demo of Unreal ported to the Hellslave engine. People thought it looked great and asked if that's what's being made instead. XL2 said Nope then disappeared again. Another year has passed and now some other channel has been uploading clips of a Saturn port of MGS which they say uses the Hellslave Engine.

[Anonymous No.10698359]

>>10698094
>Anyone know what happened to XL2?
He had a kid.

[Anonymous No.10698369]

The Saturn needed fixing? Why?
Mine still works, since 1996.

[Anonymous No.10698984]

>>10697943
>This doesn't solve the problem of bus contention.
It actually does. With bigger cache the CPUs could be allowed to complete many tasks without running out of memory and getting interrupted. It's a fact that Saturn devs were complaining about the small memory cache. Having two CPUs with bigger cache is less ideal for the programmer than having one powerful CPU and one big RAM, but it's much easier to deal with than having two CPUs with tiny cache and one big RAM they have to fight each other for all the time.
>VDP1's fillrate is the main chokepoint of the Saturn. Removing VDP2 and dumping it's job on VDP1 pretty much would kill performance.
VDP2 could be replaced by a much cheaper and simpler display processor. That's why the console would have to be limited to 256 colors.
>WTF does this solve?
Cost saving.
>You can already select those lower color depths to save VRAM.
Nope, the Saturn still needed a 512KB front buffer. Remove those higher bit rates and you won't need as much VRAM anymore.
>You're worried about bus contention and you want to have the Slave CPU hogging the bus for CD-ROM access?
While the Master CPU is working you could use the Slave CPU to read the disc and store the data in its cache temporarily before being transported to the the bigger RAM later.
>How do you know this would be cheaper
Because it's an 80s technology that requires far less RAM and less sophisticated fabbing. You just know it's cheap because the budget Atari Panther console was about to use it.
>what about the SCSP do you think is unreliable?
Nothing, you could just save money by opting for a cheaper option. The OTIS was the ol reliable midi card.
>Saturn and PS1 already cost about the same to manufacture at launch.
And that's the problem. The Saturn had inferior 3D capabilities to the PS1 and yet it cost the same. Sega would be better off selling a cheaper inferior hardware than an inferior hardware that costs the same.

[Anonymous No.10699086]

>>10689689
>sounds will be handled by the cheap and reliable Ensoniq OTIS

That means that the Sega Saturn wouldnt be able to do seamless music loops https://youtu.be/lSvve0X8IGM?feature=shared

https://youtu.be/0zAC6eYqBes?feature=shared

https://youtu.be/v0JzfVjBjWs?feature=shared

https://youtu.be/-nfM1m94WM4?feature=shared

[Anonymous No.10700908]

>>10690494
Dev friendly architecture will attract more devs.

[Anonymous No.10701056]

>>10690631
bubsy 3d was better than the literal diarrhea STI was about to shit out before SoJ stepped in and saved the sonic IP

[Anonymous No.10701138]

>>10701056
I bet the Bug! with Sonic skin RTA was gonna make would've been better than whatever STI was gonna shit out.

[Anonymous No.10701351]

>>10698984
>It actually does. With bigger cache the CPUs could be allowed to complete many tasks without running out of memory and getting interrupted
They would still need to eventually interact with each other. The CPUs are set up as in a Master Slave relationship. The Slave CPU can't do anything unless the Master tells it what to do. And 4KB is actually enough cache. It's enough that SGL was able to fit it's entire polygon pipeline in it so the slave could just crunch through all the polygon math while the master handled everything else.

If you want to fix the bus contention issues, you can get rid of the SCU DSP because it pretty much stalls everything when it tries to interact with HWRAM. You could also just design the systems to use 2 CPUs from the start and design the system bus around that instead of slapping the 2nd CPU into a design that was clearly designed around one CPU at the last second.
>VDP2 could be replaced by a much cheaper and simpler display processor. That's why the console would have to be limited to 256 colors.
This is fucking retarded. The VDPs were not the source of the Saturn's high production costs early on.
>Cost saving.
The main issue with cost was overall RAM. Reducing the frame buffer size would be a drop in the bucket.
>Nope, the Saturn still needed a 512KB front buffer.
Not really. At 15-bit RGB a 320x224 frame would need 140KB. So 2 of those would be about 280KB. You could still have higher color depths and have less frame buffers. The Frame buffers are 256KB each so it can handle higher resolutions and allow it to render stuff off screen.
> Remove those higher bit rates and you won't need as much VRAM anymore.
And then you'd be a laughing stock next to the PS1.

[Anonymous No.10701375]

>>10698984
>>10701351
>While the Master CPU is working you could use the Slave CPU to read the disc and store the data in its cache temporarily before being transported to the the bigger RAM later.
No you wouldn't because the bus would be in use. To access the CD-ROM block you'd need to access the main system bus, go through the SCU, and then access the A-Bus to get to the CD-ROM. If the Master CPU is working and accessing HWRAM, LWRAM, the SCU, B-Bus, etc. the Slave will need to wait.
>Because it's an 80s technology that requires far less RAM and less sophisticated fabbing
The SCSP doesn't require a lot of RAM, it would just be stupid not to have a decent amount of RAM for a sample based system because you want enough space for your samples. Otherwise you end up with a crippled situation like the SNES or Sega CD. And 512KB is already cutting it tight when there's no compression support. Which as far as I can tell the OTIS doesn't have compression support either so it too would be in the same boat RAM wise.
>Atari
Was fucking retarded and this kind of thinking is what killed them.
> The Saturn had inferior 3D capabilities to the PS1 and yet it cost the same.
The major chokepoint is VDP1, and that could be solved with more time in the oven to give it key features like I said previously.
>Sega would be better off selling a cheaper inferior hardware than an inferior hardware that costs the same.
They tried that with the 32X remember? And that was a complete and total disaster. The original plan was for 32X to hold the line in the west until about 1996/1997. But it failed miserably that they needed to rush the Saturn out in the west to sweep 32X under the rug.

[Anonymous No.10701525]

>>10701351
>The Slave CPU can't do anything unless the Master tells it what to do.
Of course? But it still takes many cycles to complete the tasks the master CPU gives it, hence its meant for parallel processing.
>4KB is actually enough cache.
No it's not, that's Atari Jaguar tier.
>It's enough that SGL
Oh a development kit released 2 years after the console's launch that needed to do some extreme optimizing to help the devs. Yeah, doesn't sound like the gold standard of dev friendly console hardware.
>If you want to fix the bus contention issues, you can get rid of the SCU DSP because it pretty much stalls everything when it tries to interact with HWRAM.
That's caused by the singular RAM bus and having too many chips in the first place.
>The VDPs were not the source of the Saturn's high production costs early on.
But it was one of that. At first there was only VDP1.
>The main issue with cost was overall RAM. Reducing the frame buffer size would be a drop in the bucket.
Yes? The total VRAM size is 1.5MB. Reducing the graphics quality to 256 colors and single layered texture would make the system significantly cheaper. Reduce the resolution from 320*224 to 320*200. Now you only need like 64KB for each buffer.
>And then you'd be a laughing stock next to the PS1.
That's why it would have to come out first and sold at a lower price. If you can't compete at the same price point, then be the budget alternative.

[Anonymous No.10701608]

>>10701375
>No you wouldn't because the bus would be in use.
Yeah it really is a mess. The CD reader is a different computer system entirely with its own SH CPU and huge RAM. They should've just given up CD streaming entirely to make the system less costly.
>The SCSP doesn't require a lot of RAM
512KB is a lot of RAM.
>Which as far as I can tell the OTIS doesn't have compression support either so it too would be in the same boat RAM wise.
Gravis Ultrasound only needs 256KB. The OTIS would've been a downgraded version that needed even less. It's a MIDI sequencer first and foremost. I think that's very much alright.
>Was fucking retarded and this kind of thinking is what killed them.
Their library sucked, but they were great at making sophisticated systems at a very low cost.
>more time in the oven
Would be unwise to release the Saturn after the PS1. Sony always wins baby, you can't beat Sony.
>They tried that with the 32X remember?
They didn't. 32X should've been a cheap single SVP chip filled connector with no external cables, but no, they went full retard to compete with the Jaguar.

[Anonymous No.10701895]

>>10689689
> replaces superior ym with a garbage chip from ensoniq that dates back to the mid 1980s
> he really doesn't understand how much of a fucking retard he really is

>>10699086
> has no idea how sound chips works
> won't even dare to blame the talentless hacks creating the audio
100% pure cringe. this is what happens when you think you're intelligent but your only source of information is youtubers that read wikipedia pages verbatim.

[Anonymous No.10701903]

>>10701608
>The OTIS would've been a downgraded version that needed even less. It's a MIDI sequencer first and foremost.
the otis is a multi channel stereo dac and has NOTHING to do with midi. it doesn't even have any midi input capability. you faggots here really can't help yourselves but to lie about everything.

here's an otis spec sheet, let me know when and where you find the midi functionality, genius:
https://www.dosdays.co.uk/media/ensoniq/es5505%20-%20OTIS.pdf

[Anonymous No.10701912]

>>10701895
>garbage chip from ensoniq that dates back to the mid 1980s
It was a cheap and widespread chip found in budget keyboards and PC sound cards. PCs in the early 90s still used it. As a cost saving measure it's alright.

[Anonymous No.10701930]

>>10701903
MIDI is just a standardized music sequencing file format. Wavetable synthesis chips like ensoniq could play the midi format.

[Anonymous No.10702273]

>>10701525
>its meant for parallel processing.
Not in the true sense. It's there to do jobs the Master gives it to do. It can't just have it's own separate program that runs o it's own in parallel completely separated form what the Master is doing. It only can do tasks the Master tells it to do.
>No it's not, that's Atari Jaguar tier.
Then I guess PS1 is also Jaguar Tier as it's CPU also only has 4KB of instruction cache.
>Oh a development kit released 2 years after the console's launch
SGL was out by Mid 1995, less than a few months after the Saturn came out in Japan. It's based on what AM2 did when making Virtua Fighter on the system.
>doesn't sound like the gold standard of dev friendly console hardware.
It's pretty typical for the system. Most 3D games have the 2nd CPU run through the polygon math in it's cache.
>That's caused by the singular RAM bus
It's not really a RAM bus, it's the system bus. It's how the CPUs not only interact with RAM but also the rest of the system. The issue is that you have 2 32-bit CPUs plus a weird DSP sharing the same 32-bit bus trying to access the same resources.

To relieve that pressure you could ditch the DSP, widen the bus, etc. Both would probably be better and cheaper solutions than asking Hitachi to add 32x the amount of cache in the SH2.
> At first there was only VDP1.
Both VDPs were always planned to be there there. The last minute add-on was the 2nd SH-2.
>Reducing the graphics quality to 256 colors and single layered texture would make the system significantly cheaper.
And everything would look like ass as a result. Yes RAM was the major production cost issue for both the Saturn and PS1, but we know how that plays out. RAM Prices plummet starting late 1995 and eliminate that issue. Selling the system at a loss to wait that out was the correct response.
>budget alternative.
Again they tried that with the 32X, it failed.

[Anonymous No.10702283]

>>10701608
> They should've just given up CD streaming entirely to make the system less costly.
Again this would be idiotic and none of it deals with the issue of how the Slave would get from the System bus to the CD-ROM drive while the master is busy. Even without the SH1 running it, you still need to access the A-Bus through the SCU to get to the CD-ROM drive. Secondly Hitachi gave Sega a good deal on the SH2s and the SH1s to the point where Hitachi wasn't even making money on the deal until they consolidated the 2 SH2s down to one chip.
>512KB is a lot of RAM.
But necessary if you have up to 32 channels doing uncompressed PCM samples. OTIS doesn't address this key issue. It doesn't have compression support or FM synth capabilities to allow it to get away with less RAM.
>It's a MIDI sequencer first and foremost.
And what do you think the SCSP is?
>they were great at making sophisticated systems at a very low cost.
They were making horribly buggy hardware that was an even worse nightmare to develop for than the Saturn that no one bought because it was such a laughing stock compared to Saturn, PS1, and even 3DO.
>Would be unwise to release the Saturn after the PS1
Who said anything about it releasing later? Cancel 32X and use it's development time to polish up VDP1. It's actually pretty close to having things like additive blending for transparencies and UV Texture coordinates already. With a little more time they probably would have added that.
> Sony always wins baby
Correct. Nothing anyone could do would stop Sony from winning the 5th gen. The best case scenario for the other consoles was a strong 2nd place.
>They didn't
Yes they did.

[Anonymous No.10702293]

>>10701608
>they went full retard to compete with the Jaguar.
Oh this stupid story again. The reality of 32X is that Sega of America refused to get on board with the Saturn, so Sega of Japan said "Ok what do you guys want instead?" SoA said they couldn't abandon the Genesis yet and SoJ came back asking "How are you going to compete against these new systems coming out like the PS1, 3DO, and Jaguar with just the Genesis?" and from that discussion came the 32X.

The plan was that 32X would be the low budget system in the US until Saturn and PS1 became cheaper and then they'd release the Saturn in the US. But that plan failed because no one wanted the 32X. They saw what the PS1 and Saturn were capable of in magazines, promotional material, etc. and decided to just wait for those systems instead because. The same situation would play out with your retarded idea.

[Anonymous No.10702314]

>>10701930
They could play MIDI format because there was a sound driver running on the CPU doing the MIDI playback and driving the chip to play the right samples at the right time. The SCSP is capable of the exact same thing and many games do just that with the 68k or even the slave SH2 handling reading the sequence data and telling the SCSP what samples to play on what channel at what time.

The following are all examples of the SCSP doing sequenced midi-like music:

https://www.youtube.com/watch?v=5z-crDa7etg
https://www.youtube.com/watch?v=bxgxVDvTkJM
https://www.youtube.com/watch?v=TI33p8WocCo
https://www.youtube.com/watch?v=OSDzyRFqRwc
https://www.youtube.com/watch?v=CI48WETulpc
https://www.youtube.com/watch?v=7EYKPGKVek8
https://www.youtube.com/watch?v=wE_AeJiyo3Y
https://www.youtube.com/watch?v=Re0r3iQxaKA

[Dave No.10702341]

>>10689689
In other words?
Saturn sucks major ass.

[Anonymous No.10702386]

>>10702273
>Not in the true sense.
So? It's still parallel processing even if the system couldn't directly access it.
>PS1 is also Jaguar Tier as it's CPU also only has 4KB of instruction cache
The PS1 only has 1 main CPU. It doesn't need that much cache.
>SGL was out by Mid 1995
Ah right. Still, that's not enough time to develop games. According to the wiki there are only 7 games ever released that were developed with the SGL, all came out quite late in the console's lifecycle.
>Most 3D games have the 2nd CPU run through the polygon math in it's cache.
Yeah and the devs didn't find the cache size convenient.
>It's not really a RAM bus, it's the system bus.
You know exactly what I meant.
>To relieve that pressure you could ditch the DSP, widen the bus, etc.
That would require a major makeover. You'd probably even have to turn it into a 64-bit system like the Jaguar and N64.
>Both would probably be better and cheaper solutions than asking Hitachi to add 32x the amount of cache in the SH2.
Not really. DRAM wasn't that expensive. An external cache is cheaper and simpler to implement than an internal cache.
>Both VDPs were always planned to be there there.
I guess wikipedia's article isn't that accurate then. But my point stands still. A second graphics layer, which is what VDP2 did, was unnecessary.
>Selling the system at a loss to wait that out was the correct response.
Sega's financial performance says no.
>they tried that with the 32X
Again, they didn't.

[Anonymous No.10702413]

>>10702386
>So? It's still parallel processing even if the system couldn't directly access it.
It's not in the sense you're thinking. It's a slave being given jobs to do by the master.
>The PS1 only has 1 main CPU. It doesn't need that much cache.
lol, tell that to PC gamers who were cheering when they were finally able to get L1 and L2 cache in the DOS days.
>According to the wiki
Wiki's, especially SegaRetro, are full of shit. Looking at their list I can tell there's already quite a few games they're missing. The Saturn ports of Wipeout use SGL, Virtua Cop 1 and 2 and House of the Dead use SGL. Fighter's Megamix, Fighting Vipers, Dead or Alive, etc. all use SGL. The list on SegaRetro is just games they found the string "SGL" somewhere in the games files.
>You know exactly what I meant.
No I don't because you don't even know what you're talking about here.
>That would require a major makeover.
And what you're proposing wouldn't?
>You'd probably even have to turn it into a 64-bit system like the Jaguar and N64.
Technically there already is some 64-bit stuff in it when you look at the SH2s multipliers and division units.
> DRAM wasn't that expensive.
All RAM was expensive in 1994, there was a shortage going on and prices went through the roof.
>An external cache is cheaper and simpler to implement than an internal cache.
And slower which defeats the purpose.
>A second graphics layer, which is what VDP2 did, was unnecessary.
Considering VDP1s low fillrate, the 2nd layer is definitely required.
>Sega's financial performance says no.
Saturn was sold at a loss when it launched in Japan, but by the end of 1995 Sega was already making a profit selling it at $299. We have Sega's financial reports that show us exactly how much the Saturn cost to produce when it was still being sold for $299.
>Again, they didn't.
Yes they did. 32X was literally a budget 32-bit system intended to hold it's own against the PS1.

[Anonymous No.10702434]

>>10702283
>none of it deals with the issue of how the Slave would get from the System bus to the CD-ROM drive while the master is busy
No what I was saying was just simply use the master CPU to access the CD. Simple as that. There'd be no streaming, as in reading the CD while a game program is running, you'd have to pause the game while the CD is being read, but it'd be a cheap solution.
>Hitachi gave Sega a good deal on the SH2s and the SH1s to the point where Hitachi wasn't even making money on the deal
Source? Still fewer chips = less cost, no matter how cheap it is. Also no need for 512KB CD cache.
>But necessary if you have up to 32 channels doing uncompressed PCM samples.
It didn't need that much. It would only need to be a serviceable sound system, if it's to be the budget alternative to the PS1.
>They were making horribly buggy hardware that was an even worse nightmare to develop for
So? It was cheap and powerful.
>Cancel 32X and use it's development time to polish up VDP1
Nah just release the VDP1 as is. Launch the saturn early. It didn't need transparancies, it only needed to be a cheap serviceable console. It couldn't compete in the same market segmentation as the PS1 with sega's brainless arcade games.
>Yes they did.
Whatever.

>>10702293
Wrong.
>"We were at CES '94 in Las Vegas and Sega of America’s head of R&D Joe Miller asked a few of us to join him in his suite for a call he was expecting from Nakayama," remembers Bayless. "There had already been some discussion about an up-gunned Mega Drive with Hideki Sato and his Sega Hardware Team, but the essence of the call was that we needed to respond to Atari’s Jaguar and we needed to do it right away. Joe said he was confident the US team could come up with a design that would do the job, so Nakayama said 'get it done' and we were off to the races.

[Anonymous No.10702456]

>>10702434
>No what I was saying was just simply use the master CPU to access the CD
Up until this point you've been saying have the slave CPU do it. Make up your mind. And either way it's an idiotic thing to do.
>Source?
Interviews with Hitachi engineers as well as Hideki Sato. Go look them up.
>Also no need for 512KB CD cache.
It's why Saturn games typically had better load times than PS1 games save for the few poor ports.
>It didn't need that much.
The chip you're suggesting also has 32 channels.
>So? It was cheap and powerful.
It was cheap and buggy, not powerful. The 32X alone runs circles around the Jaguar:
https://www.youtube.com/watch?v=w_B1s69m2Wg
https://www.youtube.com/watch?v=mJfrkD0E6pY
>Nah just release the VDP1 as is.
VDP1 is the chokepoint of the Saturn. It's slow, has horrible overdraw issues, and has no support for texture coordinates.
>Wrong.
That quote is out of context. The full context we now have from the Japanese side we have a better idea of what was being talked about.
https://mdshock.com/2020/06/16/sega-president-hayao-nakayamas-new-year-speech-1994/
https://mdshock.com/2023/07/10/irimajiri-speaks-out-about-the-saturn-the-32x-and-soas-financial-troubles/

That's from New Years 1994 and he says he had just spoken with his American counterparts discussing plans to counter newcomers like Sony as well as the 3DO. Bayless's recollection is just bringing up Jaguar for clickbait lulz and ignoring that the other 2 systems were also mentioned. The whole reason that discussion happened was because Sega of America was adamant they keep the Genesis going and didn't want to release the Saturn yet. They were delusional about the reality of the 16-bit market imploding around them.

[Anonymous No.10702467]

>>10702413
>It's a slave being given jobs to do by the master.
And the job can take a lot of memory and many cycles to complete.
>tell that to PC gamers who were cheering when they were finally able to get L1 and L2 cache in the DOS days
Cache is always useful to speed up things as it gives the CPU the fastest access to memory, but it's even more crucial in dual CPU designs.
>No I don't because you don't even know what you're talking about here.
The processors are fighting for the same bus to the main RAM blockhead.
>And what you're proposing wouldn't?
Sure as shit it wouldn't need as much R&D.
>Technically there already is some 64-bit stuff in it when you look at the SH2s multipliers and division units.
Those are only internal bus.
>All RAM was expensive in 1994
Compared to SRAM obviously retard. No, SRAM and especially internal CPU cache is always more expensive.
>And slower which defeats the purpose.
Only if you get rid of the internal cache.
>Considering VDP1s low fillrate
Hence lower the color depth.
>the 2nd layer is definitely required.
It was mostly for shading and second layer of textures. Unnecessary luxury.
>We have Sega's financial reports that show us exactly how much the Saturn cost to produce when it was still being sold for $299.
Does that include R&D and software development?
>32X was literally a budget 32-bit system intended to hold it's own against the PS1.
See above.

[Anonymous No.10702486]

>>10702467
>And the job can take a lot of memory and many cycles to complete.
Sure, which is again why it's not really a parallel processing system. The Slave is best used when it has something it can go off on it's own and work in it's cache due to 3 different processors sharing the same bus.
>Cache is always useful to speed up things as it gives the CPU the fastest access to memory,
Sure, but the point is more that 2 CPUs having 4KB of cache isn't too little for 1994, it's right on the mark for a consumer video game system.
>the processors are fighting for the same bus to the main RAM blockhead.
I get that dumbass, the point I was making is it's not just RAM they fight for. It's access to ANYTHING. Where the CPUs are on the system, they have to go through the System Bus and then the SCU to access anything else in the system. If one of them is using that bus, the other CPU will have to wait. Not just RAM.
>Sure as shit it wouldn't need as much R&D.
It would still require a complete radical redesign. Which if we're going back in time to around 1992 to make these kinds of changes we may as well just set it up properly with 2 CPUs from the start and a wider bus, etc.
>Compared to SRAM obviously retard
Saturn used both SDRAM and DRAM retard. And guess what, trying to use the DRAM for anything other than static data kills your performance because of how slow it is. Using DRAM for your cache would be stupid.
>Hence lower the color depth.
The colordepth isn't what hurts the fillrate. There's not really any drawing performance difference between drawing 4bpp, 8bpp, or 15-bit rgb pixels for VDP1. All those modes get you is just freeing up more space in VRAM for more textures. The issue with VDP1 is simply that it's slow and plagued with overdraw issues.
>It was mostly for shading and second layer of textures. Unnecessary luxury.
No it wasn't. It was used for backgorund layers, text layers, rotating 3D planes, etc.

[Anonymous No.10702489]

>>10702467
>Does that include R&D and software development?
It's the cost to manufacture. We can see in early 1996 Saturn was being sold for $299 and cost $239 to produce.
>See above.
I did and I replied dumbass.

[Anonymous No.10702591]

>>10702456
>Up until this point you've been saying have the slave CPU do it.
Obviously that's not what I implied when I said just get rid of CD streaming. It should've been obvious to you.
>either way it's an idiotic thing to do.
Because?
>Interviews with Hitachi engineers as well as Hideki Sato.
Well they might as well said that, but my point still stands. Fewer chips = less cost. Even if they didn't make a profit those stuff would cost money.
>It's why Saturn games typically had better load times than PS1 games save for the few poor ports.
Would be even faster if the powerful SH2 handled the CD driver and the data went straight into the main RAM. You'd need to pause the game while that happens, but it'd be fast.
>The chip you're suggesting also has 32 channels.
But it's a wavetable synthesis, not a PCM sampler. It plays shorter looping samples with analogue-esque effects added.
>It was cheap and buggy, not powerful.
The 2D performance blows 32X's and 3DO's away. With that object controller, it was created for fast 2D games in mind with only a tiny bit of hardware 3D capability added.
>The 32X alone runs circles around the Jaguar
It had less bus contention because it didn't have one singular RAM for all purposes, had lower color depth, and was released a full year later. And yet it still worse at 2D.
>has horrible overdraw issues
I can't find any document that explains how VDP2 helps with the overdraw issue. Maybe it could help games with poor quality textures to look better, but clipping and overdraw still mostly needed software solutions on the saturn.
>https://mdshock.com/2020/06/16/sega-president-hayao-nakayamas-new-year-speech-1994/
>https://mdshock.com/2023/07/10/irimajiri-speaks-out-about-the-saturn-the-32x-and-soas-financial-troubles/
None of these explains why the 32X has similar architecture to the Jaguar when they could've used a cheaper RISC chip with no external power connector required like the SVP chip.

[Anonymous No.10702681]

>>10702486
>The Slave is best used when it has something it can go off on it's own and work in it's cache due to 3 different processors sharing the same bus.
And that 4KB cache runs dry pretty quickly.
>but the point is more that 2 CPUs having 4KB of cache isn't too little for 1994
It was with that bus bottlenecked design.
>Where the CPUs are on the system, they have to go through the System Bus and then the SCU to access anything else in the system.
That's why you'd need another bus.
>we may as well just set it up properly with 2 CPUs from the start and a wider bus, etc.
2 CPUs sharing the same main RAM would still be less than ideal. If this master-slave configuration means that the other CPU can't process more than 4KB worth of data at a time, then it's stupid.
>SDRAM
SDRAM is just a type of DRAM.
>trying to use the DRAM for anything other than static data kills your performance because of how slow it is
Hence you'd only use it for a secondary cache. Internal cache would still need to be used.
>The colordepth isn't what hurts the fillrate.
Lower color depth = fewer bits per pixel = more speed with a low fill rate.
>rotating 3D planes
Only 2 3D planes.

>>10702489
>$239 to produce
That's a fortune.
>I did
You posted before I finished my response.

[Anonymous No.10702684]

>>10702591
>Obviously that's not what I implied when I said just get rid of CD streaming. It should've been obvious to you.
How would getting rid of CD Streaming suddenly change who's job it was to operate the CD-ROM drive?
>Because?
See previous CD-Based systems that tried that and how much of a pain in the ass it was to get data off the disc.
>Even if they didn't make a profit those stuff would cost money.
Sure, but the point is they weren't the root issue for the Saturn's high cost. It was the high amount of RAM in the system. PS1 had the same issue and both cost about $500 to produce when they came out in 1994.
>Would be even faster if the powerful SH2 handled the CD driver and the data went straight into the main RAM
How would having the SH2 do it be faster when the drive has a fixed data rate of 300KB/s? The cache is there to give a buffer so it doesn't have to race the drive.
>You'd need to pause the game while that happens, but it'd be fast
Then it's not faster. You're effectively stalling the system to read data off the disc.
>But it's a wavetable synthesis
What the hell do you think a wave table is? It's a table of samples. The samples being PCM based.
>The 2D performance blows 32X's and 3DO's away.
But people wanted 3D so that doesn't really matter. And Saturn and PS1 blow the Jaguar's 2D capabilities out of the water.
>It had less bus contention because it didn't have one singular RAM for all purposes
If anything it's even worse than the Saturn. It has the same 2 SH2 CPUs but now they're on a 16-bit bus with less RAM and no VDPs to help render anything.
>I can't find any document that explains how VDP2 helps with the overdraw issue.
It helps by taking things off VDP1s plate so it doesn't have to bother drawing them. Sonic R, Sonic Jam, Virtua Fighter 2, etc. use it to draw the floors for example:
https://www.youtube.com/watch?v=pQWjT0fl72A
https://www.youtube.com/watch?v=Dhpp5ilRLEU
https://www.youtube.com/watch?v=93Zpzm37sTU

[Anonymous No.10702693]

>>10702591
>None of these explains why the 32X has similar architecture to the Jaguar
It's architecture is nothing like the Jaguar. What those articles tell you is the reason why the 32X was made. It was made because Sega of America wanted to keep the Genesis going and not move on to the Saturn. So 32X was intended to be that low budget option you're talking about, and Saturn wouldn't release until 1996 or later. The idea failed because no one wanted to invest in a low budget option when PS1 and Saturn were right around the corner in Japan. Consumers didn't wanted it, and developers didn't want to support it.
>when they could've used a cheaper RISC chip with no external power connector required like the SVP chip.
The SVP chip is just a Samsung DSP and it's a buggy disaster.

[Anonymous No.10702729]

>>10702681
>And that 4KB cache runs dry pretty quickly.
Not really.
>It was with that bus bottlenecked design.
And addressing the bus issue earlier on would probably be cheaper and more worthwhile than putting more memory in a system that was already expensive to produce due to memory.
>That's why you'd need another bus.
So now the CPUs are on separate buses and unable to directly communicate with each other?
>If this master-slave configuration means that the other CPU can't process more than 4KB worth of data at a time, then it's stupid.
It basically means any time the slave and master both try to access the same resource, the master will win and the slave will have to wait it's turn.
>SDRAM is just a type of DRAM.
Yes and it's much faster.
>Hence you'd only use it for a secondary cache. Internal cache would still need to be used.
Then how would this help with performance? When the CPUs are running their programs from memory, it needs to be fast memory, especially when it's trying to do 3D tasks.
>Lower color depth = fewer bits per pixel = more speed with a low fill rate.
Except that's not how VDP1 works. VDP1's fillrate is 1 cycle per pixel for untextured draws, and 2 cycles per pixel for untextured draws. Half Transparency can take 6x longer for both, and Gouraud Shading has an overhead of ~100-200 cycles during the initial set up of reading the shading table, doing the math, etc. afterwards it's again 1 cycle for untextured, and 2 cycles for textured.

Changing the color depth will have no impact on that performance.

>Only 2 3D planes.
Which you can do some pretty spiffy stuff with if you know what you're doing with windows and what not. These examples are only using 1 plane as far as VDP2 is concerned.

https://www.youtube.com/watch?v=kJsr2j9ghOA
https://www.youtube.com/watch?v=bSHJ8x7L2rM
https://www.youtube.com/watch?v=AOsUdG8P9pg

[Anonymous No.10702731]

>>10702681
>That's a fortune.
PS1 wasn't any better, but the point is that RAM prices were falling fast and in less than a year Saturn's production cost were cut down by more than half. At a retail price of $299 they were no longer selling the system at a loss.

[Anonymous No.10704135]

>>10689689
Nothing, the console doesn’t matter
Developers will use what they have
You cunts need to stop imagining that hardware would change anything
>but muh complex chips
Didn’t matter for any other complex console

[Anonymous No.10704197]

>>10701375
>No you wouldn't because the bus would be in use. To access the CD-ROM block you'd need to access the main system bus, go through the SCU, and then access the A-Bus to get to the CD-ROM. If the Master CPU is working and accessing HWRAM, LWRAM, the SCU, B-Bus, etc. the Slave will need to wait.
and wait on a 2x cd-rom at that....

>>10701351
>The main issue with cost was overall RAM.
which we now know was due to widespread market collusion.

>>10701375
>Otherwise you end up with a crippled situation like the SNES
to be fair, coming from a cartrtidge, the SNES's sample size limitations are to be considered carefully. But its a stretch to say crippled either because you're only fetching so much data on a cart.

>And 512KB is already cutting it tight when there's no compression support
to my mind, the lack of any compression support is its biggest weakness. lots of streamed tracks ended up mono. but its support of 32 channel FM synthesis is absolutely crazy. Did it ever get used in any game?

>>10701608
>It's a MIDI sequencer first and foremost.
ah, so you dont know what you're talking about.

>>10701912
>It was a cheap and widespread chip found in budget keyboards and PC sound cards
so is pretty much any YM series yamaha sound chip. Guess what the SCSP is?

>>10702434
>No what I was saying was just simply use the master CPU to access the CD. Simple as that. There'd be no streaming, as in reading the CD while a game program is running, you'd have to pause the game while the CD is being read, but it'd be a cheap solution.

people were already pissed about load times on the SegaCD, and even still pissed with 4x drives available in PCs. You think that shit would fly in something intended to be an updated console?

[Anonymous No.10704226]

you guys need to go back to sega16 boards with your circlejerk.

[Anonymous No.10704228]

>>10702729
>VDP1's fillrate is
>1 cycle per pixel for untextured draws
>2 cycles per pixel for untextured draws

uh-huh.

[Anonymous No.10704236]

>>10704226
>you guys need to go back to sega16 boards with your circlejerk.

there there, just because you have a gaping hole in your /vr/ nahlej doesn't mean you can't participate too.


>>10702283
>Secondly Hitachi gave Sega a good deal on the SH2s and the SH1s to the point where Hitachi wasn't even making money on the deal until they consolidated the 2 SH2s down to one chip.
now that one i'm gonna call bullshit on without some evidence.

>>10702456
>Sega of America was adamant they keep the Genesis going and didn't want to release the Saturn yet. They were delusional about the reality of the 16-bit market imploding around them.

You're forgetting the reason why SOA didnt want the Saturn was the MSRP SOJ was setting at launch. That made SOA half right. The launch price was reaching shitbox (3DO, Neo Geo) and scraping towards entry level PC territory. But they were delusional about what was left of their 16-bit success wave, and the shell-game inventory of Genesis units was about to come crashing down.

[Anonymous No.10704453]

>>10704236
>now that one i'm gonna call bullshit on without some evidence.

https://169.45.167.69/forum/showthread.php?33527-The-Story-of-the-Hitachi-SH-2-and-the-Sega-Saturn
>By March 1997, a total of 7.56 million Saturn units had been manufactured. In other words, approximately 15 million SH-2 chips had been made for the Saturn. With this, the SH had suddenly risen to the second-most-selling high performance RISC microcontroller, and its name became known throughout the world.
>However, in terms of sales, the outcome was by no means favorable. Even though the Saturn was equipped with two SH-2s, that did not mean that profits simply doubled. In fact, the profit per unit decreased. Due to being the first sale, they were unable to increase the profits to a satisfactory level.
>The only solution was to decrease costs as much as possible. From April 1994, before the start of mass production, work had begun on reducing the size of the SH-2. After that, a special chip was made for the Saturn that combined two SH-2s into one. This effort paid off, and profits finally rose to a healthy level.

original article in japanese:
http://web.archive.org/web/20150417010407/http://japan.renesas.com/products/mpumcu/superh/related_sh/theme/story/06.jsp

[Anonymous No.10704464]

>>10702684
>How would getting rid of CD Streaming suddenly change who's job it was to operate the CD-ROM drive?
>You're effectively stalling the system to read data off the disc.
There you get it. And yes it'd be faster even if you could do nothing but watch a static laod screen.
>previous CD-Based systems
Like what?
>It was the high amount of RAM in the system.
And with my solution it would need less RAM and fewer chips.
>$500
Gotta need a source on that, especially for the PS1.
>How would having the SH2 do it be faster when the drive has a fixed data rate of 300KB/s?
Because data wouldn't need to be transported from the CD cache to the main RAM through the SCU, and any software decompression algorithm for any game that used it could be run faster.
>It's a table of samples. The samples being PCM based.
PCM doesn't have the ability to generate its own custom waveforms, it only plays samples. Hence it's not a wavetable. With the ensoniq you'd get away with less RAM for BGMs because you'd not need long samples to make a decent sounding music.
>And Saturn and PS1 blow the Jaguar's 2D capabilities out of the water.
Saturn, definitely. PS1, it depends on how well Jaguar's blitter and object processor are used.
>If anything it's even worse than the Saturn.
I was comparing it to the Jaguar which didn't even have a dedicated VRAM.
>draw the floors
Wow how useful.

>>10702693
>It's architecture is nothing like the Jaguar.
It has two RISC chips. Sure the way it generates graphics and sounds are a bit dissimilar to the Jaguar, but it was definitely made to compete against the Jaguar rather than being a low cost addition to the Mega Drive. It was $160 while Sega's SVP game was only $100 and didn't need an external power connector.
>The SVP chip is just a Samsung DSP and it's a buggy disaster.
You could've replace it with any other RISC DSP if it was buggy, you know. It's just an external chip.

[Anonymous No.10704468]

>>10702729
>putting more memory in a system
My idea is to add less memory though. Except for a small one for the second CPU.
>So now the CPUs are on separate buses and unable to directly communicate with each other?
By having a bus arbitrer between them. The 128K secondary cache would not be accessible during communication between the two CPUs, but when the communication is halted the slave CPU is able to freely use the 128K bank. So the master CPU would send instructions and the slave CPU could work on it's own until it's completed its task, and now the slave CPU only needs to fetch its output data to the master CPU and main RAM. There's also the NUMA architecture that involves cache snooping, shared cache, DMA connection between memory banks, and stuff but that would be a whole lot more complex.
>Then how would this help with performance?
Letting the CPU process higher quantities of data without interruption always helps with performance, and ease of development too.
>Half Transparency can take 6x longer for both, and Gouraud Shading has an overhead of ~100-200 cycles during the initial set up of reading the shading table, doing the math, etc
We don't need those. 3DO had neither of those and the 3D graphics were looking fine.
>pretty spiffy stuff
Who cares about water and road bumps? Not worth the additional cost.
>PS1 wasn't any better
Of course it was fucking better, it could run 3D games faster with fewer chips and 25% less memory. More cost efficient and easier to program for. The Saturn should've been cheaper than the PS1 right from the get go because it couldn't compete directly at all.

[Anonymous No.10704478]

>>10704468
>We don't need those.

The Saturn having no 3d transparencies was a point of ridicule as early as 1996 so you absolutely do need that.

[Anonymous No.10704485]

>>10704478
Who ridiculed it? 90s digital foundries? Fat neckbeards over the internet? The gameboy was a massive success despite not even displaying colors and having backlit screen. The soitch is a massive success despite rendering a PS4 ports at 144p 12 fps average.

As long as it's cheap and could properly run 3D games even with poor graphics, it'd sell.

[Anonymous No.10704514]

>>10704485
>Who ridiculed it? 90s digital foundries? Fat neckbeards over the internet?

It was mentioned in gaming magazines, gaming websites, and gaming related online boards. Letters in the Sega Saturn Magazine definitely mentioned it, online articles were written about it, it was mentioned in FAQs that circulated the web, it was discussed online from usenet to GameFAQs Message boards, and so on. If any of the above involved retarded console warriors like you who were not on the Sega side, it was mentioned in a highly derogatory manner. Of course this all happened before you were born, so I can't fault you for not remembering it.

>The gameboy was a massive success despite not even displaying colors and having backlit screen.

gameboy had the greatest videogame ever created as a pack-in title, and better battery time than all of its rivals combined.

>As long as it's cheap and could properly run 3D games even with poor graphics, it'd sell.
Unless you have a cheaper console that can do better 3D and more games, ie. the Playstation.

[Anonymous No.10704523]

>>10704514
>It was mentioned in gaming magazines, gaming websites, and gaming related online boards. Letters in the Sega Saturn Magazine definitely mentioned it, online articles were written about it, it was mentioned in FAQs that circulated the web, it was discussed online from usenet to GameFAQs Message boards, and so on
So neckbeards, got it.
>greatest videogame ever
Tetris is ass. You could play it on brick game anyway which was a shit ton cheaper, had better battery life, and didn't suffer from visibility issues like gameboy's screen.
>Unless you have a cheaper console that can do better 3D and more games
That's why the saturn needed to be cheaper to produce.

[Anonymous No.10704550]

>>10689689
Hardware was fine, it just needed Sonic 3 at launch (as in not splitting Sonic 3 into 2 games and moving the game to the Saturn), a proper Sonic game every year, double the SDRam, no DRam, Game Gear link up (think GBA to GameCube link up), much higher memory cartridge support and have triangle support rather then quads, thats it.

TL;DR: Just move Sonic 3 to Saturn and not release Sonic 3 on the Genesis.

[Anonymous No.10704559]

>>10704550
Nah, Sonic CD2
With background and foreground tracks

[Anonymous No.10704562]

>>10704559
That comes later.

[Anonymous No.10704574]

>>10704550
They couldn't delay Sonic 3 because they had a deal with McDonalds.

[Anonymous No.10704582]

>>10704523
>So neckbeards, got it.
yeah, basically the entire industry.

[Anonymous No.10704627]

>>10704574
Thats why they needed to reject it.
Saturn needed Sonic 3 at it's launch more.

[Anonymous No.10704631]

>>10704627
Bug! was kind of supposed to be that until Naka stepped in.

[Anonymous No.10704637]

>>10704631
That also started production on the 32X as well.
The 32X should've never happen.

[Anonymous No.10704642]

>>10704197
>lots of streamed tracks ended up mono
The compression wouldn't really hurt streaming data, more sequenced data where you don't have as much space for instruments. If the streamed data is mono it's probably due to disc space and the dev didn't want to use the Software ADPCM libraries.

>but its support of 32 channel FM synthesis is absolutely crazy. Did it ever get used in any game?
It's more advanced than that. It's 32 PCM Channels, each of those channels however can be modulated like an FM Synth channel and chained together where each channel effective acts as an FM Channel operator. So if you link 4 channels together, you end up with the equivalent of a 4OP FM Synth channel. However it can't produce it's own wave forms, instead you provide the base wave form as a PCM Sample of a sine wave.

Lots of games actually did use it such as Sakura Wars, Magic Knight Rayearth, NiGHTS into Dreams, Stellar Assault SS, Clockwork Knight, etc.

>>10704228
>uh-huh.
My bad I made a typo. It's 1 cycle for untextured, 2 cycles for textured. You can see I said this correctly later on.

[Anonymous No.10704645]

>>10704637
>The 32X should've never happen
This. 32X had some decent titles, but all of them would've been a better game on the Saturn.

[Anonymous No.10704646]

>>10704236
>now that one i'm gonna call bullshit on without some evidence.
See >>10704453
>You're forgetting the reason why SOA didnt want the Saturn was the MSRP SOJ was setting at launch.
I'm not forgetting it I'm saying it wasn't really an issue because by the time it would have launched they could have price matched Sony without breaking the bank.

[Anonymous No.10704672]

>>10704464
>There you get it. And yes it'd be faster
No I don't. How would getting rid of Streaming now make it the master's job to run the CD-ROM drive from your previous statements? And no it wouldn't be any faster with a static load screen. The drive is still set at a fixed data rate of 300KB/s. All you've done is made it so now one of the CPUs has to race the drive to get data off and if it falls behind it's going to miss data.

Secondly by getting rid of streaming you've pretty much made stuff like FMV and streamed PCM audio tracks off the disc next to impossible.
>Like what?
Sega CD, PC-Engine CD, PC CD-ROM drives, take your pick.
>And with my solution it would need less RAM and fewer chips.
Your solution is completely gimping the hardware.
>Gotta need a source on that, especially for the PS1.
The Hideki Sato interview states they sold the Saturn at a 10,000 yen loss in Japan when it launched. It launched at 44,800 Yen:
https://mdshock.com/2020/06/16/hideki-sato-discussing-the-sega-saturn/
A Japanese interview with Sony engineers revealed that PS1 cost 50,000 Yen to manufacture at launch:
https://169.45.167.69/forum/showthread.php?35945-Japan-execs-were-upset-that-Kalinske-was-allowed-to-resign-w-o-taking-blame-for-32X&p=886374#post886374
>Because data wouldn't need to be transported from the CD cache to the main RAM through the SCU
It would still need to go through the SCU. The CD-ROM Drive is not on the same bus as the CPUs.
>PCM doesn't have the ability to generate its own custom waveforms, it only plays samples
The PCM sample doesn't generate anything, it's a data source. The wave table is a table of wave data sources (PCM samples). The Chip performs modulations on those samples. You don't know what you're talking about.
>PS1, it depends on how well Jaguar's blitter and object processor are used.
No, even PS1 beats the Jaguar in 2D. PS1 is a pure fillrate beast.

[Anonymous No.10704682]

>>10704464
>I was comparing it to the Jaguar which didn't even have a dedicated VRAM.
And I was pointing out 32X's bus contention problem is even worse than Saturn's due it having the exact same dual SH-2 CPUs but on a 16-bit bus. VRAM has nothign to do with it.
>Wow how useful.
Yes it's very useful. You can use the rotating planes for, other layers for text, HUDs, background layers, etc. It also is what allows games like Sonic R to have smooth fade-in as it can do proper additive blending.
>It has two RISC chips
The Saturn also has two RISC chips, the exact same ones as the 32X. Does that make it like the Jaguar too?
>but it was definitely made to compete against the Jaguar
It was made to be a low budget 32-bit system for the west. It was intended to hold the line against the upcoming new systems including the 3DO, PS1, and Jaguar until the Saturn became cheaper around 1996. The idea failed miserably.
>You could've replace it with any other RISC DSP if it was buggy, you know. It's just an external chip.
Sure, but they instead went the add-on route because that's what Sega of America wanted to keep the Genesis going.
>>10704468
>My idea is to add less memory though. Except for a small one for the second CPU.
128KB is not a small amount, especially in 1994 and especially for CPU cache.
>Bus arbiter nonsense.
This is going to be even more of an issue. The SCU effectively is what you're talking about. But now the CPUs are on separate buses and have to go through the SCU to talk to each other. This would be extremely slow and idiotic. Not only that, this isn't how the SH-2s are intended to be wired up to work in a master slave configuration. The chips have direct lines they connect to each other with to communicate with each other. What you're proposing would most likely be even slower and more expensive when you factor in having to design the board around it.

[Anonymous No.10704697]

>>10704468
>Letting the CPU process higher quantities of data without interruption always helps with performance
Except the problem is you're proposing external DRAM for that cache. That's going to be painfully slow. We can see just how slow when we do tests with LWRAM on the Saturn. LWRAM is 1MB of DRAM while HWRAM is 1MB of SDRAM. Running any kind of code from LWRAM is painfully slow and not worthwhile.
>3DO had neither of those and the 3D graphics were looking fine
3DO had half-transparency. 3DO games may look ok without gouraud shading but it's because none of it's games have lighting. By 1996 a system not able to do lighting would be a joke.
>Who cares about water and road bumps?
You clearly weren't paying attention to the videos. The Grandia ones are showing how you can set up windows to have 1 plane use 2 different coefficient tables to create varying height levels in the ground layer, thus taking that work off VDP1's plate. It's why Grandia tends to run better on Saturn in maps that heavily use VDP2.
>Of course it was fucking better
>goes on rant about things completely unrelated.
Hey dumbass I was talking about manufacturing cost. Which in that case PS1 wasn't any better. It cost about the same to produce as the Saturn.
>it could run 3D games faster with fewer chips and 25% less memory
And what you're proposing would cripple the Saturn heavily here because the main chokepoint of the system, VDP1, you're not addressing. If anything your system will perform significantly worse because you're getting rid of RAM, VDP2, and gimping the SH2s horribly. So no VDP1 is going to have to pick up the slack which it obviously can't do.

[Anonymous No.10704705]

>>10704550
>have triangle support rather then quads
Honestly just having texture coordinate support would have fixed this issue. Quads weren't nearly as big of an issue as not having texture coordinates. If you have texture coordinates, you could draw a triangle with quads and have it actually look correct.

[Anonymous No.10704710]

[Anonymous No.10704720]

>>10704705
These aspects are all interrelated.
Quads are the natural primitives to use with forward texture mapping. Forward mapping precludes texture coords and results in overdraw.

When people say Saturn should use tris what they're really saying is it should use inverse mapping like PSX. Or they're just cargo culting things they don't really understand (more likely)

[Anonymous No.10704732]

>>10704720
Sure, I'm just saying adding the ability to do texture coordinates may have been a quick fix without re-engineering the entire chip. It's actually pretty close to already having them. There's a hack you can do with Gouraud Shading where you load a texture into CRAM and then the RGB values you assign for gouraud shading act as your coordinates. So if that was expanded into it's own kind of command and the ability to read that data from VRAM was there, you could do texture coordinates.

Not only is there that capability with coordinates almost there, you also have additive blending working just fine, but only for gouraud shading. If that could be expanded upon to also allow it to work for transparencies you'd again have something pretty nice.

[Anonymous No.10704780]

>>10704732
Having to use CRAM palettes is an awkward hack. I'm not sure whether using VRAM for palettes would have been viable. The palettes would need to reside in a cache in order to get good random access latency. And cache utilization would suck because your "palettes" with this hack are just uncompressed RGB textures.
At this point you're kind of reinventing the Playstation's texture cache, which was an important point of its design from the start.

[Anonymous No.10704818]

>>10704780
The other bit that makes it odd is I believe CRAM is in VDP2. So it seems odd that reading that from VDP2 is faster than reading it's own VRAM but it wouldn't surprise me if that was the case.

[Anonymous No.10704865]

>>10704818
SDRAM has to be refreshed periodically and if you try reading it while this refresh is in progress, you get a stalled cycle. CRAM is on-die SRAM and doesn't have such issues. It makes perfect sense that it is faster.

[Anonymous No.10704886]

>>10704865
DRAMs also have latency penalties when you're accessing nonsequentially (especially between rows). That's bad if you want to read out texels in screenspace order.

[Anonymous No.10704891]

>>10704865
>>10704886
That I get, what I was getting at is that CRAM is inside VDP2 and VDP1 has to access it through VDP2. I'd imagine that interaction would add some latency.

[Anonymous No.10704901]

>>10704672
>How would getting rid of Streaming now make it the master's job to run the CD-ROM drive from your previous statements?
There's a difference between theoretical and practical speeds of a CD drive. The size and speed of cache and data buffer are one of the factors that affect the practical seek and transfer speed of CD-ROM. Faster CPU with bigger buffer would certainly improve the CD speed.
>Sega CD, PC-Engine CD
These and Neo Geo CD had tiny data buffer and a slow CPU.
>FMV and streamed PCM audio tracks
Shit only zoomers care about. Gravis ultrasound already sounds great without audio streaming. Ocean games on the SNES sound great even though they only had less than 64KB of sound samples to work with and no wavetable synthesis. Cutscenes are still on the table so there's nothing to worry about.
>Your solution is completely gimping the hardware.
It's making the production cost a lot more sensible. Completely? Nah it'd be running full 3D games just fine.
>10,000 yen loss
That's a shit ton of money. The saturn cost 4800 yen more (a whopping 45 buckaroos) to manufacture than the PS1 and yet performs worse. This is somehow considered fine by sega lard x.
>It would still need to go through the SCU.
Yep, but now you won't need to transfer the data from 1 DRAM to another.
>The Chip performs modulations on those samples
Learn the difference between software mixed sounds and wavetable synthesis first before talking back to me.
>PS1 is a pure fillrate beast
Fillrate only matters when the entire screen is continuously updated, which isn't always the case with 2D games. In that case, object processor should be more efficient for the job.

[Anonymous No.10704904]

>>10704682
>text, HUDs, background layers
Wow, scoreboard, skybox, so powerful and exciting....
>smooth fade-in
As opposed to pop-in? That's it? Wow my life would be ruined without it.
>Does that make it like the Jaguar too?
No because it has a proper 3D geometry and texture mapping hardware.
>The idea failed miserably.
Because it's not even low cost.
>add-on route
The former could also have been an add-on route a la game genie carts.
>because that's what Sega of America wanted
Because they were scared shitless of Chad Tramiel.
>128KB is not a small amount
It peaked at $4.75 in 1994 according to that memory price history chart. If that's still too much 64K is fine then. They had a bulk of 64K DRAM chips from unsold megadrives. Anything is better than 4K anyway.
>The SCU effectively is what you're talking about.
Nah, this bus controller would be between the main CPUs only. Not like a system couldn't have more than one bus controller.
>external DRAM for that cache. That's going to be painfully slow.
Except now the CPUs could choose between parallel and serial mode by placing a bus controller in between the bridge. Serial mode could work pretty much the same as the normal saturn while in parallel the slave CPU has access to the external cache instead of the master CPU.

[Anonymous No.10704907]

>>10704904
cont
>3DO had half-transparency
I barely noticed it. Tells you how important this feature is.
By 1996 a system not able to do lighting would be a joke.
Nah, only neckbeards care about that, just like raytracing these days. We're supposed to play games, not look at it.
>Grandia
That's such an ultra specific and obscure use case for a turn based jarpig that didn't even come out of Japan. The 90s were all about Quake, Duke, and Tomb Raider, games where that background plane trick isn't useful at all.
>It cost about the same to produce as the Saturn.
Nah it cost $45 more, which would translate to $45 million per one million units sold. For a system that performs worse.
>your system will perform significantly worse
Nope, the SH2's parallel processing capability would now be improved and the games would have worse graphics, but better framerate.

Verification not required.

[Anonymous No.10704925]

>>10704901
>There's a difference between theoretical and practical speeds of a CD drive
I can at test the 300KB/s is pretty spot on as far as it goes for FMV playback.
>Faster CPU with bigger buffer would certainly improve the CD speed.
You're talking about removing the cache and having the CPU do everything. That wont improve speed at all, instead it will create a race condition where the CPU will miss data if it falls behind.
> Gravis ultrasound already sounds great without audio streaming.
So does the SCSP, that said having the ability to have stuff like ADX audio streams, voice acting, etc. is quite nice.
>SNES sound great even though they only had less than 64KB of sound samples to work with
SNES games sound like muffled dogshit compared to most chiptunes on Saturn and PS1.
>no wavetable synthesis.
The SNES can do modulation synthesis similar to what the SCSP does, but on a much more limited basis.
>Cutscenes are still on the table so there's nothing to worry about.
How when you can't stream them? Unless you mean static screens and sprite animation like the PC-Engine then that would be comically bad compared to the PS1. At that point why not just stick with the Sega CD?
> Nah it'd be running full 3D games just fine.
No, it really wont. You're gimping the system's memory and throwing all the work on VDP1. It's going to choke and struggle to run anything decently.
>That's a shit ton of money.
PS1 was sold at an even bigger loss of 10,200 Yen.
>The saturn cost 4800 yen more (a whopping 45 buckaroos) to manufacture than the PS1 and yet performs worse.
Mostly because of VDP1 it performs worse, but even then it's enough to be competitive. The issue was Sega shot themselves in the foot with the 32X outside of the Japan.
>Yep, but now you won't need to transfer the data from 1 DRAM to another.
Yeah, just now you're racing the CD-ROM drive and risking missing data if you fall behind. Great plan. You realize there's a reason buffers exist.

[Anonymous No.10704942]

>>10704901
>Learn the difference between software mixed sounds and wavetable synthesis first before talking back to me.
Learn what the hardware you're talking about actually does before talking back to me.
>Fillrate only matters when the entire screen is continuously updated, which isn't always the case with 2D games.
When all your background layers are now being down with sprites and are scrolling, the entire screen will be being updated. Add in additional background layers of parallax, transparencies, etc. and fillrate becomes an issue in any frame buffer based system, regardless of if it's 2D or 3D.
>>10704904
>Wow, scoreboard, skybox, so powerful and exciting....
Anything that takes work off VDP1's plate so it doesn't have to waste it's already limited fillrate on it is a win and a reason to keep VDP2 around.
>As opposed to pop-in? That's it?
It allows for various different color calculations and transparency effects to be used between layers. Again taking work off VDP1s plate. So yeah it's nice to have around.
>No because it has a proper 3D geometry and texture mapping hardware.
It doesn't really have proper 3D geometry and texture mapping hardware though. It has the ability to draw distorted sprites. All the 3D geometry calculations are being done on the SH2s.
>Because it's not even low cost.
$150 is pretty low cost. It's lower cost than the Jaguar by $100.
>The former could also have been an add-on route a la game genie carts.
And would have been horrible because the SVP chip was a buggy mess and the only way to expand color depth on the Genesis is how the 32X did it.
>Because they were scared shitless of Chad Tramiel.
We've been over this. You're taking an out of context quote and blowing it up with hyperbole. We have the full story now, your take is factually wrong.

[Anonymous No.10704954]

>>10704904
>It peaked at $4.75 in 1994 according to that memory price history chart.
That's for PC memory and it's dealing with higher capacity chips. Did it ever dawn on you that requesting smaller capacity ones may have actually cost more if the company has to produce them specifically for you? And again we're talking about memory for CPU cache, cheap DRAM wont cut it there, you need something faster. That will be more expensive.
>Nah, this bus controller would be between the main CPUs only.
So again why would this be better than having the SCU do it? You're talking about reducing chips in the system but here you are adding another one.
>Nonsense about Serial/parallel mode in response to DRAM.
Again how does this address the issue that DRAM is painfully slow for this purpose. Even if you have the Slave CPU off on the Saturn and run exclusively from LWRAM thus eliminating all bus contention, it's slow as fuck because it's DRAM.
>>10704907
>I barely noticed it.
Doesn't change the fact it had it.
>Tells you how important this feature is.
It was a pretty big deal when the PS1 came around and was doing tons of transparency effects.
>Nah, only neckbeards care about that,
Tell that to people who still complain about certain lazy Saturn ports not having lighting compared to their PS1 versions.
>That's such an ultra specific and obscure use case
What about Sonic Jam? Sonic R? Those use it for base floor layers and show how it could work for a 3D platformer. What about games like Panzer Dragoon that use it for the base ground layer or water layer?
>Quake and Duke
Could also use it for a base floor layer on large maps.
>Nah it cost $45 more
That's not really much in the grand scheme of things. And again the main cause of that was RAM, and that issue disappeared by early 1996 when RAM prices crashed.
>SH2's parallel processing capability would now be improved
Not when they're stuck doing all their work in slow DRAM.
> better framerate.
Not when VDP1 is doing everything.

[Anonymous No.10704961]

>>10704891
VDP1 is not aware of the CRAM at all and never has to access it. The VDP1 just writes words or bytes into the framebuffer that translate to "use RGB value x" or "use palette bank x entry y, priority a, color calculation b". VDP2 then reads the framebuffer in the next frame and processes the information accordingly.

[Anonymous No.10704963]

>>10704961
Again I know that, but here what I don't get is how it works for Gouraud shading. Doesn't VDP1 need to know what the value is so it can do the additive blending on it's frame buffer?

[Anonymous No.10705007]

>>10704963
https://antime.kapsi.fi/sega/files/ST-013-R3-061694.pdf
>When RGB codes are used, color calculation of half-lumiance, half-transparency, Gouraud shading and shadowing are possible
>In the RGB mode, color calculation of half-lumiance, half-transparency, Gouraud shading and shadowing is possible
Sounds like VDP1 can't do any sort of blending if palettes are used.

[Anonymous No.10705090]

>>10704963
So basically you don't know shit and you are fishing for info. Read the docs.

>>10705007
Nope, wrong.

[Anonymous No.10705148]

>>10705007
Basically VDP1 doesn't know what colors VDP2 is drawing if you use CRAM for paletted colors. Gouraud Shading will still technically try to work, but the results are not guaranteed because it has no idea what colors it's drawing to it's frame buffer. It only knows the CRAM index values. So it will be blending with that value instead of the correct color value.

Paletted data using CLUTs is fine though as those are in VDP1 VRAM and it knows what those colors are.
>>10705090
>Read the docs.
I am, and I'm asking because this specific interaction doesn't appear to be clear. If VDP1 is doing the gouraud shading, yet the color values it uses to do the math for the shading come from CRAM, how does it know what what colors it's blending with it's frame buffer?

[Anonymous No.10705165]

>>10705148
>Paletted data using CLUTs is fine though as those are in VDP1 VRAM and it knows what those colors are.
Oh right, that makes more sense.

[Anonymous No.10705231]

>>10705148
After rereading XL2s post I think I get what's going on. It's setting a palette code for the color of the untextured polygon, gouraud shading will increment the palette code which will then reflect the correct color in CRAM for the texture. So it's not doing blending with values from CRAM, it's doing blending on palette codes which happens to correctly increment the value for texture coordinates.

So going back to the theoretical idea of adding texture coordinates to VDP1, it could probably be done by giving VDP1 it's own texture cache to load a texture into and using the same kind of approach.

[Anonymous No.10705513]

>>10704925
>300KB/s
That is theoretical speed. A CD drive won't maintain that speed when combined with the rest of the system. We're talking about CD seek and transfer during game loading, a much less linear process than video playback.
>removing the cache
Nah, now the cache will be the main RAM itself instead of the separate 512KB DRAM.
>having the CPU do everything
A much faster CPU than SH-1.
>miss data if it falls behind
Hence pause the game and let the VDP display a static screen while it happens.
>So does the SCSP
The point is finding a cheaper alternative. Afaik the OTIS is more memory efficient, maybe because it only plays 19.5 khz samples instead of 44 khz with all its 32 channel in use. This banger only takes 78KB of memory, which is even less than most Amiga tracks I know.
https://www.youtube.com/watch?v=PT8WzAczA1k
>At that point why not just stick with the Sega CD?
You play games to watch cutscenes?
>You're gimping the system's memory and throwing all the work on VDP1. It's going to choke and struggle to run anything decently.
You haven't explained how it'd choke on only VDP1 when all VDP2 does is render a couple of flat 3D plane floors with bump effects.
>PS1 was sold at an even bigger loss of 10,200 Yen.
So like 200 yen more? $2? Even though it was like 6000 yen cheaper at the retails?
>Mostly because of VDP1 it performs worse
Well the VDP1 is practically its only 3D processor. The other one is a useless snes mode 7 esque gimmick. If we removed that, saturn would be much cheaper to build. Also with strictly 256 color mode the texture data would be smaller and they'd be faster to render. Hence we're only reducing the framebuffer memory quantity here.
>You realize there's a reason buffers exist.
There's no difference between using the main RAM and external RAM (with SH1) as the buffer. Also it seems that the latter was 512K big simply to cope with Saturn's bus contention issue.

[Anonymous No.10705516]

>>10704942
>Learn what the hardware you're talking about actually does
Does yours do PWM with samples? Couldn't find it in the SCSP User Manual. It seems to only do both FM synth and PCM playback.
>When all your background layers are now being down with sprites and are scrolling, the entire screen will be being updated
That's wrong. Scrolling and moving sprites could be done by shifting specific bits in the display list rather than swapping all of them. That's what Jaguar's object processor does. I don't think I've seen a PS1 2D game as busy as this running at 60 fps with no drops.
https://www.youtube.com/watch?v=-dCRmGmTmbk
Not that I'm denying that it could, but I when it comes to 2D performance they're doing it differently. 2D games on the PS1 would be more CPU intensive while on the Jaguar you could offload many of the tasks to the object processor, except for rotation which I couldn't find the function for afaik. PS1 could probably do rotation better, thanks to the texture mapping hardware.
>Anything that takes work off VDP1's plate so it doesn't have to waste it's already limited fillrate
The fillrate is only debilitating when you're doing shadows and shit. Otherwise it's doing 24 million/sec, which is speedy.
>$150 is pretty low cost. It's lower cost than the Jaguar by $100.
No it was $160. The jaguar was $250 only at launch with a pack in game. It got gradual discounts, could find one for $200 by the time 32X was released. Then in may of 1995 it was discounted from $189 to $149. And considering that the genesis was still like $120 or more, the 32X wasn't cheaper.
>And would have been horrible because the SVP chip was a buggy mess
Use any other RISC chip.
>the only way to expand color depth on the Genesis is how the 32X did it
Who fucking cares about color depth? It should've been about 3D rendering for the lowest price possible.
>We have the full story now, your take is factually wrong.
And yet the "full story" didn't contradict his statement.

[Anonymous No.10705520]

>>10704954
>That's for PC memory and it's dealing with higher capacity chips.
Higher capacity chips are made of an array of smaller capacity chips. Smaller chips would cost higher due to the cost of packaging, but since they're sold at a lower profit margin than retail prices since you're buying them in a bulk, effectively I don't think there should be much of a difference between buying PC RAMs at computer stores (which is where the list prices on that table came from) and tiny RAMs in a bulk from the factory.
>So again why would this be better than having the SCU do it?
SCU controls the buses between systems, this one only between two CPUs. It's better because it'd still let the two CPUs communicate as normal master-slave in serial mode.
>You're talking about reducing chips in the system but here you are adding another one.
Yeah a cheap ass bus controller.
>it's slow as fuck because it's DRAM
It's not like you'd have to take away the internal SRAM cache in the CPU. DRAM would be around 6 times slower to access but you'd not need to use it all the time. It's just an extension to the internal cache. Making use of the capacity advantage but speed disadvantage is a matter of programming priorities.
>PS1 came around and was doing tons of transparency effects
On what? Water, gems, and what else? Quake did fine without transparent waters.
>Tell that to people
>people
Gwafix trannies aren't people.
>base floor layers
VDP1 could do floors.
>What about games like Panzer Dragoon that use it for the base ground layer or water layer?
Panzer dragon is just starfox with watery floor. Doesn't hurt the gameplay without it.
>Could also use it for a base floor layer
It's only a couple of planes. It's got little use for true 3D games like these.
>$45
>That's not really much in the grand scheme of things.
200 yen is relevant yet $45 isn't???

[Anonymous No.10705529]

>>10704954
>by early 1996
Shartturd was on its last legs.
>Not when they're stuck doing all their work in slow DRAM.
With that DRAM you could store and simply fetch previously calculated geometry data instead of computing them all over again.
>Not when VDP1 is doing everything.
VDP2 does practically nothing to improve the essential 3D graphics as I've explained.

[Anonymous No.10705724]

>>10705513
> A CD drive won't maintain that speed when combined with the rest of the system. We're talking about CD seek and transfer during game loading, a much less linear process than video playback.
I'm aware of that, the point I'm making dumbass is that you're method can't go any faster than that speed. And what's already there is already able to get pretty close to that speed since you can push FMV right up to that data rate limit.

In other words your method will not be any faster, but will instead introduce errors and race conditions.
>Nah, now the cache will be the main RAM
Which is removing the CD-ROM drive's cache.
>A much faster CPU than SH-1.
Irrelevant as now it has to race the drive for data. If anything is slightly off it's going to miss data reads.
>Hence pause the game and let the VDP display a static screen while it happens.
The race condition is still there even if you do this. Anyone who's done anything like this knows this is an issue and is why you have buffering.
> Afaik the OTIS is more memory efficient, maybe because it only plays 19.5 khz samples instead of 44 khz with all its 32 channel in use.
The SCSP allows you to set any sample rate you want as long as it doesn't exceed 44100Hz. I don't think I've seen any Saturn game using 44100Hz samples for sequenced music. So that defense goes out the window.
>You play games to watch cutscenes?
The point I'm making is that your suggestions are so ass backwards and crippling that you're not really providing any decent leap over the Sega CD at this point.

[Anonymous No.10705749]

>>10705513
>You haven't explained how it'd choke on only VDP1 when all VDP2 does is render a couple of flat 3D plane floors with bump effects.
Because VDP1 now has to draw everything instead of being able to hand it off to VDP2. When it only has to draw the 3D polygons of the scene and can throw the sky background, floor, HUD, etc. off to VDP2 that's a significant amount of pixels it doesn't have to draw.

The best fill rate you can get with VDP1 for textured draws is about 12 Million Pixels per second. That may sound like a lot but it's not. And for textured draws that includes just normal 2D sprites. That's enough to draw the entire screen maybe 2.5 times at 60fps. So if you have to draw an entire background layer to fill the buffer, you've already used half your fill rate. Now you need to draw a HUD, another partial layer, then sprites, you're going to hit your fillrate limit, which will cause the game to slow down.

>So like 200 yen more? $2? Even though it was like 6000 yen cheaper at the retails?
Both were sold at a 10,000 loss. Saturn was about 4,800 Yen more expensive at the start, but that quickly evaporated as RAM prices fell and Sega consolidated the hardware. Compare a VA0 Saturn to a VA1 and you'll see the board was significantly consolidated down.
>Well the VDP1 is practically its only 3D processor.
VDP1 is NOT a 3D processor. It simply is able to draw normal sprites, scaled sprites, and distorted sprites. It has no concept of 3D. Everything it does is on 2D coordinates. All the 3D math and processing is done on the CPUs.
>the texture data would be smaller and they'd be faster to render.
I've already explained to you that color depth has no impact on VDP1's fillrate. It can be 4 bit color, 8 bit color, or 16-bit color, but it still takes 2 cycles to render a textured pixel.
>There's no difference between using the main RAM and external RAM (with SH1) as the buffer.
There is when the main CPU now has to drive the CD-ROM drive itself.

[Anonymous No.10705794]

>>10705516
>Does yours do PWM with samples?
Do you know what PWM is? It's just another form of digital audio sampling. It still takes up space and it still requires pre-recorded samples. It's just another format for storing the samples. It's what the 32X uses.
>That's wrong.
It's not if you understand how these systems actually work.
> don't think I've seen a PS1 2D game as busy as this running at 60 fps with no drops.
DoDonPachi says hi:
https://www.youtube.com/watch?v=vqLOaQJd6pI
>2D games on the PS1 would be more CPU intensive
How do you come to this conclusion? The PS1 GPU has fast 2D draw commands. It can draw sprites and everything.
>The fillrate is only debilitating when you're doing shadows and shit
No.
>Otherwise it's doing 24 million/sec
That's only if you're doing all untextured draw commands, and even that's not as fast as you think. It's enough to draw the screen maybe 5 times at 60fps. Which again if you're drawing everything including all the background layers on top of each other, you're going to hit that limit.
>No it was $160.
Who gives a shit?
>The jaguar was $250 only at launch with a pack in game
32X was $160 and came with Doom or Star Wars Arcade.
>could find one for $200 by the time 32X was released.
You could find a 32X for $50 less than a year after it released.
>Use any other RISC chip.
Like the SH2s? Oh wait they did that with the 32X.
>Who fucking cares about color depth?
Less than 64 colors is a very harsh limit, especially for 1994 and especially if you're trying to do 3D with it.
>It should've been about 3D rendering for the lowest price possible.
That was 32X.
>And yet the "full story" didn't contradict his statement.
No but it gives context that it wasn't just because they were afraid of the Jaguar. The root cause comes from Sega of America not wanting to move onto the Saturn and stick with the Genesis, so Sega of Japan went "Ok then how are you going to compete with Jaguar, 3DO and PS1?"

[Anonymous No.10705836]

>>10705520
>SCU controls the buses between systems, this one only between two CPUs. It's better because it'd still let the two CPUs communicate as normal master-slave in serial mode.
Again, weren't you trying to reduce chips? Why add this when you could have the SCU do it? The SCU's job is to control the busses across the entire system and be the link to communicate with everything else in the system.
>Yeah a cheap ass bus controller.
Prove it.
>It's not like you'd have to take away the internal SRAM cache in the CPU. DRAM would be around 6 times slower to access but you'd not need to use it all the time.
So now it's just a the same SH2 with 4KB of cache but now crippled with only 128K of DRAM to work with? How would this be better? You may as well just set the system up as is with the Slave SH2 fixed to only work in LWRAM, and the Master fixed to only work in HWRAM, you'd get the same result (Hint: it would be worse than letting the CPUs fight over bus contention, devs have tested this).
>On what? Water, gems, and what else?
This:
https://www.youtube.com/watch?v=0LIEf8zNH98
https://www.youtube.com/watch?v=m_GRkLJyxKA
>VDP1 could do floors.
And kill it's fillrate in the process.
>Panzer dragon is just starfox with watery floor
It's not just the water that uses it.
>Doesn't hurt the gameplay without it.
The game running at a horrible frame rate would definitely hurt the gameplay.
>It's only a couple of planes
Which you can do raster effects, windows, different parameter settings, etc. on to make pretty complex scenes.
>It's got little use for true 3D games like these.
It got used far more than you think. Even if the planes weren't being used, VDP2 was still being used for the base background layers.
>200 yen is relevant yet $45 isn't???
I never said that, I simply pointed out that PS1 was technically sold at a higher loss than Saturn.The point I'm getting at with the production cost is that within the first year Saturn was already no longer being sold at a loss.

[Anonymous No.10705861]

>>10705529
>Shartturd was on its last legs.
Not really, especially in Japan.
>With that DRAM you could store and simply fetch previously calculated geometry data instead of computing them all over again.
And where is your program going to reside? It might not all fit in Cache. This isn't like the Jaguar where the CPUs are busted and can't run programs from RAM and you have to run everything from cache. The SH2s can load and run their main programs from RAM just fine and most games do this with the most performance critical stuff being in Cache. Cache can also be configured to be either instruction cache, scratch pad, or both. So again your CPU is going to have to interact with RAM at some point to either read data, write data, or even fetch program instructions. And having that RAM be DRAM is going to absolutely kill performance.
>VDP2 does practically nothing to improve the essential 3D graphics as I've explained.
Because you're being deliberately dismissive and ignoring the fact that VDP1s fillrate sucks.

Here's an example for you. This is Sega Touring Car Championship:
https://www.youtube.com/watch?v=yBfqXJBf4-Y

Notice how the Frame rate is dropping and chugging? Guess what, that's not due to a CPU bottleneck or the SH2s dealing with bus conteention. It's due to VDP1's fillrate limit being reached. To prove this here is the game running with all the draw commands being changed to Polylines (wireframes) which dramatically reduces how many pixels VDP1 has to draw, and now it runs at a solid 30fps:
https://www.youtube.com/watch?v=3eTsTVpxFFM

The only thing VDP1 is drawing is the polygons. And you can see the polygon data isn't even that complex. So why is it chugging? The textures on the road and walls are causing massive amounts of overdraw combined with large polygons reaching the frustrum again resulting in VDP1 drawing a ton of pixels over and over again. That's how bad VDP1s fillrate is.

[Anonymous No.10706062]

>Now here's how the Sega Saturn could have won thread # three fucking million
Wow great

[Anonymous No.10706064]

>>10706062
This thread is more an Atari Jaguar Fanboy trying to tell us if they designed the Saturn more like the horribly broken and buggy Jaguar it would have won.

[Anonymous No.10706072]

>>10706064
Potatoes, potatos.

[Anonymous No.10706753]

>>10705231
VDP1 doesn't know what a color is, it doesn't know what blending is, it just copies bytes or words from VRAM into framebuffer. If you use Gouraud shading, it doesn't know what color it is blending, it just increments/decrements 5-bit parts of the word that is about to be written to framebuffer. The manual has a table on how the 5-bit values change for each component.
If you use a paletted pixel format where the palette entry falls right into one of those 5-bit parts, gouraud shading can ramp up or down the palette entry.

XL2s demo puts a texture in CRAM and uses gouraud shading to increment/decrement the palette entries to "move" the texture around. Wipeout XL and Zero Divide use the same effect to create metallic shining on a few objects.

>>10705231
>So going back to the theoretical idea of adding texture coordinates to VDP1, it could probably be done by giving VDP1 it's own texture cache to load a texture into and using the same kind of approach.

Then you would need to preload each texture into cache before drawing it, making it take 3 cycles to draw a texture at best, making the VDP1 lose 33% of its already low performance.

[Anonymous No.10706827]

>>10706753
>VDP1 doesn't know what a color is
It does when it's using 15-bit RGB color or CLUTs. That's why Gouraud Shading and Half Transparency actually work correctly in those modes. VDP1 has drawn actual color values to it's frame buffer and can apply the proper blending to them.

It's only when it's using palettes in CRAM that it doesn't know what colors it's drawing. XL2's method effectively abuses the "Results not guaranteed" aspect of doing gouraud shading when your color data is stored in CRAM.

>Then you would need to preload each texture into cache before drawing it, making it take 3 cycles to draw a texture at best, making the VDP1 lose 33% of its already low performance.
The loading would only be at the start of a draw command when it first loads the texture. After it's loaded in cache it would probably still be 2 cycles per pixel, possibly faster since it doesn't have to keep fetching texture data from VRAM. If you have multiple draws using the same texture you could avoid loading it in cache over and over again.

[Anonymous No.10707124]

>>10705724
>the point I'm making dumbass is that you're method can't go any faster than that speed
The point I'm making is it's *always* slower than that, but some methods are faster than others.
>Which is removing the CD-ROM drive's cache.
The CD data buffer is just a 512K DRAM chip managed by an SH1, it's not the CD drive itself. There's a smaller 64K SRAM cache sitting next to the driver controller inside the CD drive, which is the main reason its load time is faster than the PS1's drive (32KB cache). It'd literally be no different if the system replaced the SH1 and its 512K buffer with the main RAM and main CPU.
>Irrelevant as now it has to race the drive for data.
No? It's just the same. The driver microcontroller and its own CPU does that job rather than the SH1.
>The SCSP
A more expensive chip. Also isn't it derived from the OPL3 chip? It would be closer to a more modern SoundBlaster 16 than Gravis Ultrasound.
>Sega CD
It's slow because it's a 1X CD drive fitted with a 16KB cache.

[Anonymous No.10707125]

>>10705749
>sky background, floor, HUD, etc.
HUD and sky background? It's a petty as fuck stuff that even the NES tile layer could draw with less than 8KB of RAM. Floor? SNES mode 7 could do it at a very tiny fraction of the computational power and memory usage of the VDP2. Hell, the toy story programmer for the genesis did it without any special background tile chip. My idea for the saturn is it doesn't need to have the best graphics, it only needs to cost less to produce than the PS1. The necessary functions of the VDP2 could be handled by a much simpler chip with much less memory.
>quickly evaporated
Yeah took only 2 fucking years for the prices to go down to the "sensible" levels. Good job team.
>VDP1 is NOT a 3D processor
3D texturing processor, alright. The other VDP only has 3 planes.
>I've already explained to you that color depth has no impact on VDP1's fillrate.
Going from 16bpp to 8bpp does increase the framebuffer fillrate by 7 mpixel/s. The wiki says so unless you could prove the otherwise. Now where texture mapping, due to the forward texture rendering method. The issue is you have to draw the whole texture tile regardless the clipping of the polygon. And there seems to be a hard cap of 16bpp on the textures. The software programmer can't go higher or lower than that. I wonder if the hardware engineer could customize the firmware microcode so it renders 8bpp textures instead for a higher speed. I think that should be possible.
>There is when the main CPU now has to drive the CD-ROM drive itself.
Yeah now its faster.

[Anonymous No.10707130]

>>10705794
>It still takes up space and it still requires pre-recorded samples.
Of course it does. Unlike FM Synth it needs samples. However it could create richer sounds with shorter samples.
>It's not if you understand how these systems actually work.
Jaguar's object processor actually modifies the display per scanline based on the object list. It also has a few tile layers, I think 3. So no, it works more like a dedicated 2D system. Meanwhile the PS1 renders 2D sprites similarly to how it renders 3D graphics, with primitives and textures. The latter uses framebuffer, while the later uses linebuffer.
>Who gives a shit?
You gave a shit about 200 yen.
>You could find a 32X for $50 less than a year after it released.
No, that was in 1996. By that time atari was liquidated and jaguars were sold for 30 bucks.
>Like the SH2s? Oh wait they did that with the 32X.
They made it into an expensive dual chip monstrosity that needed its own power brick. You don't need two braincells to realize how inconvenient that is.
>Less than 64 colors is a very harsh limit
Wouldn't be if the framerate wasn't so bad to top it off.
>That was 32X.
Nope. No texture hardware.
>so Sega of Japan went "Ok then how are you going to compete with Jaguar, 3DO and PS1?"
So I was right.

[Anonymous No.10707131]

>>10705836
>Why add this when you could have the SCU do it?
Because it would've been a fucking nightmare if the master CPU had to go through the single shared system bus to communicate with the slave CPU, smartie. You'd better off stick with the main RAM at that point.
>You may as well just set the system up as is with the Slave SH2 fixed to only work in LWRAM, and the Master fixed to only work in HWRAM, you'd get the same result (Hint: it would be worse than letting the CPUs fight over bus contention, devs have tested this).
Because LWRAM has a 16-bit bus. If we were to put a RAM that makes use of the same bus as the master-slave bridge, then it'd inevitably have to be 32-bit.
>This:
Transparency effects? I don't need shiny jiggling keys to enjoy video games.
>It's not just the water that uses it.
And what else? Other than floors and perhaps visual effects.
>The game running at a horrible frame rate
SNES could do textured floor without a vdp2 tier chip.
>pretty complex scenes
They couldn't even sell this thing without bleeding money. Sega should've had their priorities.
>background layers
ZX spectrum games have background layers too.
>I simply pointed out that PS1 was technically sold at a higher loss than Saturn
The production cost was still lower and yet the performance was better.

[Anonymous No.10707135]

>>10705861
>especially in Japan
Got blown out of the water by the PS1 even in japan.
>And where is your program going to reside?
Of course in the main RAM. The cache would be useful for Z buffering, output buffering, data tables, and shit. It would've been one big scratchpad the dev could choose to use or not to use.
>VDP1s fillrate sucks
And VDP2 doesn't help it. To offload the VDP1 from rendering floors and ceilings, why not use a cheaper chip like SNES' mode 7? Because it's too low res? Literally not a problem because the saturn would have to be a low cost system with 8-bit colors to compete with the PS1.
>Sega Touring Car Championship
Too many large textures which isn't good for sega's forward texturing system indeed. Sega Rally runs just fine. Also it's not something the VDP2 could fix, helping render the road aside. VDP2 couldn't do shit about those buildings and railings.

[Anonymous No.10707341]

This thread is like watching two autists fighting over a jigsaw puzzle.

[Anonymous No.10707668]

>>10689689
>128K DRAM cache on top of the existing 4kb cache
Too expensive. Cut it evenly with either a single 16K cache or dual 8k caches.
>remove VDP2
wtf Anon. Half of the Saturn's graphical effects and prowess comes from VDP2.
>256 maximum colors on screen [...]
Oh, it's bait. Dammit. :(

The Saturn could not be saved without a market miracle, and Sega had already burned goodwill with market players and with consumers with their bungled 32X endeavors + wasted resources on all things relating to it and their weird 4.5 gen console endeavor. But the Saturn could have been much smarter. Some more serious suggestions:

Audio and CD reading were multi-part sub-systems, each involving their own CPUs and modules. The CD and Audio sub-systems desperately needed trimming, and with some more careful thought this would absolutely have been doable.

For cost-sensitive performance hypotheticals, let's assume all major components have to remain the same. As is, the Saturn is kneecapped by several problems:

>Its dual CPUs are not truly parallel because, despite being identical Hitachi SH-2 units, instructions can only be sent one way. CPU1 can only send commands to CPU2, never vice versa. This would need to be re-worked so that CPUs could send commands in either direction without conflict or congestion.

>Both CPUs share a low-bandwidth bus and this leads to a lot of congestion, forcing developers to work around this in slower un-ideal ways like using the DSP for transfers. This bus needed to be twice its current size to avoid this issue.

>There's a third co-processor called the SCU. The Saturn has 2MB RAM; the SCU can only use the first 1MB, and can't access the other 1MB at all, and relies on the other two CPUs to fetch and manipulate it *for* it! The SCU should have had access to all RAM for better results.

[Anonymous No.10707672]

>>10689689 >>10707668
>The Saturn's VDP1 being unable to render native triangles makes many of quad's advantages moot. The extra vertice used in quads causes more expensive computations for models that need triangle shapes, and causes nasty texture distortion because, on the Saturn, a texture IS a polygon - they cannot be decoupled, which means you cannot wrap or map textures arbitrarily! This leads to ugly warping on quad-tris, which means quad-tris were best left flat-shaded and this limited what you could do with them. There desperately needed to be a way to support native tris, along with a way to texture them appropriately.

>VDP1 has to display its framebuffer through VDP2. I'm not sure if this was a bottleneck, but it sounds like it could have been, so ideally VDP1 would display its framebuffer through itself or through an output that combines with VDP2 at the end of rendering a frame.

[Anonymous No.10707714]

>>10689689
Have a proper launch with the same price as PS1.
Manage to make a full 3D Sonic in 1994-1996.
It's all they had to do for this thing to work.
I can't believe how bad they fucked it up.

[Anonymous No.10707720]

Fixing /vr/:
-Kill OP

[OP No.10707769]

>>10707668
>Too expensive. Cut it evenly with either a single 16K cache or dual 8k caches.
For DRAM cost wasn't the problem, it's latency. Looking at the PS2 though, I think it would be okay to replace it with a 16KB SRAM external cache. It would have a ton less latency and not be too small to store 3D primitives plus other routines. The idea behind the external cache is to give the CPUs some more room for parallel processing. The slave SH-2 could be used for AI and stuff, it's not just a geometry processor like PS1's GTE but also a general purpose CPU, and I think relegating it into a strictly 3D calculation CPU would be a kind of a waste.
>Half of the Saturn's graphical effects and prowess comes from VDP2.
Having a third framebuffer to do shading and floors is a huge joke and waste of money. Using quads and forward texturing were the inherent mistakes you couldn't fix without recreating the VDP chip entirely. I say just cut the gouraud shading feature entirely and have a tiny 32-bit DSP like the one found in the SNES apply low resolution affine transformation single or double layered tiles and another layer for adding a simple HUD and flat non-transformable transparent sprite-like visual effects in the VDP1's framebuffer.
>256 maximum colors
Quake looks great with 256 colors. No need to waste money and go beyond that.
>Audio and CD reading were multi-part sub-systems, each involving their own CPUs and modules.
>desperately needed trimming.
That's also a problem I have addressed. Both would need to be more rudimentary than the PS1 for the Saturn to actually be sold at a lower price point. You simply can't compete against Sony at the same price point. Much less with this quad polygon abortion.
>without conflict or congestion.
That's what the larger external cache for.
>the SCU can only use the first 1MB, and can't access the other 1MB at all
Didn't help that the low speed RAM is on a 16-bit bus. I guess it was Sega's cost saving measure.

[OP No.10707784]

>>10707714
>Have a proper launch with the same price as PS1.
They couldn't possibly have. Sony developed a dedicated 3D machine from the get go with a much more efficient architecture than the Saturn. The Saturn was supposed to be a primarily 2D console with a slower CPU. PS1's hardware was cheaper and combined with the fact that Sony could bear losing more money selling their hardware, Sega had no chance competing at the same price point. Best course they could have taken is make a weaker but cheaper system. Not too weak to render fully textured polygons at a reasonable speed and run PS1 ports though. Hence the changes I'm proposing.

[Anonymous No.10707803]

>>10707720
>Fixing /vr/
Make /v2k/ and a tendie containment board

[Anonymous No.10707946]

>>10707720
Kill >>10707803

[Anonymous No.10709321]

>>10707784
The more I think about it the more reasonable the proposal is, though I don't think I'd budge on the color palette thing. Color output like the PlayStation's can't have been terribly expensive at the time, and if devs are desperate for performance then they can lower the color depth themselves. Quake is a beautiful game, and older consoles got by with less, but to sell something that even hopes to compete with PlayStation you've got to impress at least a little bit.

[Anonymous No.10709613]

>>10707341
nah, more like one person with actual computer science chops, and one person who thinks:

>all type of memory is the same price per byte even though some are dramatically faster R/W
>Panzer Dragoon is designed the same as Starforx
>A cd-rom doesnt need any of its own logic, the system will be nearly/just as fast if the main cpu handles all that.
>8-bit colour depth is all anyone needed in 1995
>colour depth in game design correlates to cost somehow
>The Saturn needed to compete on price by being intentionally shitty compared to its contemporaries because MSRP would have saved it.
>the one objectively superior bit of tech compared to the PS1, its audio engine, is completely useless and shit, but going with a sound chip with more limitations and older than the last generation makes more sense.

[Anonymous No.10709624]

>>10693108
>Fixing the Bush Administration
Don’t invade Iraq and Afghanistan. He’d be remembered as a middling republican president if not for those major fuckups.

[Anonymous No.10710367]

>>10709613
>nah, more like one person with actual computer science chops

all of you are just fencing shit back and forth and using it an excuse to shill your youtube channels.

[Anonymous No.10710397]

>>10693839
>I don't know how it could do so well there and yet flop so bad in other markets...

Sega made a massive amount of exclusive Japanese games that catered to Japanese tastes. Saturn was also the first console ever to have 3D Fighter games like Virtua Fighter. It carried the system hard in Japan

Meanwhile America and Europe was left BEGGING for a single Sonic game to be made. Instead we got a floating clown. Great....

Also Sega spent too much money on making the Saturn. Why spend $500 million dollars making and marketing the Sega Saturn...if you are only earning $100 million dollars back from Japanese sales?

Sega took all the profit they earned from the Sega Genesis (which 95% came from overseas sales) and made a system that only the Japanese liked. Terrible decision making by Japanese Sega management which had little to no respect for foreign markets.

Meanwhile Sony knew how to make a system with worldwide appeal and consulted with game developers across the globe and listened to their concerns and thoughts when it came to designing the Playstation and developing games for it.

[Anonymous No.10710452]

>>10709613
>one person with actual computer science chops
Sure thing samefag.
>all type of memory is the same price per byte even though some are dramatically faster R/W
The standard RAM in the early 90s was 32-bit and fast enough to run Doom and Quake geometries and texture mapping with nothing but lookup tables. I don't think you could go wrong.
>Panzer Dragoon is designed the same as Starforx
What do you mean by "designed"? How its programmed, or the gameplay style? Of course they're not programmed the same, but the gameplay is just a glorified rail shooter like star fox.
>A cd-rom doesnt need any of its own logic
Says someone who doesn't know the CD drive has its own microcontroller and buffer.
>8-bit colour depth is all anyone needed in 1995
Quake and Duke 3D came out in 1996.
>colour depth in game design correlates to cost somehow
Fewer colors require fewer bits to store and compute. So of course it always does.
>MSRP would have saved it
Yes it would. Also making sega bleed less money for each unit sold would too.
>the one objectively superior bit of tech compared to the PS1, its audio engine, is completely useless and shit, but going with a sound chip with more limitations and older than the last generation makes more sense.
Well yes it's expensive and requires 512KB of memory because it needs to play PCM samples or else it needs to relegate to the inferior FM synth sounds. I read all over the documentation and found no wavetable synth functionality, it's all FM synth. It's a YMF292, a YMF262/OPL3 derivative, a chip found in soundblaster 16 sound card and such, only with more PCM channels added. The only game that used its FM synth capability was Nights into Dreams and the FM synth parts really don't sound good. Gravis ultrasound was a lot cheaper than soundblaster and sounded a ton better. Ensoniq would have been the vastly superior choice, it's cheaper and sounds better while using much less memory.

[Anonymous No.10710458]

>>10710397
>hating on the floating clown
Why did westerners have shit taste?

[Anonymous No.10710494]

>>10710458
The floating clown didn't sell consoles like Sonic did. The clown wasn't a system seller and is largely forgotten.

Meanwhole Mario 64 sold Nintendo 64 consoles by the millions. A true system seller. Sega forgot about the power of mascots.

[Anonymous No.10710502]

>>10710397
There truly is no fixing Saturn's architecture, as PlayStation games quickly began to outpace the aesthetic of even the Model 2. Model 2's best-looking games are Sonic the Fighters and Daytona, and while much more impressive on a technical level, the complete lack of support for skinned meshes and the unorthodox method for 3D space lended itself to this strange "dry" look.

Saturn's best-looking 3D games Radiant Silvergun, Powerslave, Touge King of Spirits 2, Fighting Vipers, NiGHTS, and Panzer Dragoon Zwei (maybe PD Saga, not familiar with it) were few and far between, too little, too late. Most 3D games on Saturn were worse versions of their Model 2 counterparts or were just sloppy altogether. Your average PS1 game graphically achieved a more believable world than your average Saturn game, and it did so with great ease. With no skinned meshes, no easy way to bake vertex lighting, etc etc, there's just no saving the Saturn architecture and the PS1 was priced absurdly well for how powerful it was. The Saturn can be enhanced and have some flaws fixed without increasing the price, but there's no world in which the Saturn could globally outsell the PS1.

Shenmue for Saturn looked incredible, possibly more aesthetically pleasing than the Dreamcast release. It's a shame we never got it nor anything like it. That Saturn prototype had it all, fucking gorgeous. If development for Saturn were easier then perhaps games like Shenmue could have seen a release. It would still be an expensive console but could have been seen as worth the premium price and seen a bit more adoption worldwide. But it would not save the console and would not save Sega.

[Anonymous No.10710536]

>>10710502
>There truly is no fixing Saturn's architecture
Agreed. All this speculation in these threads is just patchwork. The Saturn really needed another 1 to 2 years of development. It was too underbaked and needed to be put back in the oven.

>The Saturn can be enhanced and have some flaws fixed without increasing the price, but there's no world in which the Saturn could globally outsell the PS1.

Based on what we know, the video game market can actively support 3 consoles. I could see a world where Sega Saturn could have done moderately well and survived. A world where Sega Saturn had strange hardware, but management still made very smart business decisions despite the quirky hardware.

For example,

1. Making a true Sonic 3D game at launch or close to it.

2. Making sequels to all their hit Sega Genesis franchises like Streets of Rage, Golden Axe, Shinobi, etc.

3. Focusing on making well made Sports games like they did for Genesis. The Saturn sports games were a joke and poorly made.

4. Not launching the Saturn early and giving developers plenty of time to make games.

5. Make proper development kits and documentation to support devs with their transition to 3D.

6. Listening to the concerns of the American Sega branch and getting rid of the branch wars nonsense.

7. Not trying to compete with Sony on console price and bleed money so much.

Basically Sega overall taking an attitude of "We aren't going to worry about the Playstation and just focus on doing our on thing. We will focus on our games and making a great library that gamers want to enjoy."

That would have carried the system. Sega still had a very strong fanbase. If the Saturn hardware remained unchanged, but Sega focused on catering to fans, they could have survived. Probably Sega would be 3rd place selling 25 to 30 million Saturns (similar to Genesis). Nintendo being 2nd place selling 30 to 40 million N64s. And Sony being 1st place selling 100 million PS1.

[OP No.10710710]

>>10710536
>The Saturn really needed another 1 to 2 years of development
No, there's no way to fix it. There's an inherent flaw in Saturn's rendering system. Saturn renders 3D textures by drawing and warping hundreds of sprites and wrapping them around polygonal shapes. That is called forward texture mapping and it's really inefficient compared to PS1's more conventional backward texture mapping system, which simply renders pieces of textures on wireframe geometries. With the latter you could choose to only render textures partially, unlike the former.

Another flaw is in the system architecture. The PS1 was really simple and straightforward to program for. The main CPU generates wireframe rendering and assigns x/y/z-ordering texture coordinates to it with the help of its GTE co-processor. The polygon and texture coordinates are sent with a DMA to the GPU to be rendered into a fully textured 3D graphics using the texture tile stored in its framebuffer based on the coordinates+ordering table provided by the CPU. And it's done.

Meanwhile, there's no such convenience for the Saturn devs. Saturn's CPU is weaker than PS1's so the engineers added another CPU which only receives commands from the first CPU and couldn't access the main RAM at the same time as the first CPU. The other CPU also acts like PS1's GTE so it's equipped with a couple of math processors that are more unwieldy to use. Then the system would use the third math accelerator that's located in the system bus control unit to calculate the texture coordinates and transformation angles. This primitive rendering data and draw commands would then be sent to the VDP1 which would transform sprites and wrap them around the geometric shapes. Then the VDP2 would copy the framebuffer of VDP1 and add floors and transparent 2D tiles to it. Oh and you'd have to fight with the CD drive and sound system for access to the main RAM as well. See, this is an extremely really unwieldy design.

[Anonymous No.10710775]

>ITT retards that think the changing the hardware makes any difference
ffs you people are dumb

[Anonymous No.10712382]

>>10689689
sega saturn mini when

[Anonymous No.10712642]

>>10693108
>>10709624
Nothing needs fixing. He secured American hegemony for a New American Century.

[Anonymous No.10712691]

>>10689689

More time in the oven. Software would've been the next hurdle, but a console that was easier to work with and program games for would've been a lot more inviting.

[Anonymous No.10713625]

>>10712382
already exists

[Anonymous No.10714297]

>>10689689
no, nothing of that.
Just release some games in 1994 and 1995, there I saved your "what If" thread.

[OP No.10715136]

>>10710536
To continue on my previous post
So yes the saturn was substantially more expensive to produce, much harder to program for, and delivering worse performance. The worst of all worlds.
>4. Not launching the Saturn early and giving developers plenty of time to make games.
This way, by the time saturn came out, people would already have the cheaper and more powerful console.
>5. Make proper development kits and documentation to support devs with their transition to 3D.
This is always necessary, but sega engineers were still busy at the arcade division. Also saturn's hardware is inherently harder to use than PS1's.
>6. Listening to the concerns of the American Sega branch and getting rid of the branch wars nonsense.
Their concern was that the saturn was too expensive, and SoJ let them make the 32X instead, a stupid decision. Both the saturn and 32X should've been cheaper. 32X shouldn't have needed a power connector, sega already made a game with the SVP chip before, they could have made the SVP a game genie style extension cart for like $80 so people wouldn't need to pay $100 every time to play 3D games.
>7. Not trying to compete with Sony on console price and bleed money so much.
Hence the only way to compete is making the saturn hardware cheaper. 256 RGB colors, no VDP2, no sound card, no external CD buffer. Also give the VDP1 some rudimentary mode 7 style floor rendering and make the CPUs capable of parallel processing. This way it could've been 40% cheaper to produce while still being competitive with the PS1 even though the graphics would be worse.
>We will focus on our games and making a great library that gamers want to enjoy.
They would require more support from the game studios, and the game studios were busy making games for the PS1.

[Anonymous No.10715142]

Why is there no performant highly compatible Saturn emulator with enhancement features

[OP No.10715149]

>>10712691
The VDP1 couldn't have been fixed no matter how long you'd bake it. The only way to fix it would be to replace it with a backward rendering GPU, and that would mean redesigning the chip from the ground up. My solution was to change the color depth from 24-bit to 8-bit, probably could squeeze out a few more frames per second that way.

[OP No.10715151]

>>10712382
Never because >>10715142

[Anonymous No.10715251]

>>10715151
there are saturn emulators that play the games just fine. This isn't 2010 anymore

[Anonymous No.10715272]

>>10715251
Not at the level of performance and compatsbility or with the number of enhancements PSX has

[Anonymous No.10715328]

>>10715149
>The VDP1 couldn't have been fixed no matter how long you'd bake it.
Just replace it with a higher speed processor. Sega can tell Hitachi the SH2 isn't good enough and make a better one.

[Anonymous No.10715368]

>>10715136
> no VDP2
so you make a machine that can't do 2d, and sucks even more at 3d.

[OP No.10715380]

>>10715328
VDP1 isn't a general purpose processor, it's a sprite processor. It's actually a really powerful sprite processor, being able to render and transform thousands of sprites a second, but as a texture renderer its really inefficient.

The SH2 is indeed a lot weaker than PS1's MIPS 3000A CPU, that's why Sega put two of them. However they can't access the RAM at the same time and they're only capable of one way communication, so it ended up being inefficient. SH2 was Hitachi's best offering at the time, they already overclocked the CPU to its limit, there's no chance they could make a more powerful CPU.

[OP No.10715407]

>>10715368
VDP2 is only the background and shading layer. VDP1 does both sprites and 3D textures. They should've integrated a much less sophisticated mode 7 style background renderer into VDP1 or the SCU (bus manager) that doesn't require a third framebuffer.

[OP No.10715493]

>>10715272
Seems that each saturn game uses custom microcode due to the SCU math DSP needing one.

[Anonymous No.10715606]

>>10689689
What really killed the Saturn was Sega's poor business decisions. The Saturn hardware wasn't perfect but Sega shot themselves in both legs repeatedly with terrible business decisions. If they didn't, Sega might still be around today or at least survived 2 to 3 more generations.

[Anonymous No.10716871]

>>10715142
>Why is there no performant highly compatible Saturn emulator with enhancement features

SSF allows you to have infinite backup space, turn meshes into real transparencies, and run hi-res titles in progressive mode.