Bandock wrote:

For anyone who is trying to compile the code through Visual Studio 2013 (possibly Visual Studio 2012), you will or have gotten t […]
Show full quote

For anyone who is trying to compile the code through Visual Studio 2013 (possibly Visual Studio 2012), you will or have gotten the following (or similar) error:

Copy code to clipboard

1Error	11	error LNK2005: _strtoull already defined in LIBCMTD.lib(strtoq.obj)	E:\DOSBox Source\dosbox-x\vs2008\* CIL library *(* CIL module *)	dosbox-x

There is a way to correct it and get it to compile. Make sure to comment out the entire custom strtoull function found in 'dosbox.cpp' (that includes commenting out the #ifdef preprocessor along with the #endif preprocessor). For some reason, it does not recognize that later versions now have their own strtoull function.

This should help any one of y'all out in getting it to compile under Visual Studio 2013 and maybe Visual Studio 2012 (works even on Express Editions, though make sure to comment out any 'afxres.h' presence). Another word is to make sure to use the Windows XP Toolset to make it use Windows SDK 7.1a unless you want to remove compatibility with Windows XP systems.

Edit: I have now confirmed that the issue only exists so far in Visual Studio 2013 (which may also affect future versions). Strtoull was added finally to Visual Studio 2013. Here's some updated code to implement support for compilation on Visual Studio 2013:

Copy code to clipboard

1/* TODO: move to utility header */
2#if _MSC_VER < 1800 /* Microsoft C++ does not have strtoull */
3	unsigned long long strtoull(const char *s,char **endptr,int base) {
4	return _strtoui64(s,endptr,base); /* pfff... whatever Microsoft */
5}
6#endif

Anything earlier than the compiler supplied with Visual Studio 2013 will use that code.

Thanks. In the 10 years I've been using strtoull I'm shocked that Microsoft actually got around to implementing it, just as surprised as when you could finally use "long long" instead of "__int64" like you had to in the Visual Studio 6.0 days. 😀

I took your example and added it to the source tree like this:

1#ifdef _MSC_VER /* Microsoft C++ does not have strtoull */
2# if _MSC_VER < 1800 /* But Visual Studio 2013 apparently does (http://www.vogons.org/viewtopic.php?f=41&t=31881&sid=49ff69ebc0459ed6523f5a250daa4d8c&start=400#p355770) */
3unsigned long long strtoull(const char *s,char **endptr,int base) {
4        return _strtoui64(s,endptr,base); /* pfff... whatever Microsoft */
5}
6# endif
7#endif

_MSC_VER doesn't exist on Linux systems and I'd rather avoid complaints from GCC about #if comparisons on a #define that doesn't exist 😀

truth5678 wrote:

ReactOS (extract jar file) boots in jDOSBox (attached picture below). However, DOSBox+enhancements (major emulation featured in DOSBox-x) results in this error when booting ReactOS: INT13: AH=41h, Function not supported 0x55aa for drive: 0x0.

jdosbox_boot.JPG

I looked at the JAR file there. Several comments.

One is that while DOSBox-X had INT 13h extensions, the code did not implement function AH=0x48 to return information about the drive. Apparently "FreeLoader" in ReactOS uses that function to get disk geometry. http://www.ctyme.com/intr/rb-0715.htm. I went ahead and added some basic emulation of that in.

Second is the .conf file in the image. jDOSBox is using a different configuration filename? When I attempted to boot DOSBox-X with it the first thing I noticed was the blank screen. It turns out for whatever reason the .conf file had set frameskip=-1, an invalid value that becomes unsigned int 0xFFFFFFFF (and thus DOSBox never redraws the screen). I added code to DOSBox-X to clamp negative values to 0, and the screen was visible again.

Third is the "boot -bochs HD" command. I've never seen that before. Is that a jDOSBox extension?

Fourth issue is that the BOOT command itself did not set the DL register to the BIOS drive it was booting. It looks like I made the mistake of statically assigning EDX. Adding code to set DL=0x80 when booting drive "C" allowed FreeLoader in ReactOS to boot it's menu. Perhaps their bootloader's approach is to assume the BIOS left the drive number in DL, instead of the MS-DOS approach of reading it from the boot sector. However, ReactOS got as far as loading the base OS and then hanging at a black screen.

Bandock wrote:

I have noticed recently that upon closing, DOSBox-X crashes (even with the provided Win32 Binary Build). Doing some debugging on it, I have found that it is trying to deallocate memory for different lists that were never allocated (or not properly allocated) in the first place. I have found that applying a condition to check if 'is_dummy' is false that it would delete/deallocate the memory for lists in reference to the Joystick.

Not sure if it was intended or not, but I tested it already with the conditional check. No more crashing upon exit.

Edit: I forgot to mention that turning off joystick support does not result in crashing. Only with it enabled (before fixing it of course).

Looking at the code to CStickBindGroup, that makes perfect sense (src/gui/sdl_mapper.cpp line 617). I now see that the issue is _dummy=true causes the class never to assign the pointers (pos_axis_lists,neg_axis_lists,button_lists,hat_lists) AT ALL. That doesn't necessarily mean they are NULL (though on my Linux system they usually are), they could contain some random pointer value based on the contents of that memory that happened to be there when the CStickBindGroup object was allocated. So the fix is simple: add code to initialize the pointers to NULL at the top.

1class CStickBindGroup : public  CBindGroup {
2public:
3        CStickBindGroup(Bitu _stick,Bitu _emustick,bool _dummy=false) : CBindGroup (){
4                stick=_stick;           // the number of the physical device (SDL numbering|)
5                emustick=_emustick;     // the number of the emulated device
6                sprintf(configname,"stick_%d",emustick);
7
8                sdl_joystick=NULL;
9                axes=0; buttons=0; hats=0;
10                button_wrap=0;
11                button_cap=0; axes_cap=0; hats_cap=0;
12                emulated_buttons=0; emulated_axes=0; emulated_hats=0;
13                pos_axis_lists = neg_axis_lists = NULL; /* <- Initialize the pointers to NULL. The C++ compiler won't do it for us. */
14                button_lists = hat_lists = NULL;
15
16                is_dummy=_dummy;
17                if (_dummy) return;

Farther down:

1        virtual ~CStickBindGroup() {
2                SDL_JoystickClose(sdl_joystick);
3                if (pos_axis_lists != NULL) delete[] pos_axis_lists;
4                if (neg_axis_lists != NULL) delete[] neg_axis_lists;
5                if (button_lists != NULL) delete[] button_lists;
6                if (hat_lists != NULL) delete[] hat_lists;
7        }

Thanks for looking at the image and for emulation to bypass the issue! I tested the image further, some time after the above post, and recall the problem with the "frameskip" parameter; but I didn't know the reason and assumed it was my system only. 🙁

I did look into the "bochs" command. I'm somewhat certain that jDOSBox uses the "Bochs bios" to boot, and that parameter allows ReactOS (and DSL Linux) to start, otherwise they result in disk errors (similar to the 7B stop error which occurs with NT4). My (naive) impression is that the booting problems are therefore likely related to the bios emulation (which you may have fully solved already).

That's great news on how far you got with loading ReactOS! 😀 Also, on debugging the DL register. It sounds like you are very close to booting the OS. I don't think it should be a video issue because jDOSBox boots with the dosbox video emulation.

TheGreatCodeholio wrote:

Looking at the code to CStickBindGroup, that makes perfect sense (src/gui/sdl_mapper.cpp line 617). I now see that the issue is […]
Show full quote

Bandock wrote:

I have noticed recently that upon closing, DOSBox-X crashes (even with the provided Win32 Binary Build). Doing some debugging on it, I have found that it is trying to deallocate memory for different lists that were never allocated (or not properly allocated) in the first place. I have found that applying a condition to check if 'is_dummy' is false that it would delete/deallocate the memory for lists in reference to the Joystick.

Not sure if it was intended or not, but I tested it already with the conditional check. No more crashing upon exit.

Edit: I forgot to mention that turning off joystick support does not result in crashing. Only with it enabled (before fixing it of course).

Looking at the code to CStickBindGroup, that makes perfect sense (src/gui/sdl_mapper.cpp line 617). I now see that the issue is _dummy=true causes the class never to assign the pointers (pos_axis_lists,neg_axis_lists,button_lists,hat_lists) AT ALL. That doesn't necessarily mean they are NULL (though on my Linux system they usually are), they could contain some random pointer value based on the contents of that memory that happened to be there when the CStickBindGroup object was allocated. So the fix is simple: add code to initialize the pointers to NULL at the top.

Copy code to clipboard

1class CStickBindGroup : public  CBindGroup {
2public:
3        CStickBindGroup(Bitu _stick,Bitu _emustick,bool _dummy=false) : CBindGroup (){
4                stick=_stick;           // the number of the physical device (SDL numbering|)
5                emustick=_emustick;     // the number of the emulated device
6                sprintf(configname,"stick_%d",emustick);
7
8                sdl_joystick=NULL;
9                axes=0; buttons=0; hats=0;
10                button_wrap=0;
11                button_cap=0; axes_cap=0; hats_cap=0;
12                emulated_buttons=0; emulated_axes=0; emulated_hats=0;
13                pos_axis_lists = neg_axis_lists = NULL; /* <- Initialize the pointers to NULL. The C++ compiler won't do it for us. */
14                button_lists = hat_lists = NULL;
15
16                is_dummy=_dummy;
17                if (_dummy) return;

Farther down:

Copy code to clipboard

1        virtual ~CStickBindGroup() {
2                SDL_JoystickClose(sdl_joystick);
3                if (pos_axis_lists != NULL) delete[] pos_axis_lists;
4                if (neg_axis_lists != NULL) delete[] neg_axis_lists;
5                if (button_lists != NULL) delete[] button_lists;
6                if (hat_lists != NULL) delete[] hat_lists;
7        }

Alrighty, I was just wondering about that. Yeah, I was thinking about adding NULL pointer checks to each list at one point. Something I have almost always done while dealing with dynamically allocated memory. 😀

Edit: I'm going to go ahead and provide the changes using the code you provided TheGreatCodeHolio. 😀

Edit 2: And it compiles with success. No crashes either. 😀

I wonder if loading a video bios will help: Video bios usage in DOSBox.

Here's another one. This one is slightly experimental.

http://hackipedia.org/Projects/DOSBox-X/dosbo … rc-nogit.tar.xz

1commit f3d764e48e06c404381400475f25192cc6ae3269
2Author: Jonathan Campbell <jonathan@castus.tv>
3Date:   Sun May 4 10:17:24 2014 -0700
4
5    El Torito bootable CD-ROM support added to IMGMOUNT command. At this
6    time, only floppy emulation is supported. The idea is that, since you
7    can imgmount a floppy with -fs none, then "boot -l a" from it, the added
8    code allows you to boot El Torito CDs with floppy emulation like this:
9    
10    imgmount d: some_cdrom.iso -t iso -fs none   # mount CD-ROM to D:
11    imgmount 0 -el-torito d: -t floppy -fs none  # mount El Torito floppy image on CD as drive A:
12    boot -l a                                    # boot OS from emulated floppy
13    
14    I'm proud to announce that the code as written now is sufficient to boot
15    from an old Windows 98 install CD I made years ago when CD burners had
16    just come out (floppy emulation).
17    
18    Up next: adding the same El Torito code to the BOOT command so that the
19    user can also boot the emulated floppy directly like this:
20    
21    imgmount d: some_cdrom.iso -t iso -fs none   # mount CD-ROM to D:
22    boot -cdrom d                                # boot OS from CD-ROM (El Torito code will automatically infer floppy emulation)
23    
24    And if I have time today, I will also add beta support for the "no
25    emulation" mode newer CDs tend to use so that Linux distros and
26    Windows XP can boot, along with the various INT 13h functions involved
27    with the El Torito support.
28
29commit fd4e4a8f503d5f160f33de46dd280532ab6728b9
30Author: Jonathan Campbell <jonathan@castus.tv>
31Date:   Sun May 4 00:09:38 2014 -0700
32
33    a LOT of modifications to IMGMOUNT command to accomodate -el-torito, and
34    to NOT require a path if -el-torito is given. Code is complete only far
35    enough to scan the ISO 9660 volume descriptors and locate the El Torito
36    structure.
37
38commit b8302486144b016ded07ba488f692342bc73219d
39Author: Jonathan Campbell <jonathan@castus.tv>
40Date:   Sat May 3 22:55:15 2014 -0700
41
42    BOOT command cleanup
43
44commit 1f60c04442a1425184336f282bdc15df0d3781f0
45Author: Jonathan Campbell <jonathan@castus.tv>
46Date:   Sat May 3 20:40:58 2014 -0700
47
48    modify IDE base IO port handler NOT to complain about I/O port lockout
49    on device/controller busy IF the port in question is the drive/head
50    register (port+6), because apparently there are MS-DOS drivers that like
51    to write to it during command execution "just to be sure" (but at least
52    the value written is the same as last time). Changed select() handler on
53    IDE device not to change state. This fixes a bug where ATAPICD.SYS
54    would issue a command then immediately write port +6 as described above,
55    causing the I/O and readback to malfunction and causing the IDE device
56    to get stuck in a busy state.
57
58commit b396f6189acb75f9ca069222f26e5c23f16ed8e8
59Author: Jonathan Campbell <jonathan@castus.tv>
60Date:   Sat May 3 19:26:52 2014 -0700

61
62    IDE: clarify why the command was dropped. fixup printf formatting and
63    typecasting in comparisons and uninitialized var warnings.
64
65commit e55bebc339fc0a7d64a4849201ace4b958179180
66Author: Jonathan Campbell <jonathan@castus.tv>
67Date:   Sat May 3 17:58:10 2014 -0700
68
69    INT 13h extensions Get Drive Params: tmpsize apparently is NOT the size
70    of the disk, added code to write disk size as cyls*heads*sects. Added
71    code to support v2.0 size 0x1E. This fixes problems with Windows 98
72    bootdisk FDISK.EXE crashing with a Divide By Zero exception.
73
74commit 4f319b3d89c7fb94f3ad567be3808db2911bb086
75Author: Jonathan Campbell <jonathan@castus.tv>
76Date:   Sat May 3 17:30:59 2014 -0700
77
78    src/ints/bios_disk.cpp when freeing the array of imageDiskList elements,
79    always scan forward and zero out future elements with the same pointer
80    value. Because apparently DOSBox will happily set that scenario up.
81    Yeah... um... can we say sloppy imageDisk management?? This fixes a
82    segfault that can happen on shutdown if you attach a hard disk, a CD-ROM
83    and then boot from a floppy.
84
85commit 69f6c25bb58666f25b5c930cb8c820883d20a26e
86Author: Jonathan Campbell <jonathan@castus.tv>
87Date:   Sat May 3 17:20:45 2014 -0700
88
89    fix printf() datatype formatting and typedefs
90
91commit 37b12ef2b2b1730ad6225bfea4a26bbcc7ad7de7
92Author: Jonathan Campbell <jonathan@castus.tv>
93Date:   Sat May 3 16:58:27 2014 -0700
94
95    fix: "value computed is not used" warning in messages.cpp
96
97commit 16b8b3172221cd93672f68ad11f26d5e607eb0ec
98Author: Jonathan Campbell <jonathan@castus.tv>
99Date:   Sat May 3 16:57:05 2014 -0700
100
101    src/shell/shell_batch.cpp remove unused variables
102
103commit 8083ba7387313408bef9b9ba5948ed85a89cabac
104Author: Jonathan Campbell <jonathan@castus.tv>
105Date:   Sat May 3 16:55:46 2014 -0700
106
107    fix: unused variable warning and comment-in-comment mistake in
108    src/shell/shell_misc.cpp
109
110commit e08cb6848db84388a1d9598e877f886c41d3d65b
111Author: Jonathan Campbell <jonathan@castus.tv>
112Date:   Sat May 3 16:49:14 2014 -0700
113
114    fix: uninitialied var warning with "scankeys", unused variable warnings
115    in two shell commands.
116
117commit 95f524b928af9f5224abb060d04bbadd37fbbe4e
118Author: Jonathan Campbell <jonathan@castus.tv>
119Date:   Tue Apr 29 23:40:08 2014 -0700
120
121    multivalue properties verify section pointer before freeing.
122    AUTOEXEC section now deletes autoexec object on shutdown, fixing another
123    memory leak.
124
125commit 89ddd179c512fb46fc0732f9f3e83d420b2702bf
126Author: Jonathan Campbell <jonathan@castus.tv>
127Date:   Tue Apr 29 23:14:03 2014 -0700
128
129    PCI bus: free PCI device objects on shutdown, fixing another memory
130    leak.
131

Thank you for the additional emulations! I noted the extensively coded El Torito emulation and look forward to testing a future version on the various operating systems! I plan to read that code portion more carefully -- it seems like an interesting implementation. I also was amazed by all the fixes, including a parameter to enable int13 extensions for "large" drives.

It is a great feat to debug and have "freeloader" (of ReactOS) work with your current code. 😀 I also now view the blank screen after the base OS is loaded, but the El Torito emulation should provide a much clearer path toward OS installations.

Your El Torito emulation works great with DSL linux! So far it loads DSL v.3.4.12 which uses syslinux floppy image emulation. The direct link to the ISO image is here. To boot, I followed your instructions and added to the dosbox.conf file:
imgmount d c:\dosbox\HDD\dsl-3.4.12-syslinux.iso -t iso -fs none
imgmount 0 -el-torito d -t floppy -fs none
boot -l a

Below is the el torito logging to screen and includes logging while DSL linux enters console mode.

The dosbox window shows the DSL boot loader:

On entering linux console mode, there are errors logged to the linux console:

Thanks! 😀

DSL "expert" mode is informative. Typed "expert" at boot prompt and it prompts before each step in boot process:

Edit: tried additional parameters at boot which provided additional logging information: dsl kernel /boot/linux24 root=/dev/hda1 vga=normal nodma noapm noswap nousb noscsi mem=48M frugal

DSL v3.4.12-syslinux boots to console mode by entering this command line at the boot loader prompt: failsafe

The older versions of DSL have no page fault exceptions, but your new core handles the few exceptions generated by the newer versions.

I believe this bypasses the previous problem by creating a ramdisk to load the DSL kernel. The previous problem may be related to the loading of the cloop kernel image and the IDE emulation.

DSL, using failsafe, eventually prompts for an xvesa or xfbdev display, but the xvesa choice is not resulting in a working GUI yet (it shows a black screen); however, I haven't yet patched for >64mb RAM in dosbox nor tried an external video bios. The other choice, xfbdev, is not functional, but by choosing this, eventually the user is dumped to a command prompt. The better solution would be to modify the failsafe boot for init=2 instead of init=5.

It looks like a fairly robust console environment! The DSL image could be modified to include additional files, too. Also, below is a sample of a screen from running dmesg:

And another dmesg screen:

😀

Edit: found a simple way to boot to console mode by entering this line at the boot prompt:
dsl 2 atapicd noapic noacpi noscsi noapm nousb nopcmcia nofirewire noagp nomce nodhcp

DSL linux now boots in GUI mode! Tried different versions, but v0.9.1-syslinux has good defaults and mouse responsiveness. It required the following line at the boot prompt:
dsl xmodule=fbdev fb800x600 atapicd noapic noacpi noscsi noapm noagp nodhcp

I haven't confirmed yet, but perhaps the atapicd module is bypassing the cloop error problem.

In dosbox.conf, advise setting mouse sensitivity to 400.

Setting the framebuffer above was crucial to entering the GUI, although the framebuffer resolution could be changed. Image below.

The audio is not detected yet.

As compared to ReactOS, DSL linux should be ideal since it boots into a GUI with the fbdev driver, provides ample logging, allows swapping of drivers at start-up, is considered robust, and should support more Windows games via wine.

An enterprising individual could, at least in theory, create a custom linux distribution for dosbox-x which is minimal in size, including a linux kernel along with necessary libraries, framebuffer along with other compatible drivers, and wine. It would be interesting on how small a resulting image could be; booted as an El Torito device possibly.

Edit: in addition to xfbdev, xvesa is now working, too! Used boot parameters specified earlier except for a 1024x768 framebuffer and loading a video bios. This suggests that the video bios emulation is not complete for working xvesa. However, xfbdev provides better compatibility in linux under the current emulation.

Have instructions to install DSL linux to a hard drive. 😀 Instructions only for advanced users and at your own risk. For instance, never run syslinux.com except within dosbox!

1. obtain dsl-3.4.12-embedded.zip (although other versions may work, too)
2. obtain syslinux-3.55.zip (didn't test other versions either)
3. open a hard disk image which is compatible with dosbox-x (I've used ImageEdit on 500mb image)
4. copy contents of zip from #1 to the FAT16 formatted hard disk image
5. copy contents of /dos from #2 zip file to hard disk image (for use of syslinux.com)
6. boot dosbox-x into dos 7.0 or similar OS
7. [from inside dosbox] create bootable disk by running the following from /dos directory on the hard disk image (assuming this image is also mounted as c drive):
syslinux -ma c:
8. boot to DSL Linux on HDD, but only RAM is writable for files (see previous post for boot parameters; seems to work with minimal parameters: dsl xmodule=fbdev atapicd)
9. open ATerminal and enter following command:
sudo mount /mnt/hda1 -o rw
Now /mnt/hda1 is read/writable as a drive. I also used the "Switch to JWM" option in the menu via a mouse right click; it switches to a lighter more responsive window manager. Alternatively, one could use an older version of DSL and ensure the mydsl apps are compatible.

Your IDE emulation is working perfectly with this setup! Also, DSL has files at the "mydsl repository" for easy addition of applications and modules. A file, such as "wine.dsl", is copied to the above hard drive and then accessible to the "MyDSL" application in the DSL GUI. I haven't succeeded at this step yet, but games and apps may eventually be available via this easy installation method. It also would allow experimenting with the alsa module for enabling sound.

note: above instructions do not cover routine changes to dosbox.conf and the mount lines.

Edit: successfully loaded a mydsl app! It's called zsnes.dsl and is a package of the zsnes emulator (tried wine but my ram is configured too low). Loaded via the MyDSL app and clicked on "Load Local" button to find the file (navigated to /mnt/hda1). The picture of the screen is below:

Confirmed that zsnes runs games with high load on cpu. And running an Asteroids clone:

And running LX version of Doom in a window with fairly modest cpu usage:

And xlin-city (installed to /ramdisk/usr/games):

truth5678 wrote:

(I've used ImageEdit on 500mb image)

ImageEdit? Is that a Mac OS program? Google's not too helpful.

This is all quite intriguing. There should be drivers that would allow the use of OpenGL in Linux with a 3DFX card, right..?

Any chance of providing git repo as well? It helps me check the changes and port the patches to my git tree...

any chance of supporting IBM/MS OS/2 1.x?

OSFmount will also mount images and has good documentation for casual use.

There are linux drivers that should (or eventually) work with the 3dfx emulation by kekko and gulikoza. However, this isn't necessarily limited to 3d function. There is a linux framebuffer driver for the Voodoo card (1) which theoretically may speed up 2d functions in dosbox-x while running linux. If this works in its current state, or is modified for dosbox-x, then it may be possible to accelerate 2d functions in dosbox. This is all conjecture without testing (see 3dfx-fb driver for details). We could speculate that dosemu inside linux inside dosbox-x could run faster in specific instances than the usual setup of dos games inside vanilla dosbox. The problem is the current state of this framebuffer device is experimental and I am not experienced with framebuffer devices; Codeholio or gulikoza will be able to confirm whether this framebuffer device has the potential to speed-up 2d drawing.

The xfbdev and xvesa servers are both comparable in speed, although xvesa is considered slightly faster via some hardware acceleration. The X server based on the S3 card may afford better 2d acceleration, but the "S3 emulation" is not hardware accelerated; perhaps the S3 emulation could speed-up certain functions in software.

I'd also like to note that I had no stability issues while running linux inside dosbox(-x). The next item of interest is working audio and then experimenting with embedded images to easily load linux. This embedded image could be customized for dosbox; and run akin to a "bios", along with minimizing the user interface for ease of use. Perhaps this solution would appeal to those who do not load 9x in dosbox-x. The "mydsl" packages allow for very simple installation of linux software, as demonstrated above.

(1) https://www.kernel.org/doc/Documentation/fb/sstfb.txt

Edit: fat16 partitions may be mounted via mount command; typically after entering window manager. This allows for file saving. However, I believe that the emulation is not fully able to handle an ext2 partition, which would allow the automatic mounting of writable directories and for saving of changes to the operating system and window manager. The latter may be achieved by the boot parameters "home" and "mydsl".

Sound is now working in DSL linux! Used the following command line:
sudo modprobe sb io=220

The dosbox.conf was configured for the sb1 device, so that it matched the OSS driver for the soundblaster card. Recommend using the built-in OSS sound drivers. Confirmed audio via LXDoom (noted high latency in sound output, but the quality of audio is very good). However, zsnes is not exhibiting the sound latency. 😀

Also, I increased the RAM in dosbox to 256mb and this allowed the mydsl "wine" packages to easily load into memory. However, the available packages are not fully compatible with my recent DSL linux version (perhaps an older DSL version would work).

Even if IDE emulation is not tailored to ext2 partitions, it should be possible to customize the embedded DSL linux distribution for dosbox. This distribution on a hard disk image (~75mb) could be booted and a second hard disk image used for applications and games (size dependent on software loaded by user).

Edit: this version of DSL linux has the sstfb driver (Voodoo1 framebuffer) built-in! I used this command line to load this driver:
sudo insmod sstfb

After loading the driver, the X server does change to the new driver, but is not yet functioning. However, note that this driver is not the same as glide. The 3dfx games, preferably any linux version, would have to be separately tested for compatibility with the current configuration and with specific glide drivers. There are also several ported linux games from the Windows game list (such as Myth II), so these would not require "wine" and allow for further testing of emulation speed (benchmarking with real games).

Edit2: linix is reporting the CPU as near in speed to a Pentium 90. However, the CPU has a higher load because of the innerworkings of emulation, so I suppose it is not comparable to a P90 in real hardware. Perhaps it is between a 486 and a Pentium I. I believe this should support Starcraft and Diablo, given that "wine" eventually is working and that this win32 layer doesn't have a large performance penalty. Note that my system is a slow Core2Duo, so a typical i5/7 is expected to run games at 2x my CPU speed.

Image showing DOSBox 0.63 running in DSL linux (which is running inside dosbox(-x)):

FreeCIV running in DSL linux:

Updated instructions to install DSL linux.

1. First, obtain a hard disk image formatted FAT16; such as this one, a 256mb image with these parameters: size 512,63,16,520.
2. Second, the syslinux version 3.0 did not work, but 3.50 did; so, it is recommended to obtain "ldlinux.sys" and "syslinux.com" from the archive file named "syslinux-3.50.zip". Copy these two files to the top directory of the hard disk image.
3. Also, tested several distributions of embedded DSL linux. From this limited sample, DSL version 3.0.1 works, although I haven't tested the 2.x versions. I am not certain, but I recall that v3.0.1 introduces the unionfs which may be necessary for loading the operating system to RAM. In any case, this version seems faster than the one in the previous instructions, v3.55. I copied the files in the v3.0.1-embedded archive to the top directory of the hard disk image from #1. I deleted some files which corresponded to qemu, but it is not necessary.
4. Boot into dosbox(-x) with a DOS floppy image (I used dos 7.0, but perhaps 6.x will work since there are no files with long names). This requires a dosbox.conf file which specifies booting from a floppy image along with the above hard disk image mounted and containing the files from #2 and #3; also set sensitivity of mouse to 400 and memory to 255mb. Run the following from the dosbox command line:
lock c:
Then, ensure the dosbox(-x) current working directory is c:\ and run this command line:
syslinux.com -ma f
Close dosbox and edit dosbox.conf so it boots from the hard disk image.
5. On start, the DSL boot loader should appear. Enter the following parameters at the boot prompt:
dsl xmodule=fbdev atapicd noscsi nodhcp
6. This method loads DSL linux to RAM. Therefore, the system does not store changes made by the user (in other words, there is no persistence). The home directory is writable, but those change do not persist across reboots either. However, the user will be able to mount this same hard disk image from within DSL linux and store files there. Also, it will be required to setup the X server on each boot, but it is simple: choose the xfbdev driver, ps/2 port for the mouse, and (us) keyboard.
7. On entering the GUI, I suggest changing to the jwm window manager via the right-click menu, although this is not a necessary step.
8. Mount the hard disk image which also contains DSL linux; from the "ATerminal" command line in the DSL window manager:
sudo mount /mnt/hda1 -o rw
Ideally, one could use another FAT16 formatted disk image to store files instead of the same image used to boot DSL linux.
9. That provides a working linux desktop. However, the "mydsl" packages provide very simple installation of applications and system files. One strategy is to copy the packages to the hard disk image and load them via the DSL window manager. The "MyDSL" application has a button labeled "Load Local..." which allows the user to navigate to the directory with mydsl packages, presumably on the hard disk image (such as /mnt/hda1/ or a subdirectory on that mounted drive). Choose the packages to install; unfortunately, this step is repeated on each boot by this method. However, if the packages have a DSL extension and are copied to the top-most directory of the bootable hard disk image, then DSL should load these files during boot.
10. Activate "OSS" sound using ATerminal:
sudo modprobe sb

Note the following commands to detect devices: lsmod, lspci. The S3 and V1 emulation are detected as PCI devices. Also, haven't tested the music emulation, but opl3 may be loaded: sudo modprobe opl3.

Edit: the SYSLINUX.CFG file specifies the parameters used at the boot "loader" prompt. I changed the "default" settings which are active when the user presses enter at that boot prompt. Originally, the setting was:
DEFAULT linux24
APPEND ramdisk_size=100000 init=/etc/init lang=us apm=power-off vga=791 initrd=minirt24.gz nomce noapic qemu quiet BOOT_IMAGE=knoppix frugal

Changed to:
DEFAULT linux24
APPEND ramdisk_size=100000 init=/etc/init lang=us initrd=minirt24.gz nomce noapic BOOT_IMAGE=knoppix atapicd minimal acpi=off noscsi nodhcp nopcmcia nofirewire noagp noacpi noapic noapm nousb vga=785

The setting vga=791 is 1024x768 while 785 is 640x480. I've set 785 for performance and to test the 3dfx framebuffer device (sstfb). I can load the sstfb module and a test showed it loaded successfully, but I haven't yet been able to load the X server with this device. There is a possibility that DSL's Tiny X server is not fully compatible with this device. I also do not have the con2fb tool to test further. Others have indicated that it will not speed up 2d functions since they are not hardware accelerated.