thicc_girls_are_teh_best
Member
![]()
Oh no, I know these words and they are a lie. Maybe in a low end CRT it was true but by the time I got a Saturn I had a 29"(roughly the same surface of a later 32" 21:9 tv) Super Trinitron and that thing sucked ass.
Well TBF, most household at the time had shitty low-end CRTs, and for the ones that had higher-end CRTs, the kids weren't playing their console on that at all (or most of the time, if they ever got a chance to hook their systems up to it).
I can't keep count of how many times my parents told me to unplug my Genesis or PS1 from the living room TV (the good CRT), constantly interrupting my play sessions as a kid. So annoying but what was I gonna do? House rules

Butterfly thinking here, your pretty deep in the woods here! I don't have an answer, but I do like the NEC option since that's where the next console went. Maybe you can have the best of both worlds - your SH2 and SH3 and split the difference with the 32X and Saturn![]()
The NEC stuff gets even crazier because IIRC they got the V830 (and maybe V850) cores ready by '94, and those offered a big MIPs and maths improvement over the V810 & V820 while also enabling on-chip peripherals like the V820 (V810 lacked any on-chip peripherals other than pins for interrupt sources; stuff like a DMA or memory controller had to be connected through glue logic to the external bus). They also were developing the VR4200 by early 1993, and that had a massive improvement over the 2x SH2s for MIPs performance plus 64-bit registers, 64-bit integer and 64-bit (and 32-bit) floating point support (though shared with the data paths the general purpose (integer) registers used, so weaker floating point vs. the VR4400 for example).
Eventually the VR4300i gets developed as a spinoff of the VR4200 and we know that the VR4300i went into the N64 as its CPU. Tho Nintendo had a weird setup of sorts themselves where the CPU had to access system memory through the RCP (even though AFAIK, the VR4200 the VR4300i is based on, had an on-chip memory controller

I've always wondered why none of the console manufacturers went with a 68K 030/040 or higher at a good MHZ. Was the chip not viable? Amiga CD32 doesn't count.
If I had to guess, probably a combination of those being expensive CPUs (at least their higher-end models that ran faster), being CISC-based architectures, and having lower MIPs performance than comparable RISC CPUs at same clocks while also requiring higher voltages and drawing more power. Even Motorola themselves were moving away from 68K when they joined the PowerPC alliance with Apple & IBM.
If any console that gen should've considered a 68K 030/040 etc. tho, it was probably the Jaguar. Even if it stayed the mess that it was, if it had a 68030 in there instead of a 68000, the devs who defaulted to that chip over Tom & Jerry would've been able to produce more impressive games. Straight-up MegaDrive & Amiga ports could've gotten extra performance "for free" in some instances as well, tho maybe it'd of been more complicated than I'm thinking (as I'm thinking of that from a modern CPU POV).
How could improving the tools help the Sega Saturn? The console was discontinued behind the scenes in June 1996.
Well

