VOGONS


JavaScript port of Dosbox

Topic actions

First post, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

JavaScript port of jDosbox. Early days - No sound, mouse control.
Project: sourceforge.net/projects/jsdosbox
Demo: jsdosbox.appspot.com.
Chrome only at this stage. Can run Doom, but is not fast enough to be playable at this stage. I hope to make further improvements.
It is faster then my previously released JavaScript port of JPC, demo booting FreeDOS at pc-emulator.appspot.com.

Reply 1 of 24, by koun

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 4 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 5 of 24, by koun

User metadata
Rank Newbie
Rank
Newbie

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)

Reply 6 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 7 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 8 of 24, by koun

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 9 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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/

Reply 11 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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...

Reply 12 of 24, by johneliot

User metadata
Rank Newbie
Rank
Newbie

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

Reply 13 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 14 of 24, by johneliot

User metadata
Rank Newbie
Rank
Newbie

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

Reply 15 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 16 of 24, by fronzel

User metadata
Rank Member
Rank
Member

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.

Reply 17 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 18 of 24, by danoon

User metadata
Rank Member
Rank
Member

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.

Reply 19 of 24, by kevodwyer

User metadata
Rank Newbie
Rank
Newbie

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.