Comparison of 5th generation ("32/64-bit") game console hardware

Quote:

---

Originally Posted by azonicrider

Yea its became obvious that Nintendo is scared of standard formats, because of piracy and royalty fees. Always gotta go proprietary.

---

Yes, those issues and the desire to have actual control over manufacturing with the ability to dictate when and how many carts could be produced. (something they were still pushing on the DS a few years back, not sure if they're doing it now though)

Quote:

---

I wouldn't say the same for Sega, they went with GD-Rom, because DVD technology would make the console cost $350, and CDs didn't have enough capacity. They needed something in the middle.

---

On that note, Sony actually developed a similar enhanced-CD format with a 1.3 GB capacity called double density CD. http://en.wikipedia.org/wiki/Double-...y_compact_disc
It never gained much mass-market popularity though, and Sony's in-house advantage made DVD more attractive for the PS2 anyway. (especially as they wanted to leverage DVD video)

Would have been interesting if the SVCD standard had adopted DDCD instead of standard CD. (might have made a more viable lower-end DVD alternative in that case, rather than the existing SVCD which really only ever catered to the Chinese -and similar- markets it was created for)

DDCD is just using a tighter track pitch than the original spec for CDs. That's commonplace as 80 minute CDs have virtually replaced anything lower, and you can get 90 and 99 minute CDs from a number of places. They work with most new drives - old drives with sloppier tracking can have trouble with the tighter track pitch. The SegaCD was designed around 65 minute CDs, if you were wondering.

Quote:

---

Originally Posted by Chilly Willy

DDCD is just using a tighter track pitch than the original spec for CDs. That's commonplace as 80 minute CDs have virtually replaced anything lower, and you can get 90 and 99 minute CDs from a number of places. They work with most new drives - old drives with sloppier tracking can have trouble with the tighter track pitch. The SegaCD was designed around 65 minute CDs, if you were wondering.

---

Yeah, the Sega CD used the old "low density" ~570 MB discs as standard.

DDCD isn't just using tighter track pitch though, but also reduces the minimum pit size, bringing the capacity beyond normal CD-ROM formats. GD-ROM used the same method for expanding capacity, though I think the specifications differ somewhat. . . . Actually, going by the basic discription on wikipedia, GD-ROM is listed at having more tightly packed pits (higher density) while DDCD is listed as using smaller length pits . . . but I think it's fair to assume that both cases involve smaller/denser pits and lands and not just one or the other.


Not sure how the track pitch fares on GD-ROM though. (I'd assume it's at least as tight as 80 minute discs though)

Quote:

---

Originally Posted by Roly

The example that comes to mind is the Nintendo 64, which looks an extremely pared back design (http://www.eevblog.com/forum/blog/ee...sole-teardown/).

Given its known issues with overall latency and DMA to the R4300i, were there feasible additions to the design that, in retrospect, would have made sense? I seem to remember that the N64 had a pre-US launch price cut, and perhaps there was some margin to increase the bill of materials (obviously, at a relatively early phase in the design).

Assuming that optical storage is ruled out, and cartridges are mandated, were there useful and plausible changes, say to the memory subsystem (which seemed to be a real focus of the Gamecube).

For instance, a small off-die SRAM or PSRAM cache (say 48kb – 96kb) or scratchpad between the R4300i and/or RCP to soften latency to RDRAM? A faster cartridge bus? DMA for the CPU?

---

The RDRAM latency issue wasn't really that huge of a problem . . . there's a LOT of other areas that limited the N64, but that's not really that bad.

On the RDRAM though, had it not been subsidized (and owned) by SGI themvelves, RDRAM wouldn't have made sense at all (way too costly), and EDO DRAM or SDRAM on a 64-bit bus would have been the de-facto option instead. (like most new PC GPUs were doing at the time ATi, 3DO, 3DFX, etc -not sure about NV-1, but Nvidia went 128-bit bus on the RIVA 128 in '97) For that matter, pentium era PC CPUs went 64-bit bus and EDO/SDRAM as well.

RDRAM or not, they also could have switched to dedicated CPU and graphics buses, but that's a major cost trade-off too. (unified bus design is a good cost cutting design measure) Still, it wasn't all that common on consoles before or after that. (most common on Atari and Microsoft consoles, actually)
The unified bus also means very flexible allocation of memory (trade-offs between CPU and graphics data/instructions/buffers), plus it meant the 4MB expansion Pak was useful for both graphics and CPU.
The "latency" from having contention for main memory is a bigger deal than actual RDRAM latency, but still you've got decent sized caches and buffers in the chipset to still make reasonably effective use of the system bandwidth. (hell, probably more so than the original Xbox's CPU too, since that Celeron mobile uses a 133 MHz single-channel SDR bus and the RAM is dual-channel 200 MHz DDR -so using 1/6 the RAM's bandwidth capacity . . . a Duron or Athlon would at least have used 1/4 the bandwidth . . . a custom Pentium III derivative with the Pentium 4's 400MT/s bus would have been really nice though -more like the later Pentium M)



