Pagefault will not always return to the original fault address. See this thread for some discussion.
But it seems to happen more with IDE active...

gulikoza wrote:

First real success! 😀

I have win95 osr2 running with ide and cd-rom. But I have to increase pagefault queue for it to work. It's up to 32 before desktop shows and up to 80 if I open something like Device Manager. So it'll crash sooner or later...
I don't know how you don't hit this limit, but this may be the cause of slowdowns. Pagefaults IIRC switch to Full core and if they're just queued up, dosbox basically runs in Full core all the time...

It might have something to do with using the VBEMP SVGA driver instead of the S3 driver.

gulikoza wrote:

Pagefault will not always return to the original fault address. See this thread for some discussion.
But it seems to happen more with IDE active...

OK. I still havent fully resolved the issue with pf_queue.used, but changing the JumpCond32_d(COND) macros in the normal core as directed (move SAVEIP to the top, have Fetchb/w/d fetch to a temporary variable first and then apply to reg_ip if COND is true) seems to have resolved a lot of random crashes in Windows 98 now. I can reliably run a lot of things in Windows 98 now (although in super slow motion 😀 ).

Another note I have is that sometimes, I can get Windows 98 to boot all the way to the desktop with IDE drivers enabled without causing the massive slowdown. I'm not certain but it seems to have something to do with the cycles count. If I boot with cycles=150000 and then rapidly crank it down to 45000 right when the desktop first appears (but before Windows starts loading the login or explorer shell), I can sometimes avoid the slowdown.

I think I also see a pattern with any remaining crashes that can happen: According to the "this program has performed an illegal operation" dialog, one consistent crash happens in KERNEL32.DLL and CS:IP points at 0x89 0x41 0x08 0x8B. Another one I've seen occasionally lists the crash in another DLL (I forget which) with CS:IP directed at a string instruction that starts with 0xF3 (REP). If that forum link is right, I just have to modify the normal core's emulation of those instructions so that they're atomic, and Win98 should have fewer issues, right?

TheGreatCodeholio wrote:

Edit: Hey, I get it. On page fault, you queue up the faults and assign PageFaultCore to the CPU decoder. PageFaultCore remains the cpu core "decoder" until all page faults are "resolved". It decides if they are resolved if and only if the CPU is returned to the original fault address stored in the entry (src/cpu/paging.cpp line 122). Perhaps Win98 is not returning to the same memory address? I need to examine that. I'm also willing to bet that we could resolve this issue by adding a "timeout" to page fault events. Meaning that, if a page fault happens and the OS fails to return to the same address within a certain amount of time, that the core assumes the OS is handling it some other way and gives up on it. It might resolve these issues with Windows 98.

I recall that you are right about that. It's been a while since I did something related to windows though, but this is what I recall:
Windows doesn't return to the fault address. Think the dynamic core handles it slightly different from the other cores though, which is why either normal or dynamic works better (If I recall correctly)

Think Danoon changed the core handling a bit, by making a pagefault cause a jump out of the code.

One note, that I haven't figured before...I thought that if I don't connect the disk to IDE and put CD-ROM on it, it will work. That's why I had problems and couldn't get CD to work. Win9x will flag the first IDE controller if the disk isn't responding on it (I thought that if only CD-ROM is connected, it'll assume the disk is on some scsi controller it can't see and proceed with loading esdi). So, having disk on IDE is not really necessary at this point, but you need to remember to always put the CD-ROM on the secondary regardless if the disk is on primary or not. Then the first ide will be marked, but secondary with CD-ROM on it will work...

