Two bugs found
When I use -freesize command jdosbox just quits.
When set the cputype to 386 there pile of errors appears in the console.
Booting without using -bochs boots fine, booting in 386 cputype with -bochs command throws that.

DOSBox version 0.74.27 Copyright 2002-2010 DOSBox Team, published under GNU GPL. --- CONFIG:Loading primary settings from config […]
Show full quote

DOSBox version 0.74.27
Copyright 2002-2010 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file F:\Torrents\Games\DOS\java\.dosbox\dosbox-0.74.conf
DOSBOX_RealInit
About to allocate memory 22543kb: 34005kb free
HARDWARE_Init not finished yet: NO SCREEN SHOTS
Keyboard AUX emulation enabled
MIDI: Using Soundbank: default
DSP:Reset
Read from port 378
Read from port 379
Read from port 3bc
Read from port 3be
Read from port 278
Read from port 279
INT10_Init
Invalid type for serial1
Invalid type for serial2
Parsing command line: AUTOEXEC.BAT
Special file open command 80 file Z:\AUTOEXEC.BAT
Special file open command 80 file Z:\AUTOEXEC.BAT
Parsing command line: SET BLASTER=A220 I7 D1 H5 T6
Special file open command 80 file Z:\AUTOEXEC.BAT
Startup time: 313ms
Parsing command line: cputype 386
Execute z:\config.COM 0
Parsing command line: imgmount A .//PM805.IMA -t floppy
Execute imgmount.COM 0
IDE: index 0 slave=false
Mounted FAT volume is FAT12 with 2863 clusters
Parsing command line: boot -bochs FD
Execute boot.COM 0
IDE: Adding IDE controller to port 0x1f0/%03x IRQ 1014
IDE: Adding IDE controller to port 0x170/%03x IRQ 886
$Revision: 1.209 $ $Date: 2008/06/02 20:08:10 $
Writing 0 to port 80
Activated
AUX Activated
Reset, disable scanning
Clear buffer,enable Scaning
Read from port 37a
Writing df to port 37a
Writing aa to port 378
Read from port 27a
Writing df to port 27a
Writing aa to port 278
Writing 2 to port 3f9
Read from port 3f9
Writing 2 to port 2f9
Read from port 2f9
Writing 2 to port 3e9
Read from port 3e9
Writing 2 to port 2e9
Read from port 2e9
VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
VBE Write 0=45248 eip=0x8a88
VBE Read 0 = 45248 eip=0x8a78
VBE Write 0=45252 eip=0x8a88
VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $

VBE Write 4=0 eip=0x8b48
DOSBox switched to max cycles, because of the setting: cycles=auto. If the game runs too fast try a fixed cycles amount in DOSBox's options.
Starting rombios32
ram_size=0x01000000
CPUID

at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093) at jdos.cpu.CPU.CPU_Exception(CPU.java:1019) at jdos.cpu.CPU.CPU_Interrupt(CPU.java […]
Show full quote

at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)
at jdos.cpu.CPU.CPU_Exception(CPU.java:1019)
at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)
at jdos.cpu.CPU.CPU_Exception(CPU.java:1019)
at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)
at jdos.cpu.CPU.CPU_Exception(CPU.java:1019)
at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)
at jdos.cpu.CPU.CPU_Exception(CPU.java:1019)
at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)
at jdos.cpu.CPU.CPU_Exception(CPU.java:1019)
at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)
at jdos.cpu.CPU.CPU_Exception(CPU.java:1019)
at jdos.cpu.CPU.CPU_Interrupt(CPU.java:1093)

Here is a demo of some 3dfx stuff I did for the java port. It seems to be working pretty well. I ported directly from Mame and peeked at Kekko's code to get it connected to the Dosbox code. This implements a 12MB Voodoo2 and is 100% implemented in Java (no JNI and no OpenGL).

Currently I have been unable to get Windows to see the card but everything DOS I could find seemed to work alright.

You will probably need at least a Core i7 or equivalent. This takes advantage of multiple cores.

This zip file contains the Tomb Raider 3dfx demo and the jdosbox.jar

http://jdosbox.sourceforge.net/TombRaider3dfx.zip

impressive!

uses more than 50% of my 2.4ghz quad core. very nice work on the multi-threading. I'll have to try it again with o/c to 3ghz.

