Emu48 Javascript ?

[sunhp]

Hello All,

A good way to spread the HP48 huge games and programs collection (lost since HP Prime move) could be having a Javascript version of Emu48.

One say pretty ambitious (not to say impossible) ?

Check out those awesome TiXX Dark sided online emulators :

https://www.cemetech.net/projects/jstified/
https://www.ocf.berkeley.edu/~pad/emu/v11.html

Hope someone could do it or at least start doing it ;-)

Julien
http://jadegame.com/games/hp48/

[TheKaneB]

the best way to have a solid JS engine would be to write one from scratch, maybe translating an existing C or C++ engine.

Another way, not so great but "hey!", would be to use an automatic translator such as this one by Mozilla: http://kripken.github.io/emscripten-site/

https://kripken.github.io/mloc_emscripte...dex.html#/

If someone would like to start a project like this, I might bring some help with my C++ and JS knowledge, but I have no spare time to do it myself unfortunately.

[sunhp]

Wow thanks for sharing this awesome project : EmScripten

I wonder how awesome could a version of jsEmu48 be and I think it could be very nice.

I have fix a few things inside the Emu48 Mac port project to run on newest macOS's versions 10.10+ so I see a little the emu48 logic.

The next thing to do is probably to port Emu48's Window/Mac related code into SDL to get at least the basic stuff (LCD Screen, Keyboard, Import Object..)

Then convert the whole project from C to JS using Emscripten..

[TheKaneB]

If you want a very good HTML / JS emulator, the best thing would be to convert to JS only the emulation engine and to export all the keyboard logic to the HTML side, and the display rendering to a set of canvas routines. Web Storage API could be used to transfer files between the PC and the emulated calculator.

It's not trivial, but it's not too difficult either.

[TheKaneB]

As a side note: EmScipten is fully supported by Mozilla and it has been used to successfully port the Unreal Engine to Javascript and also have been used to run a JS-converted version of the ffmpeg codec suite to decode H.264 streams in real time. The performance of this solution is really good.

[sunhp]

(01-18-2018 11:29 PM)TheKaneB Wrote:  As a side note: EmScipten is fully supported by Mozilla and it has been used to successfully port the Unreal Engine to Javascript and also have been used to run a JS-converted version of the ffmpeg codec suite to decode H.264 streams in real time. The performance of this solution is really good.

And also Quake3 : http://www.quakejs.com/
I tried it and it's so incredible.

[TheKaneB]

Quake 3 is at least 2 orders of magnitude less complex than Unreal Engine

[sunhp]

(01-19-2018 09:06 AM)TheKaneB Wrote:  Quake 3 is at least 2 orders of magnitude less complex than Unreal Engine

And Quake3 is 2 magnitude orders of my own home made 3D game & engine Halloween 3D : http://jadegame.com/games/halloween/

[sunhp]

I found this one HPEMU (C) Daniel Nilsson 2002, written in C and Allegro and probably more emscripten portable :

https://sourceforge.net/projects/hpemu/f...mu/v0.9.0/
http://liballeg.org/
Allegro + emscripten : https://listengine.tuxfamily.org/lists.l...00023.html
Allegro + emscripten quick demo : http://zxstudio.org/projects/allegro/ska...ter_r.html

[TheKaneB]

I don't know, Allegro is a dog its API is very badly designed. The key here is to NOT port the Allegro stuff, but only the core emulation. Allegro is just a bunch of routines for display and keyboard management, the same routines that you would probably want to rewrite from scratch anyway, to take advantage of all the HTML goodies (such as canvas)

[sunhp]

(01-19-2018 11:14 PM)TheKaneB Wrote:  I don't know, Allegro is a dog its API is very badly designed. The key here is to NOT port the Allegro stuff, but only the core emulation. Allegro is just a bunch of routines for display and keyboard management, the same routines that you would probably want to rewrite from scratch anyway, to take advantage of all the HTML goodies (such as canvas)

I know but it's ok since it's just a bridge. Go ahead and let me know how a C code can display pixels to a canvas without using SDL or OpenGL?

[TheKaneB]

That's the easy part.
The emulator engine should have some sort of framebuffer for the display, which usually is just a byte array in the form of:

int displayHeight = 160; // or whatever
int displayWidth = 120;
uint8 * frameBuffer = (uint8 *)malloc(sizeof(uint8) * displayHeight * displayWidth);

The emulator will set / clear a pixel with code like this:

void setPixel(int x, int y, uint8 value) {
frameBuffer[x + y*frameBufferWidth] = value;
}

When the rendering is completed, the C code should call some kind of callback function telling the UI code that it's time to refresh the display, and it will pass the frameBuffer object.

That's the right time to handle the object over to the canvas routine. You will just copy the pixels and apply the necessary scale and filter.

