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

[erico]

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!

[Sorunome]

Have you considered using emscfipten for this project?

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

[Sutchig]

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?

[Myndale]

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?

[Myndale]

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.

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.

[Sorunome]

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

[Myndale]

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.

[Sutchig]

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

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?

[Myndale]

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!

[Sutchig]

Many thanks

tested with current Firefox and:
simple sd.init() sketch (SDFat)
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