DOS version of DOSBox-X does not run in DOSBox-X

[Wengier]

As a DOS emulator, DOSBox-X should be able to run its DOS version as well, but it turns out not to be the case. Tried bigger memory size (e.g. 64MB), UNIVBE to add VESA modes, and running in a DOS guest system (instead of the integrated DOS), neither will work - it will either crash or show a black screen with mouse depending on the HXGUIHLP.INI setting. Tried it in DOSBox ECE and dosbox-staging, they will not work either, but (unlike DOSBox-X) they are primarily for running DOS games. I believe the problem is likely related to the VESA code.

[grapeli]

Linux version works. No revelation.
It also works under dosbox-SVN and dosbox-staging.

Older version, because I'm lazy and unwilling to build a compiler newer than gcc-4.7.4 (its compatibility with -std=c++11 is not enough). No sound support, no mouse or anything else. So unnecessary for testing purposes.

memsize=63 should usually do.
dosbox-x.linux.zip
edit: I uploaded a new compilation is faster, the previous one was terribly slow.
dosbox-x.linux.zip
edit: One more version based on the latest code, built with gcc-6.5.0. Unfortunately, like the previous ones, it does not finish working properly. This can be checked under Linux with a framebuffer, for example a web one like JSLinux (SDL_NOMOUSE=1 ./dosbox-x).
dosbox-x.linux.zip

[Wengier]

I tried your package, and it works indeed. Thanks for this. But it is not the official DOS package I was talking about, and it uses a completely different approach by booting into Linux via LOADLIN, yet there is no way to boot back to DOS unless you completely restart DOSBox-X. It is mostly useful for demonstration purpose I guess.

[grapeli]

Yes, this is a purely experimental version, probably with many bugs.

As for the dosbox-x version for HX-DOS. I was running it under Qemu and dosemu2 (it works). Under Qemu with freedos requires at least 87-90MB of memory (quite a lot) to run.

Under dosbox-x it starts to boot after changing core=normal and modifying the HXGUIHLP.INI file (change to 640x480x8) and seems to stop. Maybe it requires a higher resolution, although under qemu and dosemu2 this is fine.

[Wengier]

@joncampbell123 I see the 0.83.6 release note currently says "hx-dos builds are not available due to symbols that do not exist when compiled for that target.". Which symbol(s) do not exist for HX-DOS? Perhaps I can fix it quickly.

[joncampbell123]

tinyfd_MessageBox. I'll pull up the Windows XP VM and compile again to get the error message.

I am compiling MinGW builds now, try not to change code during this time please.

[joncampbell123]

Here you go.
Errors.txt

[Wengier]

@joncampbell123 I think I know why. Not difficult to fix, but I will wait for you to finish the current compilation of course.

[Wengier]

@joncampbell123 Please let me know when it is ready to push the code. There is only one file to be slightly changed.

[joncampbell123]

@Wengier Fell asleep early, go ahead and push for HX-DOS. I'll upload MinGW64 and Mac OS X builds that finished last night.

[Wengier]

@joncampbell123 I have already pushed the HX-DOS fix. Please check it out.

[joncampbell123]

@Wengier That fixed it. Building now.

[Wengier]

@grapeli The latest code already supports the x86 dynamic core (both 32-bit and 64-bit, with core=dynamic or core=dynamic_x86), so it will hopefully be noticeable faster than before. Also, there is now official support for Linux Flatpak, so Linux support is also improved. But I wonder if there is a way you can boot back to DOS once you start the DOSBox-X Linux version from DOS? Since the current HX-DOS package does not run inside DOSBox-X, I think the Linux approach can indeed be a pretty good alternative approach if major issues are solved. In any case, thanks for demonstrating that such a version does indeed work!

[grapeli]

