Interesting Wii U hardware overview

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...

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:

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.


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.

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...

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.


I quite agree with this.

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.

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.


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).


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.

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.)

Yeah, that was an error. Fixed.


Some people would. I haven't played it.

Probably less than a third, PSX's cpu was way older than N64's, so likely much worse clock for clock.
Isn't that a question of style? Q2 is more realistic with 3d models, Hexen is cartoony with sprites.

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).

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.)


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


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.


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?


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.


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


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.


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.

...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.

Not even Splatoon?

Full disclosure: I don't own a Wii U, and aside from Smash 4 and a brief sample of Rayman Legends I've never played any of the games on that list. I'm just going by what seems to be the popular consensus.


More power at a lower price, in a machine that lets you own your own games and doesn't act like a telescreen from 1984 even while it's supposedly turned off? The PS4 wasn't even that great, but apparently Microsoft gonna Microsoft...

I've got to admit, I was kinda underwhelmed when I first saw the Wii U. I didn't really want one, and I'm not even sure why. I do want a Switch, and once I have money I may very well act on that desire.


I watched some of a high-quality video of Hexen 64, and then switched to a video of Quake II PSX. I physically felt the relief. Hexen is an ugly game.

Which may make it an unfair comparison. How about Quake on N64?

I haven't actually played Splatoon, to be honest.

I probably should, but it doesn't look like my kind of game (I have lousy reflexes) and I can't play multiplayer out here in the boonies (20 miles from nearest meatspace gamer friends + 300-5000 ping) so I imagine the main drawcard would be lost on me anyway.

Just watched some Colony Wars. I bet you could do it on the N64 (aside from maybe the cutscenes, assuming a period-appropriate ROM size), but you'd need to use special techniques. This game makes very good use of additive transparency, making for an instructive contrast with Star Fox 64, and it looks like there may be some high-res texturing too.

It's definitely possible; there's like, nothing going on in it.

I mean, you'd have to come up with a way of doing additive transparency using the color combiner rather than the blender, which at best is going to cut your fill rate in half for those elements. The video I watched makes it hard to tell, but it kinda looks like true-colour, which would hurt fill rate as well. And if any textures didn't fit in the cache you'd have to use a streaming technique like Rare. But yeah, I think there should be enough spare performance.

If all else failed, you could always just use the Turbo3D approach of (essentially) dropping to PlayStation-level rendering fidelity. The reported performance of ~500,000+ polys per second should give you plenty of headroom, and with antialiasing turned off you wouldn't need to worry about your additive transparency scheme screwing with the coverage bits (I haven't done the math here, but it seems like it might be a danger otherwise).

I mean, it may be inneficient as hell for the Nintendo 64 hardware, but I can't think of a single thing the PlayStation could do that the Nintendo 64 couldn't. You could definitely work around no hardware support for additive transparency in that case, either by layering or software rendering. The N64 has enough performance to make either possible.

Rhythm games.

