I did just a quick test but it works. I didn't try it for a long time so it's got some suprises (gui). 😀

Man pages might still be usefull for *nix guys, but they need to be brought up to date. If you don't like messing with them, you migh try some cross-platform document generator.

I rolled up a tarballl of the current source (minus vs2008 directory): http://bocke.na.rs/distfiles/dosbox-x-git20140520.tar.xz. A patch to correct the stuff Gulikoza pointed to: http://bocke.na.rs/distfiles/dosbox-x-git2014 … 0-linux64.patch. Slackware 14.1 x86_64 package is here: http://bocke.na.rs/slackware/14.1-x64-test/em … 6_64-1bocke.txz.

It's interesting loadlin.exe works with dosbox-x. It loads Linux kernel (tried on 2.2 and 2.4 from zipslack), but it breaks during the startup not finding the hard drive partition to boot from. I guess you need to mount a disk image to get it booting. That's a bit unfortunate because UMSDOS files are in the mounted directory, not on a separate disk image.

In upstream DosBox it fails, so it's interesting to see it at least booting the kernel. Too bad it doesn't work completely. It would be great for quick testing those old Linux distros that start from DOS.

Another thing I noticed, DosBox-x, like upstream DosBox, truncates any long names. It would be more usefull to at least implement classic 8.3 shortening if not LFN.

Zipslack works, but you failed to identify the fat16 drive partition. You would change the disk image device from /dev/sda4 to /dev/hda1 (given the common scenario where an image is mounted as a primary master device and the fat partition is at #1).

You can learn more about linux devices here: http://en.wikipedia.org/wiki/Device_file. Also, you may test the LFN in 9x which works fine. You may also have failed to test this; you may read more about how UMSDOS handles LFN here: http://wiki.linuxquestions.org/wiki/UMSDOS.

I now have a custom image of linux using UMSDOS and it resides entirely on a fat16 disk image. It boots into the command line and requires just a couple of commands to start a minimal window manager. I believe it should compress to about 250 megabytes and the license allows for distribution of modified binaries. If others are interested in this disk image and have a site to host the image, please post below.

The image is based on slackware 10 and there are many additional packages available, including versions of "wine". I was able to run a past version of dosbox inside this linux guest. Also, the linux installation is further customizable since the user can write to all files. I customized many parts of the OS, including the bulk of the startup scripts (rc.d), msdos.sys, the kernel boot parameters, and the startx, xinit, and xorg.conf configuration files.

Attached is an image of Dark Forces running in dosbox 0.62 inside linux inside dosbox(-x). As expected, the frame rate was low. As an alternative to using X11, the console mode seems very responsive; given svgalib is supported in the above configuration, then SVGALib games could be tested. I believe that SDL has a svgalib driver.

The framebuffer console is an alternative to X11, at least for running dosbox within dosbox/linux. It seems more responsive to input at a better frame rate. To use this device via the bash shell: export SDL_VIDEODRIVER=fbcon. Music, sound, keyboard, and mouse are working. This may work for some SDL applications/games; attached is an image of dark forces running by this method.

I recall that an early wine version accessed the fbcon device, but I haven't confirmed this. I wonder if this would be an easier path than porting wine directly to SDL.

The 3dfx framebuffer device (3dfx-fb) is working in the Linux guest! This device replaces the vesa framebuffer, so that the X windowing system uses the Voodoo emulation instead of the S3 emulation to display to monitor.

To do this, first one finds the PCI slot of the Voodoo emulated card by running the command: lspci. In my case, output showed PCI:0:1:0. This is entered into the relevant line of xorg.conf. Also, the X device driver is changed from "vesa" (the S3 device) to "fbdev". I also set the resolution and bpp to 640x480 at 16bpp. The last setting is in the bash shell: export FRAMEBUFFER=/dev/fb1.

Next, I typed: insmod sstfb. The screen goes blank, but the keyboard is sending commands to the OS. So, I next typed: startx. This will start the X windowing system (and twm window manager as previously configured) which will then utilize the Voodoo as a framebuffer device. Attached is an image of this, including the same graphical anomaly seen in dosbox where running d3d games in the 9x guest (possibly a result of the host OS video driver and an incomplete opengl capability).

Edit: The Voodoo framebuffer in software mode is not showing any graphical artifacts. It also seems to run better and faster than the S3 device, at least as configured.

Hey, thanx for testing. 😀

I knew it would probably work with an emulated disk image. I just wanted to say i was hoping it would work without one. For example, I thougt the mounted local directory might get recognised as a physical drive. Similarly I was talking about LFN under dosbox mounted directory (in win9x on a separate drive image, I guess LFNs are handled by the OS itself).

In both cases you don't get anywhere without a disk image. But the good news is loadlin actually works (it doesn't with the upstream DosBox).

