Live data from Hacker News

Super Mario 64 has been decompiled

github.com

61–70 of 180 posts

Re: Super Mario 64 has been decompiled

#61

"For Windows, install WSL and a distro of your choice and follow the Linux guide." I love these instructions! Also, I'd love to see this converted to a native executable. I wish Nintendo would actually allow that, although I'm sure they wouldn't.

If I remember correctly, some time ago I saw a video from someone who managed to build a substantial part of SM64 as a native executable and was able to verify that tool-assisted runs ran perfectly on in it (hence it being accurate). The video displayed the game as a wireframe and had no audio, since those parts are surely tied to the N64 hardware.

I can not figure out the right keywords to find it again, but you may be able to if you are interested.

EDIT: Even though I can't find the video anywhere (I promise it existed!), from https://warosu.org/vr/thread/5644072

"To answer your questions, yes: This is a full source code which can be recompiled with modern toolchains (gcc: ive done this already) and even target other platforms (PC) with quite a bit of work. There already exists some proof of concept wireframe stuff."

Re: Super Mario 64 has been decompiled

#62
post #52
post #34

Earlier quoted context omitted.

No - qemu supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS. The IRIX kernel and OS doesn't run in this scenario.

From my limited understanding stemming from a passing interest of such things: that sounds similar to how WINE operates, is it not?

WINE is not emulating/translating instructions to a diffrent ISA. It rather has a win32 loader and inserts some shims to map some calls to windows library functions and others to native(as in host ex. Linux). That's how I understand it. You can however theoretically run x86 WINE to run a x86 windows binary on ARM with Qemu user emulation.

Re: Super Mario 64 has been decompiled

#63
post #59

"For Windows, install WSL and a distro of your choice and follow the Linux guide." I love these instructions! Also, I'd love to see this converted to a native executable. I wish Nintendo would actually allow that, although I'm sure they wouldn't.

A native executable? It's not like the Nintendo 64 was using DirectX

You'd need to emulate/simulate/shim all the graphics calls and state changes, but that shouldn't have any bearing on the actual code architecture. In fact, given that Dolphin uses a JIT, you could argue that this already happens to some degree when you're playing Gamecube games, having the source just allows ahead-of-time compilation.

Re: Super Mario 64 has been decompiled

#64
post #52
post #34

Earlier quoted context omitted.

No - qemu supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS. The IRIX kernel and OS doesn't run in this scenario.

From my limited understanding stemming from a passing interest of such things: that sounds similar to how WINE operates, is it not?

Sort of.

Wine impersonates OS calls, (including syscalls) but does not perform emulation on the binary itself. Wine can only run windows applications written for x86, but not windows applications written for itanium.

This appears to be running both hardware emulation on the supplied binary, (which is what VMware/KVM/virtualbox etc do) as well as wine-like OS impersonation.

I made up the word "impersonates" for what wine does just to avoid confusion. It's not a word that's used in the literature afaik, although perhaps it (or a word like it) should be.

Re: Super Mario 64 has been decompiled

#65
post #58
post #37

Earlier quoted context omitted.

I think you misunderstood what the parent was saying. On the technical level, you are correct in that in both scenarios the end result would be the same, as you are going from compiled code to decompiled code. What I believe the parent is saying, is that applying this to Panzer Dragoon accomplishes more (on the human level), because devs of that game don't have the original source code anymore, while Super Mario 64 d…

Maybe the confusion could have been avoided if instead of: > It would be great if this could be done... codesushi42 would have said (emphasis mine): > It would be great if this would be done... Not that I think it was incorrect as it was, just a little ambiguous, I guess.

Not a native english speaker, but this seems like a nitpicky non-issue to me. How is it not the same as "could you please pass me a glass of water" vs. "would you please pass me a glass of water"? Both indicate a request rather than talking about actual physical ability to perform the action.

Also, I would agree more with your point if the parent said "It could be great if this could be done..." instead of "It would be great if this could be done". The first "would" seems to indicate to me pretty clearly that the parent was talking about a request rather than ability.

Re: Super Mario 64 has been decompiled

#66
post #52

Earlier quoted context omitted.

From my limited understanding stemming from a passing interest of such things: that sounds similar to how WINE operates, is it not?

WINE is not emulating/translating instructions to a diffrent ISA. It rather has a win32 loader and inserts some shims to map some calls to windows library functions and others to native(as in host ex. Linux). That's how I understand it. You can however theoretically run x86 WINE to run a x86 windows binary on ARM with Qemu user emulation.

Doesn’t WINE support 16-bit emulation for Win311-stuff because you can’t run 16-bit code in x64 mode? Or was that a Windows limitation?

Re: Super Mario 64 has been decompiled

#67
post #47

I am looking forward to the mods that this will enable. I highly recommend trying mario 64 on dolphin EMU at 1080P with a texture pack. A HD mod that added a few more polygons would really round out the experience.

Is a raspberry pi a good-enough platform to run N64 1080P games on?

You'll want the Raspberry Pi 4. The 3B+ is not powerful enough for plenty of games.

Re: Super Mario 64 has been decompiled

#68
post #4

As an amusing side-effect, the team working on this effort also implemented IRIX userland support for QEMU since the original N64 toolchain ran on IRIX on the SGI Indy, and they need the original compilers to verify functional equivalence of their source: https://github.com/n64decomp/qemu-irix .

I honestly love coming to HN to see posts like this and comments like yours. It is always so neat to see the other sides of software engineering. You listed 4 acronyms and I have no idea what any of them are or how they fit into this story but all I want to do is deep dive into each one. It is also awesome to see people so interested in things that I've never even encountered before.

IRIX [1] was the version of SVR4 UNIX which ran on SGI [2] computers.

QEMU [3] is an emulator used to run programs for one machine on another.

N64 [4] is the Nintendo 64 games console.

SGI Indy [5] was a desktop SGI workstation from 1993.

[1] https://en.wikipedia.org/wiki/IRIX

[2] https://en.wikipedia.org/wiki/Silicon_Graphics

[3] https://www.qemu.org/

[4] https://en.wikipedia.org/wiki/Nintendo_64

[5] https://en.wikipedia.org/wiki/SGI_Indy

Re: Super Mario 64 has been decompiled

#69
post #35

Earlier quoted context omitted.

the team working on this effort also implemented IRIX userland support for QEMU What does this mean? I think of QEMU as emulating hardware... What exactly is being emulated here?

QEMU is thought of as a hardware emulator, but supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS.

I didn't even know QEMU could do that. That's insanely cool; kind of a weird combination of traditional virtualization and Wine.

Re: Super Mario 64 has been decompiled

#70
post #64
post #52

Earlier quoted context omitted.

From my limited understanding stemming from a passing interest of such things: that sounds similar to how WINE operates, is it not?

Sort of. Wine impersonates OS calls, (including syscalls) but does not perform emulation on the binary itself. Wine can only run windows applications written for x86, but not windows applications written for itanium. This appears to be running both hardware emulation on the supplied binary, (which is what VMware/KVM/virtualbox etc do) as well as wine-like OS impersonation. I made up the word "impersonates" for what w…

I think the usual term Wine (plus e.g. WSL1, Darling, Solaris/BSD Linux compatibility shims, etc.) uses is "translate", but "impersonate" does sound closer to what such systems actually do.
Post reply on HN