You know, this joke-cum-WTF thread has got me thinking about the various trade-offs made by the various console makers of the time. A lot of this is conjecture. I'm not a (good or practicing) programmer, but I do understand programming pretty well. I'm also a hardware junkie. Still, I've made a lot of guesses and assumptions here, and I look forward to being ripped to shreds.
Hudson/NEC based their system on a widespread and effective CPU core design with well-established audio capabilities and a graphics chip designed to push sprites and make pretty colors. It was a much more powerful and effective combination than the hardware used in the NES or Sega Mark III, and yet it was very much a direct evolution of them. The CPU was clocked faster and featured a few extra registers, but it was very similar to the NES in that it used the same 6502 core. The sound capabilities were improved, but again, rather directly evolved from predecessors. The graphics chip displayed many more colors and was more sprite capable, but it was still just sprites and a single background tileset. Though it lacked any accommodations for special effects, each component of the system was significantly more powerful than the individual components of those in systems of the previous generation. Perhaps Hudson's biggest compromise, however, was the dearth of available RAM in the system. RAM was expensive, and thus selecting limited RAM caches for the system was likely a cost decision. It could be argued that the PC Engine was the most basic and simple of the 16-bit generation systems, and it owed its design most closely to that which came immediately before it in the home console and computer space, including the necessity of developers to use optimized code to get good results, especially given the limited program RAM space. Then again, NES developers were used to working with 6502 code and even more limited RAM space, so in a sense, the system was catered to them as a distinct upgrade path. All your pre-existing NES programming skills will transfer, only you have more power, more RAM, more sprites, and more colors! Some early PCE games were clearly the product of developers who saw the PCE as simply a slightly more powerful NES. Good developers learned that the system was quite a bit more powerful, and as a result was more flexible than the NES. This said, the power of the PCE was wholly dependent upon the programmer to tease out, meaning the games library varies widely in quality. It would have been nice to have seem a few extra effects or features added into the hardware mix, but it's hard to complain about a system which is tightly designed and relatively capable. The PCE does what it was designed to do quite well, and only truly suffers in lack of RAM.
Sega seemed to go a different direction. Sega had a lot of arcade experience, and as a result of having a strong library of arcade titles it made sense they'd go more that route. Arcade hardware was often highly customized with varied capabilities. They used a stock CPU that was widespread in arcade boards, the 68k. The CPU isn't necessarily any faster than the one in the PCE as far as raw performance goes, but it's easier to develop for, what with being C friendly, and Sega's own arcade devs were already familiar with it. One can only assume that, even though the 68000 was stock and not a custom chip, that it was still more expensive as it was a more complex design and the core architecture more recent. In PC audio and arcades FM synth was starting to make a splash due to the unique sound, so Sega decided to throw in an FM-capable chipset along with a basic PSG chipset, and even a co-processor to help manage them (which makes one wonder about the troubles the Genesis has playing clear digital sound samples in some circumstances). Sega's arcade bias even showed when designing graphics capabilities. They decided they could get away with fewer colors onscreen (probably to save costs) if they kept the sprite capabilities robust and added hardware for two independent background planes. This did work pretty well, and many Genesis titles look very colorful despite heavy use of dithering and limited color counts. Ultimately programmers were able to more easily produce games that looked, sounded, and as a result behaved differently than on the NES and previous consoles and more like arcade titles as a result of these hardware decisions. There was less need for careful code management and special effects could be substituted for a lack of colors and palette variety. It did mean that some developers were driven to one-up each other via careful coding to produce new special effects, since scrolling and basic sprite effects were relatively easy. Unfortunately, the easy of coding interesting sound and visual effects meant some programming houses were willing to ship shoddy gameplay. Graphically, Genesis games were less varied in quality than PCE games (more games clustered in the middle with fewer spread out at the low end), but in terms of core gameplay there was just as wide a quality spectrum. Sega paired their CPU and other system capabilities fairly effectively. A little greater audio flexibility in regard to digital samples and improved color support are the only gripes to be found.
I'm not sure I completely understand Nintendo's approach to system design when considering the Super Famicom, though I have a few guesses. They took a 16-bit 6502 derived core which had potential (hell, look what the Apple IIGS did with a similar CPU) but then clock-starved it. Rather, they seemed much more interested in graphics and sound capabilities. The sound chip is rather flexible (also has a 6502-based core), allowing for not only very clear digital samples but also some neat DSP effects, like reverb (unfortunately over-used). The graphics chipset has very good color support, strong sprite display capabilities, and background capabilities that vary widely based on the particular mode in which the chipset is driven. They also threw in, again, more special effects. Mode 7 (scaling and rotation) is a combination of effects that can be implemented on a set of background tiles, often artfully used to simulate foreground effects as well. Limited transparency effects can also be applied to background tiles and are often used to great effect in games (but also with weird side-effects, like foreground sprite objects disappearing completely where the transparency effects are taking place). They also packed the system with spacious RAM caches. My best guess here is that they saw what Sega was doing with the specialized hardware on the Genesis and decided that that road had some advantages and tried to one-up them in most regards. But they also likely saw themselves as successors to the Nintendo market and not as much the arcade market, so the graphics capabilities they implemented didn't so closely mimic arcade developments. I think they also weren't seeing much potential in FM synth and opted to focus solely on digital sampling. The SFC has some complicated and sometimes limiting modes of operation, and I don't know if they were the result of attempts to save money in system design or simply unanticipated quirks. Further, the CPU requires rather solid coding skills to get good performance and is not nearly as easy to program for as Sega's CPU choice. In many ways it was even less accommodating than Hudson's choice in the PCE. I can only guess that Nintendo figured with all the flashy effects and clear audio that actual program coding and design would be less important. The end result is a system which, like the Genesis, has a lot of attractive games with various graphical effects and games with clear sound. The easy sound chip resulted in some fantastic sound effects and tunes, but also lead to audio Uncanny Valley problems. PSG and FM sound tend to be very distinct and don't sound much like existing real world instruments, but SFC sampled sound could mimic said instruments closely enough that it was easy to compare to the real thing, and that sometimes led to disappointment, just as computer generated characters that look too much like real people actually create distance and seem creepier and less human than obviously unreal characters. The SFC suffered in some unique ways as a result of its design. It was the home platform for some of the most attractive, best sounding, and overall impressive games of its hardware generation, but it also produced some games which seemed unnecessarily flawed. Many early and middle era games were plagued with exaggerated slowdown as a result of programming code not being up to the same standard set by the easy-to-tap graphics and audio capabilities. This hearkened back to the days of the NES, where intense action scenes were often slowdown plagued, and was a stark contrast to the PCE and Genesis, two consoles which, overall, managed slowdown fairly well. I guess Nintendo wanted to accommodate its loyal NES programmers, but in giving them easy, flexible tools in some areas and not in others it appears that Nintendo confused some of them instead. The SFC is, ultimately, the most paradoxical of the systems, with great video and audio capabilities, lots of RAM space, and a CPU that seems to be poorly paired with the rest of the package. The SFC was a system which rose to the top as a result of the good hardware decisions being enough to simply muscle over the bad. It's like having a quite, smooth-handling car which is better than all the others except that gosh darnit it's really slow to accelerate up to highway speeds. Your music sounds better in this car. The seats are more comfortable. The visibility is better out of the windows. Everything is better until you have to drive up a merge lane that's too short or pass on the left around the camper going 5 mph below the speed limit and the dude tailgating you wants you to get your ass around the camper, NOW! It's a great trip, but you're periodically reminded that bad decisions are keeping this this awesome thing from being perfect.
OK, done. Tired, and done.