Anyway, back to the N64's real problems:
Nintendo and SGI were very limited in documentation and tools for the system. They made it out like the RSP was impossibly complex to program for, but it's not . . . it's only painful to use due to lack of documentation and tools. (otherwise it's a pretty normal 32-bit MIPS based processor/controller with some DSP instructions) The RDP (the GPU) itself is pretty complicated and difficult to program directly, hence why the RSP is there to help out, but even so you weren't going to have developers generally programming the RDP by hand anyway. At most they could have made custom libraries (APIs) to suit their individual needs much better than Nintendo/SGI's standard APIs and RSP "microcode." (it's not really microcode . . . it's just 32-bit MIPS code loaded into the RDP's scratchpad)

Even the few developers Nintendo did give more detailed documentation to still have a hell of a time using it since the tools provided for programming the RSP were so primitive.

The programming model restrictions of this sort are directly related to why you don't see games pushing really high polygon counts with closer to Playstation level visual quality. (or still quite a bit higher visual quality than that . . . like perspective correction and bilinear filtered textures, but no trilinear filtered mipmapped stuff and lower precision calculations, among other things) Or allowing reloading the texture cache for high res textures on single polygons. (as it is you normally have to stretch 32x32 or 64x32 textures or use groups of smaller polygons to build up a texture -but that wastes performance much more than reloading the cache mid-polygon would)
Or really powerful 2D rendering capabilities with most of the 3D features disables and drawing speed limited mainly by fillrate. (we're talking 2D performance considerably better than the Saturn or PSX . . . theoretically better than 3 times that of the PSX)

Then there's the general limitations imposed by Nintendo's pigheaded stubborn proprietary insistence at cartridge media. And not only that, but to do that without plans for a optical drive upgrade . . . and instead ending up with an overly costly and complex ZIP-drive like magento-optical drive that arrived way too late. (and yes, CD-ROM drives are cheaper to manufacture than ZIP drives -in fact, the physical mechanism and media are cheaper than pretty much anything short of double density floppy disks . . . CD drives just had much higher licensing overhead inflating the cost until around the mid 90s)

Realistically, Nintendo should have just used CD-ROM and developed a proprietary data encoding format so they'd retain control over manufacturing (as they wanted) and provide further protection against piracy. (more like GD-ROM should have for Sega had the DC not also supported loading software from CD-ROM . . . so more like Game Cube and Wii really -which took a very long time to crack the optical data format of)

It would have increased the manufacturing costs, but the low manufacturing costs of discs and added profit margins from the game sales would have mitigated that almost immediately. (really, if you consider the cost spent on ROM cart manufacturing just in the first year of the N64's life, I'll bet that outstripped the cost of manufacturing an N64 with CD-ROM drive) And that advantage would only increase as time went on and CD drives got even cheaper.
Even more so with the N64 delayed to 1996 from the 1995 planned release date, meaning CD drive prices had come down even more.
So Nintendo could have eaten the cost and sold the system at a loss, but technically not actually spending more on manufacturing investment. ;)

Quote:

---

I am assuming that the TMEM cache issue was probably unrealistic, given that the RCP was already, from memory, quite ambitious for 350nm. Then there is the whole development environment, and microcode profile, tools, and access, which I note there are many excellent posts on.

---

I'm not positive about the RCP, but the R4300i was definitely done on NEC's .35 micron process.

Quote:

---

While I appreciate it has been debated previously, I also do wonder what a 1994/5-era RCP would have been capable of, had Sega pursued it – presumably the fabrication at 800nm – 500nm would have been a serious impediment for yields, and clock speeds, though perhaps with FPM or EDO RAM the performance diminution would have been attenuated c.f. the N64 and its RDRAM.

---

Assuming it wasn't particularly buggy, the clock speeds and/or yields would have been significantly lower, and manufacturing costs significantly higher due to the larger dies. (not to mention power consumption and heat concerns) Plus the lower cost R4300 wasn't in volume production until 1996, so an earlier release could have needed the more costly R4200. (granted, still much cheaper than the full R4000 it was based on, but not as good for a console as the more cut-down, lower pin count -and die shrunk- R4300)

Using the older .6 micron NEC process (used for R4200) for the RCP, and lower clock speeds for both the CPU and RCP, it might have been doable in 1995 . . . 1994 would depend more on the RCP's maturity in general. (the R4200 was in full production by '93, so the RCP would be the limiting factor) It also might have required separate chips for the RSP and RDP. And with RDRAM yields being so low early on, I'd imagine EDO DRAM would have been used on a 64-bit bus.