I seem to remember fewer than a half dozen N64 games were 512 Mbit (Conker's Bad Fur Day, Resident Evil 2, PAL Paper Mario, and one of the Pokémon Stadium games) and none bigger than that. But let's say you do manage to talk your rhythm game's producer into paying for a cartridge that big. If you use 448 Mbit out of 512 Mbit for compressed audio at 64 kbps Opus, you can fit about two hours, enough for maybe 75 DDR-length songs. Can Nintendo 64 even decode Opus audio in real time? Otherwise, your music would need to be sequenced, and I imagine that licensing a multitrack recording in order to reduce it to an accurate tracker file is a bit more involved than licensing a studio master.

It's not. It's the same amount of licensing "work" (i.e. sync license negotiation) but in general cover royalties are lower than those for using a recording.

There is one MIPS target supported and benchmarked by the rockbox project. That shows that Vorbis takes somewhere around 40-50MHz worth of CPU on a MIPS with SIMD instructions.

I'd note that ADPCM might actually provide adequate sound quality given for some sample rates.

I'd expect that the expensive part there is the salary time to convert from stems to sequence data.

Professional music transcription services aren't that expensive, IMO. I'd say it's comparable to translation services for similar amounts of information. (Making a more "musical" arrangement rather than merely transcribing would cost a bit more, but there are probably a lot of people willing to do it for a relatively low price.)

(...but in this hypothetical we could be talking about a non-commercial context where even modest fees are prohibitive.)

I was speaking purely theoretical anyway. If we're dragging in storage limitations, we might as well discuss the increased difficulty in programming for the N64. The PlayStation, theoretically, shouldn't have any advantage over the N64, although I don't know quite enough about the PlayStation hardware to say that decisively.

Long FMVs ;D CD full of data + mjpeg decoder, but storage mainly.

Vorbis has been proven, and I'll get out Opus etc benchmarks eventually, if only for my own curiosity. The GC controller compatibility is interesting too, but it's sad there was no Guitar Hero controller for the Cube (I do have the bongos, and there is a DDR dance mat).

Ha, now that I looked at the DDR list, there *was* a DDR game for the N64, including the dance mat, in Japan:
https://www.n64brasil.com.br/2010/08/ddrddm.html

About additive transparency: I may have been wrong about the fill rate hit.

The basic idea is that while the N64's blender (the thing that combines the pixel pipeline result with the framebuffer) doesn't clamp its output, I'm pretty sure the color combiner (further up the pixel pipeline) does. So clamped addition would need to be performed in the color combiner, meaning you'd need to get the relevant framebuffer data into the texture memory so the color combiner could use it. I've made a couple of realizations since I made my earlier post:

1) I had forgotten that copy mode (which is considerably faster than normal drawing speed) can be used to suck part of the framebuffer into TMEM.

2) I'm not clear on how fine-grained the programmer's control of the rasterizer is. Combining two textures requires two cycles per pixel, so it's possible the rasterizer could be toggled on alternate cycles between an arbitrary transform (to draw the glowy thing) and 1:1 marching (to combine it with the framebuffer texture). If the rasterizer can be used in such a way, you'd be looking at a theoretical fill rate of either 2.25 or 2.5 cycles per pixel depending on framebuffer bit depth, which is not much worse than two-cycle mode if you discount latency overhead. If the rasterizer is not capable of such a thing, it'd be more like 3.5-5 depending on framebuffer bit depth and on the drawing mode used to produce a pre-transformed glowy-thing texture.

It may also be possible to use this scheme without a texture for the glowy thing, by using vertex shading or suchlike. The color combiner is pretty flexible.

...

