TheGreatCodeholio wrote:

The IDE emulation is also reporting MHDD,EXE is sending command 0xEC while the IDE emulation is still working out command 0xEF.

I tried to optimize the Identify bytes to exclude DMA and other unused features while including NOP (excluded unchanged lines and corrected bytes 21 & 22):

1//host_writew(sector+(21*2),4);		/* ATA-1: ECC bytes on read/write long */
2host_writew(sector+(21*2),512);		/* disk cache in sectors */
3host_writew(sector+(22*2),4);		/* ATA-1: ECC bytes on read/write long */
4host_writew(sector+(50*2),0x4000);	/* Capabilities */
5//host_writew(sector+(52*2),0x00F0);
6host_writew(sector+(64*2),0x0003);	/* PIO modes */
7//host_writew(sector+(68*2),0x0078);	
8host_writew(sector+(82*2),0x4200);	/* Feature sets here and below */
9host_writew(sector+(83*2),0x4000);	
10host_writew(sector+(84*2),0x4000);	
11host_writew(sector+(85*2),0x4200);	
12host_writew(sector+(87*2),0x4000);

After these changes, MHDD no longer runs the CX test and hangs after detection on the EC command. I may have made one too many changes (in other parts). I'll test further. 😀

Edit: I wonder if MHDD is failing on a feature set check.

Jorpho wrote:

What is interesting is that the guide recommends using Intel's PCI drivers instead of the ones that come with Windows.

I tried to install that driver but dosbox isn't compatible (yet) with its signature. However, the MS driver seems to be working ok.

Edit: on further testing, found that a cache size of 512 sectors causes instability and slowdowns. A value of 8 or the current default of 4 is reasonable. However, the ECC bytes can be set at 24 bytes, at least according to an online source; I wonder whether IDE emulation requires ECC, in contrast to a physical drive. Perhaps the original settings were fine as is. 😀

As far as I know, Windows 95 seems to rely on the ISA PnP BIOS to detect the PCI bus during the setup phase. It doesn't bother probing the I/O port. So what needs to happen is, when PCI emulation is enabled, the ISA PnP BIOS emulation needs to list a PCI device for the OS to see. I'll try that this weekend when I have some spare dev time.

I just improved IDE emulation and I added READ VERIFY command emulation. I will post the source tarball shortly.

I just found out that Win98's IDE driver works fine with a drive on the secondary IDE interface. The page fault issues only occur if the boot drive (the one with swap on it) is accessed through the IDE driver, apparently. Also, if you put a hard drive on secondary master, and a CD-ROM drive on secondary slave, Win98 will refuse to talk to either one IF it sees a real-mode CD-ROM driver associated with it. The only way to make it work is to comment out (on my test VMs) OAKCDROM.SYS in CONFIG.SYS.

I also just fixed a mistake in the vm86 fakeio hack that always fired IRQ 14 regardless of drive. Prior to the fix, Win98 would hang when attempting to talk to hard drives on the secondary IDE controller.

Thank you for the updates and updated IDE controller! I wonder if the above issue involving a real-mode driver affects "real" 9x systems, too (it sounds familiar). There are also a few (un)official patches for 98 that I could test with IDE active, if you think it would help. Meanwhile, 95b is running very well and the HDD caching speeds up load times quite a bit. (In addition, I have been experimenting with changes to the PCI register values and perceived improvements to the video emulation).

I'm also noticing that whatever I did to INT 13h and IDE emulation, I resolved the issue with Windows 95 OSR1 and OSR2 hanging on shutdown.

I'm also noticing that Windows 98 doesn't like DOSBox's APM BIOS interface. The device manager shows a yellow icon next to it. But I also found out that the APM BIOS interface is the reason that Windows ME boots up and then immediately bluescreens. If you disable APM BIOS emulation, Windows ME is able to boot fine (well, still with random crashes at times). So in the latest batch of code I will be posting, there will be an apmbios= option in your dosbox.conf that you can use to enable/disable the APM BIOS interface and a comment that you will need to disable it for Windows ME.

Eh... Okay Windows ME appears to talk to the IDE emulation now (if you force-feed it the traditional ISA type driver) but apparently it makes use of the INITIALIZE DRIVE PARAMETERS command to change the logical geometry, which our code ignores, but then Win ME goes on to crash itself badly. Okay then...

Edit: Oh cool, Windows ME's IDE driver actually makes use of the LBA mode! Way to catch up to 1995 Microsoft 😀

