Welcome, Guest. Please login or register.


Author Topic: JavaScript EP Emulator (Read 22511 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #15 on: 2015.October.30. 09:27:37 »
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.

Quote
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?

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #16 on: 2015.October.30. 10:45:35 »
You say: "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."

Is that "stuck" problem what I said. Some keys, I still don't know which of them, change the behaviour of all the keyboard, just like Shift, Ctrl or Alt do, but it doesn't return to "normal" state. The solution is resetting. I even don´t know if it is pressing a key, suddenly the keyboard is corrupted. Then, keys give strange results or not at all, others don't Shift or do Caps. And the worst, some keys get stuck and fill the screen with the same un-requested character until I press a 00 code key, then it stops printing.  Strange, isn't it?

This is a Woxter toy keyboard with touch pad, but I have a full-size Logitech bluetooth keyboard  to test.

Surely it is not a problem of your code, but of Firefox. I have to install Chrome for Android to see if it acts the same.

Here you have the keyboard.js file, but not of much aid as I only have changed some assignations.

I think you can make a simple program like keytest.html to guess  the key assignments to do on the keyboard.js file and then JSEP will suit everybody. I only  took few minutes once I understood the grid system as can be seen on the "Converting Spectrum programs to run on the Enterprise" manual.
« Last Edit: 2015.October.30. 10:53:33 by gflorez »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #17 on: 2015.October.30. 11:11:21 »
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.

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #18 on: 2015.October.30. 11:24:04 »
I've already corrected that backtick key error, thanks. It was redundant, as a few lines forward you make another assignment with that same coordinates. 

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #19 on: 2015.October.30. 11:27:17 »
Is for that "esoteric" behaviour you find on every device, better that every owner do his own assignments.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #20 on: 2015.October.30. 11:40:41 »
I more or less have the feeling now, that I should give up the positional mapping. It's layout dependent on the host OS, etc. However with symbolic mapping (ie do the same "character" on the EP128 as the host OS) will makes interactivity worse. What I told, that for "virtual" shift I need to delay to propagate key events to handle the modifier key difference (ie: shift). And as we know from the Atmel AVR PS/2 keyboard interface project (by Tigrian, if I remember correctly) already: some people feels that it causes problems in games etc. Also it makes impossible (well or problematic at best) to check SHIFT key state, if an EP program really wants to know you pressed SHIFT in its own not so much as a modifier key. I guess, now you have the idea what my problem is here. There is even a chance to do mistake if no delay is done, ie shift key is scanned after the other keys. On a real EP, it's quite rare it causes problem as humans are not so fast to press eg shift + A in a situation that only microseconds difference EP can notice between them ...

But, a more quick way now: if your short-term goal only to have working ':' for example, then please send me the "KEY" display information below the status line with the key pressed/released you'd like as key ':', but only, if it's not used for other key, and the shift state is the very same on the host OS and from the viewpoint of EP. If you can find a solution like this, and even if it's a keycode = 0 situation, I can include it in the "workaround" section, and we will see ...

Some funny (or sad) material on browser differences: http://www.quirksmode.org/js/keys.html
« Last Edit: 2015.October.30. 14:12:56 by lgb »

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #21 on: 2015.October.31. 00:12:15 »
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.

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #22 on: 2015.October.31. 14:03:56 »
It is acceptable for me as it is, but I need a way to save a simple Basic program, even if it is lost at getting off Firefox.

How can I remove disc protection?

And, can I upload my disc image to your page by FTP?

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #23 on: 2015.October.31. 18:39:24 »
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.

Code: [Select]
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.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #24 on: 2015.October.31. 18:41:01 »
Ah sorry, it seems I also forgot what I code in my own emulator :) JSep currently uses a "proxy" for downloading remote (not from the hosting server of the emulator) stuffs (disk images, ROM images). So the HTTP header maybe not needed at all.

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #25 on: 2015.October.31. 19:55:53 »
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.


Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #26 on: 2015.October.31. 20:55:21 »
Quote
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 .

Something like the fileio stuff is may be possible with JSep, but again, it will be done over HTTP. So then individual files (instead of disk images) are needed on a _web_server_. The limitation is again, that it's a "web" based emulator, thus it requires web servers :) In theory, it can be done maybe, to put a button on the emulator page for a "fake" upload (ie, not to the webserver, but JS "catches" it), but I am not even sure at the moment.

Again, what I can suggest: do your stuff with ep128emu, eg at the point that your program is loaded etc, then do a snapshot. JSep is capable of loading ep128emu snapshots, not perfect, but in most cases it works. Just you need to put the snapshot on a webserver (of course) and you must use the right URL parameters for JSep that it loads then. In this way you don't even need to wait "for booting" the emulated ep128emu etc, and you can use ep128emu always running on your computer, developing your driver etc, and taking snapshots when you need to test. If you have somehow assign a network share or whatever of a web capable server, then it's even possible to load that by JSep without too much extra work, or just reloading the page of JSep.

Quote
Don't worry ...
[...]
I understand the limitations Java Script has and how titanic has been your task...

I don't worry, also I don't want to treat my work here being "titanic" :) just I would like others to understand as well, that there are some limitations based on the web nature here. As there were requests on the Hungarian forum as well about features natural to a local-running native up, but quite strange from the view point of web/JS stuffs :)

What was also my plan (but no time to do) is creating a web based IDE. Ie, you can edit ASM program right on the web page, and allow to test it on that page (with the JSep) as well. I can't find a good example for this now:

http://clrhome.org/asm/

Maybe like this, just you can see the result as well running ... A stuff like this - I guess - is great to test shorter things. Of course it's maybe not so much well suited for serious programs.

Well, like this:

http://ep.lgb.hu/jsep/editor/lgb.php

This is what I started to make a year ago or so :) Useless to try, it won't work at all :) Eg some button opens http://index.hu/ (a Hungarian news site) instead what it should do, it's a test from me (about button events, etc), don't be surprised :) If you click on the Build button on the top, it won't build, but starts the emulator. You can see, the emulator itself is under a tab, and still you can change tabs (tabs: I mean my tabs on the page) without restart of the emulator, etc. It's not a big magic, just some css stuff anyway.

But you can get the idea what I wanted to create. I can't see clearly, it's usefull too much, as for serious development it's hard to do this way in a web based editor ...

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #27 on: 2015.October.31. 21:13:21 »
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.

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: JavaScript EP Emulator
« Reply #28 on: 2016.February.20. 02:08:17 »
XEP128, and probably your JavaScript Emulator don't react very well with the actual version of the mouse driver. The movement is imprecise and jumpy, probably because the enlarged reading routine collides with your mouse caption.

On the other side, you have Boxsoft emulation but, can you implement Entermice on your emulators?

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: JavaScript EP Emulator
« Reply #29 on: 2016.February.20. 12:29:21 »
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.