I have an interesting update about Windows 98: I don't have time to dig into the source code tonight, but I did another Win98 setup tonight and I noticed most of the crashiness and most of the random slowdown goes away if you set core=dynamic and cputype=pentium. The remainder of the crashes go away if I disable IDE emulation. I'm able to use S3 SVGA emulation now with Windows 98 without any crashes.

Oooh boy... I took a look at the IDE emulation quickly and I realized the remainder of random crashes in Win98 (and in fact occasionally in Win95) were due to a bug in the way the code auto-increments the C/H/S sector numbers. All it takes is for Win9x to issue an IDE read for something like 0x40 or even 0xFF sectors, and the wrong data is read back to the OS. Shit. I hope none of you guys used the last release on any Win9x setup where data integrity was important.

Naah, data is not important yet at this moment, just making it work 😉

For me W98 works pretty stable, in fact it's stable enough to run Half Life and Unreal - without IDE. I'm still struggling to get IDE working (I ported your patch to my tree, so I might have missed something).

Can you change that host_reset() sets the device BUSY and return ready when SRST is cleared? Also, the device should be returned to default state, bochs bios will check if CHS is reset afterwards...

Also I have a problem with per-device registers. If cylinder and sector are programmed first and then drivehead (which would also trigger a device select), won't the wrong sector be read?

Why is DOSBox assigning our IDE primary help strings and defaults to ALL IDE sections?!?

DOSBox does not really have sections that are truly separate. You shouldn't use properties with same names...
You should create an [ide] section and have ide1enable, ide2enable and so on...is it needed to have int13fakeio and int13fakev86io for every ide interface or would it suffice to have a single setting under [ide] section?

Windows 98 update: The IDE driver seems to trigger problems with stability, or at least do something that drags DOSBox's dynamic core down to poor performance. Turning off IDE seems to resolve the issue. The funny thing is Windows 95 runs fine with IDE emulation enabled, but the dynamic core drops to poor performance the instant I start the "Microsoft Exchange for Windows 95" program from the start menu.

Latest source code (forgot to post last night) with fixed IDE C/H/S address increment fix: http://www.hackipedia.org/Projects/DOSBox-X/d … 3764-src.tar.xz

I wonder if the slowdown goes away with use of the normal core. Also, danoon may have encountered these same issues in the past.

gulikoza wrote:

Why is DOSBox assigning our IDE primary help strings and defaults to ALL IDE sections?!?

DOSBox does not really have sections that are truly separate. You shouldn't use properties with same names...
You should create an [ide] section and have ide1enable, ide2enable and so on...is it needed to have int13fakeio and int13fakev86io for every ide interface or would it suffice to have a single setting under [ide] section?

From src/misc/setup.cpp

1void Property::Set_help(string const& in) {
2        string result = string("CONFIG_") + propname;
3        upcase(result);
4        MSG_Add(result.c_str(),in.c_str());
5}
6
7char const* Property::Get_help() {
8        string result = string("CONFIG_") + propname;
9        upcase(result);
10        return MSG_Get(result.c_str());
11}

I see...

However I would prefer that the individual IDE controllers could be configured separately if necessary. I would also rather have the options named the same way in each section. I think a better way to fix this would be to modify the Property C++ class so that it can accept a help string associated with that instance of the property rather than through MSG_Get(), but modify it in a way the rest of the unmodified properties use MSG_Get() as usual.

The IDE section has some pretty verbose explanatory text that I'd rather not repeat 4 times in dosbox.conf, which is why I'd rather that text only appear in the "ide, primary" section. I plan on adding a few more options in the future as well, including what ATA standard to emulate and what PIO modes to enabled, etc.

gulikoza wrote:

Also I have a problem with per-device registers. If cylinder and sector are programmed first and then drivehead (which would also trigger a device select), won't the wrong sector be read?

You're supposed to write the drivehead register first to select the drive and set the head at the same time. Most IDE drivers for that reason read 0x1F7, then write 0x1F6, then write 0x1F2 through 0x1F5.

Bochs int13 handler does not do that:

1  outb(iobase1 + ATA_CB_FR, 0x00);
2  outb(iobase1 + ATA_CB_SC, count);
3  outb(iobase1 + ATA_CB_SN, sector);
4  outb(iobase1 + ATA_CB_CL, cylinder & 0x00ff);
5  outb(iobase1 + ATA_CB_CH, cylinder >> 8);
6  outb(iobase1 + ATA_CB_DH, (slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0) | (Bit8u) head );
7  outb(iobase1 + ATA_CB_CMD, command);