I was a bit confused with the "You will lose CD-ROM functionality as well if you attached the virtual CD-ROM drive to the same controller." line in the original patch as I have not been attaching CD-ROM to the same controller (I haven't attached the disk to any controller) and still didn't see it. I thought it only worked with MSCDEX loading before Windows starts. Just so that nobody repeats the same mistake 😀

1host_writew(sector+(48*2),0x0001);	/* FIXME: ??? */

This is 32-bit PIO mode according to bochs bios:

1mode      = read_byte_SS(buffer+96) ? ATA_MODE_PIO32 : ATA_MODE_PIO16;

which is not supported if I read this comment right:

1/* <- TODO: what about 32-bit PIO modes? */

if this is left at 1, bochs fails to read boot sector (only reads 256 bytes instead of 512).

gulikoza wrote:

This is 32-bit PIO mode according to bochs bios: […]
Show full quote

Copy code to clipboard

1host_writew(sector+(48*2),0x0001);	/* FIXME: ??? */

This is 32-bit PIO mode according to bochs bios:

Copy code to clipboard

1mode      = read_byte_SS(buffer+96) ? ATA_MODE_PIO32 : ATA_MODE_PIO16;

which is not supported if I read this comment right:

Copy code to clipboard

1/* <- TODO: what about 32-bit PIO modes? */

if this is left at 1, bochs fails to read boot sector (only reads 256 bytes instead of 512).

Ack! Thanks for letting me know! I will clear that bit.

*posted accidentally*

Another issue with Bochs int13 handler. It won't wait for IDE to clear BUSY on write before returning error.
In ata_cmd_data_io():

1    current++;
2    write_word_DS(&EbdaData->ata.trsfsectors,current);
3    count--;
4    if(ioflag == 0) await_ide(NOT_BSY, iobase1, IDE_TIMEOUT);
5    status = inb(iobase1 + ATA_CB_STAT);

ioflag == 0 - read, 1 - write. It waits for NOT_BSY only when reading before checking status. When busy is returned, the int13 will return error 6 fail write and issue a reset before IDE_DelayedCommand is executed.

1      if (count == 0) {
2        if ( (status & (ATA_CB_STAT_BSY | ATA_CB_STAT_RDY | ATA_CB_STAT_DF | ATA_CB_STAT_DRQ | ATA_CB_STAT_ERR) )
3            != ATA_CB_STAT_RDY ) {
4          BX_DEBUG_ATA("ata_cmd_data_io : no sectors left (status %02x)\n", (unsigned) status);
5          return 6;
6        }
7        break;

1BIOS info:int13_harddisk: function 03, error 06 !

Would conventional DOS based utilities help diagnose the emulated ATA functions?
http://martin.hinner.info/idediag ; http://hddguru.com/software/2005.10.02-MHDD

gulikoza wrote:

Another issue with Bochs int13 handler. It won't wait for IDE to clear BUSY on write before returning error. In ata_cmd_data_io( […]
Show full quote

Another issue with Bochs int13 handler. It won't wait for IDE to clear BUSY on write before returning error.
In ata_cmd_data_io():

Copy code to clipboard

1    current++;
2    write_word_DS(&EbdaData->ata.trsfsectors,current);
3    count--;
4    if(ioflag == 0) await_ide(NOT_BSY, iobase1, IDE_TIMEOUT);
5    status = inb(iobase1 + ATA_CB_STAT);

ioflag == 0 - read, 1 - write. It waits for NOT_BSY only when reading before checking status. When busy is returned, the int13 will return error 6 fail write and issue a reset before IDE_DelayedCommand is executed.

Copy code to clipboard

1      if (count == 0) {
2        if ( (status & (ATA_CB_STAT_BSY | ATA_CB_STAT_RDY | ATA_CB_STAT_DF | ATA_CB_STAT_DRQ | ATA_CB_STAT_ERR) )
3            != ATA_CB_STAT_RDY ) {
4          BX_DEBUG_ATA("ata_cmd_data_io : no sectors left (status %02x)\n", (unsigned) status);
5          return 6;
6        }
7        break;

Copy code to clipboard

1BIOS info:int13_harddisk: function 03, error 06 !

OK. What you're supposed to do on an IDE write cycle, is setup the registers and then send a write command. The drive will not yet move the heads or start writing to the disk at this point or even fire an IRQ. Instead, it waits for you to first send 256 words (512 bytes). Only when 256 words have been sent, THEN the disk will begin the process of writing. During that time, the disk is busy. I'm not sure why the Bochs BIOS developers think that hard disk writes are instantaneous unless they live by their own IDE emulation that practically does the entire cycle within the 0x1F7 I/O port handler complete with IRQ. There's a reason I've heard that there's a snarky comment in the Linux kernel about Bochs firing the IRQ before the IDE driver has even moved on to the next I/O instruction reading back the status.

In other words, this is another area where the Bochs BIOS is wrong.

truth5678 wrote:

Would conventional DOS based utilities help diagnose the emulated ATA functions?
http://martin.hinner.info/idediag ; http://hddguru.com/software/2005.10.02-MHDD

Sounds like a useful tool. I'll start using it to check IDE emulation.

Another update: I test-ran Windows 98, Windows 98 SE, and Windows ME in DOSBox-X.

Windows 98 SE has the same general crashiness as Windows 98 but like Win98 is still able to use IDE emulation.
As for Windows ME... well.. the install will work right up until it begins "configuring components" (apparently this is where it autodetects hardware?) and at some point through the progress will BSOD and cause other issues.

To clarify about Windows ME, I'm not TOO concerned about Windows ME in DOSBox, I just did it to see what would happen. If it doesn't work, that's fine by me.

Windows ME conflicts with DOSBox:
- Random crashes (probably related to Win98 random crashes) -- no fix.
- Auto-configuration at startup, if it doesn't BSOD, will at one point kill your mouse
work-around: set aux=true in your dosbox.conf. Win ME appears to take control of the keyboard controller and disable the mechanism to receive INT 15h PS/2 mouse movement calls.
- Does not work with IDE emulation -- no fix yet
- BSODs on startup after first install phase
work-around: turn off the int13fakeio and int13fakev86io options. The virtual 8086 hack that makes it work with Win95 and Win98 causes problems with Windows ME and should not be used.
- S3 emulation is incompatible with Windows ME -- no fix yet. Windows ME apparently dropped the S3 driver that worked just fine in Windows 98 with DOSBox.

What did work:
- NE2000 emulation
- keyboard and mouse (aux=true)

If you can manage to bypass the auto-setup, and get a minimal configuration going, it's possible to boot to the Windows ME desktop in 640x480x16 VGA mode. As usual, expect the page fault handler to get hung up again and everything to crawl, and things to occasionally crash at random, but it otherwise works.

Thank you for the continued efforts on IDE emulation!

I copied your IDE specific code into a dosbox-svn base+paging patch; hopefully not missing any important bits. Built dosbox binary by mingw/win32 and installed 95a to a HDD image (512mb; 512,63,32,520); had to use simple core to install 95a via that same HDD. Created a minimal installation, even without cdrom support, and afterwards used dynamic core/pentium cpu. I haven't received any "PF queue overrun" errors yet and played DOS Quake inside Windows via its own DOS box. Also, left the defaults on such as the S3 video driver at 16 color depth, but didn't install the SB16 driver yet. I am not finding any slowdowns yet that are symptomatic of a "dropdown" to the full core.

I'll continue to experiment with your code. I did note a scandisk error, but this could have been fixed in the above exchanges and after the latest source code posting. 😀

Edit: installed this working S3 driver (Trio32/64 PCI) with high color support: download/file.php?id=9456 ; thanks to dosfreak for that link. Also, installed the cdrom device on IDE and a set of multimedia drivers. Seems stable without page fault queue problem or slowdowns. Edit2: successfully installed directx5.0.

Mouse button presses (and movement?) are the only cause of page faults so far, although the page fault queue is not increasing. Using 95a. I wonder if (nearly all) stability issues can be traced to using a proper video driver and this unknown mouse problem.

Without the IDE emulation, then page faults occur with any disk access in 95a but not with mouse button presses. Perhaps page faults are not unusual while in disk/paging 16-bit compatibility mode?

Edit: I disabled APM in the 95a device manager and the system seems more responsive and the emulation faster, at least in the 95 shell.

Edit2: I haven't confirmed this yet: but removing and redetection of the IDE device will fail. Removing the PCI bus, redetecting IDE, and then adding the PCI bus appears to work.

Edit3: The Voodoo1, PCI bus, and IDE devices are all detected in 95a, but there is some difficulty in enabling all of them. Possibly they must be enabled in a specific order, particularly in reference to the IDE device? GLQuake is working!

Some hints for installing OSR2:
(mingw built dosbox+IDE: dynamic core/pentium cpu)
1. mount dos diskette (a), 512mb hdd image (2; -fs none), and the Windows cdrom (d; -fs none)
2. (boot to dos) boot -l a
3. (format hdd image) format c: ; sys c: ; then exit dosbox
4. change dosbox.conf: hdd image to (c; -fs fat); restart dosbox
5. d: ; make a new directory named win95 on c: ; copy win95 c:\win95
6. boot -l c ; install 95(a or b)
7. edit dosbox.conf to disable floppy drive; restart dosbox
8. given an error occurs; enter safe mode, remove S3 driver, restart dosbox and install will continue

The above procedure worked (took a couple of tries) for OSR2 (95b); installed Microsoft Mail and ran IE. The page fault queue isn't increasing and not detecting slowdowns. Added PCI bus manually; video driver then detected automatically.

The only application that isn't working so far is compuserve. 😀

Edit: working on procedure to install IDE device in an existing 95b installation without IDE -
1. Remove PCI bus; reboot to safe mode and remove S3 driver
2. Reboot into non-safe mode 95b, manually install PCI bus; remove IDE device; auto-detect devices
(work in progress....)

Edit2: is it possible that using large disk mode (LBA?) is causing a problem in detecting IDE in existing 9x installs? Could this be related to others' page fault queue overruns?

truth5678 wrote:

Edit2: is it possible that using large disk mode (LBA?) is causing a problem in detecting IDE in existing 9x installs? Could this be related to others' page fault queue overruns?

As far as I can tell Windows 95 doesn't appear to make use of LBA mode, at least with the stock driver. Reads and writes are always C/H/S style. Win95 OSR2 does make use of the INT 13h extensions from the DOS kernel if the FAT32 partition is type LBA (type code 0x0C) or FAT16 is type LBA (code 0x0E), but it seems to revert to C/H/S style once the IDE driver loads.

For that reason perhaps, I noticed Windows 98 won't use it's stock IDE driver if the disk is too large for C/H/S geometry.

I also want to point out that in my testing, I have PCI disabled and I use the Win9x VBEMP SVGA driver instead, which uses the VESA BIOS to provide Windows with a basic linear framebuffer (thus no page faults).

Thank you for the interesting reply. 😀 I'll verify the FAT32 partition and code on the existing OSR2 installs (or at least compare the existing install image to a new installation with IDE active).

TheGreatCodeholio wrote:

I also want to point out that in my testing, I have PCI disabled and I use the Win9x VBEMP SVGA driver instead, which uses the VESA BIOS to provide Windows with a basic linear framebuffer (thus no page faults).

I guess that means that the page faults are related to the memory mapped by PCI?

(I tried to boot a past version of ReactOS and attached the screen, too).

I see in the screenshot that ReactOS is trying to use READ MULTIPLE (command 0xC4) which is not implemented, even though my ATA emulation says it is. Sorry about that.

To explain READ (command 0x20) vs READ MULTIPLE (0xC4). The original READ command always transfers one sector at a time even when multiple sectors are requested. That means that if I ask for 4 sectors using command 0x20, I wait for an IRQ and the drive to raise DRQ, then read 512 bytes, then wait for another IRQ and DRQ, read 512 bytes, etc... over and over again until all 4 sectors are transferred. That's not very efficient. READ MULTIPLE allows the OS to read more than one sector per IRQ and DRQ cycle. Obviously, there's another command for WRITE MULTIPLE as well.

Using this guide on reading a partition table, and a hex editor, I identified the differences between the working-with-IDE FAT16 image and the FAT32 image from a prior installation without IDE.

1FAT16 (starting at 1C0)
200 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 
301 00 06 1F BF 07 3F 00 00 00 C1 FE 0F 00 00 00
4FAT32 (starting at 1C0)
501 00 06 3F FF FE 3F 00 00 00 01 F0 3E 00 00 00 
600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The prior installation (without IDE) is missing the HDD parameters. I'll test further by inserting the parameters into the existing image with the hope that 95/IDE detects it.