How can you do a recompiler in java? Some sort of bytecode generation? Or did you skip it.

Using the SDL binding right?

I only implemented the normal core with a twist to use the strategy of direct memory access (Simple core feature) for fetching instructions when paging isn't enabled.

The port isn't a complete port of all of the features of Dosbox, at least not yet. Most noticeably, sound isn't hooked up yet.

And no, I didn't use the SDL bindings. This is 100% Java, no native component.

Impressive.

Ok i did what i always do in these cases, check out and used findbugs on it.

Besides some bit twiddling warnings i'm not qualified to comment on, and some floating point tests not using a elipson:

Infinite recursion on Section_prop.Add_path

line:
tmpentry.entryname[0] != 0xe5
on Drive_fat is impossible to trigger since it (0xe5 == 229) and tmpentry.entryname[0] is a byte, so it's probably one of the many cases of unsigned byte -> only java signed byte pain that you'll find.

2 unclosed streams, 5 not checkings of mkdir and functions like that, lots of other rule laywering, but nothing except the bit twiddle that i'm not really competent on jumps as incorrect.

Thank you for the bug find. Yes, the unsigned / signed issues when porting from c to java is a nightmare. Some other hard ones are things like, UINT32+UINT32 need to be converted to (long+long) & 0xFFFFFFFFl. I spent a lot of time tracking down a bug because the value didn't properly wrap.

I didn't know about findbugs. I'll have to give that a try.

If you use netbeans you can add this to get a 3rd party plugin of it (if you use eclipse, they already give it i think and if you use the cmd line, well...).

http://deadlock.netbeans.org/hudson/job/sqe/l … ter/updates.xml

(add this to the plugins->settings->Add to add a new update center for that plugin).

It has a irritating false positive bug about a NPE on "System.out/err", that is complete crock obviously.

As for that unsigned -> signed problems, that is why some people on the java community were screaming about "structs" for so long: interfacing with native code (drivers) and porting. Sun/Oracle/IBM doesn't give a shit about the Desktop though, they prefer to leave that field to MS and the rest

(not to mention that the garbage collection technology needs quite a upgrade before it is viable to control many programs at the same time, mostly giving back memory).

I have hopes for some fields of static typing eventually reliving the pressure of garbage collection. Session types applied to garbage collection kind of thing.

I got my first Dos extender game up and running. To see Doom run as a java applet in your browser please visit my project site at

http://jdosbox.sourceforge.net/

Currently the only known bugs (besides no sound and no mouse) are that the strafe left and move back keys don't work as expected. This isn't a keyboard issue. I suspect there is a signed/unsigned instruction problems since when you hit them you go in the positive direction quickly instead of in the negative direction slowly.

first of all: very impressive. Runs straight out of Eclipse. And the applet running Doom is also pretty cool.

One issue i noticed is that my German keyboard layout does not work, many keys are misplaced or not working at all. Switching to the US layout (and remembering the positions of all relevant symbols) solves this. If you want a more detailed report (I already peaked at the relevant code) just let me know.

One other thing that might be interesting for you (in case you didn't know it): http://jpc.sourceforge.net/
It's a PC emulator written in Java, licensed under GPL2.
Mayby you can use some of it's code to tweak jdosbox, e.g. they might have some more advanced CPU emulation code for Java.
BTW, their Doom applet does not run smoothly for me, yours does.

Thanks for the feedback.

Yep, keyboard stuff is not multi-language aware yet. I think my next few priorities are:

1) Get Duke3d, MOO2 (a couple of my favorites) working
2) Finish SB16 support.
3) Keyboard support, international, and the mapper
4) Research joysticks in Java

Basically, I'm just playing with the code and working on stuff that interests me. If you are interested in finishing the dos keyboard support, please feel free to. This is way too much code for just one person to maintain 😀

I was also surprised that my first attempt with Doom seemed smoother than JPC. I credit the Dosbox guys for that since their code is so optimized.

Duke in an applet would be awesome. Please keep us updated as you work through that list.

Another thing I'm curious about:
Do you port the code completely manually or do you use any tools or scripts?

Currently I don't have time to help with code. At least not on a project of this complexity. I'll let you know if this changes.

It was all done manually. Basically I paste in c code, do about 20 common search and replaces "->" goes to ".", "Bits" goes to "int" etc, then I dive in and clean up the rest. Pointers, templates and the lack of unsigned types in java are the hard parts. A lot of my bugs end up being sign/unsigned related. Right now I'm working on code that does (this+1). Needless to say that doesn't translate directly in java, it will involve the this object knowing its index in the parent object so the final java code looks:

c code

1	case sm3AM:
2		if ( Op(0)->Silent() && Op(1)->Silent() ) {
3			old[0] = old[1] = 0;
4			return (this + 1);
5		}

java code

1         case sm3AM:
2                if ( Op(0).Silent() && Op(1).Silent() ) {
3                    old[0] = old[1] = 0;
4                    return this.parent.chan[this.index+1];
5                }
6                break;

