Arduboy Emulator for direct access to gameplay.

Android version coming soon.


How about a bit more information here. What is this we’re looking at exactly? Is the source published on Github so the community can contribute, etc?

This maybe:

Yes, that is the GitHub location. You can find many of the development notes on the project here:

I would love to have additional contributors. In essence, BoardMicro is a Dropbox connected AVR simulator primarily motivated by .hex files. There is some work on pulling out .elf information for extra debug info. Right now my focus is getting the new native Android build working so that I can reach near actual device performance on Android. I provided the second link for an ease of use, no requirements test drive.

1 Like

What language are you writing the emulator in for Android?

Also I can’t make heads or tails of fetch()… it’d be so much better if the opcodes were documented with some comments. Pretty please.

Pretty impressive work though overall. Since it seems like 100x slower than hardware in the browser I assume we’re not going to fix it just by optimizing the Javascript? Have you spent any time there? Like counting which opcodes are the most common and seeing if those can be tightened up any?

I wish I could answer these questions in a short form, but there is a bit of history to each response.

What language are you writing the emulator in for Android?
Almost every project I do is multi-language. Currently, the Android build has a standard Android(Java) front end connected to the legacy BoardMicro Javascript AVR core through interop calls. As I have been transitioning to a simavr© based AVR core,, I have decided to make a few design changes. Currently I am compiling the new core through Emscripten into asm.js. This has been awesome for the web based version, but I am planning to write new C interop code for the upcoming Android version, because it just makes sense from a performance perspective. The source for this component will be shared in line with my original goals, but the compiled outputs will be radically different.

Also I can’t make heads or tails of fetch()…
The hosted version does not allow you to run the original avrcore.js, a core that I hand wrote and then had processed with a Closure compiler. I assume this is the code you are looking at. That Javascript code has been optimized by a robot, so lack of readability is an issue. At some point, you may find references to, a C based core I also wrote before switching over to the much better simavr.

…optimizing the Javascript?
For these reasons, I think it is relatively impossible to optimize the Javascript. Perhaps the simavr code could be optimized for this device. I have provided the Batch Size option for user to customize their UI refresh rate. Performance is highly depended upon device and browser. For instance, my best results are on Chrome with an i7 Desktop. Higher BatchSize equals higher performance.

Thanks for the interest in the project.