And why I didn't try the hd emulation? Mostly because I needed a fast test. I don't know the new DosBox-x command syntax so this was quicker. 😀

truth5678 wrote:

Attached is an image of Dark Forces running in dosbox 0.62 inside linux inside dosbox(-x).

Cool. 😀

truth5678 wrote:

I believe that SDL has a svgalib driver.

SDL also has a Linux framebuffer driver. I think Linux has a support for VESA framebuffer devices since kernel 2.2.

Ok, I got what you meant: using svgalib drivers for running SDL apps and games?

With somewhat limited testing of guests inside dosbox, the framebuffer drivers, including fbcon, fbdev, and 3dfx-fb, show good results in the console and in the X window server. Between those two options, the console mode seems more responsive to input than X.

In the console, the svgalib graphics library was commonly used for games, but the linux distribution would have to be customized with the proper library versions (and maybe the kernel, too). Instead, I tried SDL-based emulators in the console via the "fbcon" driver. This was a successful approach (see one of the images above).

Wine was not working well with the above slackware-based distribution, likely because of the 2.4 linux kernel. I had success with 2.6, however. There were reports that the Wine versions of that time required a particular multithreading function, but the 2.4 kernels did not commonly compile that feature in. My impression is that the 2.4 (or even 2.2) kernels would co-exist with the dosbox emulation and Wine could be built specifically for this environment. This is not a simple method to run games and not a particularly fast one either. The linux kernel is reporting the cpu at the speed of a Pentium ~70mhz, while 9x is running games 2x or 3x faster, including much lower latency in video and audio. I have been hopeful that the console would provide an alternative environment to X-based Wine. However, many of those console-based games will have an equivalent in Dos or W3.1, both running in an unmodified dosbox.

I believe danoon is working on porting Wine to SDL. There is also a report by the Wine developers that they had done something similar for win16 applications, although the software appears unreleased. Both mention the necessity of an x86 emulator to robustly port Wine (to SDL). I'm sure they are choosing the best path to port win32 games to other environments, but I have been curious if a linux kernel could be modified and customized for running Wine and whether dosbox video emulation could provide hardware acceleration. These approaches do not require a copy of 9x.

Running linux in dosbox-x has a lot of utility, but for directx gaming -- 9x inside dosbox-x is a better choice.

The dynrec core is portable and, so far, seems fairly fast in speed. Does this core also have show the same problems in debugging as the dynamic core?

The x86-specific dynrec core allows a boot into 95, but not all applications work, such as opening a command window which results in the OS locking. If it is possible to easily add a non-recursion function to this core, and it in fact fixes the OS locking problem, then the other non-x86 dynrec cores would benefit. 😀

I enabled the dynrec core via configure (also disabled fpu-x86 for testing).

Tested further with the dynrec core, but modified the "cache block" size to 1 instruction. It shows increased compatibility for 95 games. However, it requires a "non-recursion" patch to work with your IDE emulation. Presumably the "cache block" speed optimization is the cause of some of the runtime errors while running 95 (and possibly in linux).

Also, the dynamic-x86 core may be modified in this way, but I haven't yet tested that configuration.

Hi. Glad to see Linux running so well within DOSBox-x! I went ahead and tried various things with dynamic cache block size as "1" and noted the results. It does seem to improve running with Windows 95, but it also increases the chances that 32-bit DOS games will cause DOSBox to error out with "out of cache blocks". So I went ahead and made it a dosbox.conf configuration choice for further experimentation.

Where is the "dynrec" core? I only see the dyn_x86 dynamic core.

