Web Based Gamebuino Emulator / Mobile App

[blakewford]

I've been thinking of how to respond to all of this for a few days.
For starters, while my project had a mobile direction, I do not want to limit it to just Android, so that's why I am sticking to the Dropbox strategy.

As far as ArduindDroid and direct runs you would have to ask its developer for more features, like I did on Google Play. He seemed open to it, though I understand conflicting priorities in app development.

Writing a from scratch C/C++ app using SDL is not on my radar, and I am not super interested in starting that project. I'm sure the community would welcome another emulator if you wanted to start a new project.

On a related note, I am doing a quick experiment rewriting part of the AVR CPU simulator in C++. This serves two purposes: I assume it will be easier to iron out bugs in a desktop build / test bench and I want to see if I can get more javascript performance from an emscripten asm.js compile. I'm not thrilled with my 1mhz results on mobile. But I stress that this is an experiment and may never see the light of day. If my initial tests go well, I intended to branch the code as a separate project on GitHub. Perhaps this could one day power your SDL emulator.

One way or another, the final product of the core will likely always be js. There already exist plenty of C implementations of an AVR processor. For reference, I have at least a years worth of work hours(2080) into this project, most in the avrcore.js file.

Finally, I'm really interested in custom screen resolution s, because I an trying to leverage existing Atduino / Gamebuino software. Without drivers to power them, custom screen sizes / resolutions just do not make sense in my mind.

[blakewford]

I decided to go ahead with the C/C++ port of avrcore.js.
https://github.com/blakewford/avrcore

I imagine I will still do occasional bug fixes / minor feature improvements to RetroMicro, but in the short term I am going to devote most of my time to building out this new component. Once the new piece is battle ready, I will reintegrate it with the RetroMicro source.

For those interested, here is my justification.
At the start of the project, I made a deliberate choice to build the simulated CPU in pure Javascript. The bulk of my skill actually lies in C/C++, but I knew that various forms of Javascipt / Native interop existed and at the time my primary interest was extreme portability. To a large degree that goal has been accomplished as I regularly test the core unmodified per platform on Chrome and Firefox for a decent set of disparate devices as mentioned earlier in the forum. This has helped me define reasonably solid interfaces between the CPU and UI layers which I will maintain through the transition to the new CPU build.

Where this strategy sort of fell apart for me is performance. Historically, I started creating an ATMega32u4 simulator which only ran code generated from avr-gcc, then I moved over to support code compiled through the Arduino IDE, and finally I added support for the ATMega328 / Gamebuino. The Arduino projects that run on my software stack demonstrate well, but the game engine for the Gamebuino taxes the real hardware in a way that my current stack just can't stand up to. Due to the history of the project and the lack of a performance bound use case it took me awhile to find / accept this issue. For reference, most targets I run currently peak at 1Mhz simulation.

I have been looking into resolutions for awhile now, and I cannot find any straightforward pure Javascript solutions. Granted I am no Javascript expert, but I have been tracking and improving relative performance since the start of the project. For instance, I regularly run the Google Closure Compiler on my source and merge the changes. Additionally I fix any performance related warnings from the Developer tools available in Chrome(Like breaking up the large instruction switch statement into 2 switch statements). This has the downside of occasionally making the code less human readable, but the performance has increased significantly over time. On rarer and more risky occasions, I look for instruction patterns in the compiled source of a .hex file and make assumptions about what that code intends to do(timers / interrupts) and then make performance based choices not dictated to the engine by the coded instructions. I would sum all of these techniques up as hacks and tricks which I would prefer not to have to implement, but without them my code could not run fast enough to represent even the simplest Gamebuino title.

I have been evaluating another Javascript hat trick, asm.js, in an effort to keep my software stack sane. In short this technology converts C/C++ code into Javascript, presumably with all of the best available tips and tricks baked into the final product. In order to do this evaluation, I had to rewrite a small piece of avrcore.js in C. From here I evaluated both the current implementation and the proposed using this simple program.

#include <avr/io.h>

int
main (void)
{
//Set as output pin
DDRB = _BV (3);
//Write value
PORTB = 0x1;
return 0;
}

It takes roughly 10 instructions to run this entire program. From this I generated a series of performance metrics. For the current software stack there is little difference between Chrome and Firefox, ~30 milliseconds on my test machines. With asm.js it is about the same on Chrome but ~10 milliseconds on Firefox. Here's my take away. I am not sure how familiar the audience is with various browser wars, but at times it can be pretty crazy. The morale of the story for my purposes is not to pursue anything to engine specific: V8, Nitro, Gecko, etc. The asm.js project has some adoption in other browsers, but for my use case I am not seeing the benefits cross platform. Also even if all of the platforms saw similar Firefox levels of performance increase that would only put my primary test machines running in the ~3Mhz range when I am aiming for 16. So where does this leave me?

I currently support three primary variants Desktop, Android, and HTML5. This helps me fill in strategic gaps with the other emulators, Simbuino and gbsim. To keep my niche I would like to keep servicing all of these in about the same way that I am now. Product level Android support, Good HTML5 support(My prototyping place, iOS, OSX, FFOS, Tizen, BBOS, other???), and automated test level support for Desktop. After running a series of tests, It is my belief that my best course of action is to do the work of building a native library for the Desktop and Android releases while deploying the asm.js solution to service the web. Some numbers with the test case above using the new stack.

Javascript ~30 milliseconds
Desktop(native) ~140 microseconds
Android(native) ~4 milliseconds (Snapdragon S3, circa 2011)

No sure how these numbers will scale, but I was interested in documenting them. There is too much value in giving up on js in the Desktop / Android usecases not to do it. I ran this test on an older Android device that I have rooted in order easily run custom executable files, so the performance on my Nexus 5 is likely much better.