Loading bochs bios in dosbox might prove valuable to finding dosbox bios bugs, so it would be advantageous if IDE emulation would work with it.

gulikoza wrote:

Bochs int13 handler does not do that: […]
Show full quote

Bochs int13 handler does not do that:

Copy code to clipboard

1  outb(iobase1 + ATA_CB_FR, 0x00);
2  outb(iobase1 + ATA_CB_SC, count);
3  outb(iobase1 + ATA_CB_SN, sector);
4  outb(iobase1 + ATA_CB_CL, cylinder & 0x00ff);
5  outb(iobase1 + ATA_CB_CH, cylinder >> 8);
6  outb(iobase1 + ATA_CB_DH, (slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0) | (Bit8u) head );
7  outb(iobase1 + ATA_CB_CMD, command);

Loading bochs bios in dosbox might prove valuable to finding dosbox bios bugs, so it would be advantageous if IDE emulation would work with it.

To be honest, I think the Bochs BIOS is doing it wrong. Think about it: How would the IDE controller know, until the ATA_CB_DH write, that the next read/write to count/sector/cylinder/etc is intended for the other drive? Such as, if the IDE master was selected, and the read/write operation is meant this time for the IDE slave. You have to select the IDE slave first before you start writing the other registers.

Before you say the IDE controller is responsible for those registers... experience says otherwise. For example, if I select an IDE slave and there is no IDE slave, writes to 0x1F1-0x1F5 do nothing and reads usually return 0x00. It would also make the ATAPI IDE protocol a pain because you have to write the intended transfer length AND read back the transfer length the device is willing to do. That's why IDE emulation is implemented as per-device registers rather than per-controller registers.

See also:

http://www.ele.uri.edu/courses/ele408/s2001/p … nd_ide/ide.html

I'm really not that an expert on IDE interface...just my observations 😀
Perhaps there could be a copy of the registers in the controller, which would always be written (since if there is no device, the writes are ignored) and would be copied to device registers on device select? If the registers are rewritten later, it doesn't matter...

List of programs compatible with Win3.1/Win32s: http://stephan.win31.de/w32slist.htm. If most 32-bit programs and the core instructions are the issue, then perhaps it could be verified in Win3.1. I also wonder if disabling "virtual memory" has any effect.

Win95 SP1 includes updates to Exchange (and access to shared folders) and IE2: http://support.microsoft.com/kb/146449. Perhaps installing Win95 without SP1 would produce a different result (along with the UniATA driver).

Without the paging patch and IDE enabled Win98 will crash dosbox for me before it gets to desktop. With IDE disabled it works ok, so something is definitely not completely right.
With the paging patch, the most frequent error is "PF queue overrun." Even if I increase PF_QUEUESIZE, it will just rise until everything stops working (either PF queue overrun or all the programs inside crash with invalid page fault):

1Left PageFault for 8037d000 queue 20

If IDE is disabled, queue will never rise above 0, so somehow PageFaults are not serviced correctly when IDE is enabled?

edit: so, the reason for the crashes is that w/o the paging patch, dosbox is missing PF queue overrun protection. pf_queue.used is just incremented...
If I add the check, I will also get "PF queue overrun." Without IDE, pf_queue.used is 0 or sometimes 1 or 2...

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...

gulikoza wrote:

I'm really not that an expert on IDE interface...just my observations 😀
Perhaps there could be a copy of the registers in the controller, which would always be written (since if there is no device, the writes are ignored) and would be copied to device registers on device select? If the registers are rewritten later, it doesn't matter...

