NV got DS2 contract according to BSN

As there seems to be no dedicated 3DS thread yet, and that thing is announced and has a lot more to offer than Tegra, is anyone willing to speculate what this seemingly handheld, if not 3DS, related stuff is about:


Judging by the first two patents, it seems the joint research agreement between Nintendo and InPhase to develop holographic storage was about handhelds all along. Not about holographic disks for Nintendos next generation home console. According to a few quotes I could dig up, InPhase claims a capacity of more than 60GB per square inch, which seems to be about the size of the actual storage medium in the drawings submitted with the patents - not to mention a mind blowing transfer rate. All this stuff sounds very sci-fi and too good to be true, but the patents obviously exist, they were issued in a time frame that makes it seem related...
 
Also, Nintendo has been buddy-buddy with ATI for years.
N64 used a GPU made by a team that went to ATI after leaving SGi.
GCN used ATI
Wii used ATI.

I don't see them going with nVidia.
I was under this notion too, but someone said that the deals for consoles don't necessarily apply for handhelds.
 
Oh, Hi Exophase.

How did this discussion about backward compatibility on the 3DS suddenly turn into a discussion about mupen64plus?

The dynamic recompiler in current mupen64plus (at code.google.com/p/mupen64plus) is basically the same as what Hacktarux wrote back in 2002, although Richard42 made a x86-64 version.

It is slow for a lot of reasons. It doesn't have many optimizations. The instruction decoder caches a lot of metadata and uses a lot of RAM and fills the L2 cache. The branch misprediction rate is high because it often overwrites the return address on the stack, and it uses conditional branches in many places where it could use conditional moves. In some cases, it emulates 64-bit instructions where 32 bits would be enough. The register mapping is inefficient. There is no constant propagation or combining LUI and ADDI.

It was too slow to run on many low-end systems, so I rewrote it.

Many of the things that I did for mupen64plus would not apply to DS emulation. There is a lot of code in there for handling the branch delay slots. Also, on the DS there are no 64-bit operations, and there is no FPU.

I don't convert to a substantially different intermediate representation because it's not really needed for MIPS emulation. eg add becomes add (or lea). If it adds zero then it's replaced with a move. When it can do constant propagation then the add is replaced by an immediate load. If I was writing an x86 emulator (like FX!32) I would consider a different intermediate representation because it can be useful to split complex x86 instructions into simpler ones, but for N64 or DS emulation I don't see the point.
 
Right, I confused the "plus" version with the work you had done. You should give your branch a unique name. Maybe yours can be Mupen64plusplus? ;D

I agree with you that an IR is not necessary for MIPS->x86 translation, but I actually don't think it's really that automatically beneficial for performance in most cases, and can actually be a stumbling block. Annotation can take the place of additional metadata that an IR would give, but splitting an instruction into multiple sub-set operations really only opens potential for slight scheduling improvements.

This really wasn't supposed to be a discussion about your recompiler, nor was I trying to make any direct comparisons between your work and what would be done on translation for DS emulation. I was just using you as an example of someone who did a good recompiler despite not being paid by a company.
 
This really wasn't supposed to be a discussion about your recompiler, nor was I trying to make any direct comparisons between your work and what would be done on translation for DS emulation. I was just using you as an example of someone who did a good recompiler despite not being paid by a company.
I don't understand this. Why would they worry about recompilers when they have the specs of their previous system, especially when it comes to software emulation? Also, you seem to be comparing feature sets over the accuracy of emulation, and I don't think their's anything to worry about with regards to the latter considering how spot-on Virtual Console's is. (I don't think the Zelda bonus disk counts, considering those were being streamed-off a disk, and the data transfer rate is nothing compared to having it all run off the Wii's NAND.) And I just don't buy the whole "have lots of money, can't hire passion" statements; most of the N64 emulators out there can't even get to display the filter/buffer effects right while the ones that run on the VC's can.

But again, this isn't about the N64. I see no point why DS backwards emulation would be so terribly difficult. And besides, what keeps them from just minituraizing the current DS chipset and putting it in along the new model?
 
Last edited by a moderator:
Doubt the area is significant by Tegra 2 standards and when you don't need it you can just turn it off. Using custom ASICs will obviously add a million or more to the development costs though.
 
when you don't need it you can just turn it off.

Then you have the tegra still powered, unless you have it so it's 2 separate mobos access the input/output devices (screens, buttons, etc) and that'd be expensive in every sense of the word.
 
No I'm suggesting putting it all on one die and using power gating to turn off the parts you don't need at a given time.
 
No I'm suggesting putting it all on one die and using power gating to turn off the parts you don't need at a given time.

Then you have the tegra still powered, unless you have it so it's 2 separate mobos access the input/output devices (screens, buttons, etc) and that'd be expensive in every sense of the word.

Either the I/O goes through tegra (or whatever exotic processor this hypothetical situation goes with), which means it would need to be powered.
Or there are 2 separate circuit paths, so there'd be 3DS hardware, then DSi hardware, both of which need to go to the same I/O devices.
Which seems highly unlikely. Do you really see Nintendo using a third processor, to go with the 2 DSi uses already?

Pick the simplest, least power using, and cheapest solution, and that gives you the best chance of predicting what Nintendo will go with.
 
Last edited by a moderator:
Putting a couple of (de)muxes on the ASIC isn't really a big problem.

The main reason I don't see them doing it is because it saves them a couple of million AND it saves them the risk of delays from producing a custom SOC.
 
A computer generated hologram ... you could do that with a LCD, if it had ~10000 dpi.

So not really relevant :)
 
I don't understand... :S

