DB48X: HP48-like RPL implementation for DM42

[c3d]

Hi Franco,

(05-20-2024 05:03 AM)sunpazed Wrote:  Hi Christophe — you might be interested in this little side project of mine. As a proof-of-concept, I built a version of your simulator that runs in the web-broswer (and therefore on mobile devices). I found that Qt runs fairly sluggishly after some time, so that was part of my motivation. It's also quite nice to use db48x in the palm of your hand (as I don't yet have a dm42!).

Here's what it looks like on my iPhone;


Try it in your browser here — the simulator can be run fullscreen by selecting "Add to Home Screen" on iOS or your Android device;
https://sunpazed.github.io/db48x-wasm/bin/index.html

Be warned that there are many bugs, with the simulator hanging when accessing system services (help, save state, system menu) which are not implemented .

And finally here's the repo for review; https://github.com/sunpazed/db48x-wasm — apologies in advance for butchering your excellent code.

Your idea and a lot of your code (notably the index.html and emcc.h files) were integrated in the main repository. I could not merge your code directly because you started with an initial commit that had a different structure. To test it, just use "make wasm", and this should be all you need.

I hope you won't mind if I added you to the list of authors. I tagged the first WASM commit with "Co-authored-by" to give you some credit.

Then, I did another iteration where I used the pthread emulation in emscripten.

The upside is that it fixes most of the issues you reported in your proof of concept, e.g. the system menus not working.

The downside is that it requires the web server to enable HTML COOP and COEP, otherwise the necessary WASM features are disabled by the browser. This is semi-trivial to do, and a simple Python web server doing that is included in that commit, but it't worth keeping in mind.

Another aspect that I'm looking into is that the JavaScript event loop is a bit busy, since it calls window.requestAnimationFrame. You had some code that rate-limited the fetching of the LCD buffer. I replaced that with a mixed use of window.setTimeout to fetch keyboard / LCD status, and only calling window.requestAnimationFrame when the screen actually changed. This improves things a little bit, but I still see my desktop browsers pegged at high CPU (tested with Safari and Brave).

My concern here is that this makes it a "dangerous" solution for mobile phones, where this application is likely to train the battery at high speed. I'm likely to throttle the refresh rate on the JavaScript side in a way similar to what happens on the RPL side, i.e. decrease the polling frequency over time.

In any case, if you have time to review and comment, I'd appreciate it. And obviously, if you want to keep improving this aspect of the work, we can do that on the main DB48X repo (unless of course you have reasons to want to keep your own fork).