Hi, thank you for the updates! Offering the "cache block size" configuration item is nicely implemented. A disabled "cache block" seems to have a better benefit while in the "dynrec core", accessible by the configuration line "./configure --disable-dynamic-x86" and then core=dynamic, afterwards. I think there are two dynamic recompiling cores, dynrec and dynamic-x86; even though both are accessible by core=dynamic, only one is available per dosbox executable because the compile phase only allows one or the other. 😀

The dynrec is the portable core since it is in C/C++, whereas the older dynamic-x86 core seems to be x86 assembler optimized, (much) less portable, faster, and likely more compatible with guest OS programs. All non-x86 ports are in dynrec format, but I haven't been able to determine if the fpu code is portable in this same way, via risc.xyz files in the /cpu/dynrec/directory.

@TheGreatCodeholio:

Sorry, if I wasn't too clear in my posts, I was replying after an almost sleepless night. 😀

Maybe you didn't see the question but I asked you about the removal of the man page.

I also suggested that you might use some cross-platform documentation generator if you are not really familiar with the format and do the most of your development on Windows (Visual Studio). Sorry if I got the wrong impression. 😀

bocke wrote:

A patch to correct the stuff Gulikoza pointed to: http://bocke.na.rs/distfiles/dosbox-x-git2014 … 0-linux64.patch.

Anyway, the patch itself was mine. The idea was Gulikoza's. But you're not wrong to credit Gulikoza (as you did in the git repo). He pretty much told me to put ifdefs. 😀

Cheers,

Bocke.

bocke wrote:

@TheGreatCodeholio: […]
Show full quote

@TheGreatCodeholio:

Sorry, if I wasn't too clear in my posts, I was replying after an almost sleepless night. 😀

Maybe you didn't see the question but I asked you about the removal of the man page.

I also suggested that you might use some cross-platform documentation generator if you are not really familiar with the format and do the most of your development on Windows (Visual Studio). Sorry if I got the wrong impression. 😀

No, I noted your request. I'll dig through the code now and remove the man page. I would rather do documentation in plain text anyway, now that Unicode (UTF-8) text files are widely supported everywhere. If anything more complicated is needed, I'll do HTML.

I do the majority of my work in Linux actually. Every so often I'll boot up a spare PC with Windows 7 and compile out a Win32 build, which is as far as I care to go with Visual Studio.

I apologize for sounding clueless, but where in the source tree is DOSBox's man page? I removed the libpng and SDL man pages in the vs2008 directory.

Hey guys, I did some more work on DOSBox-X this weekend. I got NMI emulation to work, I made some accuracy fixes to the Sound Blaster emulation, I removed the IRQ 6 pseudo-NMI hack for PCjr keyboard emulation and rewrote the keyboard to signal NMI for PCjr. I also made some other modifications with PC/XT emulation in mind. You can disable the second DMA controller and slave PIC (IRQ 8-15) using your dosbox.conf if it matters to some old software.

Also, DOSLIB and DOSLIB2 are now up on Github!

https://github.com/joncampbell123/doslib

https://github.com/joncampbell123/doslib2

Codeholio, about that last PM I sent you: I just confirmed it was a bug in your win32 builds; Whenever you try to mount multiple cd-rom images (.iso), with or without the IDE interface, DOSBox-X seems to crash. I fount this out by testing ykhwong's latest build against all of the DOSBox-X win32 releases, all with default dosbox.conf settings. Has anyone found this out on the Linux builds too, or is it only the Windows ones that do this?

Gui55 wrote:

Codeholio, about that last PM I sent you: I just confirmed it was a bug in your win32 builds; Whenever you try to mount multiple cd-rom images (.iso), with or without the IDE interface, DOSBox-X seems to crash. I fount this out by testing ykhwong's latest build against all of the DOSBox-X win32 releases, all with default dosbox.conf settings. Has anyone found this out on the Linux builds too, or is it only the Windows ones that do this?

I know that a few months ago I found several places where it was possible more than one array could refer to the same CDROM object, and cause segfaults when the object is deleted twice. I added code to detect that. Have you tried compiling a Win32 build of the latest DOSBox-X code?