Virtua Racing is a very advanced game and one of the best racing games on the Sega Saturn. It has little pop-in and runs at up to 30fps.
sorry, there is no way the Sega Saturn can do better, it doesn't have the processing power, you're overestimate the capabilities of this primitive console.
You don't seem to understand what the Saturn could actually do.
For example, VDP2's most powerful features, very few games actually made use of them. In terms of outright power, Saturn wasn't that off from the PS1, and like I said, in some areas it's certainly more powerful. Most games avoided the SCU DSP, because babysitting it with the SH2s carefully sending it data through a carefully managed partition in system RAM (WRAM-H) was an exercise in attrition. That was because SEGA had very poor documentation and tools for it, and you had to do all its programming in unconventional assembly. It also lacked a hardware divider but for fixed-point you could just multiply one value by a fraction and get the same result (basically).
But that SCU DSP was a powerhouse if you used it right: 3D matrix transforms in CPU-bottlenecked scenarios. It didn't suffer delays from branches either, whereas the SH-2s did, and the SH-2s had another issue (IMO) in terms of low register count, as you've only got 32 between the both of them. PS1's CPU alone has 32 registers, and the GTE has another 64, tho I think half of those are system-reserved. The SCU DSP doesn't have registers in the conventional sense; it's more like a streaming processor kind of. You stream in operands for it to calculate and you push the results somewhere else along one of the connecting buses (like the CPU bus, to send results to the SH-2s so they can do further calculations from there). Tho I do think the SCU DSP had a small on-chip cache buffer, like 2 KB or 4 KB, something like that.
Anyway my point is, Saturn had a good deal of performance on the table that rarely got utilized, but SEGA never kept developing improvements to the APIs & SDKs enough to make it easy enough for devs to tap into using that power in realistic time frames of commercial software development. And they didn't do this, because they were already pushing ahead with investing all R&D resources into the Dreamcast by 1997, but likely even earlier than that. They were not interested in prioritizing the Saturn's dev environment because they considered its commercial market viability increasingly irrelevant by late 1996.
But that's a very different argument vs. just thinking the Saturn had no power in it to squeeze out beyond what we saw. Honestly, the more I've been studying its architecture, the more impressed I am by it. Even so, I still stand by the thought that had Saturn's 3D fully matured, it'd of still not been at quite the exact level of the PS1 or N64's best-looking 3D games. Tho also worth stressing, PS1 & N64's best looking games didn't release until mid-1998 or later. Saturn's AAA game dev market was completely dead by that point, so it becomes a bit unfair to start comparing, say, Banjo-Tooie or Gran Turismo 2 to SEGA Rally & Croc, IMHO.
Gaming is subjective and sure many people will have their own views own which is the better RPG for story and all that. I don't think it's in much doubt that Grandia was graphically the better looking game mind, than FF7. I'm just on about FF7 here mind, Square really upped their game with FF 8 which had stupendous visuals (more so for the battle sections) and the best FMV I have ever seen at the time
Graphically, opinions would still come down to preference tho. Which game's art style a person'd prefer, for example.
I also think you're wrong to focus on Time Warner, it's not like they were a good developer and for me the main issue was they seemed to have no access to the source code which for me would be the main issue. Sure SEGA tools needed to be better and weren't up to par, but SEGA Japan was already addressing that in March of 1995 when they were showing off the 1st screen shots of VF2 on the Saturn and their new official development system, the SGL tool set, which credit to SEGA America (for once) looked to use a consumer massed produced Saturn's and its Cart slot.
The Time Warner example was to illustrate how poorly SEGA supported 3P in the very early years of Saturn development, even into after its release date. They did finally start improving things by mid-late 1995, but they lost a lot of early ground with 3P in providing capable devkits and SDK API packages, to Sony. And just because SEGA's tools improved, didn't mean Sony's stayed stagnant, so there was always something of a steady gulf between the two platforms in that area no matter what period on the timeline you're looking at.
The thing with Virtual Racing, had we not had the 32X then The Saturn would have had the CS Team handling the version and that would have been even better than the 32X version, with that team working on the more powerful hardware. Doom would have been better on the Saturn with the 32X Team handling the Saturn port and would have been out months before the PS1 version too
Well, maybe. Actually in DOOM's case, the Saturn version would've been a lot better if Carmack just let iD do things the way they originally wanted to. I still don't understand why he went out of his way to crazily optimize the Jaguar's DOOM port, yet never afforded that level of care to the Saturn version.
It all goes back to the 32X for me, even for development. I bet SEGA had trouble making enough SH-2 to be distributed in both Saturn and 32X development units, never mind also making them for retail early in, never mind how it split SEGA development budgets, development teams and PR, even SONY found it hard trying to support 2 different systems with its consoles and handhelds, while SEGA was looking to support the Mega Drive, Game Gear, Master System, 32X, Saturn and the Arcades in 1995, It was sheer madness in anyone book
I completely agree with all of this. Been said 32X was a mistake altogether, and should've never been released. SEGA should've made a standalone SVP cartridge and left things at that. Then, if it were technically possible, they could've made the SVP cart compatible on the Saturn as a peripheral in the cartridge slot, tho that would've required reshaping the slot to fit in Genesis carts.
And I guess if they went that far, might as well had made the Saturn BC with Genesis software. IIRC that was part of the plan to some degree, since all other SEGA consoles had BC with previous models. They'd of just needed another VDP or modified the VDP2 to also handle sprites in a way the MegaDrive would've (while hopefully retaining the benefits of the design as we know it for).
If SEGA America was so worried about the price of the Saturn (which for me wasn't an issue) They should have backed the original plan of the Jupiter system which was a Saturn without the CD-Rom (that could be added latter) At least that system would have allowed developers to use the same development kits and share resources
I half-agree with this but, a complication with Jupiter in that sense would've been you'd need to redesign games with cartridges in mind from the get-go. Going by the N64, realistically Jupiter cartridges would've probably topped out at 64 MB, but potentially less. Compression could've helped, but that's still "only" 128 MB for lossless, and that's considering all the data could compress further anyway (2:1 could probably allow for cheap hardware decompression implementations based on run-length encoding, for example).
But starting out? Jupiter carts would've probably been something like 8 MB (64 Mbit), 12 MB if you were lucky. Then we're talking a Saturn whose games would need to also work on Jupiter, so what are they gonna do with all that extra disc space? Well, probably pad it out with Redbook audio or uncompressed FMV to stream through the console. At that point tho you're probably running into a problem add-ons like the SEGA CD faced: what's the point of all that extra space if it's "basically" a cartridge game on a disc with CD-quality music? You trade away the benefit of carts (fast load times; potentially accessing ROM as RAM tho for a console like Jupiter you'd need SUPER fast ROMs, and companies did make them. I know NEC have one with like 10 ns access time latency from the early '90s, but it was probably expensive) and it's not like most devs would add tons of gameplay content to the disc version of a cartridge game, when we're talking about simultaneous releases on both Saturn and Jupiter.
So I do kinda understand why Jupiter was cancelled. All things considered, CD was the best format choice for that generation, balancing out capacity for access speed and price. The 512 KB cache buffer in Saturn mitigated a lot of the pains using a 2x CD-ROM drive would've brought, anyway. If price wasn't a concern, MO (Magneto Optical) discs would've been awesome to see in a home console that gen, but the drives were very expensive and even single 128 MB or 230 MB discs were like $60 a pop if not more, and SEGA would've had to buy all of that from a source anyway, so no cost savings on their end. So, still way more expensive than CD and way more per MB comparatively, especially if you went for 1 GB discs. Guess you could've also compressed data on smaller disc capacities, for say 460 MB on a 230 MB MO disc, but even still you lose out in pure capacitance vs CD (way better long-term shelf life and access speeds, though

No way could SEGA beat or match SONY and the $500 they put into the PS1 even before it launched, but the N64 was there for the taking and thanks to SEGA America and Europe, SEGA cocked it all up
All that said mind, The Sega Saturn is still the best console I've ever owned and the system that gave me the best enjoyment in gaming
SEGA, GameArts, RAIZING and Lobotomy were GODs back them
I agree that even if SEGA did everything right that gen, they'd of probably still lose out Sony & the PS1. It would've been a much closer fight though, and Saturn could've outsold N64 globally in that type of alternate timeline.
Don't think the PS1 costed Sony $500 to manufacture tho; quite far from that in fact. The Saturn's BOM costs at launch were likely closer to that than PS1. Remember, Sony co-owned the CD format so they didn't pay royalties on that. They manufactured their own CD-ROM drives, fabbed the PS1's chipset (CPU, GTE, graphic renderer etc.) with their own plants; one of the few thing for PS1 they did source elsewhere was the system RAM and VRAM. They already had major distribution networks for hardware and CD software due to their home electronics division and Sony Music record label.
SEGA didn't have any of those inherent advantages and the one advantage they did have, the arcade market, they did not leverage synergy between that and Saturn (and even later, with NAOMI and Dreamcast) to the absolute level they could have IMHO. Tho I'm speaking with hindsight here, seeing the aftermath of results that SEGA could not have foreseen at the time back in the day. So I do want to stress that.