Thanks lil_stenly for the bug report. Its always nice when a bug is 100% reproducible so easily like that. It is fixed in this new release.

0.74.25b (BETA) Aug 11, 2011
* First version to supported Windows 98
* Fixed VGA bug that affected many games, including Civilization, the city screen would leave black bar under the cursor
* Major speed improvements,
* Improved file path handling for Mac/LInux
* Added NE2000 network card support (requires PCap)

http://jdosbox.sourceforge.net/jdosbox-0.74.25beta2.zip

This is big news, I finally fixed a VGA bug that has been there since the beginning. Hopefully a lot of those strange graphical glitches will be fixed.

This version should also be about 25% faster than the previous beta.

Great will try it!

Meanwhile cputype...

I'm playing around with bootable images
(haiku os boot floppy requires at least pentium cpu)
that normal dosbox has a command
"cputype pentium_slow"
and if i try to run the boot image there, that require pentium, using this command, then it works. And jdosbox has
"cputype pentium"
still when i try to run the same image there, the boot process returns a message that i need to have pentium cpu or higher, the same standard message appears like i'm using the normal cpu type. So I don't know if thats a bug, still that command (if implented) not works as it must. 😀

P.S. I know... that dosbox is dos emulator, so can't deal with bios hard disk detection, (because there is no such a thing) thats why it is impossible to boot some operation systems, still that never stopped me from experimenting with any kind of stuff. 😀

Yeah, its fun to try other stuff, I got the linux 2.4 kernel to boot. It detected the network card, but without hard drive access and not much RAM it wasn't very useful. 😀

I briefly looked for a haiku boot floppy and only found instructions on make one. Do you have one you can post a link to?

Yep, just nobody mentioning that the boot floppy image is there, haiku faqs are kinda mash up. Well I extract it from the iso. 😀 You don't need the iso to check that anyway. So I attached the image to this post here.
__________________________

[Meaningles stuff here]

By the way, QNX rtp 4.5 can be installed thru 98 within fat/32 fs in a image file that will be a host disk for the system, which sounds good. And when you boot up qnx thru dos, that os tries to access the image that lays over the readable filesystem, also sounds good. Just don't know why it can't access it... since there the hard disk detection is not needed. I should try that with the new builds and well just hoping some miracle to happens there. 😁
P.S. Just it is too much "to play around" till you prepare everything. And since it is free for personal use the image can be redistributed to other people too, so if it runs that will be something pointless, still somehow nice.

[/Meaningless stuff here]

I tried this at some point, it booted to desktop but the mouse doesn't work due to lack of hardware emulation.

lil_stenly: use pentium_slow for now, I forgot to change it when I ported h-a-l-9000's paging patch. I tested it with pentium_slow and that floppy tries to execute op code 0x3c7 (66 0F C7) VMCLEAR which according to one website is a P4 instruction. If I ignore it then I get a double page fault which I currently do not handle. Still pretty cool to see how far it gets.

It behaved the same way in Dosbox Megabuild 6

No way, i'm not going to use it, just found that not works as it should and decide to report it. 😀 I'm using it just to compare the work of dosbox with it's java port and it works so far, that is the only reason.

I'm getting back to test something that actually may come in use for the people in this community, like old games for example. 🤣
Like Might And Magic, Jorune and more of Daggerfall to see if these works.
So, that is for now, hope your improvements over the port going well, I will try to test more titles later and will report back if some bug appears.

Hi, danoon. I have found one thing that normal DOSBox has no problems running that jDOSBox chokes on. The LSL7 demo. No matter what core, cycles frame skip, etc. I try, it is unplayable.

Collector: What do you mean unplayable? I installed the dosbox installer on your page. When I tried it with jdosbox it hung. Then I changed the audio to SB16 and was able to play liar dice.

Does anyone know of a good program for DOS to test how the FPU behaves. I have some bugs in my port of the FPU. Using Java's version of floats and doubles leads to some wrong results. I'm testing out a soft fpu library that fixed the game I was looking at but I want a more thorough test before committing to using it.

