Ah thank you, will try that...

Is it possible to install win95 with dosbox-x only?

Here dosbox-x crashes when running setup.

stand the x from dosbox-x for 9x ?

I get crashes with Windows 3.1 (the same installation works under regular Dosbox), never mind Windows 95.

TheGreatCodeholio, do you know anything about win3.1's vdd from switching DOS sessions from fullscreen to windowed mode (for the vram and addresses b0000-bffff)? (in vga only, about *vddvga).

Another question for TheGreatCodeholio: Are you planning on adding the NE2000 Ethernet patch to DOSBox-X? I am wondering this because your last 2-3 releases have that section in dosbox.conf

marzsyndrome wrote:

(BTW, why does DOSBox-X pick Direct3D as the default output when it doesn't even support it? Is D3D support in the pipeline at all?)

Alas, v0.801 appears to be more broken to me than previous builds. For starters, I can't even use OpenGL for output without the emu showing its window for a nano-second and then crashing on me straight away. I'm none the wiser as to why it's doing this when older builds can do OpenGL without keeling over.

I've been hoping for some time that opengl/openglnb/direct3d output gets implemented in Dosbox-x. Without it ... well, it's like a fish tank without water. I can appreciate all the work that's gone into it, but without proper video scaling it's unusable for gaming.

SedrynTyros wrote:

marzsyndrome wrote:

(BTW, why does DOSBox-X pick Direct3D as the default output when it doesn't even support it? Is D3D support in the pipeline at all?)

Alas, v0.801 appears to be more broken to me than previous builds. For starters, I can't even use OpenGL for output without the emu showing its window for a nano-second and then crashing on me straight away. I'm none the wiser as to why it's doing this when older builds can do OpenGL without keeling over.

I've been hoping for some time that opengl/openglnb/direct3d output gets implemented in Dosbox-x. Without it ... well, it's like a fish tank without water. I can appreciate all the work that's gone into it, but without proper video scaling it's unusable for gaming.

Personally, that what I'd like to see too. The work done on Dosbox-x has really helped improved compatibility with some software but, at the moment, any non 4:3 ratio resolutions (320x200, 640x400) look like ass without proper scaling. Unfortunately, custom resolutions on the graphics card don't help, as 640x400 gets scaled as 16:10, where as the original intended display was 4:3 with non-square pixels.

arromdee3 wrote:

bocke wrote:

On a related note, maybe configure could automatically set --disable-dynamic-x86 on x86_64?

Replying to an old post (May 2014), but when I try it now I see that dosbox-x still disables the dynamic core for 64 bit. Is the dynamic core still not working in 64 bit? My system doesn't give me a way to compile as 32 bit.

The dynamic core was written for 32-bit x86 targets. The opcodes change somewhat from 32-bit to 64-bit x86.

marzsyndrome wrote:

Hey, just had a couple of questions to ask regarding DOSBox-X if that's okay. […]
Show full quote

Hey, just had a couple of questions to ask regarding DOSBox-X if that's okay.

1) What's going on with the config saving function at the moment? Two or three releases ago it did the traditional thing of auto-building an extended config in %LocalAppData%\DOSBox with all the possible settings, but now it seems to not build any config, and if you use the menu to manually save settings, the new file will only list those settings that got changed from their default position. Everything else is ignored. I could just bring over the bigger config from the last build to make them, but I have no clue if it's still missing details on any particular features added since then, particularly in v0.801.

2) What's the best tutorial to follow on installing and setting up Windows 95 under v0.801? I know there's http://dosbox95.darktraveler.com/, but its guide seems to focus on using a combination of plain v0.74 and an old Daum build to get around graphical bugs during the setup process, and I'd like to know if DOSBox-X avoids all that, or indeed would expect one to do a lot of things differently to that guide.

Thanks!

You will need to select the normal core and turn on the non-recursive page fault system. Do not use the dynamic core, that code is not maintained and doesn't work properly with Windows 95.

Use Bochs or a utility to create a hard disk image. Then, get an MS-DOS 6.22 bootdisk with working CD-ROM drivers, and an ISO image of Windows 95. If you're installing Windows 98 you'll need a Windows 95 bootdisk (I have a reminder in the issue tracker to document that the Windows 98 installer has a problem when run from MS-DOS 6.22). Turn on the IDE emulation, make sure the v86 hack is enabled, and that DOSBox has the HDD image and ISO image attached to the IDE controller. Boot from drive A: (the MS-DOS 6.22 boot disk). Use the boot disk to format C: and install DOS on it. Remove the disk image from drive A. Then boot from C: and make sure the CD-ROM drive is visible as a drive letter. If it is, then change to the CD-ROM drive letter, and CD into the WIN95 subdirectory that contains SETUP.EXE and run it. It should run SCANDISK and then bring up a minimal graphical install program. If SETUP.EXE says that "Microsoft Windows is required to run this program" then you've found the graphical installer for Windows 3.1 and you need to go one directory level deeper for the right SETUP.EXE. Proceed from there to install Windows 95. The install is about as slow as running it on a 386, so be patient.

SA1988 wrote:

TheGreatCodeholio, do you know anything about win3.1's vdd from switching DOS sessions from fullscreen to windowed mode (for the vram and addresses b0000-bffff)? (in vga only, about *vddvga).

