Simbuino4Web released (was Simbuino emulator running in...)

I don't normally like to announce things like this before they're ready but here's a sneak peak at a work-in-progress. I've got some upcoming work on an unrelated project that involves migrating some back-end web code client-side and it dawned on me that Simbuino would make an ideal test case. This is an initial port of the core emulator code to Javascript, running under Chrome on a Surface Pro 2:



(Once again you'll have to ignore my total inability to play games and record video at the same time). No sound yet (that'll be next) and there's still some major optimization work to go in, but I'm quietly confident that it can be made to run at full-speed on current high-end mobile phones. Never as good as the real thing of course, but it should open up Simbuino development to any moderately capable device that has a web browser.

UPDATE: This is now playable at http://simbuino4web.ppl-pilot.com/. Input controls are keyboard only, I'll add some buttons soon. Only been tested on Chrome, it does run on Internet Explorer but very slowly and with no sound.

Simbuino goes cross-platform! Thank you Myndale. The need to reboot or screw around with a damned Windows virtual machine is a real obstacle for me. Looks like this problem will go away soon enough. :)

This is looking quite awesome!

Perhaps you could make a cross-platform offline version using node.js?

Does it emulate sd cards?

Very nice, the performance on the video looks quite good on my end. :)

SD card emulation would indeed be really, really great ;)

Love it.

The SD code has already been ported but I'm not sure how to do partial reads of local files in html5, so the file read itself is currently commented out. I'm loading local HEX files no problem, but I'd like to avoid loading entire IMG files into the browser's virtual machine if I can help it.

I did manage to test a few games on my Samsung Note 5 today, it's running at around 12Mhz which is about half that of my desktop machine. I actually implemented a JIT compiler on almost every instruction expecting a massive speed-up and it actually slowed down! No idea what's going on there, I suspect that Chrome doesn't do it's own JIT on scripts that are generated at runtime and "compiled" with eval().

I've put this online now if anyone wants a play, there's a link in the first post of this thread. Lemme know what you think! :)

Hi Myndale, tested it with a fex HEX on Chrome, runs smoothly ;)
Have you planned making the code available? I'd love to see an Arduboy version of this web emulator!

Nicolas

Ah yes, a little complaint sorry ;)
I have a French AZERTY keyboard, with it your emulator controls are super hard!
Look what my fingers must do: :lol:

Hm, rendering is blurred for me, instead of pixilated....

Using latest version of firefox

Other than that, it seems to be running at full speed which is pretty awesome, great job! :D

mougino wrote:Have you planned making the code available?

Already have, it's got its own folder in the Simbuino github repository:

https://github.com/Myndale/Simbuino/tre ... mbuino4Web

All the relevant stuff is in Views\Home and Scripts\Views.

mougino wrote:I'd love to see an Arduboy version of this web emulator!

Not really that interested in Arduboy myself (not enough time for Gamebuino as is) but if anyone else wanted to give it a crack I don't think it would be that much work. The buttons class would have to be changed to reflect the different pins, and the audio code might be on a different PWM pin; the only real change would be a rewrite of the Lcd class to support the SSD1306 OLED instead of the 5110 LCD. From the the spec sheet it looks pretty straightforward.

That's why every game should default on ESDF. =)

mougino wrote:I have a French AZERTY keyboard, with it your emulator controls are super hard!

Changed now as per Drakker's mapping suggestion, thanks for the heads-up.

Sorunome wrote:Hm, rendering is blurred for me, instead of pixilated....Using latest version of firefox

Try now, I was missing a firefox css setting for canvas up-scaling.

Drakker wrote:That's why every game should default on ESDF. =)

Good tip. Done!

I had a little trouble keeping my browser focused on the screen element so that control input would be recognized. Possibly change focus to that element on load? Basically I had to click on the screen before the controls started working. Other than that, I was very impressed.

Can you elaborate a little on the tech behind your browser transition? Is all of the code now client side, or does the solution require server deployment? Did you use a cross compiler for C#?

Myndale wrote:

Sorunome wrote:Hm, rendering is blurred for me, instead of pixilated....Using latest version of firefox

Try now, I was missing a firefox css setting for canvas up-scaling.

Yup, it's working now, awesome!

Is there a way to emulate an SD card, yet?

blakewford wrote:I had a little trouble keeping my browser focused on the screen element so that control input would be recognized.

Should be fixed now, thanks!

blakewford wrote:Can you elaborate a little on the tech behind your browser transition? Is all of the code now client side, or does the solution require server deployment? Did you use a cross compiler for C#?

It's all client-side, if you do a page save you can run it locally.

I did the port by hand but it wasn't as much work as I thought it was going to be, the trick was to first get the original C# code as close to Javascript as I could in order to take advantage of the compiler's error checking instead of waiting for things to blow up at runtime in the browser. First step was to strip away everything that wasn't part of the core engine. Next step was to change any code that relied on C# language-specific features i.e. op code handler attributes (which I replaced with a lookup table along with the handlers themselves) and index operators (which I replaced with get/set/get_bit/set_bit functions); this was probably the most time consuming part of the port but it was just a matter of working through the errors that cropped up when I tried to compile. One of the last stages was replacing all scalar types with doubles, since that's all javascript uses; this created a compile time error everywhere I did an array lookup so I put a cast in all those places and did a project-wide delete of "(int)" when it came time for the actual port.

