Confirmed: I think fread() is failing to read, yet the Read_AbsoluteSector() function doesn't check for failure to read. Zeroing the buffer before fread() makes the two consistent and Win95 OSR2 accepts our IDE emulation.
I'm guessing this has something to do with the disk image exceeding 2GB in size...
OK. The fseek()/fread() failure was simply because I entered the wrong number of cylinders (too many) for what the file really contained. Fixing the cylinder count fixed the read error and Win95 OSR2 is able to use IDE emulation now.
I also added code to Read_AbsoluteSector() to error out if it cannot read, rather than silently ignore the error (and return as the sector whatever gibberish happened to be in the buffer).
Got it. Adding the same emulation to INT 13h AH=0x42 and patching the partition table to mark the FAT32 as LBA, also allowed OSR2 to fully use it's IDE driver on two 7.8GB hard disk images I made up.
The only remaining hangup is that OSR2 periodically sends IDE command 0x40 (READ VERIFY SECTORS WITH RETRY) and when my IDE emulation aborts it, OSR2 freezes for a second or two before issuing IDE command 0x91 and resuming disk I/O. I'm also seeing it issue command 0x10 (SEEK) every so often.
I'm also noticing that the Win95 OSR2 version of fdisk doesn't support hard drives larger than 8GB. You can use external linux tools to preformat a disk image for drives larger than 8GB, but if you try to create a primary partition from FDISK it only creates one that is 8GB or less.
OSR2 fdisk issue: http://support.microsoft.com/?id=245213 ; fdisk fix for OSR2: http://www.mdgx.com/files/Q245213.EXE
Possible hints(?): http://forum.osdev.org/viewtopic.php?f=1&t=25606
OK, the latest source code has been pushed to Hackipedia:
http://hackipedia.org/Projects/DOSBox-X/dosbo … b826-src.tar.xz
Note that I changed from SVN to GIT so new postings are now named dosbox-x-<date>-<time>-commit...
As I mentioned in an earlier post some source has been removed because I intend to refactor the code. This includes OpenGL and visual studio project files (since I develop primarily in Linux).
As for IDE compatibility: Windows seems to demand that whatever BIOS geometry you give the disk, that the IDE interface have something similar. So, if I make a C: drive using 255 heads/track, Windows 9x will not use IDE emulation and will rely on INT 13h. But if I make it something that INT 13h can translate to IDE geometry from: 240 heads/track and 1023 cylinders or less, then Windows 9x will use it's IDE driver. The good news is that if the drive is larger than 8GB then Windows 95 OSR2 and Windows 98 work perfectly fine with INT 13h extensions.
My only other comments are that you should use core=dynamic (it's way too slow otherwise) and do NOT use the svga_s3 driver with Windows 9x: it will work for maybe 2-3 seconds before a BSOD happens. Make do either with plain VGA graphics or the VBEMP SVGA driver.
Update regarding Win98: I'm actually seeing quite a bit of crashiness with Win98. I'm not certain if my IDE emulation is at fault or not, I will investigate. Booting into Safe Mode seems to resolve a lot of it.
OK. No matter what I do, IDE or not, Win98 will randomly crash at times. IDE emulation doesn't seem to help it any, but I don't think it's responsible. The only time Windows 98 is stable at all is if you boot into Safe Mode. I'm also noticing that while the dynamic core helps speed up emulation, it loses it after awhile and everything runs extremely slow---again, unless you're in Safe Mode.
OK I think this might help diagnose whatever is making Win98 crashy in DOSBox: I removed the Sound Blaster 16 driver from Safe mode and rebooted, and the slowdown and crashiness seems to have completely disappeared.
I have a theory that this may have something to do with the KMixer component of Windows 98. By default, Windows 98 mixes audio streams in realtime to allow multiple multimedia programs to play audio, rather than Win95 and earlier where one program "owned" the sound card as long as it had it open. Perhaps the slowdown is the mixing component. But also, perhaps there's something the KMixer component does that DOSBox's dynamic core does not like.
I noticed when writing the vm86 fake I/O driver that DOSBox's cores seem to cache pages. When I first wrote the fake I/O function I had it write an IN/OUT instruction as needed to a fixed location. I quickly found that once the instruction had been written to memory, DOSBox always executed that area of memory as if the same instruction were still there, even if the function later changed it. I can understand why that would apply to the dynamic core, but the other cores (full, simple, etc) had the same effect as well. To put it another way, I'm not certain how well DOSBox would handle self-modifying or dynamically generated code, and I'm wondering if, for performance reasons, Microsoft may have employed such techniques for their format and sample rate conversion in KMixer or related components since obviously an audio mixing engine takes CPU time away from the rest of the system.
Anyway to sum it up: removing the Sound Blaster 16 driver resolves the random crashing in Win98.
It seems like there are cases where DOSBox's dynamic core will suddenly lose performance, and then things start crashing randomly in Win98. Perhaps it wasn't fair to blame KMixer.
A lot of earlier games used selfmodifying code so Dosbox should handle that pretty ok...
I'm debugging a crash in win98 when ide is active, I'll see if I can find it.
Should mounting CD-ROMs now work?
Mounting CDs has always worked so far, just add -ide 2m to the IMGMOUNT command to attach the CD-ROM to the secondary master IDE port and it should work. I think it hasn't "worked" yet for some people because there are possible mistakes in IDE auto-assignment that need to be worked out.
(I personally would love to see a DOSBox provide a QEMU-style console to permit inserting and removing CD and floppy images while booted into an OS or running a DOS game BTW).
It seems like Windows 32-bit paging in general kills the dynamic core's performance, and once the dynamic core is struggling, things in Win98 crash a lot. The IDE driver seems to "help" Win98 in that way, perhaps Win98 figures it can page out more of the DOS region when IDE is used? For example, when IDE is in use by Win98, the instance the "Enter Network Password" dialog appears, the dynamic core slows to a crawl, and after that when bringing up the desktop, that's when EXPLORER.EXE begins to crash at times from within KERNEL32.DLL at <module> 0000:xxxxxxxxx for some reason. I'm wondering if the KMixer thing with Sound Blaster 16 audio also kills the dynamic core in the same way.
UPDATE: The strange thing is I see the same slowdown in Win95 OSR2, except that OSR2 doesn't crash.
UPDATE: Windows 95 SP1 generally doesn't slow down, but if you run a 32-bit program like the Microsoft Exchange program, then it triggers the massive slowdown in the dynamic core.... or not. I can't seem to reproduce it now. Win95 SP1 is generally quite fast but at random, sooner or later, the dynamic core isn't able to run full speed anymore.
UPDATE: Win98 setup runs smoothly until it too causes the massive slowdown in the core, then things start to crash.
OK. One source of massive slowdown seems to be Win95 OSR2's preference for large read/write blocks combined with inappropriate delays coded into the IDE emulation. It's true that starting a READ operation might take 0.5-1ms, but on most drives the next sectors in the read operation usually come in a lot faster. Reducing the initial delay and coding the READ/WRITE commands to set a very small delay for the sectors following the first one greatly improved Win95 OSR2's responsiveness.
Perhaps (loading) a video bios would be compatible with the s3 driver: Video bios usage in DOSBox.
OK. If you followed my advice and created a BIOS hard disk with 240 heads/track, there's a C/H/S calculation bug in the IDE READ/WRITE command emulation regarding multisector reads. The code assumes 16 heads/track when it increments through C/H/S addresses, so if you have 240 heads/track and IDE emulation has 15 sectors/track it will error out incorrectly. I am fixing that bug now.
I just had a hunch about Windows 98: The minimum requirements are that it requires a 486DX or higher, right? Could it be that Windows 98 requires the use of the INVD/WBINVD and INVLPG instructions and that DOSBox is failing to emulate cache flushing that it expects? Perhaps their implementation needs it for it's multithreading constructs like mutexes, semaphores, etc. ? Perhaps CMPXCHG is not properly implemented?
I noticed in src/cpu/core_normal/prefix_0f.h that INVD and WBINVD are implemented as code that checks for invalid cases such as unprivileged code in protected mode, but beyond that, it doesn't really do anything.
jDOSBox source may help (98se supported with IDE). Its changelog also shows implementation of IDE, yet no changes to CPU code other than additional 686 instructions. I'll look if it would help. (Ironically, NT4 requires 486/25, a lower requirement than 98's 486DX2/66; 95 = 386DX).
Edit: Verified that jDOSBox has one function for INVD in the dynamic core which is very similar to DOSBox-SVN; CMPXCHG is also implemented in its dynamic core - checked in normal and dynamic core (it must be in its normal core but not referenced by name?). I posted an incomplete port of danoon's normal core code to allow for 9x compatibility, too.
Edit #2: I recall danoon mentioning his changes to the normal core, but not about additional 486 instructions (and 98se I believe runs under his normal core).
I'll check that code out when I have more free time next weekend. Right now, I'm certain my IDE emulation works properly with Windows 98 but I can't tell how reliable it is when it either crashes at random or runs the DOSBox VM at the speed of tar in freezing cold winter.
I know this is not a popular opinion, but I prefer 95OSR2 over 98se. It runs faster and is much stabler in DOSBox+existing_patches. I'd rather use the non-OSR 95, but the FAT32 support in OSR2 allows for a complete HDD installation of Baldur's Gate+expansion; with your IDE code, I think FAT16 is sufficient because the CDROMs can be mounted, requiring less files installed on the HDD. (Is the major reason for 98 compatibility its widespread availability?)