My understanding of the VDD is that it's there to save/restore VGA state. I also recall that in Windows 95, the VDD contains code to make older ISA SVGA cards look like a linear framebuffer by mapping a linear memory region and using page faults to do the necessary bank switching to fake it.

Gui55 wrote:

Another question for TheGreatCodeholio: Are you planning on adding the NE2000 Ethernet patch to DOSBox-X? I am wondering this because your last 2-3 releases have that section in dosbox.conf

The NE2000 code is already there. It was inherited as a side effect of importing code from Daum's branch of DOSBox. It's the same code, except that I have it OFF by default because I don't think DOSBox should be opening up network access by default when you didn't intend it to.

SedrynTyros wrote:

marzsyndrome wrote:

(BTW, why does DOSBox-X pick Direct3D as the default output when it doesn't even support it? Is D3D support in the pipeline at all?)

Alas, v0.801 appears to be more broken to me than previous builds. For starters, I can't even use OpenGL for output without the emu showing its window for a nano-second and then crashing on me straight away. I'm none the wiser as to why it's doing this when older builds can do OpenGL without keeling over.

I've been hoping for some time that opengl/openglnb/direct3d output gets implemented in Dosbox-x. Without it ... well, it's like a fish tank without water. I can appreciate all the work that's gone into it, but without proper video scaling it's unusable for gaming.

As far as I know, the actual choice of output is up to the SDL library, with guidance from DOSBox. The code in my opinion is iffy as it is and a little difficult to decipher or untangle, so far I don't bother. I plan to develop that with the source-destination rectangle stretch-blit system I discussed earlier when I was talking about how to emulate the full VGA raster instead of just the active display area.

Direct3D is actually separate from SDL and should only need proper headers to function... 😀

D-Fend Reloaded can't seem to launch games using DOSBox-X windows-v0.801.next.b1. It ends up showing "Illegal command: DOSBOX.CONF" inside of the DOSBox window. I think D-Fend Reloaded is trying to specify a custom .conf file on the command-line, but apparently DOSBox-X isn't compatible with stock DOSBox's command line parameters?

HunterZ wrote:

D-Fend Reloaded can't seem to launch games using DOSBox-X windows-v0.801.next.b1. It ends up showing "Illegal command: DOSBOX.CONF" inside of the DOSBox window. I think D-Fend Reloaded is trying to specify a custom .conf file on the command-line, but apparently DOSBox-X isn't compatible with stock DOSBox's command line parameters?

Do you have any way to know exactly what it's passing on the command line? The exact string?

HunterZ wrote:

D-Fend Reloaded can't seem to launch games using DOSBox-X windows-v0.801.next.b1. It ends up showing "Illegal command: DOSBOX.CONF" inside of the DOSBox window. I think D-Fend Reloaded is trying to specify a custom .conf file on the command-line, but apparently DOSBox-X isn't compatible with stock DOSBox's command line parameters?

Okay, I see this has something to do with my cleanup of argv[] parsing at startup mixed with some funky argv[] parsing later in AUTOEXEC.BAT generation.

It's trying to execute "dosbox.conf" as if it's a program!

D-Fend is running DOSBox in a way that is not out of the ordinary at all:

1"C:\src\dosbox-x\bin\x64\Release\dosbox-x.exe" -CONF "C:\Users\jon\AppData\Local\Temp\DOSBOX.CONF" -NOCONSOLE

I wanted to try out this version of DosBox, just out of curiosity and t osee if one of the games I can't get to work with the vanilla DosBox( Savage Warriors) would maybe work with this one. But i can't get any cue file mounted with imgmount. ISO files work, though. I try to munt them like this:

imgmount D ..\game\cd\NAMEOFTHECUEFILE.cue -t cdrom -fs iso

I always get the error "MSCDEX: Failure: Invalid file or unable to open." I tried both the x86 and the x64 version, without any success. The same CUE files work flawlessly with vanilla DosBox.

Open the cue file and make sure that it references the correct bin file. Best make sure no path is set for the bin file but that the cue and bin file are in the same folder.

Dominus wrote:

Open the cue file and make sure that it references the correct bin file. Best make sure no path is set for the bin file but that the cue and bin file are in the same folder.

Did that, the CUE file has no path set whatsoever and both files lie in the same directory:

1FILE "WARRIORS.BIN" BINARY
2  TRACK 01 MODE1/2352
3    INDEX 01 00:00:00
4    (...references to OGG files for music)

As I said, it works perfectly fine in vanilla DosBox.

yes, I just wanted to get the common mistake out of the way 😀
(I presume the ogg files are fine, too with the paths?)

Now that I see you are using a mixed bin and ogg files cue, the problem could be with the ogg files. For that to work Dosbox-x needs to be compiled with SDL-Sound (and that with ogg/vorbis support). It could very well be the source of the problem and not something directly related to Dosbox-x.

Yeah, the OGGs are fine, too. No paths and lying directly in the same directory as the CUE and the BIN file.

Oh, I thought OGG support is implemented in any DosBox version, that's why I chose OGG as format for the music files for all my games in the first place.

UPDATE: But you were right, when I remove the track info for the OGG files from the CUE, it mounts. So, I'll rip a full BIN/CUE again (with cd audio) and try again.

UPDATE 2: It works! 😁 Finally!