SA1988 wrote:

what are the best settings to run Win98 and Win98SE with 32bit disk access?

a lot of RAM helps. the problem is that Win98's page fault handling does not return to the same address which doesn't fit well with DOSBox's assumptions. 32-bit disk access apparently makes that worse. You can play around with things to delay when that page fault hits but the page fault will hit that causes DOSBox to slow. Turning off the sound card seems to help delay that.

TheGreatCodeholio wrote:

SA1988 wrote:

what are the best settings to run Win98 and Win98SE with 32bit disk access?

a lot of RAM helps. the problem is that Win98's page fault handling does not return to the same address which doesn't fit well with DOSBox's assumptions. 32-bit disk access apparently makes that worse. You can play around with things to delay when that page fault hits but the page fault will hit that causes DOSBox to slow. Turning off the sound card seems to help delay that.

in your src, I changed the PF_QUEUE from 80 to 64000, it helped a bit.

Last time i tried to run win98 i got in debug window many unsupported cpu functions.
Is there way to make some sort of FIXME and name them at least ?
Maybe in that way we can sort out some functions that can need be implemented and other that popout less frequently.

just litle suggestion:)

is it also possible to switch disks (both floppies and cdroms) anytime without having to close dosbox and restarting it, I mean, putting floppies and cdroms anytime we want without being mentioned in dosbox.conf (the GUI menu may also be ready for this)

SA1988 wrote:

is it also possible to switch disks (both floppies and cdroms) anytime without having to close dosbox and restarting it, I mean, putting floppies and cdroms anytime we want without being mentioned in dosbox.conf (the GUI menu may also be ready for this)

Not yet. I am considering adding a QEMU-style "console" and perhaps something to the GUI menu to allow this. I would like to be able to switch in arbitrary CDs as well without having to shutdown and restart.

On a related note, I would also like to see if the hotkey to swap CDs could be separated from the hotkey to swap floppies (you could do them with different hotkeys).

nvm, in my binary, switching isos and floppies is possible with the built-in GUI, I edited dos_tables.cpp, ide.cpp and menu.cpp to allow the swaps of said storage while the emulation is active with IDE active.

Update regarding the CD-ROM media change code: I found that Windows 95's auto-insertion detection is far more reliable if the "insert CD" delay is set to 3-4 seconds or more. The 1-second delay in the last release is too fast and can fall between Windows 95's polling interval and get missed. The delay constant is in src/hardware/ide.cpp.

masaykh wrote:

Last time i tried to run win98 i got in debug window many unsupported cpu functions. Is there way to make some sort of FIXME an […]
Show full quote

Last time i tried to run win98 i got in debug window many unsupported cpu functions.
Is there way to make some sort of FIXME and name them at least ?
Maybe in that way we can sort out some functions that can need be implemented and other that popout less frequently.

just litle suggestion:)

I think you'll find unfortunately that Windows itself is apparently reliant on the Invalid opcode exception. Which is why I added a boolean that if set (by default), the CPU core does not announce certain known invalid opcode sequences. Without this hack, running Windows 3.1 will easily spam your debugger with "Warning: invalid opcode exception".

Windows 98 I've noticed seems to use a different invalid opcode which I'll take a look at.

TheGreatCodeholio wrote:

detection is far more reliable if the "insert CD" delay is set to 3-4 seconds

Thank you, that adjustment works perfectly.

Heads up: I do not have an update posted yet but I just finished adding proper CTRL+C and CTRL+BREAK handling for DOS programs in DOSBox-X. I know few DOS games use it but it makes it easier to deal with DOS development tools like compilers and linkers because it is now possible to terminate the compile with CTRL+C just like on a real DOS machine.

I also tested running Microsoft CodeView in DOSBox-X and the update allows CTRL+C and CTRL+BREAK to break into the debugger when running the program. Just like on real DOS systems.

On a related note, I wonder what the hell Microsoft programmers were thinking when they wrote the CTRL+C and CTRL+BREAK handling in their SCANDISK.EXE utility in MS-DOS 6.22? Ever see a DOS program attempt to handle ESC, CTRL+C, CTRL+BREAK by itself by both hooking INT 1Bh and intercepting INT 16h ahead of DOS while simultaneously using INT 21h standard I/O functions? Yechhh. Why hook INT 16h? To catch and dispose of those particular scan codes, of course, so that DOS does not trigger INT 23h! The fix at least allows SCANDISK.EXE to respond to the keyboard correctly when run from DOSBox's native command interpreter. SCANDISK.EXE of course can't scan DOSBox's virtual drives properly, but it works properly otherwise.

Did memory handling break somewhere down the line?
I've tried to install Windows 98SE using Daums, DosBox-X and jDosBox, but no matter what I set the memsize to (I've tried 24, 31, 32, 61, 64) the Windows installer still reports that I need more than 16MB memory to install W98.
I got past the memory check using an older version, but instead they gave mysterious errors.

silvercat wrote:

Did memory handling break somewhere down the line?
I've tried to install Windows 98SE using Daums, DosBox-X and jDosBox, but no matter what I set the memsize to (I've tried 24, 31, 32, 61, 64) the Windows installer still reports that I need more than 16MB memory to install W98.
I got past the memory check using an older version, but instead they gave mysterious errors.

Are you sure you're modifying the right settings? Make sure you're changing memsize= and not memsizekb=