I get the following exception every time I loose the game (Windows 7 64bit, Oracle Java 7 64bit):

No byte handler for read from 60400804java.lang.Exception: Stacktrace
at jdos.misc.Log.exit(Log.java:15)
at jdos.hardware.mame.VoodooCommon$VoodooPageHandler.readb(VoodooCommon.java:7654)
at jdos.hardware.mame.VoodooCommon$VoodooPageHandler.readw(VoodooCommon.java:7659)
at jdos.cpu.Paging.mem_readw_inline(Paging.java:261)
at jdos.hardware.Memory.mem_readw(Memory.java:872)
at jdos.cpu.Paging$NewInitPageHandler.readw(Paging.java:882)
at jdos.cpu.Paging.mem_readw_inline(Paging.java:261)
at jdos.hardware.Memory.mem_readw(Memory.java:872)
at jdos.cpu.core_dynamic.Inst1$MovGwEw_mem.call(Inst1.java:4783)
at jdos.cpu.core_dynamic.Inst3$GrplEdId_reg_add.call(Inst3.java:1920)
at jdos.cpu.core_dynamic.Inst3$Incd_reg.call(Inst3.java:1144)
at jdos.cpu.core_dynamic.Inst3$Xord_reg.call(Inst3.java:902)
at jdos.cpu.core_dynamic.Inst3$AddEaxId.call(Inst3.java:111)
at jdos.cpu.core_dynamic.Inst3$MovEdGd_reg.call(Inst3.java:2584)
at jdos.cpu.core_dynamic.Inst3$Xord_reg.call(Inst3.java:902)
at jdos.cpu.core_dynamic.DecodeBlock.call(DecodeBlock.java:71)
at jdos.cpu.Core_dynamic$2.call(Core_dynamic.java:136)
at jdos.Dosbox$1.call(Dosbox.java:66)
at jdos.Dosbox.DOSBOX_RunMachine(Dosbox.java:204)
at jdos.cpu.Callback.CALLBACK_RunRealInt(Callback.java:158)
at jdos.shell.Dos_shell.Execute(Dos_shell.java:755)
at jdos.shell.Dos_shell.DoCommand(Dos_shell.java:633)
at jdos.shell.Dos_shell.ParseLine(Dos_shell.java:173)
at jdos.shell.Dos_shell.Run(Dos_shell.java:91)
at jdos.shell.Shell$5.call(Shell.java:398)
at jdos.misc.setup.Config.StartUp(Config.java:97)
at jdos.gui.MainBase.main(MainBase.java:521)
at jdos.gui.MainFrame$4.run(MainFrame.java:247)
at java.lang.Thread.run(Unknown Source)

Thanks for the stack, based on the address it looks like it was reading the frame buffer. After looking at the spec it seems like I need to implement 16-bit read/writes to the frame buffer.

Hopefully close to making an official release:

It is now configurable between a Voodoo 1 and Voodoo 2 with 2MB or 4MB for the frame buffer and 2,4,8 or 16MB for the texture units.

The Voodoo 1 works in Windows 95/98 using the same driver that kekko's version uses. I was unable to get Windows to recognize the Voodoo 2. I wonder if its because the PCI implementation is not complete.

Here is the 3dfx Tomb Raider demo running in an unsigned applet as a Voodoo 1 with 2MB frame buffer and 2x 4MB texture memory units

http://jdosbox.sourceforge.net/tr3dfx/TombRaider.html

ive been following your work for about 6 months now on and off, I must say kudos. using local dir's isn't seeming to work for me though 😒 all have to be on whatever server I'm using the .jar file on 😒

What do you mean local dir isn't working for you? You mean you are running jDosbox as an applet, you want to download, unzip a file on the client machine then run it from there?

I have tested that on various mac's and windows machines with different versions of Java. Without knowing more the only thing I can say is make sure the applet is signed. Unsigned applets do not have permission to write to the client machine.

I'm talking using the jdosbox.jar from a webpage aka uploaded to a private server to test if I could boot games on the physical computer using the .jar file running in a browser it hangs up when I try to use mount c c:\game folders, the bypass I found was uploading the games to the server as well then making a custom config for the paths for each game (so I can play them from any computer without downloading) so far daggerfall plays around 15fps which isnt bad for a java port IMO but I'm not entirely sure how to use the browser java to config for local access 😒 besides a temp folder but it still won't boot the c: drive on the physical computer via a browser

