Forgot screenshot.

By default the "386 enhanced" control panel applet does not show the checkbox to enable it. You will have to edit your system.ini manually.

Bring up notepad, and scroll down to your [386enh] section.

Add near the middle two lines:

device=*int13
device=*wdctrl

I recommend adding it between the *pageswap and *biosxlat drivers.

Then at the bottom of the [386enh] section add:

32BitDiskAccess=ON

Save the file, exit Windows, shutdown DOSBox-X, and double-check your dosbox.conf uses imgmount correctly to attach your drive C: to the primary master IDE interface. The Windows WDCTRL driver will only check the primary IDE interface and it does not support the secondary IDE interface. Add "-ide 1m" to the imgmount command to make sure it is attached as primary master.

If you have CD-ROM drives attached in the emulator, you will also want to make sure that imgmount attaches the CD-ROM drive to the secondary IDE interface. WDCTRL doesn't know what to do with CD-ROM drives and it will fail to load and use the IDE interface if it sees them. If you want to use a CD-ROM drive regardless, you must use "-ide 2m" or "-ide 2s" to make sure it is attached to the secondary interface.

Finally, you must add -reservecyl 1 to the imgmount command for your C: drive to emulate the reserved cylinder thing that older BIOSes used to do. WDCTRL assumes at least one reserved cylinder and it won't work if none are reserved. See http://www.os2museum.com/wp/?p=935 for more information.

If everything is setup OK, you should be able to boot up DOSBox-X and see no error message while Windows starts up, and you should see the debug messages from the IDE driver as read/write commands are issued. If it works, the "386 enhanced" control panel applet should show that 32-bit disk access is being used.

Thank you for a working IDE patch in W3.1! That is quite an accomplishment. (Also, the MMX patch is not yet complete.)

Indeed, very encouraging. To be clear, the 504 MB limit still applies, right?

(And of course I suppose IDE emulation with a mounted directory instead of imgmount is still a long way off.)

[quote="Jorpho"]Indeed, very encouraging. To be clear, the 504 MB limit still applies, right?

(And of course I suppose IDE emulation with a mounted directory instead of imgmount is still a long way off.)[/quote]

Yes. WDCTRL requires a drive with less than 1024 cylinders because it pre-dates the INT 13h LBA extensions and it pre-dates the INT 13h remapping that later BIOSes had to do to support drives larger than 504MB. Notes in the source code suggest it was written in the 1990-1991 timeframe when typical hard drives were nowhere near large enough to hit that limit.

The traditional INT 13h call can only allow for sectors 1-63 (6-bit), and cylinders 0-1023 (10-bit), so later BIOSes supported larger drives by increasing the number of "heads" (8-bit field) and converting it down to the geometry supported by the IDE disk (reporting a hard disk with 800 cylinders, 63 sectors/track and 128 heads where the drive actually has 6400 cylinders, 63 sectors/track and 16 heads---it converts the cylinder and head count to make it work). WDCTRL doesn't support that remapping, and will fail the test on startup because the registers it reads back from the IDE controller would not match what it asked for.

