Robustness in hardware design

[marurun]

I think a lot about the design decisions made for console hardware. What features are sacrificed for cost? How do hardware designers get optimal performance with limited options?

I'd like to talk briefly (edit: apparently not-so briefly) about a couple consoles I think were extremely robust hardware designs and a couple that I think were not.

The first is the Neo Geo. The Neo Geo doesn't suffer some of the cost/performance issues other systems have. It wasn't the most powerful arcade hardware released at the time, but it certainly was the most expensive and powerful home hardware.

The design of the system was designed to be basic but powerful. It has a strong color palette, but most importantly it does away with background tiles. The display system can push TONS of sprites, but that's all it can do. By dispensing with background tiles and layers and simply beefing up the sprite engine, the system is relatively efficient with its power. The only drawback is that the CPU had to be quite beefy to coordinate everything. The only real complicated aspect of the Neo Geo is the audio hardware. Rather than having general purpose audio channels that are flexible in function, the Neo Geo has several different audio channels of different types with different capabilities. Digitized sound effects can only go to certain channels, and the quality and format of the sound determines which ones, for example. That said, the system has more than enough audio channels to go around, so making things sound good was merely a matter of being flexible as a composer.

The system has excellent system memory and the ability to address large cartridges, ensuring the system would be able to compete with CD-based systems. The Neo Geo's core design guaranteed it would remain in use, even as its popularity waned.

The PC Engine is another robust design that's under-appreciated. This system is much more bound by cost/performance tradeoffs and the tech of the time than some that came later. Still, it's my opinion that the designers struck a good balance.

The PC Engine is essentially the younger brother to the Famicom by another mother. It uses a then already traditional sprite and tile setup. While it can only display up to 64 sprites on a screen, the same number as the Famicom, flexibility in sprite sizes is what made the difference. The PC Engine can display sprites of up to 32x64 pixels, which is larger than most player characters in Famicom games. The PC Engine's only major sprite weakness is that the minimum size is 16 x 16. The Famicom, meanwhile, can use only 8 x 8 and 8 x 16 sprites. It has to use 8 sprites to generate a 32x64 character. This means that the Famicom uses up sprites quickly. The PC Engine can tailor sprite use to maximize the 64-sprite budget. Further, the PC Engine features great color use, using large palettes and many of them. The only real limitation here is that the system palette is relatively small, at 512 colors (equal to the Mega Drive).

The PC Engine features 6 audio channels to the Famicom's 5. Whereas the Famicom's channels are all very specific (2 square waves, 1 triangle wave, etc...), the PC Engine's are fully programmable. You can use a custom waveform and custom mask over the waveform in any channel. Some of the channels have auxiliary functions which are channel-specific, including handling digital samples, but the flexibility of all 6 channels means that you don't lose a specific type of waveform for using one of those functions.

Some see the choice of an 8-bit CPU as a major drawback, but really it made sense. So many home developers cut their teeth on the Famicom's CPU that Hudson capitalized on that familiarity by using a CPU in the same family, but much faster and more capable. One need only look at the lack of slowdown on many intense shooter titles to see that the CPU is more than capable at handling the collision detection routines necessary to juggle all its system sprites, even while driving the audio engine at the same time. And let's be honest, collision detection is really what typically taxed CPUs back then. One need only look at early Super Famicom titles and the slowdown they suffer to see how important the CPU is to that particular task. Slowdown in a game is completely CPU-bound.

