nesdev.org

Well, in my minor absence, I may not have been working on anything for the SNES or the M92 (I'd really like to buy one first and there's no indication prices are going down) but have actually been poking around at the Wii U because I thought I would try to make a hack for Splatoon to increase the number of weapon slots, which involved me opening up the actual code file in IDAPro and finding the internal weapon names. Anyway, I actually got in contact with what was one of the big data miners of the game and as a bit of a reference, they showed me this, which details what the chips are and how the system is laid out https://fail0verflow.com/blog/2014/cons ... 013-omake/

I never realized just how much of a Frankenstein creation the Wii U is; Nintendo really went through great lengths for backwards compatibility, emulating in both hardware and software, and either in full or in partial depending on what they could get away with. The CPU is actually just three overclocked GameCube/Wii ones, which are completely identical except two have a 512KB L2 cache, and one has a 2MB L2 cache (who knows why they didn't just divide it evenly). Unlike the DS that could do away with some of the original GameBoy hardware, the Wii U actually uses everything the GameCube/Wii had in native mode, meaning a theoretical, backwards compatible Wii U successor would be a total clusterfuck of hardware and would actually still be compatible with the GameCube.

To be fair, the GameCube architecture was a really good one for the time and punched above its weight, while still being easy to program for.

The exact opposite of the Nintendo 64, which was not programmer-friendly (though not as bad as the Saturn) and regularly hosted games that looked worse than similar titles on a system with a third of the power and half the RAM (the PlayStation). I still can't get over the fact that the RCP's blender didn't clamp its output despite being capable of additive transparency - if I could go back in time and give the design team some hindsight, I'd probably get that out of the way first...

Espozo wrote:The CPU is actually just three overclocked GameCube/Wii ones, which are completely identical except two have a 512KB L2 cache, and one has a 2MB L2 cache (who knows why they didn't just divide it evenly).

As a way of explaining by comparison, the PS3 had 1 "big" main CPU and 7 "smalll" SPU units. (Why didn't they just divide this evenly? Why is so much power concentrated in one CPU?)

The default way of thinking about programs is single threaded, and having to write a program that divides work into separate parallelizable workloads is an additional design problem, and even if you can do this, you will still very likely have a "main" thread that probably needs the majority of resources. Similarly it makes some sense to have a "main" CPU to run this on. There's nothing unusual about this.

Symmetry can be useful, but isn't necessarily a useful property, and your typical parallelizable game workload probably does not split into 3 equal parts. (Plus they probably had any number of other design constraints that neither of us can speculate about that could have made a bigger cache for one CPU cost effective.)

A converse way of putting this: why didn't the SNES have a second 65C816 with 128k RAM to run the sound instead of the SPC? Wouldn't it have been better to have another CPU that was exactly the same instead?


(The Xbox 360 did in fact have a 3 core PowerPC where all were identical, and you probably could find some arcade machine that uses 2 of the same CPU with one handling music. The more symmetrical cases do exist, I'm just advocating that it's not a given that it's an advantage. The relevant problems for games aren't symmetrical, like they are for e.g. bitcoin mining.)

From the featured article:

This blog post is a follow-up to the talk and contains clarifications, corrections, and material that we couldn’t fit in the one-hour time slot.

If you haven’t yet, please watch the talk before reading the rest of this post:

I feel frustrated lately that so many publishers expect readers to sit through a long video, neglecting or even refusing to provide a transcript in text form that users can read at their own pace even if they have a hearing or attention disability.

rainwarrior wrote:A converse way of putting this: why didn't the SNES have a second 65C816 with 128k RAM to run the sound instead of the SPC? Wouldn't it have been better to have another CPU that was exactly the same instead?

My first guess is to reduce the royalty obligation to WDC under the then-new exclusive rights in mask works. It could also be for the same reason that opcodes in the SPC700 are reordered compared to those of the 65C02 that it largely reimplements. Consider that after using Z80 in its Radar Scope-derived arcade platform, Nintendo had gone with the 6502 for its previous console in part* because of its unfamiliarity in Japan.


* Also because of smaller die size and indexing that isn't dog slow.

93143 wrote:To be fair, the GameCube architecture was a really good one for the time and punched above its weight, while still being easy to program for.

The exact opposite of the Nintendo 64, which was not programmer-friendly (though not as bad as the Saturn) and regularly hosted games that looked worse than similar titles on a system with a third of the power and half the RAM (the PlayStation). I still can't get over the fact that the RCP's blender didn't clamp its output despite being capable of additive transparency - if I could go back in time and give the design team some hindsight, I'd probably get that out of the way first...

A Kutaragi console "programmer friendly" ??? Ps1 games better looking than a N64 game???
I mean the PS1 is probably the most 2nd most sane thing Kutaragi made, but they did try and hide it under a library for a few years...

tepples wrote:

rainwarrior wrote:A converse way of putting this: why didn't the SNES have a second 65C816 with 128k RAM to run the sound instead of the SPC? Wouldn't it have been better to have another CPU that was exactly the same instead?

My first guess is to reduce the royalty obligation to WDC under the then-new exclusive rights in mask works. It could also be for the same reason that opcodes in the SPC700 are reordered compared to those of the 65C02 that it largely reimplements. Consider that after using Z80 in its Radar Scope-derived arcade platform, Nintendo had gone with the 6502 for its previous console in part* because of its unfamiliarity in Japan.

I think there are some more obvious reasons for the SPC than this, but it was a rhetorical question. I was trying to show to Espozo that he would not have asked this question of SNES, because in that case there is obvious asymmetry between the tasks. There's just as much asymmetry between multithreading tasks in a modern game, though, even if that isn't quite so obvious.

tepples wrote:I feel frustrated lately that so many publishers expect readers to sit through a long video, neglecting or even refusing to provide a transcript in text form that users can read at their own pace even if they have a hearing or attention disability.

I quite agree with this.

tepples wrote:I feel frustrated lately that so many publishers expect readers to sit through a long video, neglecting or even refusing to provide a transcript in text form that users can read at their own pace even if they have a hearing or attention disability.

Or a rural internet connection.

On topic, it's nice to see Nintendo cared enough about backwards compatibility to go the extra mile here. Too bad the console didn't get more (any?) good games. Feels like a shame that it flopped.

Oziphantom wrote:A Kutaragi console "programmer friendly" ???

I was under the impression that it was easier than the N64, of which it has been said "it was an easy machine to screw yourself and [get] very poor performance on". And then there was the difficulty associated with programming the RCP microcode for developers who were allowed to do so - apparently critical bugs were easy to generate and hard to find. The memory architecture and RAM latency caused issues, and it was only later in the system's life that Rare managed to figure out how to stream textures through the texture cache (something I think the PlayStation did automatically - it might have been part of the SDK, but the upshot is the same).

I haven't programmed either one, so this is all hearsay.

Ps1 games better looking than a N64 game???

Compare Carmageddon 64 with Gran Turismo 2 (or Twisted Metal 4 for that matter). Or Hexen on N64 with Quake II on PSX. Both game libraries exhibited a wide range of graphical quality, but there was a surprising amount of overlap considering the difference in power.

The comparison can depend somewhat on taste (and on brand loyalty), particularly when weighing "BlurOVision" against jiggly jaggies. But for a couple of reasons PlayStation games tended to have (or look like they had) higher-resolution textures, the console had proper support for clamped additive transparency (Body Harvest is the poster child for why this is a good idea), and I get the impression that it was easier to maintain a high fill rate. The ability to use large quantities of reasonably high-quality full-motion video and prerendered backdrops was an obvious advantage, though nowadays we don't care as much. Also, I believe some highly-regarded games, like Metal Gear Solid and Crash Bandicoot, deliberately limited their environments and/or onscreen perspective in order to jack up the quality of what you were allowed to see (I believe Crash in particular used prebaked triangle ordering; note that one of the most frequently cited ways to improve the N64's fill rate was to turn off the Z-buffer).

Rahsennor wrote:Too bad the console didn't get more (any?) good games.

There were a bunch of highly regarded Wii U games. People who actually had one tend to agree that it had a great library. Some of the popular ones:

Splatoon
Smash 4
Captain Toad
NSMBU
SM3DW
Super Mario Maker
Wonderful 101
ZombiU
DKC Tropical Freeze
Nintendo Land
Tokyo Mirage Sessions
Lego City Undercover
Rayman Legends
Yoshi's Woolly World
Hyrule Warriors
Paper Mario Color Splash (seems to have gotten a bad rap for no good reason)
Star Fox Zero (it seems like either you get it or you don't)
New Super Luigi U
Mario Kart 8
Bayonetta 2
Pikmin 3
Xenoblade Chronicles X
Breath of the Wild

That's excluding ports, multiplats (mostly), and indies, and there were good games in all three of those categories.

93143 wrote:Kirby's Epic Yarn

Do you mean Woolly World? KEY was original Wii.

There was Kirby and the Rainbow Curse, but I would definitely not put it on a list of good Wii U games. There were many very good Wii U games, though.

The top few for me were: Mario 3D World, Splatoon, Mario Maker, Breath of the Wild, Mario Kart 8. (I suspect Bayonetta 2 will go on there once I finally play it.) I had a good time with several others on the list above.

The most interesting VC release was Earthbound Beginnings, since it's the only legally available version of that game in this market. Probably not important unless you're an Earthbound fan, though. (I am.)

lidnariq wrote:Do you mean Woolly World? KEY was original Wii.

Yeah, that was an error. Fixed.

rainwarrior wrote:There was Kirby and the Rainbow Curse, but I would definitely not put it on a list of good Wii U games.

Some people would. I haven't played it.

third of the power

Probably less than a third, PSX's cpu was way older than N64's, so likely much worse clock for clock.

Hexen n64 vs Q2 psx

Isn't that a question of style? Q2 is more realistic with 3d models, Hexen is cartoony with sprites.

93143 wrote:texture cache (something I think the PlayStation did automatically - it might have been part of the SDK, but the upshot is the same).

I'm pretty sure that on PSX only the 1 MB VRAM was visible to the programmer, and the texture cache was automatically managed in hardware. I don't think the SDK was involved with it in any way.

Then again maybe it's misleading to call the N64 texture memory a "texture cache" in the first place. The official developer documentation calls it simply texture memory (TMEM).

93143 wrote:To be fair, the GameCube architecture was a really good one for the time and punched above its weight, while still being easy to program for.

It produced similar graphics as the Xbox while costing a whole $100 less. (Of course, it didn't have a hard drive and some other stuff.)

93143 wrote:The exact opposite of the Nintendo 64, which was not programmer-friendly (though not as bad as the Saturn) and regularly hosted games that looked worse than similar titles on a system with a third of the power and half the RAM (the PlayStation).

I'm not sure about worse, but the N64 is definitely one of the most misused consoles ever. Jaguar easily takes the crown though.

rainwarrior wrote:A converse way of putting this: why didn't the SNES have a second 65C816 with 128k RAM to run the sound instead of the SPC? Wouldn't it have been better to have another CPU that was exactly the same instead?

Probably not the best example, because that would actually be a huge benefit. On top of having twice the memory, you could just DMA in new samples, assuming the 65816 has a DMA unit like in the 5A22, and even still, it would be faster at a handshake loop.

rainwarrior wrote:Symmetry can be useful, but isn't necessarily a useful property, and your typical parallelizable game workload probably does not split into 3 equal parts. (Plus they probably had any number of other design constraints that neither of us can speculate about that could have made a bigger cache for one CPU cost effective.)

I know, but I find it a bit bizzare that they all run at the exact same speed then. I don't know how well the heat will be dissipated though. How are multicore processors even "connected"? They all share the same data bus, so there's got to be some sort of memory controller. Would ram be in the same address space as cache?

rainwarrior wrote:The Xbox 360 did in fact have a 3 core PowerPC where all were identical

How would you say it stacks up to the three PPC750 cores in the Wii U? It's got to be a more modern microarchitecture, but it's probably doesn't run at the same clockspeed because it was probably built using a process bigger than 45nm. I wonder how much faster you could get the PPC750 to be using the 20nm process; a core in the Wii U runs at about 2.5x the speed of the speed of the 180nm one in the GameCube. A theoretical Wii U successor would probably just have to have a ton more of PPC750 cores (or possibly something else on top of the Wii U's 3) to be a significant improvement.

93143 wrote:The comparison can depend somewhat on taste (and on brand loyalty), particularly when weighing "BlurOVision" against jiggly jaggies.

The lack of perspective correction is 10x more offensive than nearest neighbor scalling, in my opinion.

93143 wrote:There were a bunch of highly regarded Wii U games. People who actually had one tend to agree that it had a great library. Some of the popular ones:

Splatoon was enough to sell it for me. The Switch getting virtually every Wii U game should show that it had a good library. It's funny how big of a flop the Wii U was and how big of a success the Switch is considering they have 90% of the same game library. The Xbox One vs the PlayStation 4 shows just how important initial impressions are.

rainwarrior wrote:There was Kirby and the Rainbow Curse, but I would definitely not put it on a list of good Wii U games.

Which is why it's not on the Switch. I always wanted to see a sequel to Kirby and the Canvas Curse, but was more than dissapointed when I saw what we got.

93143 wrote:There were a bunch of highly regarded Wii U games. People who actually had one tend to agree that it had a great library. Some of the popular ones:

Splatoon
Smash 4
Captain Toad
NSMBU
SM3DW
Super Mario Maker
Wonderful 101
ZombiU
DKC Tropical Freeze
Nintendo Land
Tokyo Mirage Sessions
Lego City Undercover
Rayman Legends
Yoshi's Woolly World
Hyrule Warriors
Paper Mario Color Splash (seems to have gotten a bad rap for no good reason)
Star Fox Zero (it seems like either you get it or you don't)
New Super Luigi U
Mario Kart 8
Bayonetta 2
Pikmin 3
Xenoblade Chronicles X
Breath of the Wild

That's excluding ports, multiplats (mostly), and indies, and there were good games in all three of those categories.

...seriously? Super Mario 3D World is the only one on that list I actually enjoyed. Super Mario Maker is the worst 'game' I've ever played. SSB4, MK8, BotW and XCX all felt watered down compared to their predecessors - they're bigger, but they're still only filled with around the same amount of fun. Hyrule Warriors is just yet another identical Warriors game with Zelda characters painted on. Captain Toad is a cute gimmick. And so on.

Maybe I'm just too old to appreciate them.