Well, I am interested what kind of modifications you did, maybe useful for other people as well. And I should know what kind of keyboard layout you use on the host OS

Please have a look at "function keyPreTrans(evt)". As I've written, there are some workarounds implemented there, for example firefox uses some key ids differently than most of the other browsers. Also, you can see the comment there about "Hungarian keys". This is tried to handle the most common situation, ie ';' and ':' on Hungarian host OS kbd layout ... You can see that the "if" block checks for kc == 0 that is: key code zero. Those are keys (you mention the problem as well) do not have keycodes, then the charcode is asked, and I "fake" a keycode for them used to look-up in the kbd matrix JS object. As on EP128 ';' key is right to key 'L', this is the situation with US layout, however, on Hungarian kbd, the key right to 'L' is 'é'. So that's why I tried to handle the situation for people having Hungarian kbd layout, which is a common case on the Hungarian forum The problem here, that kbd layout cannot be easily "detected" and of course I can't workaround all possible keyboard layouts etc (without the knowledge of host OS kbd layout) soon there would be even conflicts.

I think, the more rational solution would be to use symbolic mapping, so no knowledge is needed on the layout and  "physical arrangement" of keys, and everybody can use the native layout as they like, with the meaning they would use the kbd on the host OS otherwise, no problem. However the minor issue here, that keys like SHIFT then would be virtual, and also it is not so much possible to give only a "press of shift key" towards the emulator, as shift is only "calculated" from the given keypress by char code (rather than key code, which is done with the current positional mapping). It can be a problem, if an EP software checks only shift. Also, virtual shift is tricky, ie you must simulate to delay the keypress of the normal key, and emulate the shift press first, so EP surely will see the shifted key when scanning the kbd matrix. I even had problems with SymbOS, if I remember correctly, ALT is used for some kind of mouse emulation stuff or such (I can't remember now), but ALT in once is not passed for the browser, as it's a special key on my over-configured Linux desktop. So I even use F9 as an alternative solution for sending the "ALT key press" notification. You see, though keyboard emulation looks so trivial, if you go in details, it's quite complicated. And the fact that browsers have their own idea sometimes how key events in JS are handled, what the IDs, etc, it makes it even more complicated. Eg "function keyPress" is only used in keyboard.js as it seems some browsers / browser versions has the "interesting" feature to generate only up/down event for key or press event, some keys generates both ... Some of them generates events causing "stuck" of a key, as you can see in comments in "function keyUp" for example about my workaround this problem.

But sometimes the keys give strange results and I have to reset the JSEP. Maybe some error on the correction subroutines, not a big problem by now.

Hmm, interesting, what kind of strange results do you mean here?

And does it happen with the original JSep too, or only with the modified version by you? If both are affected, is there any noticeable difference?

One thing is important, but maybe it's trivial: do not ever put a "0" into "var keyCodes" object, I mean no line can start with "0: { ...".

Also, if you map a key to a modifier key on the EP (I mean, like shift), then of course that key will function as a shift. CapsLock is even more interesting of course.

Have you done any modification in the code other than editing the "mapping" in "var keyCodes" object? Ok, just read in your msg, that not so much, OK.

I think, some of the problem can caused by the different JS key event behaviour of Android compared to - for example - a "normal" desktop PC. For example, if keyup even is not generated (but keydown is) of course the emulation won't notice ever that you released the key. In theory, you can see this quite easily. Again, look at the line "KEY ...." below the status line (below FPS etc). You can notice "KEY ^" and "KEY v" like lines if you press/release some keys. Here, the "^" and "v" want to symbolize little arrows, ie "v" is down (key is pressed down) and "^" is up (key is "released up"). If you see a key do not generate the release event, than that's a problem, indeed.

If you have problems like these only with the modified version, please try to modify only a single key at one time, and check if it caused problems.

I found an interesting mistake in my mapping: backtick key ` is meant to be mapped as CapsLock (see the comment, with key code 192) but it's mapped to key 'N' for some reason. It should be corrected Btw, the problem with mapping host OS CapsLock as EP128 CapsLock is the fact, that maybe CapsLock is toogled outside of the JSep control (another browser tab, window, etc) so the function of CapsLock will be "inverted" then. That's why I thought, I map another host OS key as EP CapsLock, which is not used otherwise, that is the backtick key here. So, please be careful, I can't say I didn't do mistakes with the mapping matrix, there can be!

An interesting (well for me ...) story: on one of my Linux machines (only one!) using the shift caused to be stuck all the time. I had no idea what happens, then I noticed, that some other - even native code! - software are affected too. It turned out, that some input method defined on the Gnome/Unity desktop caused this behaviour (unfortunately I can't remember which), but even the low level X event dump utility I could see the problem. It seems keyboard handling, emulation etc is kinda black magic everywhere a bit ... If you put all those quirks, workarounds, and problems together I already told about ...

But I could find my bug report on this issue to the VICE (= Versatile Commodore Emulator) team, if you're interested:

https://sourceforge.net/p/vice-emu/bugs/383/

Note, that it's not an JS/in-browser stuff, but a native application and still it was affected! So the issue can be even deeper than just my JS code, or even the browser itself. Huh.

Is for that "esoteric" behaviour you find on every device, better that every owner do his own assignments.

You can't wait for an standard or try to parse yourself all the incompatibilities. Better make some form of keys editor.

Making virtual the keyboard you lose that precious FPS you have gained.

I have been testing JSEP with Chrome for Android. It is disaponting, at least it is half fast than Firefox.

One of the 00 keys now gives a value, and again ":· is lost.

Well, the the problem with saving that it is simply not implemented, ie no writing support in the WD/EXDOS emulation at all. So it's actually not a protection but the lack of support. Emulator "fakes" a read-only disk situation so at least the emulation does not crash Anyway, saving a program is always a problem with a web emulator since web stuffs without specific server side support is not designed for "saving" at all. You can think about that, if you have a web page at a provider, you can visit the page via HTTP, no problem, but it's load (download) information. To upload ("save") something, HTTP is not enough and FTP or other solution (like WebDAV) is needed. So there is a fundamental problem here ... JSep is thought (by me) as a tool to demonstrate running programs, but I would not use it to develop anything, ep128emu etc is much better for that, JSep is only a much simplier web presentation tool, we can say, for an already ready stuff.

At the other hand, in theory it's possible to form a disk image in "localStorage" of your browser (in theory it's persistent, even if you restart your browser, for example, but it will only work with that browser on that device since it's "local"). It would need to re-write some parts of JSep, and there is another problem: you're about the plan to use JSep locally, ie file:// URLs, not from a web server. The problem here, that web is basically designed for the network, ie I am not sure JS scripts from file:// can even have localestorage feature, as it would use - again - the notion of the domain of the URL. But I can be wrong here. There are up-coming standards in JS for example the File API etc, but first of all I am not familiar with them (yet) and I am not sure about the support (last when I read about it, it was read only with Firefox - again the ugly read-only stuff, but you can understand it, from viewpoint of web, "saving" something - ie writing - is dangerous, you wouldn't like a random visited web page start to write your files, or files on other servers at their own, that would  be a very huge security problem).

Uploading anything to my page is not needed at all. JSep is capable to load its files from anywhere, which is accessible via Internet and http. There was a thread on the forum about this somewhere, but maybe it was Hungarian. The only problem with this, is the AJAX cross-domain security policy of the browsers. Ie, a script cannot initiate AJAX calls to another domain. It affects JSep too, of course. The solution, that on your server (where you want to access stuffs from, in JSep) you need to emit a special HTTP header which instructs the browser to allow the access.

Access-Control-Allow-Origin: *
As you can see, there are several "interesting" problems with web based stuffs if you want to use them as "local applications". There are products like FirefoxOS which would do everything (ie, even the dialer is a HTML page) with web technologies on a smartphone, but it's not so much widespread and the special extra APIs for this is not quite a standard to be supported by other browsers. As far as I can see, the tendency that more and more techniques are invented to solve these kind of problems on the "generic browsers" as well, but we're quite not there yet, what all is needed for the fair comparison with native applications.

Here it is an example, where JSep loads the disk image from another URL than its "hosting server" (which is ep.lgb.hu in our case), ie in this case from here: http://www.symbos.de/files/SymbOS-EP-Full.dsk so the disk= parameter in JSep's URL accepts even a full URL, just be careful about the cross-domain stuff, I mentioned before (I guess on symbos.de it's allowed by its admin - maybe Prodatron), that's why it works.

Sorry, I can't provide access to my server via FTP or whatever, because it's not entirely "mine" to be exact just I use that too for my domain lgb.hu Of course if you have a disk image you can send me to put there, but it's not so much a sane solution if you want to update it regularly.

Don't worry, at present I want to know about LPT, and your emulator serves perfectly for that purpose. I only want to do simple basic programs to see how can I implement text modes on the mouse driver.

But is tedious to type every time the same lines. I only wanted to have a draft program and then tweak it some var or constant. Is for that I looked for  some form of saving on JSEP like can be done with "epfileio.rom" on the Ep128emu .

I understand the limitations Java Script has and how titanic has been your task...

 I can do the more complicate things on other computer, no problem.

Another note: if you want to test something which is not supported by ep128emu (maybe the mouse?) you can try my native emulator (Xep128) if you have Windows or Linux (on x86) to be able to run it. It supports SD cartridge, again, only read-only, but everything is local in contrast of JSep (which is web based). I guess, there is some windows tool maybe (demontools or whatever? I am not so familiar with windows, to be honest ...) to "mount" disk images, so if you can see one partition of the SD card image as a directory, you can edit your program with a PC editor (or whatever) and save it "into" the SD card image, then Xep128 will be able to "see" it. Just be careful as if the SD card image is used meanwhile and not fully updated before Xep128 uses it (or it changes meanwhile) it can cause some EXDOS headache, I guess

https://github.com/lgblgblgb/xep128

You can read some howto on the page (scroll down) how to install on Windows and Linux. SymbOS seems to work with mouse with it.

But one warning: please do not trust in my mouse emulation in Xep128 or JSep it can be wrong, and not your driver is bad Though because SymbOS seems to be able to use it with both of JSep and Xep128 it can't be totally wrong at least. Xep128 tries to detect the usage of otherwise conflicting extjoy + mouse thus it's possible that you need to click into Xep128 window for "mouse grab mode" (host OS mouse cursor hidden then etc) to be able to use it.

I feel somewhat confused abouse the mouse topics. It seems Boxsoft was the de-facto standard for mouse on EP, but still only a very limited amount of software used it. I don't feel the need too much to implement many different "standards". My hope that Entermice will be the "standard": as with only a few titles to support mouse, I don't think it worth supporting multiple mouse protocols. A few existing software (like EGI?) can be ported, etc. I would love Entermice that it won't "collide" with the joystick emulation badly, which can cause problems on a real EP, and in my emulatorts too. Honestly, my only goal with mouse support to have usable SymbOS session in my emulators Once we can "safely" say that Entermice is enough, I would only support that.

In JSep the situation is even more complicated: it's so bad code (was a kind of learning material for me on JavaScript, to be honest) that I fear to even look on the source currently That will need a full rewrite to have any major modification ...

Well, the jumpy and imprecise movement is interesting. Do you feel that with eg plain SymbOS + boxsoft in my emulator too? If not, it's interesting what can be the difference. But I guess it's hard to tell, as SymbOS uses its own routines regardless of the actual hardware would be on a real EP, a boxsoft mouse interface or Entermice. Another problem that I don't have a real working machine to test anything ... neither another emulator which supports mouse, and so on.