It would have been considerably more expensive than the Saturn or PSX in 1994 though, but it should have fallen much more rapidly than the those designs with further integration, reduced power consumption, and generally decreasing component costs.
But I'm going to guess the RDP and RSP weren't fully mature at by 1994. (granted, it could have been RDRAM and the R4300 -and Nintendo's bottom line- that delayed it rather than the chip designs themselves)


Still, there's a reason the N64 was delayed until 1996 and very real reasons why Sega Engineers were so uncertain about it. Joe Miller sheds more light on the work in progress Sega looked at back in 1993:
http://www.sega-16.com/2013/02/interview-joe-miller/

Quote:

---

Joe Miller: It’s true. I would say that it’s not so much that they shot it down as much as it was that they simply didn’t warm up to it. We were highly confident that collaboration between Sega and SGI would work well, and Tom and I were excited about it; we were strong proponents of it. We were able to get the conversation to a level that had all the right people from Japan looking at the opportunity and in the room. This was partially due to the fact that Sega had always been a hardware company; its DNA was driven by its ability to design high performance hardware systems for coin-op for many, many years. There was a tremendous pride within the organization about their ability to engineer whatever was needed to create compelling entertainment platforms, whether they were consumer, coin-op or whatever they might have been.

I think the problem with the SGI opportunity was that there may have been a touch of NIH (Not Invented Here) in the reaction. That might not be completely fair, because they were concerned that the process required for fabricating that particular chipset was new. There were concerns about yield; there were some voiced concerns about how many of these could be made quickly. Part of what makes a consumer products company successful is that you understand the manufacturing process well enough to know that you can make enough product to meet demand, and there was concern on that particular opportunity that that chip was going to be difficult to manufacture at the quantities needed.

The way I would put it is that it would have been an amazing opportunity– obviously Nintendo figured it out… so it wasn’t a problem ultimately for those involved, except I’m not sure that Jim Clark felt that it was the best result for SGI. I think it’s fair to say that both Tom and I, and others at SOA, felt this was absolutely a potential next platform opportunity for us, and we got fairly deep into conversations with all the right people at SGI, brought SOJ in, and we wound it down pretty quickly. At that point, it was pretty clear that if Jim Clark wanted to pursue that idea, he was going to have to start making other phone calls, and he did and went with Nintendo.

---

You've got to keep in mind that Nintendo could afford the sort of delays the design saw, let alone some of the weird design/management choices Nintendo forced on it. Nintendo had the market share (in all major markets), reputation, and budget to make a few mistakes and be OK, plus the SNES was 2 years newer and in less immediate need for replacement (especially in Japan).
Sega couldn't afford that kind of latitude with their console market performance in Japan and relatively newfound success in the US (and 2 generations in Europe), and how much Sega was hurt by the mistakes made in '94-97 demonstrate this vulnerability pretty well. (more so with their Arcade and amusement market sales falling during that period as well)




However, there's a lesser known parallel to this:
Back in 1990, when Michael Katz was still president, Dave Needle and RJ Mical (or Amiga and Lynx engineering distinction) came to Katz with the proposal of developing a next generation video game chipset for $2 million. Katz favored it, but SoJ management turned it down (apparently with less to do than the later SGI deal).
That chipset became the 3DO.

This was discussed here:
http://www.sega-16.com/forum/showthr...l=1#post601102

The context of this was detailed on page 484 of Steve Kent's Ultimate History of Video Games. And while that's really a sensationalistic editorial approach on game history (with poor fact checking and plenty of errors), it's at least good for direct quotes, and this ones from Michael Katz himself:

Quote:

---

Originally Posted by Mike Katz

Dave Moris, Who replaced me briefly as president of Epyx, came to me with RJ and Dave Needle when I was president of Sega. They presented to me the concept of paying them $2 million and giving them two years to develop the nest "ultimate revolutionary" video game system; and I was all for it, based on their cridentials, because they had developed the Amiga computer and they had developed the Lynx. I had just paid 1.7 million dollars to Joe Montana to get his picture on a game. I thought it was nothing to pay $2 million to get the next hardware system developed
So I recommended that they go to Japan, which they did two or three times, and present their concepts to Nakayama. They were turned down.

---

It's particularly ironic given that VDP1 in the Saturn works very similarly to the 3DO's Cel engine, though lacking a few features (3DO had some texture compression support, better lighting/shading/blending, and the full-screen interpolation AA). Not to mention it was even more "safe" than the Saturn design itself, in terms of complexity and release date target. With a 2 year design cycle and then a further year to gear up for launch (manufacturing and software development lead-up).

Even more so considering that, partnered with Sega, the design could have benefited from Sega's manufacturing connections with Hitachi and the like, and likely would have had a faster CPU (SH2 wasn't ready, but a 20 MHz SH1 with an 8k scratchpad would be nice), perhaps SDRAM, but probably just good deals on FPM DRAM and VRAM, and probably some other cost trade-offs too. If they cut the framebuffer size to 512kB (1 MB was excessive) and added dedicated texture RAM to avoid CPU contention (say split it for 1 MB for textures and 1 MB of CPU/audio), they'd have avoided the CPU/GPU contention of the 3DO and had general sprite/quad rendering performance very close to that of VDP1 in the Saturn but with more features and a year sooner.
Maybe there'd have been some other design differences with access to the hardware in the MD and Sega CD. (maybe for a backwards compatible design, but more likely saving some design work on the CD-ROM interface and maybe sound)