Edit: OK. Windows ME's random crashes with IDE emulation are caused by an autoincrement bug in the IDE read code. Masking them off at 8-bit quantities during increment fixed the issue and WinME is able to boot now with IDE drivers.

Edit: Contrary to my previous comments in this thread, Windows ME actually does rely on the same INT 13 in virtual 8086 mode trick that Win95 and Win98 uses to autodetect IDE to BIOS disk mappings.

That's a good test OS for LBA function. 😀 I wonder if using a ~400mb drive would avoid that ATA command and the LBA mode change. (Or the remote possibility of swapping IDE drivers with 98se). Edit: I see you have it working!

UIDE drivers have been updated: http://sourceforge.net/p/freedos/news/2013/11 … ide-etc-nov-14/

does cdrom swapping work now?

SA1988 wrote:

does cdrom swapping work now?

Haven't been working on that.
To be honest, I think a better way to support CD swapping would be to add a QEMU-like "console" that you could switch to and issue CD-change commands.

Regarding Windows ME: I don't know what the hell it's doing yet but if you let the "system configuration" stage of setup do it's thing it is guaranteed to crash Windows ME and hang DOSBox. Unfortunately even if you reset a couple times to boot normally to the desktop, it always wants to run the System Configuration stage anyway. So here's how you bypass that problem:

Boot Windows ME and AS SOON AS POSSIBLE hit F8 to bring up the boot menu. Select "safe mode" and let it boot normally. It will seem to pause for a long period of time, but it will eventually make it to the desktop. Use start -> run and type "regedit". Go to HKEY_LOCAL_MACHINE -> Software -> Microsoft -> Windows -> CurrentVersion -> Run and delete all the registry keys in that area. Then select "RunOnce" and do the same. Doing this removes all that "helpful" auto-start initial setup stuff that is causing ME to crash in DOSBox. Then restart Windows ME. When it reboots, it should do a few setup steps at first, but it should make it to the desktop.

Note that doing this also seems to kill certain parts of Windows ME's driver loading functions. You got ME to boot, but for some reason you will never get it to actually load the Creative Sound Blaster 16 or AWE32 driver. And it will forever pester you that your display adapter is not configured correctly, only to complain when you install one that it conflicts with the adapter already installed---don't bother trying to resolve it you will only kill an entire afternoon going in circles if you try.

The good news is that the NE2000 emulation still works. If you can get Internet Explorer past the wizard (which for some reason is not able to progress when the display is 640x480x16 VGA graphics), you could browse your LAN.

I haven't made a working fix for it yet, but one way to avoid getting stuck in the pagefault handler queue is to prevent windows 98 and ME from loading the Explorer shell by default.

Windows 98: Boot into pure DOS mode, and then type EDIT C:\WINDOWS\SYSTEM.INI.
Locate the line "Shell=Explorer.exe" and change it to "Shell=C:\WINDOWS\COMMAND.COM" (bring up the MS-DOS prompt instead of the shell).

Windows ME: Boot into Safe mode, and use msconfig or notepad to edit SYSTEM.INI and change "Shell=Explorer.exe" to "Shell=C:\WINDOWS\COMMAND.COM"

As long as you don't load anything large, you won't incur page faults that build up in DOSBox and prevent the dynamic core from doing it's work.

Regarding the pagefault stuff, I've tried modifying the code to auto-timeout in various ways and force execution back down the call stack in DOSBox, so far unsuccessful. Some of my attempts only caused DOSBox to crash. Other attempts were only successful in causing random spontaneous BSODs in Windows. If anyone here can provide clues on what to do to the code to allow the PF queue to timeout safely without crashing DOSBox or the guest OS within, let me know.