A few other things helped...I did everything in a separate local branch and made frequent commits along the way so that if I discovered something had broken I could keep rolling back until I found the commit that caused it (although in the end I only had to do this a few times). I eventually reached a point where errors were occurring a few hundred thousand cycles into execution and the lack of an integrated debugger was making it difficult to track them down, so I modified the original C# code to check every single variable in the context after each cycle (RAM, flags, PC etc) and dump the changes to a log file. This took about 40 minutes to log 1 second of execution time but it only had to be done once and after that I knew the exact cycle that every single issue occurred on. If I were to do it all over again I would do this step first because tracking down the remaining bugs was trivial after that.

So yeah, maybe somewhere around 15 hours work all up but not too bad considering, and the code's now in a state where a port to Android/Java (say) would probably only take an hour or two. It'd be interesting to do that alongside a Xamarin version using the original C# code to see how they compare performance-wise.

Isn't there like 10 native javascript engines available for Android? I don't think you have to use Java for that. Anyway, with the way Oracle is handling Java, I'd keep away from it.

Btw, it works amazing on my side with Chromium on Linux. Now all I need is some free time and I could maybe finish a project or two. =)

Thanks for all your efforts!

Works like a charm on the desktop, it even makes those faster games easier to play.
I can also run it on chrome on my galaxy note II at about 25fps.
I can´t play obviously because of lack of keyboard but it works fine. Sound stuttered a bit probably cause of the fps.

Great work there!

Have you considered using emscfipten for this project?

Or, well, on of the c# to js compilers

tested Digger with Firefox and it works great :)
What does the fps mean? If its above 20fps, then not slower than Gamebuino? I guess so, just wanna be sure ;)

I have problems with sd-card access.
Tested b-rally and loader with an image which works well in Simbuino (Win).
Firefox&Chrome, Win10
There is no error at the JS-Console (except missing PortRegister.htm)
The image is loaded (verified via taskmanager -> RAM usage), but loader prints: insert sd-card, and b-rally "hangs" :(
what game should work?

Sorunome wrote:Have you considered using emscfipten for this project? Or, well, on of the c# to js compilers

Haven't used either, to be honest. Have you had much experience with them yourself?

Sutchig wrote:What does the fps mean? If its above 20fps, then not slower than Gamebuino? I guess so, just wanna be sure ;)

The FPS is a bit of an arbitrary metric I use in the absence of proper display refresh circuitry, if it's running at the same speed as Gamebuino then it should show around 60. On other platforms the game update rate is typically tied to the refresh rate in order to minimize tearing, which historically has been at least 60 (the exception being when you decouple the world modelling rate from the graphics, but I digress). The 5110 LCD device doesn't support refresh notification or even have a fixed frame rate, and while Rodot's library drives the screen at a default of 20 some games do change it for greyscale etc. So what this version of Simbuino does instead is simulate CPU cycles in chunks of 1/60th of a second i.e. ~267k cycles per "frame", and the LCD just updates as-and-when it receives the data. This gives a standard way of measuring performance irrespective of actual frame rate and ensures that responsiveness of the key press handling is never delayed by more than 17ms, just as if you were running at "60fps". If the simulator says 60fps then it means it's running at 100% speed (i.e. ~16,000,000 CPU cycles per second). On slower machines it'll drop under that and the sound will start to break up, on faster machines the frame rate will be clamped.

Sutchig wrote:I have problems with sd-card access.

Sorry about that, there's a bug in the IMG code and I accidentally pushed a version out with all that stuff enabled before it was working properly. Thanks for the heads-up, gimme a day or two and I'll post back here when it's fixed.

Myndale wrote:

Sorunome wrote:Have you considered using emscfipten for this project? Or, well, on of the c# to js compilers

Haven't used either, to be honest. Have you had much experience with them yourself?

No, I don't have any experience with that, sorry.
However, if they take use of asm.js (i know emscripten does) then you have near-native speed with your compiled JS.
Also, due to compiler optimizations compiled JS usually performs better that self-written JS.

Another way to increase performance would be to minify the JS :P

Sutchig wrote:I have problems with sd-card access.

This has been fixed now. I've also added the bootloader and support for the SPM instruction, so LOADER.HEX is can now list games and from an IMG file and flash them to memory. However, I still haven't gotten around to implementing the watchdog timer, so although the games are actually being written to memory the bootloader has no way of resetting the device in order to start them. Oh well, one thing at a time...for now though reading data files off SD should work fine.

Thanks, SD-card access with petitfatfs works with Firefox (Win10) :)
Tested with b-rally and the old loader you included.
Thanks :D