It also should have been considerably cheaper than the 3DO since it would be designed and sold as a console at cost (or marginal loss) and low-cost optimized rather than licensed and sold for profit as a high-end multimedia product.
Plus it likely would have launched in Japan in 1993, and in the US in 1994, so the most expensive year would have been in Japan (where high end tech sells better) and would have dropped more by the time it hit the US. ($400 in fall of 1994 in the US should have been totally feasible, perhaps $350 even, and then cheaper than the PSX by late 1995 without eating losses like with the Saturn at $300 that year)

Pushing the Dreamcast slightly sooner might have made sense then too, but remember you'd still have 3D performance about as good as the Saturn (just more CPU bound and weaker without VDP2), and 1993 to 1998 (or '94 to '99 in US) would comprise the typical 5 year console market cycle. ;)

Many thanks Chilly Willy, and very happy to have the post moved, this forum operates very well in terms of coherence. That sounds quite logical as a design, if parsimonious (4k... without code compression), and in a sense, not the nightmare that tended to be described at the time (or less of a nightmare). The RSP of itself sounds more intriguing the more I read of it, a sort of liminal, orphan approach between the older generation, and the PS2-era.

My thanks also Kool Kitty, for a typically compelling and detailed post, not only on the Nintendo 64, but also on the various counterfactual options that could have been pursued for the Saturn (even if there were circumstances – not entirely technical, that forestalled their pursuit).

It was useful to have another view of the RDRAM and the memory subsystem, which along with Chilly Willy’s description – it sounds less dysfunctional than the orthodoxy / mythology that I’ve previously seen. The lack of developer tools and suitable microcode is arguably more depressing, because it could have been remedied with presumably modest funding and a change in policy. I also do wonder if point sample purchased any performance beyond even straight bilinear (or the three sample approximated bilinear). I only ever saw it on Perfect Dark.

I still remain impressed with the Rare titles in terms of their texturing, though obviously a large part of the effect is derived from the art style etc.

The RCP avenue sounds more and more infeasible for the Saturn, when the context is discussed – both in terms of contemporary fabrication capacity, available MIPS CPUs, and the context of Sega as a hardware company with an established tradition and other partnerships.

Regarding the 3DO evolved option, I very vaguely remember an early EGM issue, which had an interview with Mical (and maybe Needle) on the design of the Lynx, why the 65C02, the capabilities of “Suzy” as a sprite engine and similar. It was really interesting, though I last read it maybe twenty years ago, so could be misremembering. They seemed fairly amazing as console and computer designers (the reasoning behind the TIA, as detailed in “Racing the Beam” was elegant).

Quote:

---

Originally Posted by Chilly Willy

@Roly, in addition to the note on the 4300 cache, the RSP in the RCP executed directly out of the IMEM and directly accessed the DMEM, both inbedded in the RCP. So there's no latency there at all. You'd have to program carefully to DMA data (and more code if needed) in or out of the I/DMEM, but it's nothing a decent programmer couldn't handle. The primary limitation is that 4KB of IMEM - that's all the room for code allowed. Given you didn't have MIPS16 instructions at the time, you are limited to 1024 instructions total. Nintendo's "microcode" libraries automatically DMAd code overlays into IMEM as needed. If you think about it, Nintendo's RSP was handled almost identically to the GPU/DSP risc processors in the Jaguar - there, programmers used the BLITTER to DMA code into the GPU or DSP local ram for execution.

---