Edit: Here's what I know about the PF handing in DOSBox. Whoever wrote that code knows that you can just call RunMachine and DOSBox's core will not return to the caller until the CPU returns to the starting point (that's what I could tell when I wrote that hack to put I/O instructions in ROM BIOS and force the CPU to execute them as a FAR CALL). The issue is that kind of logic doesn't work well when Windows is obviously NOT returning to the same address. And the PF handler sort of "builds up" on itself recursively because RunMachine never returns in that case but the PF handler makes another call to RunMachine. If we could get DOSBox to "time out" page fault handling and force itself to unwind that stack and discard PF tracking, we could probably better support Windows 98 and ME.

I've tried:
1. Restoring the old CPU decoder pointer on timeout (crashes dosbox)
2. Setting a timeout flag that triggers PageFaultCore to return the same way as it would have had CS:EIP matched (crashes dosbox)
3. Setting a timeout flag, having PageFaultCore throw a C++ exception that the PF handler catches (with the CPU exception setup and RunMachine call in the try { } block), which then causes the PF handler to immediately return. (Windows crashes)

I'm pretty sure that the reason DOSBox was written this way was that DOS programmers were not "clever" (or stupid?) enough to try that given the limitations that various DPMI servers might have imposed with the page fault exception. Right? 😀

Edit: Argh, never mind. The COMMAND shell trick works in Windows 98 SE and Windows ME but somehow Windows 98 FE manages to trigger the pf queue buildup before the command shell even shows up on screen.

Hi, I think DOSBox page fault handling deserves its exclusive discussion. See Revisiting DOSBox page fault handling in dyn_x86 core.
My solution to this is to enable pf_queue monitoring and keep restarting DOSBox until it reaches Win9x desktop with pf_queue fully flushed.
As a side note, optimized build helps. If you are using MinGW gcc, then make sure you experiment with gcc optimizations.

TheGreatCodeholio wrote:

I haven't made a working fix for it yet, but one way to avoid getting stuck in the pagefault handler queue is to prevent windows 98 and ME from loading the Explorer shell by default.

I posted a patch to do this, but in the normal core: Pagefault handling in the normal core. Please let me know how I can best help - I've been testing with 95, but I could install 98 with your IDE emulation. 😀

Another good solution to avoid pf_queue overrun is to avoid using S3 display drivers. Use VBEMP VESA generic driver. Here's the behavior of S3 drivers on Win95 and Win98SE which I can conclude:

- Win95B/C (OSR2/OSR2.5)
In-box S3 drivers is completely unusable. DOSBox will crash with pf_queue overrun. No fix.
S3 drivers W95 2.11 is useable with h-a-l-9000 paging patch. Completely unusable without the patch. Same crash with pf_queue overrun.

-Win98SE
In-box S3 drivers is useable with h-a-l-9000 paging patch. But pf_queue may not flushed properly after booting to desktop.

Behold, surprising but true, the generic VBEMP w9x driver has *BETTER* performance than S3 drivers. This is not a typo.

I kind of suspecting that the native Win9x drivers maybe the cause to different OS behaviors that trigger page fault in a way not friendly to DOSBox. If this is true, then IDE emulation will make it worse for DOSBox as Win9x will be using native driver for IDE controller instead of the compatibility INT13 layer for disk access. If win9x native drivers does not bring any advantage to DOSBox dyn_x86 core, then I am sorry to say that IDE emulation is really a mood idea.

In pure CPU computation, DOSBox dyn_x86 core is only second to QEMU without KVM acceleration as benchmarked by 7-Zip under Win98. But DOSBox graphic performance is way better than QEMU on Win98. While DOSBox SB16 and related DOS sound system is unmatched by any other emulators, QEMU also has a stable and mature AC97 PCI audio controller implementation which is good enough for Win9x gaming.

TheGreatCodeholio wrote:

"Shell=Explorer.exe"

copy windows95's explorer.exe and rename it to Explorer95.exe
Try use windows 95 ' explorer95.exe , It work on real machine.

Replicated your ME installation procedure:
Removed APM (in safe mode) and set core=auto to proceed with final part of installation; after error in "component progress", followed your hint but removed just three major groups of installations in RunOnce (I recall it was media player and the nearby registry keys). Cancelled future PnP searches so APM was not installed. Then, manually selected the ESDI driver as per the other hint and set its configuration manually (port settings).

It's hanging on the 0x91 command, LBA mode? Haven't experienced a page fault overrun yet.

Edit: WinME boots without the ESDI driver; but with ESDI the OS locks during the boot phase (as you mentioned). The video and audio drivers are problematic, too. 🙁

Edit2: I recall that jDOSBox uses this strategy to overcome the page fault overruns: change the pagefault handler to "normal core" and make many of the normal core instructions re-entrant.

I installed WinME under the "modified" normal core. A couple of glitches along the way, as in the dynamic core, but the OS installed. When I included ESDI, then it the emulation stopped as in the dynamic core.

Attached is a picture of the status window of WinME(+ATA) after the emulation stopped. It shows a few ATA reads and then it stops; however, there is no message about a page fault (the top frame of attached picture). However, when I excluded the IDE driver, then the log shows page faults (the bottom frame in the attached picture). This suggests that page faults are not the cause of the IDE driver not working properly in WinME; it would be consistent with the difficulty in loading the other drivers under WinME.

Looks like Windows 95 OSR 2.1 doesn't recognize CDDA tracks on mounted discs. Bummer ....