If you are talking about the game's configuration, I often use DACTHUND.DRV because it is more trouble free than the Sierra SB driver. The SoundBlaster driver often is noisy and the Thunder Board driver is more reliable and does not cause noise. It is a moot point, anyway, because I was already using the SB driver with jDOSBox.

If you click the "Show me everything button, it keeps locking up for a second or two, over and over. Once you get to the Liars Dice the lockups are much shorter than during the into and not nearly as noticeable.

I have tried jDOSBox with a fair number of my other Sierra DOS demos with good results. It is just the LSL7 demo that I am having trouble with.

10.74.25 Aug 25, 2011
2* First version to supported Windows 98
3* Dynamic core can now recompile java byte code with support for saving and loading the compiled blocks
4* Fixed many bugs including:
5  - Floating point rounding errors
6  - VGA bugs, Dragons Bane: Mah Jongg II and Civilization (City Screen) now draw cursor correctly
7  - Improved file path handling for Mac/LInux
8* Major speed improvements
9* Applets will now center their viewing area
10* Video card memory default has been bumped to 2MB (still 1MB for Applets).  Now supports up to 8MB.
11* Added NE2000 network card support (requires PCap)

The new recompiler improved Doom performance by 50% and increase PCP Bench by 2x.

There were a lot of changes in this release, a new soft FPU, HAL's new paging patch, and a recompiling core, so feel free to test your favorite games and let me know.

http://sourceforge.net/projects/jdosbox/files … 5b.zip/download

danoon wrote:

0.74.25 Aug 25, 2011 ... The new recompiler improved Doom performance by 50% and increase PCP Bench by 2x. […]
Show full quote

0.74.25 Aug 25, 2011
...
The new recompiler improved Doom performance by 50% and increase PCP Bench by 2x.

There were a lot of changes in this release, a new soft FPU, HAL's new paging patch, and a recompiling core, so feel free to test your favorite games and let me know.

Hi, 😀

First of all, excellent work! I'll admit I'm not a very dedicated or experienced gamer nor a heavy user of Java (big understatement), but it's still awesome to see this. In other words, I don't have a lot of old games to test on this (only a handful) nor heavy motivation either.

My favorite test case is Paku Paku (original), esp. since both the original arcade Pac-Man and the original IBM PC (which Paku Paku supports!) each just turned 30 years old.

Anyways, I don't know why, I felt like installing Java on (Lucid) PuppyLinux (32-bit) yesterday, probably just for laughs to test jDOSBox. Then I remembered Anton Ertl's old Doom benchmark ("doom -timedemo demo3") and results for various cpus, so I tested that for comparison.

However, the main deal is that I must've tested your old version yesterday because now today when I try again (Win64, then back to PuppyLinux) it's much slower, not faster (oddly). So I dunno. I mean, it doesn't matter to me, but it's still a little odd, esp. after your recent "improvements", heh. 😕 I could swear I was getting "PentiumMMX/250" speeds (600-ish realtics) yesterday but only slow "Pentium/60" (1800-ish realtics) today.

Anyways, nice job overall, no complaints, just having fun seeing some random but cool games here and there. 😁

EDIT: Ertl's site isn't loading now, for some odd reason, but Google Cache has it. Honestly, I'm not sure he's updated the results in a few years, dunno, so it's probably moot.

Thanks for the link and testing. If your real tics beat your game ticks then you must have a pretty fast computer. Slow pentium speeds is where jDosbox is at right now. On PCP Bench sometimes I can hit Pentium 133MHz. PentiumMMX/250 (3x faster than game ticks) probably didn't happen with jdosbox, though I'm sure Dosbox could get those numbers.

At first i would like to take the time to thank danoon for this outstanding port.

I am quite impressed by the speed and compatibility of the latest version. I have made several images for DOS games, WIndows 3.11, Windows 95 and Windows 98. Windows 3.11 runs perfectly. WIndows 95 and 98 have smaller bugs, especially with Windows 98 i have been having loads of fights and problems, but most obviously already occured while installing it in normal/Megabuild6 Dosbox. I am still testing different builts, so far WIndows 95 OSR2 runs very well in Jdosbox, actually amazingly well.