Please note that after the engine will be converted from C to JS using EmScripten, the framebuffer object will be converted to a similar javascript array in the form:

frameBuffer = [1, 0, 0, 1, 1, 1, 0, 0, ....]; // we just have monochrome pixels here

so the glue code to render it into canvas will be very short:

var canvas = document.createElement("canvas"),
ctx = canvas.getContext("2d"),

// Get a pointer to the current location in the image.
var palette = ctx.getImageData(0,0,160,120); //x,y,w,h
// Wrap your array as a Uint8ClampedArray
palette.data.set(new Uint8ClampedArray(frameBuffer));
// Repost the data.
ctx.putImageData(palette,0,0);

Actually, you might want to scale the pixel values from 1 to 255 and invert their values (ie: a clear pixel will have value 0, but 0 is usually associated with black and you want white instead).
Anyway, that's just little details that you can figure out once you know exactly the data format of the framebuffer.

[TheKaneB]

Anyway, I don't know the differences between the various emulators of the 48 series. Is there a "best" one? If so, I would ignore everything else and concentrate my efforts on the best available emulator.
Don't go for an emulator just because is "easy", go for the ones that are "good"

If the code is too difficult to follow I will try to help as much as I can. I worked on so many projects ranging from "pretty decent" to "oh my god, who's the dog who wrote this junk?", so I have developed a spidy-sense for figuring out shitty code

[sunhp]

(01-20-2018 01:13 AM)TheKaneB Wrote:  Anyway, I don't know the differences between the various emulators of the 48 series. Is there a "best" one? If so, I would ignore everything else and concentrate my efforts on the best available emulator.
Don't go for an emulator just because is "easy", go for the ones that are "good"

If the code is too difficult to follow I will try to help as much as I can. I worked on so many projects ranging from "pretty decent" to "oh my god, who's the dog who wrote this junk?", so I have developed a spidy-sense for figuring out shitty code

Actually it's more a matter of removing the Windows.h / MacOS code rather than "easy" or "hard" core emu code. Emu48 is a genius master piece code made by Sebastien "sebc" Carlier in 1995 (epita).
In other hand hpemu seems very good with a few Allegro stuff easily removable I think.

[TheKaneB]

Unfortunately I don't have time to dig into the code right now, but as I understand, Emu48 should already have some sort of fork for iOS and Android, so maybe someone has already done a bit of refactoring? If that's the case, one can start from the Android fork, which should have all the Windows stuff stripped down and the UI should be (hopefully) isolated from the engine code.

[sunhp]

Actually iOS and Android Emu48 versions authors didn't share their sources and they are selling/distributing it on the AppStore and PlayStore. Good point to notice any Emu48 fork has core emu code isolated and written in pure C by Sebastien Carlier ( was a MS DOS project at start ).

Christoph Gießelink did a LOT of improvements on the Window version and Cyrille de Brebisson also add a lot of Apple stuff and also HP49 flash memory addition and probably other things I miss.

Emu48 Core code is complex to follow and use a LOT of genius optimisations you wont want to know I need to dig more into the code though and as CTO I'm heavily busy too.

As a side note my little contribution was based on a Project Lead Da Woon Jung and a port by Pierre Tardy on Mac OS 9, my contribution is buildable and runnable under latest macOS 10.11 and that would be a good starting point for open-source iOS version, if some developer would.

[TheKaneB]

Too bad that the mobile versions are closed source. I assumed they all shared the same license, but apparently I was wrong.

Anyway, it looks like neither of us have much time to play with it! I'm in the middle of a side project whish is eating all my spare time, and that I absolutely have to finish ASAP, but when I'm done with it I might take a closer look at this whole js 48 emulation idea of yours

It's been a while, at least 3 or 4 years, since I've done any serious work in C or C++, and a departure from the routine boring web & apps development may be a good idea

[sunhp]

Sounds great and I plan to check out ASAP how Emu48 core could run with an array as LCD screen. Great to share ideas with you and Emscripten is definitely a must try ;-)

[sunhp]

TIMER.C has contains Windows.h code such as :
uT2TimerId = timeSetEvent(uDelay,0,&TimeProc,2,TIME_ONESHOT)

And here is the MacOS version in Objective C :
uT2TimerId = [[NSTimer scheduledTimerWithTimeInterval:(uDelay/1000.0) target:self selector:@selector(TimeProc:) userInfo:nil repeats:NO] retain];

There are other OS Windows specific ( or to Mac ) C files to be refactored dunno how before being able to run through Emscripten the whole project :

THREADS.C
FILES.C
KML.C
STACK.C

Definitely not an quick job to convert all this stuff from Emu48.

[sunhp]

Droid48 Android is open sources : https://github.com/shagr4th/droid48
Let's check that ;-)