whats not working is access with the new loader (sdfat library??). It doesn't work with Win-simbuino too. Maybe the library uses some different sdcard commands?

Sutchig wrote:whats not working is access with the new loader (sdfat library??). It doesn't work with Win-simbuino too. Maybe the library uses some different sdcard commands?

Actually it was due to my IMG code presenting the card physically as an early generation device, which I did in the (evidently) mistaken belief that it would increase the likelihood of compatibility with all SD libs. For some reason sdfat just doesn't like it. Fixed now in the HTML5 version, I'll roll it out to the Windows version sometime tomorrow. Thanks for the help with testing!

Many thanks :)

tested with current Firefox and:
simple sd.init() sketch (SDFat) :P
wolf3d (petitfatfs)
current loader.hex (SDFat)

all works fine :)

GB-fat by Sorunome (viewtopic.php?f=13&t=3392) should work, too. As its derived from SDFat if i remember correctly.
Will test it as soon as possible.

I'm really impressed what possible with JavaScript and Browsers today. (like JSLinux)

//edit: simple tinyFAT-test-sketch (open file and read 80bytes) works :)

Sutchig wrote:Many thanks :)

tested with current Firefox and:
simple sd.init() sketch (SDFat) :P
wolf3d (petitfatfs)
current loader.hex (SDFat)
all works fine :)

GB-fat by Sorunome (viewtopic.php?f=13&t=3392) should work, too. As its derived from SDFat if i remember correctly.
Will test it as soon as possible.

I'm really impressed what possible with JavaScript and Browsers today. (like JSLinux)

GBFat is derived from TinyFAT

Also, if this is working i might have to write some scripts to automatically generate IMG files so that i can acutally test the community RPG thing in an emulator, heehee

I don't check the forum for a bit but then this! Heck yeah :)
I'll attempt playing this on my tablet later, seems cool.

I played a little bit with the js-code and added I2C-Master mode (kind of) and a (very basic) mockup of an ADXL345-accelerometer device.
Thanks to the very good code (my opinion ;)) and comments by Myndale in the original Simbuino4Web-code, the real problem was to read the atmel-spec according TWI "backwards" :)
the fake device will not use any of the settings made by setting registers to the device (for instance: range, powermode, interval, doubletap threshold (it doesnt even support doubletap ;)) The only flag used is "powerup" to add the JS event listener.

http://www.scmar.de/Simbuino4Web.htm

I added a "I2C-Accel-Test" button with a little "game": try to get all balls in the hole... no startscreen (for use with smartphones), no gameover, no ..., just a test :)
it needs a device with builtin accelerometer (as most smartphones/tablets/convertibles) has, and a browser which supports deviceMotion event. (FF/Chrome...). You may want to lock screen orientation ;)

Oh, and for debugging purposes i redirected Serial.write()... to console.log().

Performs greatly on my note II.
It rocks on an average of 15-20 fps, reads the accelerometer perfectly. :)
edit:better img size ;)

Excellent work Myndale, thank you.
Quick question, I have an Apple MacBook, and have been successfully running Simbuino4Web today, however is there an offline emulator I could use on my Mac?

Leonskibeat :ugeek:

Hi :)
You can save the website local and load from there. There is no interaction with any server.

Yet again, thank you Sutchig - you're such a star!
I never knew that downloading a page as archive would include the code to run things;
all this time I just thought it was text/images/formatting..
Darn I learned something today - thank you Sutchig, thank you Myndale!

Kind regards - Leonskibeat :ugeek:

OK, I tested the emulator in Microsoft Edge, what I normally use. The screen is blurred, and two or more channels playing at the same time sounds...kind of like an an Atari 2600, or similar. It's still pretty awesome though. :P

Hi Myndale,

I'm using your emulator quite often to test my devs. That's a great app!
Based on what you already did, I'm trying to think about a way to propose our visitors to play games directly on our website, without downloading hex files, and load them again after.

Something like a combo-box (replacing the file input field) where you could select the game you want to play to, and then just click 'Load' to launch the emulator.
That, or directly load a .img containing all the games...

Is that something feasible, or am I dreaming? :)

Putting games in a drop-down list would be very easy, but you'd need to know some Javascript. I'm already including jquery and jquery ui so you could easily use that for the list itself along with a handler that gets called when the user selects a new game.

The main change would involve replacing the OnLoadHex function in Simulation.js. As it stands that function currently creates a 'FileReader' object to read the HEX file off disk:

Code: Select all

var reader = new FileReader();
reader.onload = function (e) {
   try
   {
      self.CurrentFirmware = reader.result.replaceAll("\r", "").split("\n")
   // game gets loaded here with the HEX data in self.CurrentFirmware


To load games off a web site all you'd have to do is replace this with an AJAX call to pull the game off a web site instead, so something like this:

Code: Select all

$.get( URL_OF_YOUR_HEX_FILE, function(data) {
   self.CurrentFirmware = data;
   // load game here as per usual
});


Thanks for this!
I'm not really familiar with these languages, but I'll try to test things!

I'll let you know when I'll have something working! :)