What I am still haggling with is the NE2000 support. I have used Megabuild6 successfully with NE2000 support, but in Jdosbox i get an error about it. I have included the standard config file and load the NE2000 enabled jar but win 95 tells me something like "Your NE2000 is not working properly" like when you boot from a non-NE2000 enabled build.

Is the NE2000 jar even possible to use in a browser from a remote (internet) server? If yes can someone explain how to get it working? I just don't understand the instructions in the pcap dir very well.

Hi Danoon, first of all, congratulations for this excellent program! I have a question about the current version of jDosBox. Its possible run the applet in full screen? (not local)

Or change the "width" and "height" values to use this code:

http://alecjacobson.com/programs/fullscreen-applet/

Thx! 😁

Sorry, that has been a feature I've been meaning to do for quite a while but I always get distracted by something else.

Off the top of my head here is my todo list if anyone wants to jump in and help.

This is not in priority order, I just work on what ever catches my eye at the moment.

• 1) SB16 FM sounds are off key
  2) Gus port
  3) Catch up on dosbox svn checkins, I'm up to svn #3649
  4) Keymapper port
  5) Research OpenGL(JOGL/LWJGL) and what it would take to support the 3dfx patch (probably dependent on #3). This is low on my priority list because I would like exclude the use of JNI as long as possible.
  6) More work on the recompiler for further speed enhancements
  7) Port WINE
  8) Mostly I have only tested 32-bit DOS extender SVGA games, I still need to test and work on older games, Tandy, etc
  9) More work on the applet, including optimizing memory usage and full screen support
  10) Implement user mode networking like in QEMU (basically implement a custom router)
  11) Someone else will need to help on internalizing this port
  12) Android port (though this might just be academic since it might be too slow for 32-bit dos games, like Doom)
  13) MMX (if and when a WINE game needs it)

Currently I'm working on WINE stuff because I find it interesting, I would love to see Diablo 1 in Java someday. I have the kernel, page tables, processes, threads and DirectDraw mostly working. Some of the full screen DirectX 3 SDK examples work. I can also start a game of Age of Empires 1 with midi sound. Though there is a major weirdness, none of the units will follow my orders to go to the lower left of the screen, they take off in the opposite direction. Kind of funny. This really isn't a port of WINE. I do look at WINE code for ideas, especially at the higher levels, like gdi32 and user32. But hardware, DC's and Kernel stuff mainly have to be from scratch. Also, given the slowness of the recompiler I doubt games requiring more than a P166 will work well. This should give Diablo 1's 60MHz requirement room to breath, but Diablo 2's 233MHz is probably out of the question unless I speed up the recompiler.

When I first saw the update post, I thought the references to a kernal and WINE meant you had implemented win32 calls something like the minimal sanos [http://www.jbox.dk/sanos/]. I like your approach, very clever indeed.

I may have some java gus code to contribute. The output currently sounds a bit sick and bugs out after a while. If I manage to debug it, I'll send it through.

As to GL in java, there is OGLJava which includes a pure software renderer. It hasn't seen updates in years, but it was seemingly robust enough that it was included inside midpath [http://midpath.thenesis.org/].

I previously ported JPC to android for fun some time back. Didn't get much past loading the BIOS before running out of heap space (16mb at the time). I think the most recent android version has increased the heap to 64MB.

Full screen in nine place... not bad 😁

One more thing... can be possible save the savegames in local or ftp? Fullscreen + Savegames! Can you imagine that?

Yeah, save games for an unsigned applet would have to be pushed to a server. But that would be pretty cool. For a signed applet, you can download the game to the local user directory and run it from there. The applet params would look like this. The zip can contain an image or just the games files.

1    <param name="download1" value="http://jdosbox.sourceforge.net/doom.04.zip">
2    <param name="param1" value="imgmount e ~/.jdosbox/doom.04/doom.img -size 512,16,2,512">
3    <param name="param2" value="e:">
4    <param name="param3" value="doom">
5    <param name="param4" value="-conf ~/.jdosbox/doom.04/dosbox.conf">