As far as DMAing code and data . . . that's kind of general fare for DSPs in general and some MCUs (which aren't directly mapped to main memory for code/data), and easier to work with than typical DSPs as far as the instruction set goes (normal MIPS CPU for the most part, easier than typical primitive/limited DSP instruction architectures).
Actually, that's a little like the way the Jaguar RISC processors are set up . . . except they're mostly stuck like that due to bugs and data can still be pulled from main RAM. (code can't be run . . . at least without a significant workaround in assembly language)

Quote:

---

Originally Posted by Roly

It was useful to have another view of the RDRAM and the memory subsystem, which along with Chilly Willy’s description – it sounds less dysfunctional than the orthodoxy / mythology that I’ve previously seen. The lack of developer tools and suitable microcode is arguably more depressing, because it could have been remedied with presumably modest funding and a change in policy. I also do wonder if point sample purchased any performance beyond even straight bilinear (or the three sample approximated bilinear). I only ever saw it on Perfect Dark.

---

N64 homebrew efforts of reverse engineering and tweaking the hardware combined with additional leaked documentation has demystified the N64's architectural oddities to a fair degree. (not sure how much that's happened only in recent years and how much is just not common knowledge outside the N64 homebrew scene)

So far, I haven't actually seen hard figures on how much faster fillrate is with different texture detail settings (or color depth for that matter). Same for how much vertex performance gain there is by changing polygon rendering accuracy/precision. (I'm actually not sure what the "accuracy" term used in some articles refers to, it's mostly in comparing Turbo 3D to the normal "Fast 3D" microcode, and may be just a typo/misinterpretation of precision -ie using lower precision computations, like 32-bit floating point instead of 64-bit or such)

As far as texture fillrate goes, I can at least speculate based on performance of early PC accelerators of the time with broadly similar feature sets, like S3 ViRGE 325, ATi RAGE II (Rage I has too poor a showing of software to really compare), Rendition Verite V1000, and 3DFX Voodoo.
Voodoo is the only one of those that has "free" bilinear filtering at full speed, and in fact, almost all of its features have very little performance loss when enabled (though it's also fixed to 16-bit color depth). ViRGE and Rage II general gain a lot from dropping features, especially filtering (massive fillrate games -up to 8x in theory on ViRGE- and not uncommon to double framerate in actual games/demos), but perspective correction is "free" on ViRGE while Rage is variable. (though on rage-2 there's not much gain/loss to perspective correction in general -but at best it looks worse than virge, as does its texture filtering, especially in 32-bit color -where virge looks really smooth)

There's lots of neat info on this here:
vintage3d.org/
(there's a few other feature-rich 3D chips like 3DLabs' stuff, but more limited info)


But I think it's a fair guess you could have a nice boost on RDP fillrate with features cut down to Z-buffering and perspective correct textures, and still better visual quality than the PSX. (and there's a lot of cases where faster rendering with fewer features . . . and the lack of filtering would matter much less if texture res was higher, namely if cart space didn't limit things and if more flexible use of the texture cache was possible -which really should be the case with the right programming tools, particularly since the cache is software managed)

I still remain impressed with the Rare titles in terms of their texturing, though obviously a large part of the effect is derived from the art style etc.

Quote:

---

Regarding the 3DO evolved option, I very vaguely remember an early EGM issue, which had an interview with Mical (and maybe Needle) on the design of the Lynx, why the 65C02, the capabilities of “Suzy” as a sprite engine and similar. It was really interesting, though I last read it maybe twenty years ago, so could be misremembering. They seemed fairly amazing as console and computer designers (the reasoning behind the TIA, as detailed in “Racing the Beam” was elegant).

---

I don't think Needle or Mical worked on TIA, that was J Miner (who did some concept work on the later 400/800 chipset too, though that was actually engineered/designed after he left Atari).

Miner was the lead designer on the Amiga project, and that's where the connection comes in. Miner wasn't part of the Lynx or 3DO teams either.


On another note, it's kind of ironic that Epyx (where Katz had formerly been president) ended up with the Lynx (handy) design who brought it to Atari Corp (which Katz had built a relationship between Epyx while president of Atari Corp entertainment), but that went down after Katz left (in early 1989) . . . and by the time the Lynx actually came out, Katz was working as president of Sega of America. (after several months on vacation from the industry -spring through fall 1989)
And a few months after that, Needle and Mical went to see Katz at Sega.

Oh, even more: Sega had tried to license the Mega Drive (in North America) to Atari Corp in 1988, but ended up being turned down after Dave Rosen and Jack Tramiel couldn't agree on terms of the contract. (though Katz was "all for it")
And then he ended up at Sega, and within a year there he got the offer from Needle and Mical, which ended up turned down by SoJ higher ups.

Interesting how that all tangled around.


