Not necessarily. It would be like a iphone to iPad difference. The hardware architecture would be the same but at different clock speeds and such so the game's would be scaled down to run on the handheld.
So from 2016-2018 Wii U owners are going to play another Mario, another Zelda and HD remakes with little to no third party games? That's enough content to satisfy them for two years?
All it proves is that backwards compatibility is worthless if it comes at the expense of better hardware for the newest system, not that the feature has no value to the consumer in and of itself. The two most successful console follow-ups to date (PS2, Wii) had backwards compatibility, and so did all of Nintendo's handhelds. The most popular gaming platforms on the market right now (tablets and smartphones) are built around forward and backwards compatibility.
In what shape or form are mainstream ARM platforms hard for 3rd parties to put games on? That's a genuine question.
What premium experience? You're not getting > 2.5GHz i5s / i7s and stand-alone GPUs in any of the consoles. Not this gen, and not in the next one. Consoles will be actually going more mainstream-SoC based, if anything. There you need both a decent CPU and a decent GPU on the same die. Who exactly do you propose to integrate an i7 with a 3rd party GPU? Intel? There's one 3rd party GPU IP that Intel know how to couple with their mobile cores - PowerVR. That might cut it on the handheld front, but there nintendo have zero reasons to part with ARM, so while their next handheld's GPU could be a PowerVR, the CPU's still going to be an ARM. Intel's desktop cores have never shared a die with anything else but an Intel Graphics. If we assumed there was a 3rd party IP Intel would need to integrate with a desktop core for nintendo, that'd be way more than a customization - that'd be a serious undertaking for all the parties involved. Do you actually believe Intel would do that for a potential customer like nintendo?
Who's everybody else? Currently, SoCs based on custom v8's are done by:
Are you referring to Bay Trails? Those boast Jaguar-level IPC and solid turbo boosts, but that's about them. That makes them quite performance-competitive against A15 parts, but they'll have a hard time against A57s, and be entirely out of the 'top-players' v8's league (currently including A8, Denver, X-Gene/Helix, but that will soon change).
If they do it, it shouldn't cost more than $250
Quite likely.
I agree, the gamepad is awesome...but if the cut it out next time they can sell it for upto $100 less. Imo the main reasons WiiU isn't selling is because its too high, especially when you can get another system in 3DS for much cheaper.
First off, there's no such thing as 'x86 optimisation expertise'. You can be an expert with this or that microarchitecture (or a few of them at the same time), but x86 and PPC are both ISAs, not a microarchitecture. Reality in x86 world is that what yields nice IPC on a Haswell might not on a Jaguar, etc. Heck, the differences between IvyBridge and Haswell are not negligible, to the point that one'd have to be careful when targeting the two microarchitectures with the same binaries, if optimal performance on either of them was sought. Devs get proficient with the hw anew with the start of each new generation, and x86 does not magically dispel that. You can ask any ps4/xb1 dev about the cache intricacies of the dual-cluster Jaguar configs in the current consoles - you'd be excited to learn about the 'x86 desktop experiences' they got there.
Well, I guess I fell for the 'premium experience' red herring there. A premium experience in my eyes is something traditionally provided by an 4..8-core desktop Intel and an AMD/NV standalone GPU, so I went on a SoC trajectory from there. Anything else requires very serious efforts on developers' part, as repeatedly demonstrated by pc/console multiplat devs this gen, x86 and all (Ubisoft's recent discussion, etc.)
Let's see. NV can, easily (sans the x86 part, apparently, the value of which is subject to this very discussion). Apple have proven that they can (with the help of IMG), alas they're not interested. Qualcomm (to whom once upon a time AMD sold ATI's entire mobile division, engineers, architects and all), also can, and are actually interested. Broadcom could, if given the incentive, and the same goes for AMCC. The thing about open ecosystem architectures is that quite a few IP vendors are willing to provide you with all kinds of added-value IP. For instance, three vendors (IMG, ARM, Vivante) offer ARM-tailored GPU IPs, and every ARM vendor could use any of those IPs with their designs, if they don't have a domestic one already. Now, how many of those IP vendors could match AMD at the high end of the spectrum? Perhaps none, but two of the in-house GPU vendors - NV and QCOMM, could, and would, if given the opportunity.
We don't really know. I've not seen it, but the SDK leaked, and there's apparently no direct register access or anything - you have to go through GX2. At least that's what I've heard.
Because that's what microarchitecture expertise is about. Knowledge beyond the ISA of a given CPU is microarchitecture knowledge, or IOW knowledge of the particular implementation of the ISA. It comprises things as trivial as caches setup, through ops scheduling (in-order, OOO, etc), through individual ops' port utilisation, and related throughput and latencies. That doesn't mean you can rebuild the CPU at hand from scratch, but that you could make some educated guesses about the performance of this or that code and data when passed though this CPU, and knowing what the performance-counter profiler tells you. Knowing the ISA alone does not help you there.
You entirely missed my point about what x86 expertise comprises. Again, read what I said about IPC across x86's. The fact you might be a Haswell expert does not automatically make you a Jaguar expert, and vice versa. Devs were forced from one uarch to another this gen, and that did comprise a 'new cpu' learning curve for them. Unless you believe many devs were Jaguar experts prior to this gen. Also, when talking about somebody being 'forced' from this to that, let's not forget we're talking about modern, OOO CPUs, of which, low and behold, all armv8 specimen have overall better macro characteristics compared to the Jaguars and Silvermonts of today: wider, more aggressive superscalarity. You're not going from your desktop CPU to some PPE here. And you have *all* the tools at hand that you're traditionally accustomed to on your desktop (since you somehow missed that part altogether).
ARMv8 comprises of aarch32 and aarch64. An implementation may choose to skip aarch32, but no v8 so far has done so, AFAIK. Re Apple, they've had their v8 for over a generation cycle now, and I'm yet to hear an iOS developer complain about the 'alien CPU' they've been 'forced to develop for'. On the contrary, everybody's been praising it. Clang devs have gone as far as declaring aarch64 'the best possible architecture a compiler could hope to work with' (citing from memory here, so pardon any paraphrasing).
On what grounds? Console devs have traditionally been ppc-centric (before that - mips) until this gen (original xbox non-withstanding). And many console devs are also mobile/handheld devs. Aren't you picking the x86 divisor a bit arbitrarily?
They might provide either solution, but not to an equal effect. Their current entry-level x86 (Puma) will most likely not match their entry level ARM (A57) at the end of this year. You could argue that their next-gen x86 and ARM entries will be on more equal grounds (or not, if we're to believe Jim Keller's own words), but again, that supposes nintendo's serious change-of-heart to cut any ties with ARM.
If the next Nintendo console doesn't use the Gamepad, it won't be backwards compatible
They have at least 2 hardware launches next year; New 3DS/XL (NA/EU) and QOL (WW). 2016 is when we might see next gen.
Iwata has stated that future platforms will be single virtual account, single programming model, like iOS, and no longer hardware based, in favor of cloud-based. Nintendo is tired of starting over every generation and rebuilding the user base. This is one of the factors that hampered the Wii U's success; the Wii's accounts, save the shop channel, could not carry forward and most users were lost to attrition. For this reason, hardware-locked accounts and hardware-locked games will be a thing of the past. I wouldn't be surprised if the disc drive and cartridge slot got axed too.
They'll likely have to use tech that isn't even out yet this time, and carry that forward in the future. It will be the basis for future Nintendo tech, just as the GameCube was the basis for the Wii and Wii U. Iwata has commented that the tech for a unified architecture is just now coming into focus, and that it had been previously impossible. There's no reason to drop PowerPC if they stay at 32-bit, especially if they can cram Espresso into a handheld.