All that work, and then he hits the expected killer problem - self modifying code. Getting past that without an interpreter is going to be tough. Not impossible, because the self modifying code isn't that dynamic in the places he found it. It's not like it's reading external input and compiling it. There are a limited number of cases to be handled.<p>It's amusing seeing this in a machine which gets its code from a ROM.
NES cartridges also could have their own hardware too. Don’t like the NES sound card? You could ship your own inside of the cartridge. I think notoriously castlevania 3 shipped some custom hardware in their cartridge. Some of the cartridges for the famicom came with an fm synth chip.
Interesting read, shame about the dynamic code problems.<p>I wonder whether something like this might be better attempted in rpython which will build a JIT compiler for you.<p><a href="http://rpython.readthedocs.io/en/latest/" rel="nofollow">http://rpython.readthedocs.io/en/latest/</a>
<i>This means that they test some condition, and then either transfer control flow to the next instruction, or to a different label. This means that we can mark the possible branch address and the next address as instructions.</i><p>I hope all of these NES ROMs were coded well. Seems like you could do something like...<p><pre><code> if False:
jump_to_data_address
</code></pre>
... then he'd be interpreting data as code.
I had a similar project idea for ages. Instead of LLVM it would static recompile into C macros or C++ inline function calls for each opcode. Then it would compile the output and run the game.<p>Emulation is just plain fun.
lol, it just came to me that clang is an abbreviation for C language. I always imagined it to be the sound metal makes when you slam it together, because bare metal programming etc.
Dupe: submitted 1560 days ago - <a href="https://news.ycombinator.com/item?id=5838326" rel="nofollow">https://news.ycombinator.com/item?id=5838326</a>