I can also only imagine what impact Katz might have had on the Lynx (or Panther . . . or Jaguar for that matter) had he stayed at Atari Corp, and whether that would have affected what happened with the 3DO. (supposedly Needle and Mical were upset with Atari's handling of the Lynx release in '89, and looked elsewhere for their next project)
Heh, Marin Brennan (from Flare Technology) was already consulting at Atari Corp in 1989 (on the Panther), and had Katz stayed and things with the Lynx and related engineers gone better, maybe the Flare guys (who designed the Jaguar) could have been brought in with the 3DO guys on one big collaborative project. (or I say big, but we're still talking about a scant handful of engineers -the Jaguar itself was mostly designed and engineered by Martin Brennan and John Mathieson)

You know... I'm still confused by the "PSX" name.

I barely hear anyone say "Ultra 64" nowadays.

Have never heard anyone say "Giga Drive".

I'm only a year younger than kool kitty, so you can't say I'm too young to remember the early days.

Maybe the PSX name wasn't as popular in Canada.

At least PSX was used a lot in European countries...

My thanks Kool Kitty, for further compelling detail on the N64 and the microcode possibilities, and also for the correction on my confusion on Miner c.f. Needle, Mical, and the nexus at the Amiga.

The hardware design world in that era seems relatively concentrated amongst a few groups – and the Flare and Konix tale is always an intriguing one (CVG and The Games Machine covered a lot of this, I remember reading it on the way to school). A history of that period, like "Racing the Beam", or the Amiga "Future Was Here", and Bagnall's Commodore book, would be so interesting to read.

That Vintage 3d site is promising indeed – so many strange cards, all the way back to the Glint SX. The performance increments with various features on the s3 cards is reasonably dramatic, across all of the evolutions. Their Rage II filtering screen shot was quite telling as well. At the time, for that late 90s era, I had the Verite s2100, I remember it fondly – though I kept the resolution at 400 x 300.

Quote:

---

Originally Posted by Roly

The hardware design world in that era seems relatively concentrated amongst a few groups – and the Flare and Konix tale is always an intriguing one (CVG and The Games Machine covered a lot of this, I remember reading it on the way to school). A history of that period, like "Racing the Beam", or the Amiga "Future Was Here", and Bagnall's Commodore book, would be so interesting to read.

---

Yes and no . . . more like a bunch of different people moved around and did different things, some went back and forth between hardware and software, and between computers, arcade and game consoles, and most ended up doing independent contracting on and off, some split up and reformed with others with other start-ups. (and that's only looking at North America and Europe)

You've got the likes of the Atari Inc, MOS, CBM, Atari Corp, Amstrad, Sinclair, etc moving on or moving around (particularly in regards to mergers -Amstrad+Sinclair, MOS+CBM-, management changes -various-, company liquidation -like Atari Inc in 1984- etc).
There's the small start-up company GCC from the early 80s doing arcade modifications and unlicensed sequels of sorts which ended up with legal action and then actual partnetship with Warner (and licensing what became Ms Pac Man to Midway -itself an unlicensed sequel to Namco's Pac Man), and then their development of the 7800, and then splitting up in the mid 80s to do various other things.

Flare emerged from the Sinclair Loki project, with the team leaving during the Amstrad takeover and then doing Flare 1 and later Slipstream (in various multi-chip, single-chip, 8-bit, mixed 8/16-bit, fully 16-bit, and Z80/8088/8086 configurations), then the three of them splitting up to do contract work in '89. Brennan went to Atari and Mathieson later joined him for the Flare2/Jaguar project, while Ben Cheese (who did the Flare1 DSP design) ended up with Argonaut on the M.A.R.I.O. Chip (Super FX) project.

Quote:

---

That Vintage 3d site is promising indeed – so many strange cards, all the way back to the Glint SX. The performance increments with various features on the s3 cards is reasonably dramatic, across all of the evolutions. Their Rage II filtering screen shot was quite telling as well. At the time, for that late 90s era, I had the Verite s2100, I remember it fondly – though I kept the resolution at 400 x 300.

---

The real shame with S3 ViRGE stuff is the DirectX drivers were never quite right, at least for a large number of games . . . and no OpenGL support (pretty common problem there though), and very limited support for their S3D API. (also a common problem -3DFX was pretty much the only one to end up with actual competitive software support for their API)

Kind of makes me wonder if it would have fared better in a console . . . much better chance for optimization and tailoring to performance and feature quirks. (Dreamcast's use of PowerVR was much above average for that reason, even in DirectX -Windows CE games)

ATI had a shaky start, but from the Rage II onward they pretty much kept on track with reasonably competitive products with fairly consistent and timely releases. (and very strong OEM sales -something S3 also had, but many others like 3DFX lacked)

NVidia was kind of the biggest turn around for that time though. A new and relatively small company on the market, and with the weird but interesting NV1 very different than any of the others at the time, but also without any real developer interest to make use of it (Sega barely did, and only as far as its native quad rendering on a couple Saturn ports), and pretty weak performance and compatibility for DirectX 2D or 3D.

But then they made a complete 180 with the 1997 release of the RIVA 128, the first really Dirext3D optimized card out there and the first that directly rivaled (or exceeded) 3DFX in raw performance and features, let alone doing so in Direct3D. (though visual quality often wasn't as good -especially dithering) Plus, unlike the Voodoo and Vodoo II, was not an add-on card but a total 2D/3D solution with 16 and 32-bit color (16-bit only in 3D) and real potential for OEMs as well. (though it took some time before Nvidia became competitive in the OEM market)
NVidia also had a better reputation for having more reasonable quality early generation drivers for their cards compared to others at the time. (ATi tended to lag with early drivers up through the Rage 128 series at the very least . . . which meant they tended to be much more competitive as mid/low-end accelerator options a couple years down the road and less so as high-end new products)


3DFX started moving more in that direction with the Voodoo Banshee and Voodoo 3 series, but they never really gained strong OEM acceptance, and also failed to keep pace with the competition after that. (with Voodoo 2 they were the high performance leader, but by the time of Voodoo 3 they were mostly just keeping pace on the upper end, and then fell behind in both performance and cost effectiveness)

Quote:

---

Originally Posted by azonicrider

You know... I'm still confused by the "PSX" name.

I barely hear anyone say "Ultra 64" nowadays.

Have never heard anyone say "Giga Drive".

I'm only a year younger than kool kitty, so you can't say I'm too young to remember the early days.

Maybe the PSX name wasn't as popular in Canada.

---

PSX was and is used a lot of the developer/programmer/tech side of things . . . including modern homebrew to some extent. (seems pretty commonly used on Youtube video titles too -and tags)

It became a habit of mine mostly due to conversations on this site, probably from Chilly Willy especially.

It's a convenient abbreviation . . . and easier to build up a habit on than PS1 (easier to type). Ultra 64 is not . . . N64 is easy and the standard abbreviation. Giga Drive is an obscure and non-specific term in general. (does NOT apply to the Saturn directly in any case)

On the note of abbreviation, there's a lot of non-standard stuff commonly used too . . . and I generally refuse to use GCN out of the principal that it looks and sounds stupid IMO. I usually just use GC. (NGC is OK too, but GC is usually enough)

Well, PSX was ubiquitous where I came from for standing for the first Playstation. When Sony came out with a "PSX" based on the PS2, that caused a LOT of confusion, with Sony justifiying it by saying THEY had never used PSX for the PS1. I suppose I ought to start using PS1 more often instead of PSX.

N64 is pretty much all you'll see in the US. I liked Ultra64, but Nintendo couldn't get the rights to the name in the US, so it never used it here. I normally use GC, but NGC is fine, too.

Quote:

---

Originally Posted by Chilly Willy

Well, PSX was ubiquitous where I came from for standing for the first Playstation. When Sony came out with a "PSX" based on the PS2, that caused a LOT of confusion, with Sony justifiying it by saying THEY had never used PSX for the PS1. I suppose I ought to start using PS1 more often instead of PSX.

---

Heh, not nearly as bad as the XboxOne naming confusion. :p (more so since the "PSX" DVR thing was super niche, short lived, and Japan only)

Quote:

---

Originally Posted by Chilly Willy

Well, PSX was ubiquitous where I came from for standing for the first Playstation. When Sony came out with a "PSX" based on the PS2, that caused a LOT of confusion, with Sony justifiying it by saying THEY had never used PSX for the PS1. I suppose I ought to start using PS1 more often instead of PSX.

N64 is pretty much all you'll see in the US. I liked Ultra64, but Nintendo couldn't get the rights to the name in the US, so it never used it here. I normally use GC, but NGC is fine, too.

---

Same here. I distinctly remember the original PlayStation being referred to as the PSX. Way before the PS2 came out. I figured it was an internal name that devs and the such used, but Sony is lame creating that confusion with releasing the official PSX as something different - later on. I continue to use PSX naming scheme for the original PS; screw the uptight/anal collectors :P

Well I wonder what went wrong with the real PSX, I think a 250 GB hard drive, was a little too advanced for 2003.

With that mess of a discussion going on in the "Amount of consoles sold worldwide" thread, I thought I'd move that N64 tech tangent over here, given there's a few details that I don't think have been really addressed already.

I ended up summarizing a lot of the subject here:
http://www.sega-16.com/forum/showthr...l=1#post610149

Here's the more relevant part of that post:

Quote:

---

Again, some of these details are guesswork, as I don't have actual benchmarks/tests (or detailed specs) for, but given the general system bandwidth and typical GPU designs of the time, it's pretty likely that perspective correction was "free" (as in little/no impact on fillrate) while bilinear filtering probably slowed things down a fair extent (and consumed much more bandwidth), while things like Z-buffering and alpha blending would be more unclear.

In fact the only remotely definitive information on what "polygon accuracy" refers to is in regards to the default T&L mechanism used for "fast3D," ie the 3D geometric transoformation processing along with the light-sourcing compuation and logic handled by the Vector unit and RSP, which has absolutely NOTHING to do with the sort of detail feature issues you've been mentioning in terms of "accuracy." (it very well may have been an issue with T&L computation being done at excessively high precision on the RSP+VU -and not even an RDP triangle-set-up or fillrate related bottleneck at all)
--If the T&L overhead was really the main bottleneck across the board, and the RDP is indeed quite fast for most/all features (more like the Voodoo), that's even more ridiculous and implies that there'd be no reason to drop features like texture interpolation or such, and still have a huge fillrate advantage over the PSX or Saturn. (but in actuality, there was probably at least SOME added overhead and hit to fillrate and bus bandwidth needed for doing filtering, Z-buffering, and certainly apha blending -and Z-buffering uses more RAM too)


Oh, and on another note, I should say a couple more things on the programming interface:

1. The API itself was pretty good, powerful, and flexible (and OpenGL-like), and many of the fillrate cripling features could be disabled or enabled as desired (though things like dithering were either forced in 16-bit mode or only adjustable per-frame not per-polygon -like all GPUs using that).

2. It was more the "driver" end of things rather than the API itself that was the problem, meaning certain features were not programmable as such and were done in inefficient ways. And since custom drivers (let alone APIs or direct low-level programming) wern't possible or practical to do for the most part, most developers were "stuck" with the in-house drivers as such. (and completely at the mercy of any updates/changes/improvements at SGI/Nintendo discretion)

3. the combination of driver/microcode performance and programmability issues and the use of carts meant that, even of the existing "performance boosting" possibilities, there were too many other bottlenecks to make it worth bothering in many cases. ie, if fillrate wasn't going to be a huge bottleneck, than using lower quality texture rendering (or software z-sorting) wouldn't make much difference. Plus, even with the polygon budget and texture rendering issues addressed, ROM space issues would tend to force lower res textures too, making unfiltered textures not worth the trade-offs of fillrate. (albeit you'd at least have more potential for games using a limited variety of much higher quality textures)

---

The whole "accuracy" thing came up in the typically vague context it's been applied to on the N64 (particularly in reference to the slow original "Fast 3D" and later "Turbo 3D" RSP code).

Ablackfalcon seems fixated on the idea that "less accurate" is totally implying "lower detail graphical features" (as in less/no AA, bilinear filtering, perspective correction, z-buffering, etc), and in all seriousness I used to think that was a big part of the context of "fast" vs "turbo" microcode too . . . albeit the whole thing seemed vague and had little specific information attached to it. (and the "accuracy" thing seemed odd)

With more reflection on the general issue (and the knowledge I have now compared to several years back), the "accuracy" comments seem very likely to be do with precision and not accuracy, and directly related to geometry transformation and lighting computation and logical operations performed by the RSP and vector unit, and nothing to do with the RDP's rendering modes, features, or fillrate. (albeit RSP microcode should have some impact on RDP functionality, since the RSP is used as the controller for the RDP in standard N64 programming . . . so changing the RSP code is about as imporatant as changing the driver for a PC CPU in that sense) And the "too accurate" thing for "fast 3D" very well may be a poor translation of "excessively high precision" for T&L calculations. (if fast 3D is doing double-precision floating point stuff, that would be a huge performance killer right there)


Furthermore, the big deal between "fast" and "turbo" microcode on the N64 is listed as polygon throughput, and the main (hard) limits on that would be vertex performance (geometry transformation) and actual triangle-set-up and rasterization performance on the RDP. (and the latter would be largely fixed, but the former would heavily depend on RSP+VU programming)
Disabling RDP effects to improve fillrate could indeed impact real-world polygon rates, but it wouldn't have an impact on theoretical peak throughput as those sort of specs usually relate to. (and the 100,000 polygon thing really does seem REALLY low in that context, and the massive boost turbo gave would make sense in a double vs single precision floating point situation -especially for SIMD/vector performance)




Hell, "fast 3D" might not even be that limiting in terms of "forced" features or fillrate options . . . though with those sort of vertex bottlenecks there's little incentive to make trade-offs to boost fillrate. :p
Though things like the limited texture resolution per-polygon and not ability to program tiled texture mapping for higher res textures per-polygon, or uncached texture mapping in general for the same purpose may have been forced due to RSP code . . . that and the general drivers used for the standard API.
Granted, with a higher polygon budget you could afford to tile textures in 3D too -use polygon fans to composite segmented textures- though you might run into problems with texture seam artifacts, especially since we're talking filtered textures -and filtering/blending ends at polygon edges . . . while nearest-neighbor rendering would largely avoid obvious seams of that sort. (heh, also ironic that on the likes of the PSX -or software renderers- that sort of texture/polygon subdivision is useful for perspective correction reasons too ;))