Why?

http://andrewkelley.me/post/jamulator.html

Subject says it all.

Maybe this compiled ROM thing is just a hobby or a research project of his (I was too lazybusy to read the whole thing, so I might have missed the whole point of this thread).

Actually I can think of a use for this. Translating a game from a system into a native binary of another system can help the target system to run said game under limited resources or processing power, and still deliver (mostly) accurate playing experience of the original game. Though of course most modern platforms (computers, smartphones, TV sets, refrigerators, whatever, etc.) are capable enough to have a Famicom emulator, this concept may be applied to games originally designed for more demanding systems (e.g. arcade games, games for more "next-gen" consoles) that lower-end modern devices are still struggling to emulate accurately (even in the case of Famicom games, running a Famicom emulator on a modern smartphone can drain your battery in no time). In fact, as far as I have heard, apart from purely emulated games (such as Nintendo's Virtual Console, those old games in PSX store, etc.) some accurate arcade ports for recent consoles (by recent I meant from Playstation/Saturn onwards) are actually done by abstracting the original arcade systems into components, emulating logical components such as graphic and sound generation like the original boards, so that the games can use directly the data files of the original systems, but instead of emulating the CPU (could be one of the most demanding part, especially during the PS1 & PS2 eras and recompilers weren't that common) the code part was completely refactored into native codes of the target system (either by reverse engineering/decompiling/deassembling the ROM files, or if the developer happened to possess the source code of the original game they could just recompile it for the target system). This is similar to how some people made SMB to run on the Mega Drive by using the deassembled codes of the game.

Any time someone takes a swipe at something (in this case, gcc, at the beginning), baring extenuating evidence I conclude they're more interested in being a jerk than actually making their point.

At the end of the entire writeup he concluded:

Which is pretty blatantly false, unless he very specifically meant "NES video game emulation". Even half-assed static recompilation has been used to great success in high-level emulators.

The biggest problem with his methodology is that he completely half-assed the disassembly. GIGO and all that, if you can't get a good master document, you're not going to get good output. I can't really fault him for not wanting to make a Comprehensive NES Disassembler, since that's Hard and a Big Project that's Suspiciously Yak-Shaped, but...

Another is assuming that he could start with a 6502 core and just bolt the PPU on. Failing to identify the full shape of the project is a great way to get blind-sided later on ... which he did.

Statically recompiling some kind of "no surprises" architecture like CHIP8 or (i think) the Z-machine would have been much more successful.

Ultimately he had two goals: learn how to write a frontend for LLVM, and write a NES emulator that was Different, and he definitely succeeded at those two.

edit:typo (tags should have been takes)

Oh yea ! NES emulation on a refrigerator

Z-machine runs most code in ROM, in high memory (high memory of the Z-machine can only contain instructions and encoded text strings), although it is possible to run code in RAM too.

Harvard architectures do not have this problem, however.

I thought it would be an interesting example of how it compiled, or how the compiler optimized it, but it was one error warning after another with nothing to show at the end. It's like those people who tweet that they just used the bathroom. Not interesting. I stopped after that.

That or a game is being ported to a platform whose application acceptance policy forbids interpreters. At various points in the history of Apple's App Store, iPhone and iPad were examples of such platforms. Or a game is being ported to a platform that can only run programs written in one language. Xbox 360 is like this: unless you have tens of thousands of dollars and a relationship with an established publisher of disc games, you have to stick to Xbox Live Indie Games, which requires all games to be written in C# using the XNA framework, and for various reasons, XNA isn't exactly designed to be an emulator host. (The actual requirement is no native code, no unsafe constructions, and no Reflection.Emit, but no unsafe constructions rules out languages like standard C++, and no Reflection.Emit rules out IronPython.) It's not quite as necessary on a platform like Ouya, where both emulators written in Java and emulators using the NDK should work.


EDIT: Errors are made. From the article:

And Balloon Fight is chopped liver.


The wiki already calls that a bad idea. See Tricky-to-emulate games.

Fairly pointless in practice, but looked like a fun learning experience to see how LLVM worked and such. Long as he had fun making it, it doesn't bother me.

But yeah, the answer was obvious from the beginning. The more accurate you get, the more optimizations you lose, and eventually a theoretically perfect static recompiler would end up with enough dynamic hooks (like generating instructions from 6502 code placed in RAM) that it's effectively equivalent to a traditional emulator anyway. Only much more complex for likely no speed benefit.

Traditionally, static recompilation is just one more way to cut corners for speedups. Which is great if you're writing a game emulator for limited resources. Not so great if you want compatibility with any theoretically valid software program.

High-level emulators actually use dynamic recompilation, i.e. recompiling the code on the fly as it's running. I'm not sure of any using static recompilation, though things like jump tables and such can easily fool recompilers (otherwise disassemblers wouldn't have any issues reverse engineering any program all on their own *sigh*).

So in application, basically a static port, removing the need for disassembly and rewriting large portions of the code to account for architectural differences?

This reminds me in a more abstract way of that Super Mario Brothers port to Megadrive that was done fairly automatically, save for the PPU and audio handling.

I had no idea we had such a list. Should Kick Master be on there for its timing critical title screen effect?

Super Cars does something pretty funky with $2004 to blank scanlines at the top of the screen (watches sprite fetches to detect scanlines?). Many emulators have the top of the screen flickering or even huge parts of the screen blanked out instead of just the top.