I have a feeling that the above would break antialiasing if you just added the two textures and dumped them into the framebuffer at full opacity. (My understanding of the N64's antialiasing is not great, but I'm pretty sure the coverage bits would get clobbered.) However, if the framebuffer data could be used to preclamp the glowy thing, instead of trying to generate the final image in the color combiner, you could do the addition with the blender without fear of overflow, and the antialiasing scheme might give you better results. (Or not - the description I'm using of the blender's ADD mode doesn't include a lot of detail.) I think what you could do is use the first color combiner cycle to add the two pixels, and then use the second cycle to subtract the framebuffer pixel from the combined (added/clamped) pixel. This wouldn't even change the fill rate, unless you were trying to use vertex colour addition in one-cycle mode - it would just remove the ability to use that second cycle to combine the pixel with any other colour, unless you can add a third cycle to the drawing pipeline...?

Unfortunately fog doesn't seem like it would be compatible with the blender's add mode, and I can't see it working all that well with the basic CC add scheme either. I'm sure there's something that can be done, even if it's just setting the glowy thing's palette based on distance from the camera...

That arguably had more to do with the RAM inside of the N64 than the architecture of any particular chip like RCP, though.


I don't think this is quite true if you take a truly holistic approach (virtually all games on the PS1 suffer from at least one of its famous 3D defects - and the console was host to plenty of shovelware), though poor N64 emulation over the last 20 years has done no favors to the system's reputation for good graphics (missing lighting effects makes emulated N64 games look really bland).

IMO, the most popular PS1 games tended to be those with the best visuals on the console, while it was not quite the case with the N64, which I also think explains why opinions similar to yours tend to crop up every so often. It's also worth considering the PS1 had a selection of pretty looking 2D games and pre-rendered background games which were aesthetically pleasing, though that had nothing to do with raw system power or ease of programming...but rather the cartridge format and many developers steering clear of the N64's huge royalty fees.


Well the Playstation didn't have half the RAM of the N64. It had 2 MB main RAM, 1 MB VRAM, and 512 KB of sound RAM. That's 3.5 MB total (plus 128 KB CD cache). While N64 had 4 MB unified RAM (though it was a bit bigger than it seems due to having a 9th parity bit for anti-aliasing).

But that's not the real crux of the matter. The two consoles had extremely similar "peak" memory bandwidth. IIRC, the Playstation had 133 MB/s main RAM + 266 MB/s VRAM + 33 MB/s sound RAM for a total of 432 MB/s bandwidth, while the N64 had 500 MB/s bandwidth (+ 62.5 MB/s reserved exclusively for anti-aliasing coverage values along the parity channel).

When you factor in N64-in-its-console-generation-exclusive things like
-bandwidth hungry z-buffer (can be mitigated by using a microcode without a (or reduced) z-buffer - but not always practical to do so because a z-buffer could be a very good thing)
-many additional read-modify-writes for anti-aliasing and post-processing (can obviously be turned off, but then you aren't maximizing use of RCP's pipeline nor using the parity bandwidth!)
-alpha channel in some textures
-texture-cache needing manual refreshing for large textures
-unusually high random-access RAM latency (can be mitigated by very careful programming to avoid random access)
-every component in the console sharing a single RAM channel (bus contention hell unless CPU, RSP, and RDP cache use is absolutely maximized)

Then for all intents and purposes, you are left with less or much less practical memory bandwidth than the PS1. Because of this bad textures were probably caused more by developers decreasing the resolution to lower bandwidth usage more than the size the texture cache's size being the issue (4 KB was not small for a 1996 home GPU texture cache with four interleaves, it was big, though if it were even bigger it would have partially alieved texturing problems). Or decreasing framebuffer resolution making everything blurry (and that's before post-processing...). Or less music fidelity.

I don't know why people spend so much time taking about RCP and microcodes when trying to work out why developing for N64 was difficult, when the answer is so simple: it's the RAM. To make the N64 much easier to program all Nintendo had to do was give the CPU and RCP their own RAM channels, with more total bandwidth. Exclusively talking about RCP being so very fill-limited is IMO even more silly when you consider the memory controller in the N64 is designed to give RCP access priority (this is where the myth about the N64 CPU not having DMA comes from - like having an off-chip memory controller means the CPU has no DMA????) - if anything, poorly optimized N64 games are probably stalling on a RAM starved CPU rather than RCP - so much for 3x the clock speed!