I'm installing Win95 again in a DOSBox-X VM with no problems now.

Yes, I even get the warning that memory over 31mb is not recommended in stdout (this doesn't appear if I set memsize to 31 or less), so I'm pretty sure it's the right setting.
However I'll try installing Win95 now to see if it works, I don't really need 98 anyway.

EDIT:
Works better, but I get stuck on "Installing Control Panel" after first reboot, where I get a BSOD.
I've set cpu type to pentium_mmx, anything else I've missed?

EDIT2:
Enabling only Standard VGA and disabling all sound during install fixed it.

O GreatCodeholio - this is really an impressive project. Thank you for all the work you've done on it.

Is there any chance you might be willing to sketch out a guide to building DOSBox-X? I haven't been able to build it with Visual Studio Express (2008 and 2010 versions), which is all I've got on my laptop while I'm away from home. Is it likely that the problem is simply that I'm using the Express version, and I should simply wait until I get back to a machine with a full VS2008 and build it there? (Thanks to patient help from tearex, ripsaw8080, Dominus, and others, I can build DOSBox SVN easily on this laptop.)

Thanks again - and thanks to you or anyone who can give any tips on building DOSBox-X.

I agree Codeholio, nice work on CD-ROM swapping! But also, did you get my PM reply that answered your question on how I was able to get Windows ME's display adapter working? I haven't heard back yet if you were able to get it working as well, so I want to make sure you got it. Thanks!

emendelson wrote:

O GreatCodeholio - this is really an impressive project. Thank you for all the work you've done on it.

Is there any chance you might be willing to sketch out a guide to building DOSBox-X? I haven't been able to build it with Visual Studio Express (2008 and 2010 versions), which is all I've got on my laptop while I'm away from home. Is it likely that the problem is simply that I'm using the Express version, and I should simply wait until I get back to a machine with a full VS2008 and build it there? (Thanks to patient help from tearex, ripsaw8080, Dominus, and others, I can build DOSBox SVN easily on this laptop.)

Thanks again - and thanks to you or anyone who can give any tips on building DOSBox-X.

I use Visual Studio 2008 to compile the Win32 version. I don't know what the express versions are limited to, so I can't say whether the express version can compile it. The SDL library contained in the source code requires the DirectX SDK which needs to be installed separately. Make sure you install VS2008 first then install the DirectX SDK, the SDK adds some include header and library paths to Visual Studio to make it work.

Gui55 wrote:

I agree Codeholio, nice work on CD-ROM swapping! But also, did you get my PM reply that answered your question on how I was able to get Windows ME's display adapter working? I haven't heard back yet if you were able to get it working as well, so I want to make sure you got it. Thanks!

I haven't yet tried. Windows ME is not a priority because it's the first of the 9x series that runs perfectly fine in VirtualBox and QEMU. I tend to focus on Windows 3.1, 95, and 98 because those are useful versions of the Windows 9x series that are not stable in many other emulators, in fact Windows 95/98 are the only versions of Windows that require me to TURN OFF the VT-x acceleration in VirtualBox just to get them to run (and QEMU's VT-x support outright hangs solid attempting to boot Win95!). The other reason is that Windows ME is the first of the series explicitly designed to lock out native DOS mode (yeah I know there are well known hacks you can apply to IO.SYS and COMMAND.COM to fix that, but still..). I also don't recall much in the way of software that explicitly required ME when they ran just fine with 98 or 98se.

At some point, yeah, I'd like DOSBox-X to run Windows ME and emulate the hardware of it's time period, but that's not yet something I'm willing to work on. I only boot-tested Windows ME just to see if it was possible and whether the IDE v8086 hack still applied, but that's as far as I'm willing to go right now with WinME.

Being able to emulate Win9X properly would be great ! 😮 😀
Of course, writing such an emulator is a very difficult task. But the challenge is interesting.

Hi and thanx for the great job on this project. 😀

I have a small question about Linux build. I was unsuccessfully trying to build dosbox-x a few months ago (20140125-201539, rev: 13aa2844a0355b699a44abf30c56faf5c9383e1c), so I was wondering if you still regulary test if it builds under linux? If you do, do you test 64-bit builds? I'm using gcc 4.8.2 on 64-bit box and it spews a bunch of errors on typecasting. I managed to fix some of them, but eventually gave up as I couldn't get it to build. I haven't tried the 32-bit build. The snapshots from 2013 I tried previously worked just fine.

Anyway, I'll get around to try a newer snapshot these days. Just wanted to make a (late) report on previous unsuccessful builds.

bocke wrote:

Hi and thanx for the great job on this project. 😀

I have a small question about Linux build. I was unsuccessfully trying to build dosbox-x a few months ago (20140125-201539, rev: 13aa2844a0355b699a44abf30c56faf5c9383e1c), so I was wondering if you still regulary test if it builds under linux? If you do, do you test 64-bit builds? I'm using gcc 4.8.2 on 64-bit box and it spews a bunch of errors on typecasting. I managed to fix some of them, but eventually gave up as I couldn't get it to build. I haven't tried the 32-bit build. The snapshots from 2013 I tried previously worked just fine.

Anyway, I'll get around to try a newer snapshot these days. Just wanted to make a (late) report on previous unsuccessful builds.

I'm glad you bring that up. I do have a 64-bit development system but my development happens primarily in 32-bit mode so far. I will boot into 64-bit to see if I get the same compiler errors.