i found this linked to nintendo and nvidia, there's some possibility that those kind of screen ends up in the 3ds?
 
i found this linked to nintendo and nvidia, there's some possibility that those kind of screen ends up in the 3ds?
Before you can print the most common form of CGHs you need to compute hemisphere environment maps for individual sections of the hologram (they call them hogels, which might for instance be 1/2*1/2 mm2 in size). Since this is basically normal 3D rendering a GPU can be used to accelerate it, that's what it has to do with NVIDIA.

It has bugger all to do with 3ds though. As I said, these holograms have resolutions in the range of 10000 dpi ... there are display methods which can do that but not something which can go into the 3ds.
 
I don't understand this. Why would they worry about recompilers when they have the specs of their previous system, especially when it comes to software emulation?

How does "having specs" negate recompilation? You can't just run things natively by having a compatible CPU (and Cortex-A9, if they're using that, isn't 100% compatible with the ARM9 used btw), you need more hardware support. ARM doesn't really have support for true virtualization either, and it's not a good fit for more embedded/real time platforms like DS anyway.

Also, you seem to be comparing feature sets over the accuracy of emulation, and I don't think their's anything to worry about with regards to the latter considering how spot-on Virtual Console's is. (I don't think the Zelda bonus disk counts, considering those were being streamed-off a disk, and the data transfer rate is nothing compared to having it all run off the Wii's NAND.)

Virtual Console is a poor comparison. With VC Nintendo has the luxury of hacking the emulation for each release in order to get things right. And this is something they do invoke regularly, there are all kinds of hacks in their emulators. They also have the luxury of not releasing anything that they can't emulate well. With 3DS they'd need to get a general purpose emulator right and it'd need to have as high compatibility as possible (btw, compatibility != accuracy)

VC is moot anyway because the performance deltas between anything it emulates and the Wii itself are larger than the deltas between DS emulation and whatever 3DS hardware will be. Grossly so except in the case of N64, which like most other N64 emulators out isn't really emulating all the N64 hardware.

And I just don't buy the whole "have lots of money, can't hire passion" statements; most of the N64 emulators out there can't even get to display the filter/buffer effects right while the ones that run on the VC's can.

Yeah, whatever, see my above comments on VC. Hardly a level playing field when they can fine tune the emulator per-game and modify the ROMs themselves. SNES games on VC don't even emulate the audio chip, they're modified to store raw samples.

That aside, saying that the industry is better at console emulation than enthusiasts based on a few cherry picked examples shows a pretty deep ignorance of what has actually been done on both sides.

But again, this isn't about the N64. I see no point why DS backwards emulation would be so terribly difficult. And besides, what keeps them from just minituraizing the current DS chipset and putting it in along the new model?
[/quote]

I didn't say "it's so terribly difficult", I looked at the three different methods of achieving backwards compatibility and identified pros/cons and reasoning towards the likelihood of Nintendo pursuing it.

There's software emulation, which would be very difficult to get perfect (or good enough). If you don't understand this then you don't know enough about what it means to emulate a DS in software. Compare the backwards compatibility in XBox 360 and PS3 Slim with Wii. There's an obvious compromise at hand with those platforms.

There's redundant hardware, which is an option Nintendo has specifically avoided (at compromise to their overall design, IMO). This is probably because it's a waste of resources. For whatever reasons, Nintendo doesn't like including significant amounts of hardware that exist just for backwards compatibility, instead opting to build their new hardware around augmenting the old.

Which is the third option. It would be a design compromise - the main point of the original post I made in this thread - but aside from using less resources and being consistent with what Nintendo has been doing it'd have a few other advantages. One would be that it'd be much easier to migrate tools and libraries. Another would be that it'd be much easier for developers to transition (see the really short transition guide for Wii as a reference), which would give them a quicker leg up on getting the first really big titles out the door, especially when developers will have to adapt to doing things that fit well with 3D displays.

Look at the timeline between announce and release for the following:
GBA - "Project Atlantis" was first revealed 5 years before release, with more concrete details about 2 years prior
DS - November 11, 2003 to November 21, 2004 - 1 year
PSP - May 2003 to December 12, 2004 - 1.75 years

While 3DS is looking to come out around 8 months after announce.

Yes, DS hardware is small by Tegra 2 standards. And Tegra 2 is probably expensive by Nintendo standards. At this point we don't actually know what's going to be used, deal with nVidia or not.

Nintendo may go with high end 3D (by handheld standards), but it's really not the sure thing that some are making it out to be. They've already proven that that isn't really central to their overall game plan, especially in the handheld arena where they're trying to save power. DS has been very successful with pretty meager graphics, with a lot of its bigger titles even being predominantly 2D. 3DS is introducing yet another Nintendo Gimmick, but has no official hype of setting a new standard for graphical capabilities. And yet people are really certain that Nintendo will roll out a handheld that even surpasses their current console. I just wouldn't be so certain.
 
Who is talking about surpassing wii power? Nobody. At best people are talking GC gfx and even that probably wont mean GC power as screen resolution etc will probably be a fair bit lower and with a 3'' screen you can get away with a lot lower quality but still have the overall same perception of quality as with GC on a TV screen anyway.

People are talking about Nintendo probably going with something that will have a low price and decent battery life. Rumors are GC like specs. Cost wise GC hardware probably wont be a problem. Nintendo could sell a GC for profit at 99 euro's. Now we are a few later again plus a lot of stuff inside GC doesnt have to go into 3DS so the hardware is probably cheap enough to fit into a 150 ~ 200 euro handheld. The bigger question to me would be can they get it small and power sufficient enough.
 
Back
Top