You can serve the jdosbox.jar applet from a server to a client machine and run "mount c c:\games", of course c:\games refers to the the client machine and the applet must be signed.

If you are talking about c:\games on the server, then no, that's not possible. The applet runs on the client, not the server.

Version 0.74.28 is out http://jdosbox.sourceforge.net

1    Added support for 3dfx
2        Ported from MAME
3        Multi-threaded pure software implementation
4        Configurable memory options
5        Supports Voodoo 1 and Voodoo 2, currently only Voodoo 1 works in Win95/98
6        Disabled by default because it requires PCI support which breaks loading OS's with Bochs
7    FPU performance improvements: 20% faster MDK, Tomb Raider is playable at high res and Quake does alright at 640x480
8    Fixed a few serious FPU bugs
9    Solved the "Cp: memory exhausted" issue when booting some Linux distros
10    Fixed a bug with Settlers 2 intro movie
11    Lowered memory usage of the dynamic core, in return, applets will now get 16MB of RAM by default instead of 8MB.

Big compliment to Danoon! Who'd have thought to do Lightwave renderings in a webbrowser?

And the TVGuy sample scene in 640x480 (1Frame) in under 4 minutes. beats my old rendering machine from the early 90s. So thumbs up!

Problem with latest Java JRE 1.7.0_25 (Java SE 7u25)

1Exception in thread "Thread-15" Exception in thread "Thread-21" java.lang.ExceptionInInitializerError
2	at jdos.cpu.core_dynamic.Compiler.<clinit>(Compiler.java:6468)
3	at jdos.cpu.core_dynamic.CacheBlockDynRec.Clear(CacheBlockDynRec.java:18)
4	at jdos.cpu.core_dynamic.CodePageHandlerDynRec.InvalidateRange(CodePageHandlerDynRec.java:73)
5	at jdos.cpu.core_dynamic.CodePageHandlerDynRec.writeb(CodePageHandlerDynRec.java:100)
6	at jdos.cpu.Paging.mem_writeb_inline(Paging.java:287)
7	at jdos.hardware.Memory.mem_writeb(Memory.java:869)
8	at jdos.cpu.core_dynamic.Inst1$MovIb_mem.call(Inst1.java:5929)
9	at jdos.cpu.core_dynamic.Inst1$SegCS.call(Inst1.java:2087)
10	at jdos.cpu.core_dynamic.DecodeBlock.call(DecodeBlock.java:71)
11	at jdos.cpu.Core_dynamic$2.call(Core_dynamic.java:136)
12	at jdos.Dosbox$1.call(Dosbox.java:67)
13	at jdos.Dosbox.DOSBOX_RunMachine(Dosbox.java:205)
14	at jdos.cpu.Callback.CALLBACK_RunRealInt(Callback.java:158)
15	at jdos.shell.Dos_shell.Execute(Dos_shell.java:755)
16	at jdos.shell.Dos_shell.DoCommand(Dos_shell.java:633)
17	at jdos.shell.Dos_shell.ParseLine(Dos_shell.java:173)
18	at jdos.shell.Dos_shell.Run(Dos_shell.java:91)
19	at jdos.shell.Shell$5.call(Shell.java:398)
20	at jdos.misc.setup.Config.StartUp(Config.java:97)
21	at jdos.gui.MainBase.main(MainBase.java:521)
22	at jdos.gui.MainApplet.run(MainApplet.java:269)
23	at java.lang.Thread.run(Unknown Source)
24Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers")
25	at java.security.AccessControlContext.checkPermission(Unknown Source)
26	at java.security.AccessController.checkPermission(Unknown Source)
27	at java.lang.SecurityManager.checkPermission(Unknown Source)
28	at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
29	at java.lang.Class.checkMemberAccess(Unknown Source)
30	at java.lang.Class.getDeclaredMethod(Unknown Source)
31	at javassist.ClassPool$1.run(ClassPool.java:79)
32	at java.security.AccessController.doPrivileged(Native Method)
33	at javassist.ClassPool.<clinit>(ClassPool.java:76)
34	... 22 more
35java.lang.NoClassDefFoundError: Could not initialize class jdos.cpu.core_dynamic.Compiler
36	at jdos.cpu.core_dynamic.Compiler$1.run(Compiler.java:44)
37	at java.lang.Thread.run(Unknown Source)