This site (http://alter.org.ua/en/soft/win/uni_ata) has a universal ATA driver for the NT-class OS, but here (http://reboot.pro/topic/2384-alter-group-univ … -nt351nt42000xp) has a port to Windows 9x. The source code is available. Since W3.1 has detected your IDE emulation, then it must be WD1003 compliant (ATA-2)?

truth5678 wrote:

This site (http://alter.org.ua/en/soft/win/uni_ata) has a universal ATA driver for the NT-class OS, but here (http://reboot.pro/topic/2384-alter-group-univ … -nt351nt42000xp) has a port to Windows 9x. The source code is available. Since W3.1 has detected your IDE emulation, then it must be WD1003 compliant (ATA-2)?

It probably isn't fully ATA-2 compliant since it only implements the bare minimum needed for Windows 3.11 to talk to it. WDCTRL doesn't use very many commands, it only uses the READ/WRITE SECTOR commands and... that's it. The initial tests are little more than exotic INT 13h tests and comparing IDE registers with expected values to make sure disk geometry isn't screwed up.

I'll take a look at that driver code, see what it expects. Perhaps it's a good short-term workaround until better emulation is added, much like using VBEMP for SVGA graphics until DOSBox can run S3 emulation in Win 95 without crashing.

It is said that ATA-2 drives no longer update the sector/head/cylinder values after a command, unless an error, which then breaks compatibility with Windows 3.11 and WDCTRL. So, the IDE emulation right now could be better described as barely ATA-1. I have to fine-tune the code and add more commands and parameters to make it ATA-1 and then ATA-2 compatible.

Have you tried using a kernel debugger for ESDI? At the moment I get:

1Kernel Debugger  Version 4.1.0 01/06/98 16:54:26 ID:00262D84
2Can not find the ring 0 CS
3WDEB98 NOTES: Detected Win9x Build 4.10.2222
4WDEB98 NOTES: Detected GenuineIntel CPU, Family 4 Model 0x0 Stepping 0x2
5  Instruction Sets: 80386, 80486
6
7ESDIINQ: no I/O on BIOS read so punting ESDI

I'm eager to test your new code with int13 updates 😀

gulikoza wrote:

Have you tried using a kernel debugger for ESDI? At the moment I get: […]
Show full quote

Have you tried using a kernel debugger for ESDI? At the moment I get:

Copy code to clipboard

1Kernel Debugger  Version 4.1.0 01/06/98 16:54:26 ID:00262D84
2Can not find the ring 0 CS
3WDEB98 NOTES: Detected Win9x Build 4.10.2222
4WDEB98 NOTES: Detected GenuineIntel CPU, Family 4 Model 0x0 Stepping 0x2
5  Instruction Sets: 80386, 80486
6
7ESDIINQ: no I/O on BIOS read so punting ESDI

I'm eager to test your new code with int13 updates :)

Never thought of that... are you using wdeb386.exe and will it work against retail Win95 or will I need to track down a debug version?

Yes wdeb386 and debug version of esdi_506.pdr from win98se ddk. I don't see this string in the retail version so I guess you need the debug version.

gulikoza wrote:

Yes wdeb386 and debug version of esdi_506.pdr from win98se ddk. I don't see this string in the retail version so I guess you need the debug version.

OK well I don't have a copy handy of the debug build, but it did help me figure out what Windows 95 was looking for. Apparently, the IDE driver in Windows 95 likes to autodetect IDE to BIOS INT 13h mapping by executing INT 13h in virtual 8086 mode. But it does it with the IDE ports trapped so that it can determine what I/O ports the INT 13h routine is using as well as what IRQ is involved. DOSBox does not execute code (as far as Win95 can tell) on INT 13h, so Win95's autodetection comes up empty and it decides the IDE controller is too weird or nonstandard to work with and gives up.

Once I figured that out, getting it to work was conceptually simple, but ugly to implement. Here's what I did:

I added code to the IDE INT 13h read emulation to autodetect whether INT 13h was executed in virtual 8086 mode. If it wasn't, then it does the fake ATA register update needed for Windows 3.1. If it was, then it calls some new code I added to src/cpu/cpu.cpp that forces the CPU to execute specific IN AL,DX or OUT DX,AL instructions. It uses this new code to fake CPU I/O and "go through the motions" of a basic INT 13h IDE disk read, as if it were a BIOS subroutine.

The new code in src/cpu/cpu.cpp is written as a simple function that writes IN AL/AX/EAX,DX (or for output, OUT DX,AL/AX/EAX) to an unused area of ROM BIOS, and then forces the DOS machine to CALL FAR to that area. What this accomplishes is that it puts the I/O instruction out there for the OS (Windows 95 in this case) to see, so that Win95 can trap on it, act on it, and carry on, even though the actual disk I/O was emulated internally by DOSBox. It's doing a dummy IDE read with I/O to bullshit Windows 95's IDE driver so that it properly autodetects the IRQ and IDE port.

Once that was implemented, I saw Windows 95 come up and sure enough---the IDE emulation reported read and write commands coming directly from the OS. It also reported an attempt to use command 0x91 (I'll have to look that up).

It's not entirely stable yet, but it works.

It looks like it generally works, all I need to add next is a default dummy IRQ 14 and IRQ 15 handler. I'm seeing DOSBox crash with a stack overflow because despite the CLI hack I put in the code Win95 is attempting to execute the vm IRQ 14 which at the moment is unassigned and left at 0000:0000 by DOSBox. This crash only seems to happen if I run DOSBox with core=dynamic. I can run it so far with core=full, but it's very sluggish.

Ah... Command 0x91 is "initialize drive parameters".

Great news! Thanks

Okay get this: If INT 13h does not clear (disable) interrupts, Win95 goes into an infinite pagefault (or DOSBox does?). In other words, Win95 assumes that your INT 13h code will CLI at some point, and if it doesn't, it will crash.

OK. I tested the IDE emulation against Windows 95 and Windows 95 SP1 and it works perfectly. Windows 95 OSR2 however has an interesting twist: If INT 13h extensions are available, then the IDE driver will use the INT 13h extensions to perform the same test instead of AH=0x02. So for my IDE emulation to work, I will need to apply the same hack to the INT 13h extensions emulation. Here I go...

OK sorry, Win95 OSR2 does make the call to check for INT 13h extensions, but it doesn't seem to use them, at least so far. But the test it does doesn't work the same as Windows 95. I'm also getting a report at boot time (right about the time CONFIG.SYS is handled) that INT 13h was called from virtual 8086 mode...

🙁 Ookay, so the reason INT 13h was reporting that it was being called from vm86 mode on DOS boot-up was that OSR2 setup felt it necessary to stick EMM386.EXE in the CONFIG.SYS file for some stupid reason.

Alright: Windows 95 OSR2 uses INT 13h extensions IF you label the partition as FAT32 LBA, and it uses INT 13h C/H/S read/write commands if you label the partition as FAT32 CHS.

Okay, I see what the issue is: Windows 95 OSR2 does an INT 13h read from the start of the disk and then another read from about 90% out to the end of the disk. For some reason, a bug in the code is causing INT 13h to read a different sector from the IDE emulation, and that's why Windows 95 OSR2 is ignoring the IDE controller.