It's pretty ironic that the Saturn was hard to program because the overlap of components was too complex, while the N64 was hard to program because the memory architecture was overly simplistic and (practically) inadequate to the extreme. At the same time, I don't think the Saturn could have ever been better than the PS1 at 3D even with perfect programming (2D is another story) because its hardware is just not that suited to full 3D simulations, while the N64 actually could meet its potential of around 3x or more the power of PS1 3D with a good enough program (arguably Conker's Bad Fur Day and a handful of other top-tier games demonstrate it). People tend to forget that the N64 uses a lot of its processing power to clean up 3D image quality behind the scenes - it's not a straight-up polygon count contest.


I'd say that's because additive blending support was thrown in at the last moment. The designers of RCP probably thought for a long time that having true % alpha-channel blending support was an advanced enough feature to satisfy everyone. Arguably if you had to pick between the two, they made the right choice since an alpha channel allows for much cleaner transparency all-round (though diminished in practice since many N64 developers were too pressed for bandwidth to make good use of it), but it's undeniable that additive blending looks great for explosions and fire effects.

RCP was a good little chip, much like Flipper was. Nothing at home had better "theoretical' (i.e. unbound from RAM) trilinear filtering performance until Voodoo 2, not even the first Voodoo. And RSP's vertex shader like programmability (and the proto-pixel shader color combiner in RDP) was unknowingly ahead of its time. If only Nintendo dedicated enough RAM bandwidth to it so it could fully move its legs.


I think the only sane way to use hardware additive blending on N64 is just where the RGB values in your scene are very low, so you can avoid the glitchy overflow of blending a pixel beyond white. IIRC Doom 64 used a little additive blending, but that game is dark as all hell so they could probably get away with it.

EDIT: The more enterprising developers on N64 got around the lack of easy additive blending just by using an animated texture that has white-ish highlights. Not as good as the real thing, but IMO looked fairly convincing in Ocarina of Time's "how the world was made" cutscenes.

Sorry for continuing the derail of this thread about N64. I'd also be happy to discuss the Gamecube and its hardware-based children

Funnily enough, I find myself asking if the Switch is worth it yet given that I continue to play Mario Kart 8 and Splatoon from time to time, and I still have Breath of the Wild patiently sitting on the shelf ready for the long dark winter months. Thus, the trio of Mario Kart 8 Deluxe, Splatoon 2 and Breath of the Wild on the Switch simply doesn’t feel compelling enough for me to drop my Wii U (yet).

I played the Arms testfire thingummy a while ago, and whilst it was visually impressive, it didn’t do anything for me, especially at a time when Tekken 7 was available. I am more of a 2D fighter fan than a 3D one though.

I’m quite aware that the portability factor is a big deal to most Switch owners however, I have never been one to play games on my daily commute. I only play my 3DS in the comfort of my own home.

Still, when the likes of Mario Odyssey, Metroid Prime 4 and whatever Retro Studios are up to are available, I am pretty sure I shall buy one there and then!

In regards to the OP, however, the answer is a resounding ‘no’. The Wii U isn’t worth it nowaday; even Nintendo have distanced themselves from it.

Yeah, there's no need to get a Switch at this time if you already have a Wii U. I made the mistake of getting one for Splatoon 2 whilst already owning Splatoon for Wii U. Arms fizzled out and died; it's got the depth of a bottle of water spread five miles.


It had already diverged into a discussion about the N64. I'm just impressed you know so much about the it.


I'll take you up on that offer. Do you know how they managed to join three PPC750's together in the Wii U?

Bitmanns is a spambot, I reported it yesterday but mods seem slow.

Oh, that's really wierd... The one post and this part threw me off


I didn't ask whether or not you should buy one.

What's even the point of that spambot? It didn't provide a link to a website or anything in regards to someone making a profit.

It had a spam link in the signature.

Oh; I'd have thought it were just a weird prank. Will spambots get past most anything at this point? I've heard Captcha tests have been useless for a long time now.

If this N64 discussion goes much further, maybe we should take it to a different thread in Other Retro Dev. I made one a while back, actually...


I'm not taking a holistic approach. I'm just saying that there was a surprising amount of overlap given the power difference, which may be attributable to the N64 being hard to program, compounded by the inefficient official microcode holding the system back. Comparing bad N64 games with good PlayStation games can make it look like the PlayStation was more powerful, which is not something you tend to get with (say) the NES vs. the SNES.


I noticed this with F-Zero X. I play the real one regularly. It's higher res in emulation, if you want it, but the shiny is gone.


I realized about the VRAM after posting, and figured it wasn't important enough to warrant an edit. With audio RAM it comes pretty close to even... and Expansion Pak games were usually not the worst-looking ones, so I can't really claim that as a trump card...

Speaking of RAM, what was the latency like on the RCP side? I've heard figures as high as 600 ns for a CPU cache miss, but I can't imagine that's representative of RCP random access... Also, I believe the N64's RAM was divided into four banks; did this have any relevance to latency?


Absolutely.

And yet, it seems that certain late games, such as World Driver Championship, managed to match or exceed the PlayStation's advertised capabilities (180,000 textured tris per second) while maintaining the additional features that made N64 polygons so power-intensive...


I'm sorry; I can't accept that without more detail. What's wrong with the methods I proposed? I could guess, but that's not a path to edification.

I have to admit that I don't know too much about Wii U specific features, and have not been privy to any detailed information about it. From memory, the PPC750 did have an incomplete SMP implementation which was finally completed in the G4 design, so I'm guessing IBM may have done some 'backporting' of G4 SMP technology into the PPC750.


I think I will take you up on that. I have posted to this thread http://forums.nesdev.com/viewtopic.php?f=23&t=16414&p=216380#p216380