Live data from Hacker News

Statically Recompiling NES Games into Native Executables with LLVM and Go

andrewkelley.me

51–60 of 103 posts

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#51
Somewhat off-topic, but to defend gcc against clang, here is a modern version of gcc with the correct warning option:

    $ gcc-4.8 -std=gnu99 -Wall -o test test.c
    test.c: In function 'main':
    test.c:6:5: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
         if (foo & 0x80 == 0x80) {
         ^
gcc 4.9 will have colored diagnostics, too.

Cool project, though.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#52
post #35
post #31

Earlier quoted context omitted.

I think it might actually work better for more modern hardware. Less handcrafted ASM tricks, much more regular (compiler generated) machine code. And of course no self-modifying code that would be extremely difficult to recompile correctly. Modern hardware (GPU, sound cards,...) is also very similar to what you find on a PC so it would be more straightforward to port all this code. No messing around with the framebuf…

The other interesting thing about older hardware is that each cart could embed special hardware that the NES could take advantage of. To play those games: that extra hardware has to be emulated as well. So far as I know: this is unheard of with current gen consoles. The most recent example I can think of is for a handheld console. The Pokemon Walker that was bundled with the newer Pokemon games for the Nintendo DS; w…

I don't know how common add-ons were in the NES era, but they were very common for the SNES (which was very similar to the NES power wise).

Games stopped embedding hardware when they went to discs. There is no way to put a parallel processor into a DVD.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#54
post #17

This is amazing. Also, this is the Dark Magic of programming that I don't think I'll 100% grok in 20 years, but its good to try! edit: now that I think of it, I really need to keep expanding my knowledge. I'm going to go through this post in my terminal and try to at least make the stuff work, so I can start understanding this process. I've been trying to learn Go and C better anyway. Thanks for providing a ground to…

I've looked at this sort of stuff as utter voodoo for a long time. Then I ran into this book[1], and everything just kind of 'clicked' into place in my head. I can't recommend this book often enough.

[1]: http://www.nand2tetris.org/book.php

In short: It gives you a hands-on approach in designing and building your own computer and programming language, to end up writing and running your own games on the system.

    * It starts with simple boolean algebra to explain and create logic gates (NAND, AND, OR, XOR, etc).
    * Use these to build an ALU, memory banks and eventually a full CPU.
    * Design an assembly language and assembler for this system.
    * Use the assembler to create a higher level OOP language, compiler and code base.
    * Use this language to write a rudimentary operating system.
    * Write a game to run on the OS.
All using very clear and simple English and a very comprehensive emulation system (written in Java) by the authors.

Edit: For some reason, this site has started showing malware warnings in chrome and firefox since today. Even though Google's advisory[1] makes no mention of any actual malware being detected. I've visited this site safely for a long time. Still, if you don't trust it, then wait until Google clears up the issue. I've already contacted one of the authors about it.

[1]: http://safebrowsing.clients.google.com/safebrowsing/diagnost...

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#55
post #47
post #43

Earlier quoted context omitted.

Why is static pointless and why is dynamic better? If emulating a newer game console, couldn't you get better performance by running a statically recompiled game, since it doesn't have to do the extra work at runtime? Or better yet, couldn't you cross-recompile a game to run it on a platform that couldn't normally handle emulation of the target platform?

Dynamic lets you do lots of nasty tricks, and also lets you detect and work around various nasty tricks at runtime (worst case by falling back to emulation). Consider that old games often would use self-modifying code, for example. Reliably statically detecting self-modifying code can be extremely hard even when it's not intentionally obfuscated. But at runtime it is "easy": Write protect all the code pages, and trap…

Thanks for the thorough response. I really appreciate it.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#56
post #52
post #35

Earlier quoted context omitted.

The other interesting thing about older hardware is that each cart could embed special hardware that the NES could take advantage of. To play those games: that extra hardware has to be emulated as well. So far as I know: this is unheard of with current gen consoles. The most recent example I can think of is for a handheld console. The Pokemon Walker that was bundled with the newer Pokemon games for the Nintendo DS; w…

I don't know how common add-ons were in the NES era, but they were very common for the SNES (which was very similar to the NES power wise). Games stopped embedding hardware when they went to discs. There is no way to put a parallel processor into a DVD.

Well, modern consoles _could_ still be extensible; but their hardware is already so general purpose that there's not much point.

Best you could do w/ current gen technolgy is bundle a dongle w/ the game, where the user plugs in some kind of co-processor through USB.

So far I haven't really seen anything like that -- the only USB dongles I've seen bundled w/ games are for games like RockBand and they're just RF receivers.

Aside from bandwidth concerns, and the poor sales of previous attempts (for e.g the SEGA's whole 32x/CD addon), there's nothing preventing a disc-based from having an external co-processor.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#57
post #47
post #43

Earlier quoted context omitted.

Why is static pointless and why is dynamic better? If emulating a newer game console, couldn't you get better performance by running a statically recompiled game, since it doesn't have to do the extra work at runtime? Or better yet, couldn't you cross-recompile a game to run it on a platform that couldn't normally handle emulation of the target platform?

Dynamic lets you do lots of nasty tricks, and also lets you detect and work around various nasty tricks at runtime (worst case by falling back to emulation). Consider that old games often would use self-modifying code, for example. Reliably statically detecting self-modifying code can be extremely hard even when it's not intentionally obfuscated. But at runtime it is "easy": Write protect all the code pages, and trap…

[deleted]

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#59
post #54
post #17

This is amazing. Also, this is the Dark Magic of programming that I don't think I'll 100% grok in 20 years, but its good to try! edit: now that I think of it, I really need to keep expanding my knowledge. I'm going to go through this post in my terminal and try to at least make the stuff work, so I can start understanding this process. I've been trying to learn Go and C better anyway. Thanks for providing a ground to…

I've looked at this sort of stuff as utter voodoo for a long time. Then I ran into this book[1], and everything just kind of 'clicked' into place in my head. I can't recommend this book often enough. [1]: http://www.nand2tetris.org/book.php In short: It gives you a hands-on approach in designing and building your own computer and programming language, to end up writing and running your own games on the system. * It s…

Brilliant! I just bought this based on your recommendation.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#60
post #54

Earlier quoted context omitted.

I've looked at this sort of stuff as utter voodoo for a long time. Then I ran into this book[1], and everything just kind of 'clicked' into place in my head. I can't recommend this book often enough. [1]: http://www.nand2tetris.org/book.php In short: It gives you a hands-on approach in designing and building your own computer and programming language, to end up writing and running your own games on the system. * It s…

Brilliant! I just bought this based on your recommendation.

Likewise. Awesome comment. Book I wasn't aware of. Thanks so much for taking the time to write this.
Post reply on HN