Among cost-cutting decisions are limited system RAM and a singular tile layer (no multiplane backgrounds). Still, the hardware design is such that only one cartridge title ever needed a mapper (Street Fighter II') and the system is highly expandable. The design decisions later competitors of the same generation had to make were very different. Despite this, the PC Engine remained competitive, featuring CD add-ons and RAM expansions that succeeded in the market. Later manufacturers largely failed with console add-ons and expansions.

So if the Neo Geo and PC Engine are robust designs. What systems hamstring themselves with their designs? Keep in mind that when talking about design, popularity is not important.

The Sega Saturn was a system of compromises. Sega originally set out to make a 2D powerhouse with some 3D capabilities. The problem is that the Playstation's focus on 3D scared Sega. Sega was sure they'd lose the market outright if they didn't do something. So they bolted on an extra CPU. The end result was a design that was expensive and complicated to develop for. The system sold very well in Japan and produced some great titles, but the best titles tended to be 2D, sticking to the strengths of the system. While the Saturn did ultimately have some memorable and boundary-pushing 3D games (Panzer Dragoon- all of them, Grandia, Virtua Fighter 2, Shining Force 3, etc...), this was despite the hardware design decisions, and rarely because of them.

The Saturn is a two-CPU design. However, the CPUs share memory and memory bandwidth, putting a choke around them. It takes extremely good programming design to maximize both CPUs. The only wins the Saturn takes in 3D games over 3D Playstation games are where particular hardware quirks, such as the quadrilateral rendering model (vs the Playstation's more standard triangle rendering model) or a well-designed multi-CPU title, specifically enable critical graphical or design decisions. The Saturn did much better in 2D titles, naturally, but that's because the system was designed to excel in that area from step 1.

On the audio side the Saturn has a fantastically powerful and flexible engine, with one major drawback: lack of support for audio compression. This means that sound effects and music samples must all fit within the audio RAM. Fortunately, the audio CPU is easily powerful enough to decompressed streamed audio for music and continuous play audio, but this was a major oversight, even then. This singular design decision handed occasional audio wins to the Playstation, despite its largely inferior audio design.

The Super Famicom, despite its incredible popularity, is a problematic design. The CPU was chosen for backwards compatibility with 8-bit code, yet few if any games utilize this. Further, the CPU design doesn't jibe with industry trends at the time. 16-bit code in arcade titles was largely designed for Motorola's M68000 series CPUs. Nintendo, by choosing to use a 6502-based design, basically shot themselves in the foot. The M68000 featured in the Mega Drive is much better with 16-bit code and advanced operators. Super Famicom games are notorious for slowdown, especially in early titles. The Super Famicom can push lots of sprites around on screen, but the CPU is hard-pressed to keep up with the collision routines, despite not having to split its attention on audio processing.

The Super Famicom's graphics capabilities are generally well-regarded. It can push a lot of sprites around on-screen and display a lot of colors, but there are problems behind the curtain. The SFC can only display two sprite sizes on screen at a time. This means game designers had to be very careful. Do you choose a really small and really large size and just make medium sized objects out of lots of little bits? Or do you just decide that none of your sprite objects will be small (or if they are, they will waste a lot of sprite pixels)? The SFC has a lot of sprites it can waste if it needs to, but just like the PCE and the MD, it can't put more sprite pixels on a scanline than its horizontal resolution. The SFC has a very large system palette of ~32,000 colors. That's great! But you have to choose between different graphics modes that affect your palette options. Further, while the SNES has a high-resolution mode (that was rarely used), it doesn't support the most popular arcade resolution of 320 x 240, a resolution supported by both its competitors (the PCE and the MD).

SFC audio is also highly lauded, as it should be. The audio engine is a complex system with an 8-bit CPU at the helm, a DSP, and some additional effects. Further, it is a sample-based system rather than being waveform-based, much like the Amiga MOD format. This results in some fantastic audio capabilities. However, the audio system is shy on memory. The disadvantage of sample-based audio is that the quality of the audio is highly dependent upon sample quality. The SFC doesn't have enough audio RAM to store lots of high-quality samples, so it often does lots of filtering and effects to cover up low sample quality. In some games this works very well. Audio often sounds like it's underwater or in an echo chamber, and for some games that's great. But other games suffer as a result. Why does an open, sunlit vista have audio that sounds like it's coming out of a metal bucket? Because otherwise you'll notice that the samples are low quality.

The Super Famicom is thus a system defined by capabilities that are "awesome, but..." For every advantage there is a caveat or drawback. Early games are impressive due to use of special effects, but once the Mode 7 craze subsided, developers had to put in a lot of effort to make good use of the hardware. Coming off the success of the Famicom, the SFC couldn't have failed in Nintendo's golden hands, but the SFC succeeded just as much in spite of its design as because of it.

Without going into detail, here's where I think some other systems fall:

Robust designs-
Playstation (serious cost/performance compromises that resulted in a system that was fast and effective despite its flaws)
Dreamcast (best cost/performance balance I've ever seen; I think this system is the best example available of "just right")
Sega Mega Drive (design flaws all balanced by excellent and forward-looking design wins; great example of incorporating backwards compatibility into hardware design in a way that is complementary rather than redundant)
GameCube (interesting extension of some of the Dreamcast's design wins mixed with lessons learned from the N64)
Gameboy Advance (another great example of incorporating backwards compatibility into hardware design in a way that is complementary rather than redundant)

Compromised designs-
N64 (acceptable base hardware hamstrung by memory limitations at every turn)
Playstation 2 (tiny system memory with a fat data bus to compensate, only the fat data bus is connected to SLOW optical media; highly programmable emotion engine hamstrung by the lack of simplicity and built-in functionality; redundant backwards compatibility)
Playstation 3 (Playstation 2 all over again, with only the lesson on low memory learned)

[ApolloBoy]

I'm surprised you didn't even factor build quality into this. For example, the AES has fairly thin plastic which shatters easily and a low quality PCB despite being a powerful system. Most of the other systems you brought up are solidly built though.

[marurun]

I'm surprised you didn't even factor build quality into this. For example, the AES has fairly thin plastic which shatters easily and a low quality PCB despite being a powerful system. Most of the other systems you brought up are solidly built though.

Well, I think of build quality as a slightly different issue. While it is a cost/performance tradeoff, at the same time, it's something that can be changed later with no effect on past or future games. You can redesign a case and it'll still play the same titles, for example. Besides, I don't find that aspect of hardware design nearly as fascinating : )

[BoneSnapDeez]

I'm surprised you didn't even factor build quality into this. For example, the AES has fairly thin plastic which shatters easily and a low quality PCB despite being a powerful system. Most of the other systems you brought up are solidly built though.

Yeah when I got an AES I was shocked to see how crappy the plastic was. I expected more from a system that used to retail at $600.

I find cheap brittle plastic irksome. I love how heavy and tough systems like the SNES and Saturn are.

[Ziggy]

I only just skimmed your post (I'll read it entirely when I get the chance) but didn't see any mention of SFC co-processors. The SFC CPU was old and slow, yes, but the console was designed with the ability to use co-processors. It was a good plan. You can keep the cost of the system down, but you can gain extra CPU power when you need it and ONLY when you need it.

Just look at Super Mario RPG, which uses the SA-1 co-processor. Wiki says the SA-1 doesn't work as a slave to the SFC's CPU, both CPUs can interrupt each other. So it's an awesome dual CPU design, which is probably more powerful than if Nintendo put a better CPU in the SFC back in 1991.

The DSP-1 in Super Mario Kart and DSP-4 in Top Gear 3000 are another good example of co-processors. The DSP-1 gave Mario Kart the ability to run without any slowdown.

I guess the original revisions of the GSU (aka Super FX) in Star Fox would be a bad example since that game can have slowdown issues when too many things are on screen. But later revisions, the GSU-2, allowed Yoshi's Island to have huge massive sprites for bosses, and that game runs pretty smoothly IIRC.

The SA-1 and S-DD1, aside from their obvious functions, allowed 16-bit ROMs to be used with the SFC's 8-bit data bus. They also had built in region lockout, which left out the need for a stand alone region lockout IC. More components means more money, so to help off set the cost of a co-processor, not needing a lockout chip helps. Pretty much every SFC co-processor has minor capabilities aside from their main attractions.

[Omerta]

The advancement of technology has brought to light some interesting points to consider during the engineering stage of console development that have never had to be considered before to stay with the competition.

Take for example, the prevalence of downloadable media. It's cheap to maintain, there's no physical shipping costs/logistics, and quite a bit of the games are past hits and the IPs are already owned by the hardware manufacturers thus cutting licensing and development costs.

It now becomes a viable strategy to pack newer consoles way heavier with features than one can reasonably expect for the price tag because the manufacturer is willing to take a loss on hardware to get their platforms into homes of consumers. Games, be they physical or digital, are intended to become the money maker on the other end so people don't have to pay PC prices to get their hands on the hardware.

[marurun]

I only just skimmed your post (I'll read it entirely when I get the chance) but didn't see any mention of SFC co-processors. The SFC CPU was old and slow, yes, but the console was designed with the ability to use co-processors. It was a good plan. You can keep the cost of the system down, but you can gain extra CPU power when you need it and ONLY when you need it.

I'm not sure those were intended as a part of the original design. I think they were a great way of getting around the inherent shortcomings of the original design, but I don't think they chose that CPU because the knew they were going to offload later. Besides, co-processors are not unique to the SNES. You could argue that systems that need that help more are more likely to get it later in the system's life. There's at least one Sega Mega Drive cart that also uses a co-processor. The PC Engine was certainly capable of using one, even though it never did. And the Famicom featured lots of extra hardware in the form of various mappers over the years. You could argue the CD-ROM and memory expansions for the PC Engine served the same purpose, to ameliorate what become a deficiency in system design. However, the SFC's CPU was an immediate liability, and other systems' shortcoming took longer to tease out.

The PC Engine, at least, was released with an expansion almost immediately after hitting the market, for save memory. They made a conscious decision to market expansions from day one. The CD-ROM was apparently planned before the base system was actually released to market.

And Omerta, Nintendo, Sega, and NEC all controlled game licensing even back then, so they sometimes sold, if not at a loss, at break-even, because they could make back the costs through licensing and manufacturing of the actual game cartridges, a service for which they charged other companies.

[Ziggy]

I'm not sure those were intended as a part of the original design. I think they were a great way of getting around the inherent shortcomings of the original design, but I don't think they chose that CPU because the knew they were going to offload later.

No, I'm pretty sure it was fully intended from the start. Look at the SFC's cart slot. There's 62 pins total, but the standard cart only used 46 pins. The outer pins (8 on each side of the cart slot) allow for a few things. One or more of those "extra" pins will link a cart's co-processor directly to the SFC's CPU. So while some co-processors (like the DSP) didn't need this, I believe that others (like the SA-1, S-DD1, Cx4, etc) wouldn't be possible without it. Just looking at the way the cart slot was designed, it's sort of obvious that it was an idea from the start. Otherwise, Nintendo would just be STUPID for putting such a slow CPU in their console.

[marurun]

Just looking at the way the cart slot was designed, it's sort of obvious that it was an idea from the start. Otherwise, Nintendo would just be STUPID for putting such a slow CPU in their console.

I could get on board that Nintendo expected to have to bolster the system as it got on in years and therefore built the cart slot out to easily accommodate that. They certainly had experience with the original Famicom pulling stuff like that. Even with that, I think they were stupid for putting such a slow CPU in their console. That extra hardware raises the cost of cartridges and lowers profit. They wouldn't want to go that route unless they had to. I can't imagine the CPU they chose was any cheaper in bulk than a faster one would have been, especially since that CPU core was not widely used.

I don't think hardware robustness really has as much to do with console market success. The PS2 and PS3 both succeeded despite messy hardware, and the Dreamcast and Gamecube both stumbled despite robust, powerful, and easy-to-develop-for hardware. In fact, I'd argue that hardware design seems, at least in part, to be relatively independent from console success. There are winners and loses at hardware design in both the market winners and market losers columns.

[Ziggy]

In fact, I'd argue that hardware design seems, at least in part, to be relatively independent from console success. There are winners and loses at hardware design in both the market winners and market losers columns.

But it's a whole can of worms if you really get into it. Console X was a "market loser" but each console was sold at a profit. Console Y was a "market winner" but sold at a lost. Then to further complicate things, Console X has little to know first party software, while Console Y had major first party software. Who really won?

That extra hardware raises the cost of cartridges and lowers profit. They wouldn't want to go that route unless they had to.

But that's exactly the point. The extra hardware raises the cost of production... but only on carts that need them! There's something like 800 SFC games, but only about 50 or 60 games with enhancement chips. And I'm sure the extra cost was no concern at all for massive blockbuster first party games (Star Fox, Super Mario RPG, Yoshi's Island, Super Mario Kart).

And out of the rest of the library, how many games really have a problem with slowdown? I know some early games had slowdown when too many sprites were on the screen (SMW) or that plus mode 7 going on (one level in Castlevania 4) but it's not even that big of a deal. So I'd have to say as a whole, Nintendo's decision to go with a slower CPU didn't negatively effect the console. It was a smart idea, and kinda risky, but it payed off.