I would say 95% of the code is obvious how to port. The other 5% is what keeps me busy.

Hi Danoon!

I am following your port of java and everybody else I'm impressed as it is getting cool! I fan of the old DOS system, and dosbox. I downloaded the source code, and tried to compile (under windows) using JDK typing this command:

javac -Xlint: unchecked jdos\Dosbox.java

I received no error. but it compiles all the *. java in *. class individually, I thought that would create the final file dosbox.jar, but did not.

What is the correct option to compile the jdos to create jdosbox.jar output file?

I just saw the page of Doom and the sound now works! I was very impressed, and I hope, you will accomplish this port to work 100%. 😁

As you said, DOSBox code is optimized and does not compare to "Jpc" and "Discouri" which are create for different purposes.

I used DOSBox port to PalmOS, and I am hoping that you can run the ethernet network with IPX protocol, and I can play Doom with multplayer!

Greetings from Brazil. Live long and prosper!

Felix.

felixcatx: Thanks for the words of encouragement. Perhaps in the future I will add an ant script which should make it easier to generate the jar. As for now I used IntelliJ which builds the jar for me with the Manifest. If you just want to play with the newest release I just updated the jar file on my site:

: New Release Build 12

* Fixed MOVSX instruction. This caused problems for many games.
* Added SB16 support. Music still sounds a bit off.
* Move Back and Strafe Left now works for Doom.
* Colonization now works.
* Duke3D is getting closer. I can play the first level, but there are glitches.
* Djgpp "Hello World" now works. Now I can write test programs to help diagnose problems.
* Noctropolis still doesn't handle PagesFaults[/list]

Hi Danoon!

I downloaded the new version and're beautiful! 😁 I'll test with classic games such as small and Prince of Persia Wold3D, Spear of Destiny, BlakeStone ... especially the games that used the id Software engine´s versions like "Wolf3D and Doom".

I did a test with a hd of 50 megabytes (running local, not as an applet) and it worked fine! I'm using QEMU disk creator (qemu-img.exe) on it I get the infos number of cylinders, sectors, heads, etc ...

Do you have any recommendations for HD size limit to use the website (applet)? In Doom1 shareware, you used one hd of 10 megabytes, and in Duke3D?, 20, 25, 30 megabytes?

Yesterday, I was testing a HD (running local) I tried to run an old browser software called xtree.exe, it helps me to rename files among other things, but to run the dosbox it closed on time! 😳 I received no error message or crashed, the dosbox closes instantly ... (It is very small, has some 43 kbytes)

For now this is, I'm looking for my old floppy disks into several boxes covered with dust and mold to find old games ... 😎

I´m following this post daily, if you need help to test something (app or game) I'm available! Send me a PM ok?

Qapla '! (Klingon greetings!)

Yesterday, I was testing a HD (running local) I tried to run an old browser software called xtree.exe

Does it work in the last official release (win/linux for example) using the very same HD image?

Applets are tricky and I'm still learning about them. They can't access the hard drive, so hd images downloaded from a server have to be run from memory. So in answer to your question, the size of the image depends on how much memory is available to the applet. By default I believe applets have 64MB of memory, so after dosbox starts that doesn't leave much. Possible work arounds: Java 6 allows the applet to request more memory and webstart can launch dosbox outside of the browser. Another work around might include creating a new drive type in dosbox for jars. This way the applet can just include a game jar then access it from the hard drive via java getInputStream.

The dosbox jar will spit out some information and may include a stack trace for crashes in the java console. To see this in Windows:

1) Go to control panel
2) Open Java
3) Select Advanced tab
4) Select Java Console tree
5) click on "Show Console"
6) click OK

This will display the console anytime a java app starts so it will be annoying to most users to leave on. But if you want to see why you app is crashing this might help.

Currently I'm investigating MDK installer and researching performance issues. I have a timed demo running for Doom that is about 400 game ticks long. Dosbox .74 can run it on my machine in about 175 real ticks. My java version takes 1500 real ticks. I doubt I will every achieve the same performance as the C++ version, but it would be nice to get closer.

Hello WD!

The xtree.exe works perfectly in the "official" releases and in all other SVN versions I tested, included the latest versions of XtreeGold 3 and 4 work fine.
I do not think the problem is the image of the hd, I'm using the same image with windows 3.1 and msdos6 under the Dosbox 0.72 and it works 100%.

I dont have found any program with problems to work under DOSBox, except extended memory managers like QEMM. But QEMM also have problems under Qemu and Bochs. Xtree I've only seen this problem occur in this version of Jdosbox, but Danoon dont finished converting the code and how it is still a "beta" and I think are relevant inform that.

Hello Danoon,

I'll do it but in my house, and try to observe and watch the console messages. I'll make a web page using IIS, and test a few games via browser, and test HD´s images also.

Qapla '

Java applets can access the hard drive. To do so they have to be signed. AFAIK you can use a self signed certificate for that. The user has to accept it. Then the applet has the same privileges as a desktop app.