Awesome work (I mean that). I looked into porting jdosbox (also considered JPC at one point) using GWT before, but never managed to finish the important step of replacing the main-loop with a repeatedly called function, as there are multiple nested "main"-loops in jdosbox. I'll look through your code in detail as soon as get the time.
I have ported 'simpler' emulators before and gathered a bit of experience here and there. If you don't mind, I'll see if i can contribute some patches to this project, maybe sound or some performance tweaks.

BTW, you might get more feedback when starting a thread in "DOSBox Development", or maybe a mod can move this thread there.

[Moved]

Sound is definitely a priority. Did come across a project on GitHub that may assist - https://github.com/bfirsh/dynamicaudio.js
Input is also an area in need of work. See http://www.quirksmode.org/js/keys.html for description of the problem. I'm hoping a GWT compatibility layer exists somewhere.

I have written a simple audio class wrapping riffwave.js by Pedro Ladaria. It should work in any browser that supports html5 audio elements including the wave format. I'll look into adding it into your project when i get some free time.

Could you explain the keyboard input issues? I'll see if I can help out (I worked on GWT based emulators and JavaScript based text editing/word processing, so I had to work around some issues before).

After my first quick look into the code I wonder if there is a reason for the "replaced" package, instead of using a "super-source"?

Also, I wonder what the steps are for setting this up locally, especially how to add files to the dos file system. I assume I have to create an image, but I don't know what kind and where to put it. (edit: I think I found it in the source. But a few words on configuration and loading the image (as well as creating it) might be a good addition to the read-me to help new people working with the code)

Re-baselined from more recent jDosbox codebase. Still need to clean up some things. Doom almost playable but chrome only. Instructions in readme file have been updated to provide more detail.

The input problems relate to the keyboard handling differences across browsers and operating systems. As to the replaced directory - that contains mocks and stubs. Makes up for things missing in GWT or where the existing functionality doesn't meet my needs.

I'm working on sound and I think I'm close to getting it work.

For testing I'd need some shareware games or sample programs that use sound blaster (supported by dosbox) with as low CPU requirements as possible. Any suggestions are much appreciated.

Try an old mod player. goto scene.org and search for rmp120.zip, glx212.zip or iplay122.zip. They all work in dosbox
grab a mod tune from the site also: select browse files then navigate to mirrors/hornet/music/songs/

I'm not sure about the cpu requirements, but I used the setup for duke3d. It allowed me to select 8 or 16 bit along with the sample rate then test it.

Uploaded new version
Added:
- Support for compressed disk images (7Zip)
- Some internal re-working of runtime exception handling (GWT/JS limitation)
- other minor fixes
Also added the first stab at a JavaScript 'compiler' to the dynamic core. At this stage it is incomplete and not recommended for general use. Does not currently provide a speed boost - Oh well, someone needed to be foolish enough to try.

Next todo item will be sound...

Fantastic 😀 couldn't be more excited someone did this! 😀 congrats.
I got it working with some old games in chrome without problem, but it crashes safari on the ipad, which is where this port would be spectacular! Especially since dosbox got yanked out of the appstore twice and is most likely never to return.

I imagine it would be not so hard to add a few html5/js onclick buttons that fired off keystrokes to integrate with the existing listeners for key presses?

are you looking for help with this project? and or still working on it?

cheers,
john

Still making some progress. Planning to clean up and upload the remainder of the JavaScript 'compiler' stuff in the next few days. It took some time to track down a number of 'what was i thinking?' bugs.
As to the iPad, adding handlers for touch events is technically easy, but making it fluid and intuitive to use is the tough bit. Haven't as yet played with tablet devices much, so i don't know how such problems are solved. I guess getting it to run at all on tablets would be a start - Another item to add to the long todo list.

So what does the new javascript 'compiler' stuff do?

I tried the new build.zip from 2 days ago and it hard crashed the iPad Safari browser. I wish there was a way to get some feedback from the iPad browser as to exactly what went wrong? I would love to see JsDosBox running on a tablet 😀 even if there weren't responsive controls, or hell even any controls! 😀 it would just be great to see what what sort of speed it was capable of.

cheers,
john

I am not sure what the problem with the iPad safari browser is. I have tried with some success with desktop Safari on a Mac OSX 10.6 machine. Given that it's performance is disappointing on a desktop, I don't think it would run well on a tablet. On the bright side, as browsers evolve they bring with them a performance boost for free. This software is very much still alpha quality, I will provide an update as progress is made.

The demo is not so useful as it refers to "localhost" to load the image. Can't that be changed? I am sure there is some shareware or demo version of doom around if this is a copyright problem.

Added sound. Only PCSpeaker and basic SoundBlaster at this point. Not able to remove audible ticks from the PCSpeaker emulation. SB emulation fares a little better using Chrome dev channel (with rare lock ups). Have only tested with the default config of sb1, 11025Hz. Anything more seemed ambitious - output currently hardcoded to mono. Sound produced by generating wav files on the fly and sending the base64 encoded data to HTML5 AudioElements. There might be a better way. Spent considerable time blindly adjusting the parameters, but it would benefit from wider testing/experimentation (see project readme file).
All this extra work knocks ~10% off performance. Any program is not likely to benefit from sound unless it previously ran at least 15fps (nosound is default). See http://retropcdemos.appspot.com for sound example.

Yeah, sound can be hard to get right. I still believe there are bugs in the java sound blaster implementation. I ported that pretty blindly as I have no professional audio experience. Sometimes I can hear a difference between the java and c++ versions. But I could never pinpoint where the differences were coming from.

Congrats on another milestone.

Your java code works a treat; it is invariably the code I touched and mangled that causes me grief. Hopefully layering WebGL on top of HTML Canvas will remove the per-pixel access inefficiencies that seems to cause a number of browser compatibility problems.