@Wengier
Before that, I was interested in the comparison with dosbox-SVN and staging (universal build). They cannot handle the keyboard on kernels newer than 2.4 (8042 auxiliary port). A serious limitation.
In general, under dosbox, it is only possible to boot the linux kernel under 386 architecture. On Linux, support for it was removed in 2013 (newer than 3.7 won't work).
https://kernelnewbies.org/Linux_3.8#Removal_of_support_for_386_processors

I will try to build the latest dosbox-x.

edit: Linux kernel built for i486 and i586 (I checked it on 3.2.102) boots under the latest dosbox-x

[grapeli]

The latest dosbox-x with fluidsynth support.
I have configured the kernel with OSS sound support and additionally SDL, fluidsynth, but I can't get them to work.

edit: Soundblaster works under Linux. At least in that form: cat /root/.dosbox/dosbox-x.conf > /dev/dsp0
Unfortunately not in dosbox-x.

edit: Configuration error. Instead of SDL_AUDIODRIVER=dsp I used oss.
Now the sound works under silverball.
My expectations for fluidsynth service were excessive. Is there not enough CPU power? All you hear now is gurgling.
fluidsynth -m oss -a oss -l -i /etc/sf2/minipiano.sf2 /root/dos/DOSMID/12.mid

[Wengier]

@grapeli Sure, you can check and compare these branches (you are apparently an experienced user). We are also trying to helping each other and several collective efforts are made as well. Recent examples include #1961 and #1964.

Back to topic - I have checked out the latest DOSBox-X Linux build you made. Thanks for making it, and it certainly runs successfully inside DOSBox-X itself. Since it appears to run better with more DOS file handles, I have now increased the default maximum DOS handles in the latest DOSBox-X code, although it is always customizable in the config file (in [config] section which tries to emulate DOS's CONFIG.SYS file).

The other issue was that there is no way to boot back to DOS once LOADLIN has started - even the menu items "Reset virtual machine" or "Reboot guest system" apparently did not work previously. So I have decided to fix the resetting function as well, and with the latest code I can now click the reboot menu option to boot back to DOS, at least with core=normal or core=auto. I do not know if there is a native way to exit from LOADLIN, but getting DOSBox-X's reboot function to work for LOADLIN (as already done) is certainly very helpful.

I think the biggest issue for now seems that there is no mouse support, so I cannot select the menu items from DOSBox-X running inside LOADLIN. Additionally, moving the mouse may sometimes cause DOSBox-X inside LOADLIN to freeze, although I can now select DOSBox-X's reboot function to restart LOADLIN. I wonder if there is a way to get the mouse to work?

I have also tried to play the /root/dos/DOSMID/12.mid file with DOSMID inside LOADLIN+DOSBox-X, and it does show the graphical interface and seem to be playing, but I did not hear sound yet. Perhaps there are some settings (or other adjustments) required to get the sound to work?

In any case, it is definitely getting better and better, and I highly appreciate your effort.

[grapeli]

@Wengier
A fifo /dev/gpmdata was missing. Now the mouse works in the menu (as far as).
dosbox-x.linux.zip

Fluidsynth works properly under qemu only with kvm acceleration. With tcg, also not enough power. Switch to the second console (alt-f2) and run top.

qemu-system-x86_64 -machine pc,accel=kvm -cpu host -m 128 -net none 
-device sb16,iobase=0x220,irq=7,dma=1,dma16=5 
-kernel /tmp/dosbox-x/vmlinuz 
-initrd /tmp/dosbox-x/dosbox.cfs 
-append 'ramdisk_size=12288K root=/dev/ram0 rw vga=788 sb=0x220,7,1,5 dmabuf=1 quiet' -monitor stdio

Too bad dosbox-x doesn't work with the linux 8-bit framebuffer (vga=771). Framebuffer is generally slow with a 16-bit color palette much more.
https://www.systutorials.com/configuration-of-linux-kernel-video-mode/

[grapeli]

@Wengier
Latest build containing this commit.
dosbox-x.linux.zip
Compiled with flags, among others -march=i386 -mtune=generic .

dosbox-x, running linux, top (busybox), ~10% CPU usage
qemu (accel=tcg), running linux, top (busybox), ~0.2% CPU usage

[Wengier]

@grapeli Yes, I can now use the mouse to activate the menu with the new build, which is certainly a good progress, although the mouse operations may appear to be somewhat buggy. But I can open for example Configuration Tool and Mapper Editor from menu just fine, so the menu system is already starting to become useful.

Since I am primarily using Windows, kvm is not available for QEmu on Windows. I usually run Linux inside a VM, and apparently you cannot expect a good speed for this. When I run the Linux DOSBox-X inside Windows DOSBox-X Fluidsynth did not appear to work yet, but OPL3 did work so that "dosmid /opl 12.mid" will indeed play the music (although speed may be a concern).

For Linux 8-bit framebuffer support, I am not sure if there is an existing config option in DOSBox-X for this purpose. Perhaps @joncampbell123 knows more about this.

As for CPU usage, perhaps you can try DOSBox-X's built-in DOSIDLE program. Activating it may significantly reduce the CPU usage.

Once again, thanks for the improvement. I hope to further improve DOSBox-X's compatibility with LOADLIN as well.

[joncampbell123]

@Wengier The way the code is written (and DOSBox SVN has the same limitation) makes it extremely unlikely DOSBox/DOSBox-X would ever support rendering to a 256-color display.

Most SVGA cards since the late 1990s have supported highcolor and truecolor modes.

[grapeli]

@Wengier
Fluidsynth is currently not working.

fluisynth: error: Device </dev/dsp> could not be opened for writing: Device or resource busy
LOG: MIDI: fluidsynth: Can't create audio driver

Before it worked (or so I thought). Soundfont was also loaded (I saw it in the logs). I'll check it (I don't know what's going on). It works.
/bin/fluidsynth -m oss -a oss -l -i /etc/sf2/minipiano.sf2 /root/dos/DOSMID/12.mid
Starting the second fluidsynth fails (too few dsp devices).

As for the support of 256 colors. Maybe there is some incompatibility with the linux framebuffer (maybe it's SDL's fault). I checked an earlier HX-DOS version of dosbox-x and it worked fine in that color space.

I only treat it as a curiosity. I don't see any use in this.

edit: With OSS only one process can open a given sound device at one time. These limitations can only be overridden by using the sound server (esd).

[Wengier]

@grapeli I see. It is certainly helpful to get Fluidsynth working again.

Meanwhile, I have tried to further improve compatibility with LOADLIN - now menu items such as "Show Sound Blaster configuration" and "Show MIDI device configuration" should work in the outside DOSBox-X that has LOADLIN running. Previously it did not appear to work at all and will likely cause a LOADLIN kernel panic message.

[grapeli]

I see. It is certainly helpful to get Fluidsynth working again.

I can use ALSA. It can mix sound from multiple sources (dmix) when the sound card has no hardware mixer. The libasound library is linked in dosbox-x anyway. Useless. Although SDL and fluidsynth were built without alsa support, dosbox-x requires libasound for linking. Although it was configured with --disable-alsa-midi.

I wanted to simplify the configuration, minimize the size of the binary code.

I will build another toolchain based on uclibc-ng or musl-libc. Maybe it will be a better option. It certainly won't provide as good binary compatibility as this one (Linux 2.4.6).

edit: I compiled a working version of dosbox-x based on musl-libc (buildroot). Under kernel 3.2.102 it works (the size of vmlinuz increased 3 times). Dosbox-x exits correctly after the exit command. The mouse works, the sound - I don't know (setup requires effort).

[grapeli]

New build. In one better, in another, weaker.
dosbox-x.linux.zip

The menu works correctly after clicking on Video>Toogle fullscreen.
The sound works. Fluidsynth too.

Framebuffer (vesafb) is slower. Much better under dosbox-x, s3fb does not work 100% correctly with dosbox on this kernel (I had to drop it).
Poweroff and reboot doesn't work. Busybox (default config) is very truncated. A few redundant libraries, pcre, glib2 (fluidsynth can be built without these dependencies).

Under qemu it runs at a speed a few percent slower than the native binary (maybe around 10%).
qemu-system-x86_64 -machine pc,accel=kvm -cpu host -m 128 -net none -device sb16,iobase=0x220,irq=7,dma=1,dma16=5 -kernel vmlinuz -initrd dosbox.cfs -append 'root=/dev/ram0 rw vga=788 ide-core.noprobe=0.0 ide-core.noprobe=0.1 ide-core.noprobe=1.0 ide-core.noprobe=1.1 quiet' -monitor stdio

I am impressed - Linux kernel 4.4.241 runs under DOSBox-X.

[Wengier]

@grapeli Yes, the latest build of DOSBox-X Linux runs fine inside my latest DOSBox-X Windows with the settings memsize=63 and files=255. The menu works too (in full-screen mode as you mentioned). So it is already usable, and I can run the programs in the Linux directories.

For some reason mididevice=fluidsynth does not work here - when I click the menu "Show MIID device configuration" it says "MIDI device: None". But since it works on your system I guess it may be a configuration issue here.

Overall, it is pretty impressive, and thanks for the efforts! As I mentioned earlier it can be eventually offered as an alternative package considering that the HX-DOS package does not run in DOSBox-X.

[grapeli]

@Wengier
Memory usage. The key is kernel configuration. The current one is underdeveloped (Is bad). The kernel boots at memsize=32 and with this initrd, it will be at 16-18. Counting down the memory needed for dosbox.cfs is too much.

The file system is read-only. You can modify the configuration file.
vi .dosboxrc

The whole thing is makeshift. To perfect it, you need to have knowledge, appropriate skills and a lot of time (I miss these three elements).

[Wengier]

@grapeli I don't think there is actually a need to "perfect" it anyway. You can never expect any DOS version (HX-DOS or LOADLIN) of DOSBox-X to work the same way as if you are running the Windows or Linux version of DOSBox-X. In fact, many features have to be disabled in the HX-DOS build so that it will build successfully. However, since the main target users for the DOS package are DOS users (MS-DOS or FreeDOS users for example), they will definitely know even if the DOS version will run on their DOS systems, it cannot provide all features as in the other OSes.

Considering the above, I think the general expectation of any DOS version of DOSBox-X is basically this - it will launch reliably from a DOS environment (real DOS or inside DOSBox-X in the case of LOADLIN version), and from its shell users can run basic DOS commands and programs, and they can also use the major menu functions (Configuration Tool etc) or change the common config options (frequently-used machine types etc) and see the results. On the other hand, they cannot expect all menu functions/config options/features to work exactly the same way as in Windows or Linux version of DOSBox-X. If any DOS package can meet this expectation then I think it can be considered a functioning DOS package.

[Wengier]

The HX-DOS package has the advantage that it is actually running in DOS in the whole time, and users can exit to DOS any time they want. On the other hand, the LOADLIN version cannot do this, but it can run in DOSBox-X itself. The HX-DOS package is a truer DOS package in this sense, but the LOADLIN version may be considered an alternative solution.

P.S. DOSBox-X version 0.83.7 was released. You can check it out.

[Wengier]

@grapeli Thanks! The said header file was added and the updated DOS LOADLIN package now appears on the website.

[grapeli]

@Wengier
Build 0.83.16.
dosbox-x.linux.zip

[Wengier]

@grapeli Thanks. It has been repackaged as usual and appears in the website.

[Wengier]

@grapeli Is there a DOS loadlin package for the 0.83.19 version? Thanks.

[grapeli]

Build 0.83.19.
dosbox-x.linux.zip

[Wengier]

Thanks @grapeli. It loads DOSBox-X fine.

[Wengier]

@grapeli DOSBox-X 0.83.20 is now released. Is there a DOS LOADLIN package for it? Thanks.

[grapeli]

Build 0.83.20.
dosbox-x.linux.zip

[Wengier]

@grapeli Thanks. It is now up.

[Wengier]

@grapeli DOSBox-X 0.83.21 is now released. Do you have a DOS LOADLIN package for it? Thanks.

By the way, can you add language files to the file system so that they can be loaded?

[grapeli]

@Wengier

By the way, can you add language files to the file system so that they can be loaded?

Next time.

Build 0.83.21.
dosbox-x.linux.zip

[Wengier]

@grapeli It is up now.

[grapeli]

@Wengier

@grapeli It is up now.

Very good news for the beginning of 2022.
I didn't add language files because the whole thing was to be as small as possible. Buildroot is built without NLS (Native Language Support) without locale support, moreover its essential part of busybox without unicode support.

One more observation. More and more system dialogs are added to dosbox-x. When running dosbox-x on fbcon or kmsdrm (it is possible that someone will run it on RPi, for example), this pop-up is blocked (it's good to know magic SysRq shortcuts). Remember when using kmsdrm, fbcon you cannot use anything else at the same time.

For example, let's take this commit.
Run this dosbox-x in dosbox-x or wherever you want.
Make a screenshot. OKAY. Works fine (because dosbox-x is invoked from init).

Quit dosbox-x. Hit enter. Run now directly from the shell.
Make a screenshot. Suddenly everything freezes. Tiny file dialogs appears underneath, waiting for "Enter" to be pressed. You are blocked at this point.

Try again. Now preventing the unwanted "window" from appearing.
( dosbox-x & ) >/dev/null

[Wengier]

@grapeli I tried to see the CJK characters as displayed by the TTF output in the LOADLIN build, which was why I asked to add the language files (otherwise they are not accessible from the file system). The TTF output does work in the LOADLIN build as far as I know.

[grapeli]

@Wengier
dosbox-x.linux.zip
I added these language files. They are located in /usr/share/dosbox-x/translations.

Of course, you can attach a disk image (I am thinking of running dosbox-x in dosbox-x).
The kernel has added support for such filesystems, among others - ext2, vfat, msdos (9p from Qemu).
For hd_520. In the linux.par file, change the lines to:

#ide-core.chs=0.0:32,16,63
ide-core.chs=0.0:489,16,63

and

ide-core.noprobe=0.0
#ide-core.noprobe=0.0

Please mount this disk image before starting loadlin.
imgmount 2 hda.img -size 512,63,16,489 -t hdd -fs none
Be patient. There will be a 30-second pause that cannot be skipped - "hda: lost interrupt" (unless you use Linux 2.2.x from 1999).
Quit dosbox-x. Mount filesystem from shell.
mount /dev/hda1 /mnt
Run dosbox-x.
dosbox-x -set output=ttf -lang /mnt/src/dosbox-x/contrib/translations/es/es_ES.lng -c "mount d /mnt/dos"

[Wengier]

@grapeli Can you make a DOS LOADLIN package for the latest release (0.83.23)? Thanks!

[grapeli]

@Wengier
Build 0.83.23. I only checked it briefly in action. I haven't tested it.
dosbox-x.linux.zip

[Wengier]

@grapeli Thanks. It appears to run; added the link accordingly.

[grapeli]

Boot up properly with cputype=pentium, pentium_ii, ppro_slow (host settings).
Does not work properly with cputype=pentium_iii.

dosbox-x-0.83.23.in.dosbox-x-0.83.23.cputype.pentium_iii.mp4

[Wengier]

@grapeli DOSBox-X 0.83.24 is being released. Can you make a DOS LOADLIN package for it? Thanks!

[grapeli]

@Wengier
Build 0.83.24.
dosbox-x.linux.zip

[Wengier]

@grapeli DOSBox-X 0.83.25 has been just released. Can you make a LOADLIN package so that it can be run in DOSBox-X itself? Thanks!

[grapeli]

@Wengier
Build 0.83.25.
dosbox-x.linux.zip

It works. Thanks to the new option show recorded filename=false, even better, it does not lock up when taking a screenshot, for example.

[Wengier]

@grapeli Thanks for it. I can confirm it can run (with memsize=127 and cputype=pentium as mentioned in README.TXT).

[BridgeHeadland]

@joncampbell123 At least I don't have NTVDM on my PC, so I wonder if the configuration files, which come with HX-DOS, really have any effect on HX-DOS, since they come with it. I would like to see if I can run HX-DOS with Tandy as machine value, in DOSBox-X with VESA 2.0 (NOLFB) as machine value.
At least I can find out here, without having to test it myself, not until there is a replacement or something for NTVDM, if that happens.
Regarding HXGUIHLP.DLL, why is the default setting at 800x600x16? Why isn't it at -1x-1x-1 - which (at least in my case) is at 4294967295x4294967295x4294967295? I have tried 0x0x0 to, but then no picture comes up.

[grapeli]

ScummVM 2.6.1 for DOSBox-X.

I run it like this.
dosbox-x -set "floppy drive data rate limit=0" -set "hard drive data rate limit=0" -set cputype=pentium -set memsize=128 -set cycles="max 105%" -set core=dynamic_x86 -set output=opengl -set "sample accurate=true" -c "imgmount 0 ./boot/grub.ima -t floppy -nofs" -c "mount c ." -c "boot a:"

For what purpose? Neither. Just for fun. Test version. Certain things certainly don't work.
With fluidsynth and mt32. I do not suggest activating them, they need much more cpu power than emulation can provide.

Keyboard shortcuts:
Ctrl+m displays the global main menu.

There is still a version under win9x, I didn't try to run it under dosbox-x.