This is why I am redoing a large subset of completed work in the CPU and taking break from more obvious features. As a bonus certain asm.js ready browsers will also see performance gains albeit less significant. For a period of time, I may make the Android build CPU implementation switchable.

Added bonus. If the Simbuino and gbsim devs are interested in contributing to the new from scratch CPU core perhaps we could now all share a common source base?

[Myndale]

Very interesting read!

Good idea with the AVR simulation code experiment, it should hopefully give you a useful code base that would be much easier to profile. I would be wary, though, of potentially misleading indications of where the performance issues really lie due to the compiler being able to make assumptions about the target platform that can't be done in managed code. Take for example your AVR core's fetch function, which is currently a large switch statement. If you were to implement that in C++ then I would expect any compiler worth its salt to implement it with a jump table, but from my own experience with Android I wouldn't rely on that or any other any behaviour from a mobile Javascript implementation. I was even hesitant to make this assumption with Simbuino, and manually implemented my own inner loop using a function handler LUT just to be sure:

Code: Select all

      public static void Step()
      {
         // if any timers or interrupts have triggered then go take care of them
         if (AtmelContext.Clock >= AtmelContext.NextTimerEvent)
            UpdateTimers();
         if (AtmelContext.InterruptPending && CheckInterrupts())
         {
            AtmelContext.UpdateInterruptFlags();
            return;
         }
         
         // get the current op code and call its handler
         var opCode = AtmelContext.Flash[AtmelContext.PC];
         var handler = OpCodeMap[opCode];
         var cycles = handler(opCode);

         // update the clock and PC (unless the op code modified it itself)
         AtmelContext.Clock += cycles;
         if (!PCModifyMap[opCode])
            AtmelContext.PC += OpCodeSizes[opCode];
         if (AtmelContext.PC >= AtmelContext.Flash.Length)
            AtmelContext.PC %= AtmelContext.Flash.Length;
      }


If the Simbuino and gbsim devs are interested in contributing to the new from scratch CPU core perhaps we could now all share a common source base?.

I've msg'd you about this offline.

[jonnection]

Allow me to butt in again with a stupid question from someone who designs plumbing for living.

A hex file is avr assembly = static code. Then you take it to a dynamic runtime java compiler.

Stupid q 1: if all code is interpreted from avr bytecode, how would it even be possible for a java jit to optimize?

Stupid q 2: why not translate static avr bytecode directly to static java bytecode before runtime, instead of interpreting at runtime?

I never use java so i might not make a lot of sense.

[jonnection]

Now that I really think about it I kind of see why it would be very difficult to do. For starters you'd have to control execution speed somehow. Maybe java+native core is indeed he only option here. Just thinking aloud, about things I really know very little about.

[Myndale]

Those aren't stupid questions at all, this is exactly the kinds of things the developers of emulators do.

Converting the static HEX files into native code at run-time isn't always possible. In the case of Simbuino, for example, all the op-code handlers are written in C#. I currently burn a considerable number of cycles figuring out at run-time which registers each op-code is working with, and a pre-generated routine for each op code that hard-codes those constants would definitely be faster but I have no way of compiling that C# into CLR byte code in the app. I'd have to re-write all of my handlers and hand-code them in byte code myself....certainly possible, but not high on my priority list at the moment. blakewford would find this much easier though because javascript can generate and run its own script, but he's always going to be dependent on the (often crappy) browser to then convert that script into efficient native code afterwards. In both C# and Java though there areadditional security issues that may prevent this from working in certain cases, mainly to stop somebody sneaking malicious code into an otherwise innocuous application.

With regards to your first question there is a lot more going on than simulation of the core. The AVR code is, as you say, fixed and cannot be optimized further (actually technically this isn't always true, but that's another area). But in addition to the core and the overhead of running it you've also got a number of fairly complex timers that are constantly running, interrupts that are being fired at random times from all over the system, the i2C and SPI buses that are sending data all over the place and of course the simulation of the various peripherals.

[blakewford]

I figured I should give a quick update since it has been about two weeks from the last. I have integrated the new core into the main application along with a switch to toggle between the old pure Javascript implementation and the new C/C++ based backend. It is not turned on by default and it is only available by syncing and building the source.

As of now I have ~45 or so instruction implemented, not quite enough to make it through my basic screen test. However I am confident that everything will work, and that it is just a matter of time before I get the rest of the instruction set implemented. My goal is to have the bulk of the work done by May with minor updates like this in between now and then. In early testing I can see many improvements, but none are really ready to demo just yet.

I am going to do a phased roll out in early May, gradually shifting everything over to the new Javascript backend. Once the Web based and Android apps can stand up competently using the new JS code, I will begin migrating the Android app over to a pure native C library. I expect this to yield awesome performance improvements. I want to do the extra Javascript update to the Android app as I expect performance will improve significantly with little effort and I am unsure how long it will take to refactor the app to use a native library in place of the Javascript version it uses now.

As always any thoughts or suggestions are always welcome.

[blakewford]

Seems like forever since I have posted.

I am still making progress, though less than I had hoped for. As of today, I can almost draw to the screen. I have had some work/life balance issues of late that stall speedier improvements. That being said, I am always on the lookout for co-developers, which leads me to the ultimate point of my post.

I will be exhibiting the apps at the Austin Maker Faire, promoting a petition to get some level of simulation included in Arduino Create, the upcoming web-based IDE. If interested in such a feature, please sign.

Petition and related information
https://t.co/9b7WhhHikH

Maker Faire Info
http://austinmakerfaire.com/maker/starlo/

[Hark0]

Signed!

[Hark0]

Hi guys!

Please sign a petition from @blakewford...

It's free, and fast (take around -1 min.)