fonzel: Always good to see that stuff works

ZaDarkSize: I will need more information since I am unable to reproduce your bug. Did you compile this yourself? Does the doom demo work for you in your setup on http://jdosbox.sourceforge.net/Doom.html?

The Doom Demo works but it's different from the latest release jar

http://jdosbox.sourceforge.net/Doom.html
File: jdosbox.27.1.jar Size: 4.782.457 bytes

http://sourceforge.net/projects/jdosbox/files … ox.jar/download
File: jdosbox.jar Size: 4.782.413 bytes

The latest release jar is causing that error.

ZaDarkSize:

Here is doom running an unsigned version of the latest released jdosbox.jar

http://jdosbox.sourceforge.net/Doom/Doom.html

From the java console I can see that I was using the latest JRE

Using JRE version 1.7.0_25-b16 Java HotSpot(TM) Client VM

and further down I can see that it correctly identified it self as running unsigned and thus disabling the compiler.

Applet.init()
Applet is not signed
mouse capture will not work
disabling compiler
Applet.start
About to start DosBox
DOSBox version 0.74.28

Your error looks like it was trying to use the recompiler. The only things I can think of are.
1) You compiled it yourself and had a problem
2) jdosbox.jar is not signed and for some reason it didn't detect that
3) jdosbox.jar is signed but your browser for some reason didn't allow creating classes on the fly

Questions
1) What OS and browser are you using?
2) Did you compile the source yourself?
3) Are you trying to run signed or unsigned jdosbox.jar?
4) Did you try other browsers or OS's with the same JRE?

OS: Windows 8
Browser: Firefox 21.0 (but I don't think browser matters)

I didn't compile it myself, I downloaded the official jar from sourceforge. The official jar is unsigned.

Just follow the link and observe the problem: http://dekadence.ro/jdosbox/

ZaDarkSize: I noticed that your version is 0.74.27, the latest is 0.74.28. I was able to reproduce the problem with your build.

I also discovered that the download link on sourceforge was pointing to 0.74.27, I updated that to point to 0.74.28 now. Sorry about the confusion, hopefully build 28 will work for you.

Glad that's fixed, 0.74.28 is working perfectly fine for me 😁

Just an update on the state of the Java port.

I'm not actively working on it any more. I feel that it performed its primary mission of playing DOS games in a browser pretty well. I started adding more features to it so that it could boot Windows 95/98/ME/XP with the hope of being able to play older games but there were a lot of problems with that approach. Firstly, we can't share Windows images on a website legally, but perhaps we could work around that with Linux/WINE or ReactOS. Secondly performance wasn't really there. I've spent a lot of time looking at performance and I pretty much hit a brick wall.

But I still have a goal of playing old Windows games, like Win16 games on Windows 7/8. Or just older Win95 games which no longer work on Windows. I tried starting from scratch and added some Win32 API's to an experimental copy of jDosbox. I even got Age of Empires and Caesar 3 to work. But it quickly became evident that this approach would be too much work for one person. And since WINE already did all this work perhaps I could find a way to leverage what they have done. Basically I want WINE to run on Windows and/or in a browser. So for the past few months I've been researching porting WINE to SDL with the stretch goal of compiling it to javascript with emscripten. I will base the CPU emulation off of what I've learned from DOSBox, but because it won't have interrupts it should be simpler and faster. So far I don't have anything to demo yet, but I did get the kernel32, gdi32 and user32 to compile with Visual Studio with only about 100 changes to the WINE code.

If anyone would like to continue work on jDosbox let me know and I'll give you check in privileges on sf.net

I appreciate your work in developing the Java port and its additional patches. Your work toward avoiding page fault overruns is particularly interesting; I also have been curious about your implementation of multithreading for the Voodoo1 code.

I wish you success on your current work on WINE to SDL, I'm sure we will all benefit from it. I wonder how this approach relates to HX DOS Extender. It also provides a replacement for kernel32 and other system files, although WINE will have the other important bits for the gaming API.

Thank you!