5 ms·

This is interesting. If this project can output LLVM byte code, then you could also codegen to javascript with emscripten and make a web based version of a NES

by quux 13y ago

This is interesting. If this project can output LLVM byte code, then you could also codegen to javascript with emscripten and make a web based version of a NES game.

AndyKelley 13y ago
That thought occurred to me as well, although I did not actually try it.
- quux 13y ago
  Cool, no need to reply to my email then :) I've been messing around with emscripten lately myself. Maybe I'll try it some time.
- tibbon 13y ago
  Seems like a good followup post. I'd read that. I mean essentially it would make NES games running natively in the browser with no emulator right?
  - AndyKelley 13y ago
    It's not quite as sunshine and rainbows as that. For one, I had to embed an interpreter runtime in the generated code to handle some dirty assembly tricks that programmers can do. Further, the Picture Processing Unit and Audio Processing Unit must be emulated. Even worse, there are some things that fool the disassembler that many games do. And finally, this project never even attempted to support mappers, which means that there are only about 8 or 9 notable games that this could even potentially support. As is, it supports Super Mario Bros. 1 only.
    - boomlinde 13y ago
      There was a NES emulator for the Game Boy Advance that performed with a surprising level of accuracy at full frame rate. I guess the CPU emulator was a simple state machine, but the interesting thing in this context is how it did the graphics and sound. Having a pretty advanced "PPU" of its own, with the same basic types of features (sprites, tile indexing background layers), it translated the PPU register writes (with appropriate scaling, I guess) to native register writes. I'm not sure how things like collision interrupts were handled, but presumably the GBA has similar functionality. For a javascript emulator or static recompilation, similar methods could be used to set up a bunch of shaders dealing with the basic functionality of the PPU (sprites, tile layers etc). Certainly less accurate and probably missing a bunch of corner cases, but it would definitely be the fastest approach to dealing with graphics emulation.
rboulton 13y ago
Or, you could just use an emulator written by hand in javascript: http://fir.sh/projects/jsnes http://fir.sh/projects/jsnes
- BHSPitMonkey 13y ago
  That project's name has always bothered me... My brain tokenizes it as J SNES rather than JS NES.
acdha 13y ago
See also https://github.com/jsmess/jsmess https://github.com/jsmess/jsmess which is a port of an existing emulator codebase using emscripten
- chadseibert 13y ago
  I'm not quite sure what the point of this project is, as MESS is rather slow when built natively [1]. Perhaps some of the lower end systems can be emulated, albeit slowly. [1] http://www.mess.org/faq#it_works_but_it_is_way_too_slow http://www.mess.org/faq#it_works_but_it_is_way_too_slow
  - acdha 13y ago
    http://archiveteam.org/index.php?title=Javascript_Mess http://archiveteam.org/index.php?title=Javascript_Mess summarizes why: it makes it as widely available as possible and lowers the barrier to entry considerably.
  - derleth 13y ago
    The point is historical preservation: Putting ancient games and systems on the Web as a way to enable people to experience them, as part of digital museums, online academic papers, and such, to provide some (imperfect) context for what would otherwise be dry technical history. It's in JS because it's the only language that doesn't require plugins, and so has a better-than-average chance of running on a variety of different hardware. http://jsmess.textfiles.com http://jsmess.textfiles.com http://ascii.textfiles.com/archives/3745 http://ascii.textfiles.com/archives/3745 http://archiveteam.org/index.php?title=Javascript_Mess http://archiveteam.org/index.php?title=Javascript_Mess
    - chadseibert 13y ago
      But why use a deliberately slow emulator as a base for all of this? Is accuracy really that important when compared to being able to run it on a wide variety of hardware? Why not just bundle some existing JS emulators together or take some fast native emulators and do the emscripten thing?

by quux 13y ago

This is interesting. If this project can output LLVM byte code, then you could also codegen to javascript with emscripten and make a web based version of a NES game.

AndyKelley 13y ago

That thought occurred to me as well, although I did not actually try it.

quux 13y ago
Cool, no need to reply to my email then :) I've been messing around with emscripten lately myself. Maybe I'll try it some time.
tibbon 13y ago
Seems like a good followup post. I'd read that. I mean essentially it would make NES games running natively in the browser with no emulator right?
- AndyKelley 13y ago
  It's not quite as sunshine and rainbows as that. For one, I had to embed an interpreter runtime in the generated code to handle some dirty assembly tricks that programmers can do. Further, the Picture Processing Unit and Audio Processing Unit must be emulated. Even worse, there are some things that fool the disassembler that many games do. And finally, this project never even attempted to support mappers, which means that there are only about 8 or 9 notable games that this could even potentially support. As is, it supports Super Mario Bros. 1 only.
  - boomlinde 13y ago
    There was a NES emulator for the Game Boy Advance that performed with a surprising level of accuracy at full frame rate. I guess the CPU emulator was a simple state machine, but the interesting thing in this context is how it did the graphics and sound. Having a pretty advanced "PPU" of its own, with the same basic types of features (sprites, tile indexing background layers), it translated the PPU register writes (with appropriate scaling, I guess) to native register writes. I'm not sure how things like collision interrupts were handled, but presumably the GBA has similar functionality. For a javascript emulator or static recompilation, similar methods could be used to set up a bunch of shaders dealing with the basic functionality of the PPU (sprites, tile layers etc). Certainly less accurate and probably missing a bunch of corner cases, but it would definitely be the fastest approach to dealing with graphics emulation.

rboulton 13y ago

Or, you could just use an emulator written by hand in javascript: http://fir.sh/projects/jsnes http://fir.sh/projects/jsnes

BHSPitMonkey 13y ago
That project's name has always bothered me... My brain tokenizes it as J SNES rather than JS NES.

acdha 13y ago

See also https://github.com/jsmess/jsmess https://github.com/jsmess/jsmess which is a port of an existing emulator codebase using emscripten

chadseibert 13y ago
I'm not quite sure what the point of this project is, as MESS is rather slow when built natively [1]. Perhaps some of the lower end systems can be emulated, albeit slowly. [1] http://www.mess.org/faq#it_works_but_it_is_way_too_slow http://www.mess.org/faq#it_works_but_it_is_way_too_slow
- acdha 13y ago
  http://archiveteam.org/index.php?title=Javascript_Mess http://archiveteam.org/index.php?title=Javascript_Mess summarizes why: it makes it as widely available as possible and lowers the barrier to entry considerably.
- derleth 13y ago
  The point is historical preservation: Putting ancient games and systems on the Web as a way to enable people to experience them, as part of digital museums, online academic papers, and such, to provide some (imperfect) context for what would otherwise be dry technical history. It's in JS because it's the only language that doesn't require plugins, and so has a better-than-average chance of running on a variety of different hardware. http://jsmess.textfiles.com http://jsmess.textfiles.com http://ascii.textfiles.com/archives/3745 http://ascii.textfiles.com/archives/3745 http://archiveteam.org/index.php?title=Javascript_Mess http://archiveteam.org/index.php?title=Javascript_Mess
  - chadseibert 13y ago
    But why use a deliberately slow emulator as a base for all of this? Is accuracy really that important when compared to being able to run it on a wide variety of hardware? Why not just bundle some existing JS emulators together or take some fast native emulators and do the emscripten thing?