I also asked my father (who's dealt in hardware) and he's confirmed that the IDE controller is more of a passive conduit for 8 I/O ports from the ISA/PCI bus to the hard drives than a smart controller. To put it another way, when the CPU issues I/O to the IDE controller, that I/O cycle is passed onto the hard drive. The I/O port in question is signalled on DA0-DA2 of the IDE cable (the 3 lower bits of the I/O port are sent down the cable). There's even pins on the IDE cable to carry the ISA 8/16-bit signal and IORDY in case the drive needs more time to respond. The only processing I know of by the IDE controller is bit 4 in the drive/head register to select master/slave, and reset via 0x3F6. I do not yet have documentation on how PCI controllers do the bus master DMA with it, but that's basically it.

gulikoza wrote:

Without the paging patch and IDE enabled Win98 will crash dosbox for me before it gets to desktop. With IDE disabled it works ok […]
Show full quote

Without the paging patch and IDE enabled Win98 will crash dosbox for me before it gets to desktop. With IDE disabled it works ok, so something is definitely not completely right.
With the paging patch, the most frequent error is "PF queue overrun." Even if I increase PF_QUEUESIZE, it will just rise until everything stops working (either PF queue overrun or all the programs inside crash with invalid page fault):

Copy code to clipboard

1Left PageFault for 8037d000 queue 20

If IDE is disabled, queue will never rise above 0, so somehow PageFaults are not serviced correctly when IDE is enabled?

edit: so, the reason for the crashes is that w/o the paging patch, dosbox is missing PF queue overrun protection. pf_queue.used is just incremented...
If I add the check, I will also get "PF queue overrun." Without IDE, pf_queue.used is 0 or sometimes 1 or 2...

gulikoza, thanks for the hint. I noticed in my copy of the code a commented out range check in src/cpu/paging.cpp under PAGING_NewPageFault(). I added a printf() statement to show me the value of pf_queue.used every time it's called, and then uncommented the range check and removed the commented out LOG_MSG("FAULT exit") statement. For whatever reason that resolved the massive slowdown in Win95 starting Microsoft Exchange, and I'm able to use IDE emulation with Windows 98 now without any slowdown. Could the slowdown be something as simple as DOSBox allowing pf_queue.used to increment past PF_QUEUESIZE, in other words, a buffer overrun bug that corrupts memory beyond the array and causes the slowdown?

What happens on your end?

Edit: Erm... okay perhaps by announcing this finding I jinxed it and now I am getting "PF queue overrun" errors with PF_QUEUESIZE == 16 apparently. I will try raising the limit.
Edit: Yup, false hope strikes again. I'm no longer getting that exception but Win98 has returned DOSBox to the non-dynamic core again.
Edit: I see what you mean. I saw Win98 crash as if it couldn't find EXPLORER.EXE with pf_queue.used=18.

OK quick question while I poke around DOSBox internals again: The page fault handler increments pf_queue.used and then creates a page fault exception and runs the DOS machine, then decrements pf_queue.used. How does DOSBox know when the page fault handler is finished? Does it go by IRETF?

I added debug messages to show entry AND exit from PAGING_NewPageFault() and it shows that sometimes, execution enters the function, but never leaves.

1entry: pf_queue.used=0
2IDE ATA command 20 dh=0xab count=0x08 chs=1bc/0b/3f
3exit: pf_queue.used=0
4entry: pf_queue.used=0
5IDE ATA command 20 dh=0xa2 count=0x08 chs=129/02/21
6entry: pf_queue.used=1
7entry: pf_queue.used=2
8exit: pf_queue.used=2
9entry: pf_queue.used=2
10exit: pf_queue.used=2
11entry: pf_queue.used=2
12exit: pf_queue.used=2
13entry: pf_queue.used=2
14exit: pf_queue.used=2
15entry: pf_queue.used=2
16entry: pf_queue.used=3
17exit: pf_queue.used=3
18exit: pf_queue.used=2
19entry: pf_queue.used=2
20entry: pf_queue.used=3
21IDE ATA command 20 dh=0xad count=0x08 chs=17f/0d/0e
22entry: pf_queue.used=4
23IDE ATA command 20 dh=0xab count=0x08 chs=17a/0b/31
24entry: pf_queue.used=5
25IDE ATA command 20 dh=0xa1 count=0x08 chs=180/01/09
26entry: pf_queue.used=6
27IDE ATA command 20 dh=0xad count=0x08 chs=17a/0d/0b
28entry: pf_queue.used=7
29IDE ATA command 20 dh=0xad count=0x08 chs=17f/0d/06
30IDE ATA command 20 dh=0xab count=0x08 chs=157/0b/14
31exit: pf_queue.used=7
32entry: pf_queue.used=7
33entry: pf_queue.used=8

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.

If cputype=pentium, then is it possible that there are pentium (or even 486) instructions which are not resolved by the "full core" during page faults?