[quote="truth5678"]I guess that means that the page faults are related to the memory mapped by PCI?

That's not what I'm saying. I'm saying that some drivers in Windows 95 and 98 that could be used with DOSBox are written for ISA cards that use bank-switching. They fake a linear framebuffer for Win95 by hooking the page fault, and if the page fault happens in a specific linear memory address that corresponds to the fake "framebuffer", they switch the read/write banks of the card and then change which page is "present" in the LFB to permit Win95 to draw on the screen. In that way, Windows 95's GDI rendering engine can always assume a linear framebuffer even if the SVGA card is not really a linear framebuffer. I was saying that by using the VBEMP driver and machine=svga_s3, we use the VESA BIOS to set up a linear framebuffer which is then given to Win95, and no page faults are needed to fake a linear framebuffer.

I don't know if the Win9x stock S3 driver is using any of the same bank switching tricks. I do know however that if you want to see how well DOSBox would handle such a trick, that you can set machine=svga_et4000 and then force Win95 to install the stock Tseng ET4000 driver. How well it works is very dependent on the CPU core. On most of the cores it flat out doesn't work and Win95 ends up drawing everything on the top of the screen (no bank switching is occurring) if you try that.

truth5678 wrote:

Using this guide on reading a partition table, and a hex editor, I identified the differences between the working-with-IDE FAT16 […]
Show full quote

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.

Copy code to clipboard

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.

Is that the partition table? It looks like both are marked type 0x06 (FAT16B) look at offset 0x1C2 which would be first partition entry, 4th byte. FAT32 would be marked 0x0B or 0x0C and an LBA FAT16 would be type 0x0E.

http://en.wikipedia.org/wiki/Partition_type

TheGreatCodeholio wrote:

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.

That's hopeful news that it can potentially boot further! I was glad that the binary distribution (0.1.0) was available and boots by way of a DOS boot disk inside dosbox. The newer distributions appear to boot by ISO instead (although there are other options I haven't fully tried yet, such as converting a qemu image of it).

truth5678 wrote:

TheGreatCodeholio wrote:

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.

That's hopeful news that it can potentially boot further! I was glad that the binary distribution (0.1.0) was available and boots by way of a DOS boot disk inside dosbox. The newer distributions appear to boot by ISO instead (although there are other options I haven't fully tried yet, such as converting a qemu image of it).

Who's up for modifying the "boot" command to accept an ISO image and emulate the El Torito CD-ROM boot specification? 😀

http://en.wikipedia.org/wiki/El_Torito_%28CD-ROM_standard%29

TheGreatCodeholio wrote:

Is that the partition table? It looks like both are marked type 0x06 (FAT16B) look at offset 0x1C2 which would be first partition entry, 4th byte. FAT32 would be marked 0x0B or 0x0C and an LBA FAT16 would be type 0x0E.

I read it wrongly, you're right that both are FAT16(B). At least the existing drive image's partition table should be compatible with 95/IDE.

TheGreatCodeholio wrote:

...They fake a linear framebuffer for Win95 by hooking the page fault, and if the page fault happens in a specific linear memory address that corresponds to the fake "framebuffer"...

Thank you for the the very helpful explanation on the framebuffer issue. 😀

TheGreatCodeholio wrote:

Who's up for modifying the "boot" command to accept an ISO image and emulate the El Torito CD-ROM boot specification? 😀

http://bochs.sourceforge.net/techdata.html ; http://paulski.com/zpages.php?id=1812 ; http://bochs.sourceforge.net/cgi-bin/lxr/sour … /bios/rombios.c ; http://www.virtualbox.org/svn/vbox/trunk/src/ … BIOS/eltorito.c

The spec appears well documented; I'll try to interpret as much as I can. (Noted that 95 and 98_upgrade editions don't support el torito booting).

Edit: possible to download latest ReactOS release version for qemu and convert the vmdk image to raw format: qemu-img convert ReactOS.vmdk -O raw ROS.raw. The qemu-img.exe from here, qemu-1.5.3-windows, and requires exe file + libglib, intl, libz dll files. Update: older ReactOS qemu images are bootable in dosbox; could also establish working images in jdosbox for use with dosbox.

Edit2: dos_programs.cpp has the boot command code; eltorito.c from vbox has code for el torito emulation

1if(imageDiskList[drive-65]==NULL) {
2			WriteOut(MSG_Get("PROGRAM_BOOT_UNABLE"), drive);
3			//return;
4		}
5		bootSector bootarea;
6		imageDiskList[drive-65]->Read_Sector(0,0,1,(Bit8u *)&bootarea); ...
7		for(i=0;i<512;i++) real_writeb(0, 0x7c00 + i, bootarea.rawdata[i]);

I was incorrect earlier, your IDE emulation works well with existing non-IDE installations of 95 (for example: OSR2 with FAT16 1.96gb image). The 32-bit protected mode driver was previously disabled in a property sheet of Windows 95 "System Properties" -- once this was enabled, then "Add New Hardware" detected the IDE device and it was working with the HDD.

Also, here is a warning about duplicating HDD images and using them simultaneously on IDE. The problem associated with the warning can be bypassed by writing different bytes to 0DCh through 0DFh of the MBR (this is the timestamp portion).

Edit: confirmed that Unreal Tournament works in 95b+IDE; it seemed to run better under IDE, too (certainly no downside to it). Also, seems like the IDE emulation is working very well. When moving the code over to SVN, I did make a few minor modifications and remove the parallel port patch code (and maybe some other bits).

Edit2: Scandisk is working on the disk images which is another advantage of your IDE emulation. 😀

Edit3: corrected line about the mystery bytes.

can you, TheGreatCodeHolio, post a win32 binary of your new updated dosbox-x fork? I'm still unable to compile it

SA1988 wrote:

can you, TheGreatCodeHolio, post a win32 binary of your new updated dosbox-x fork? I'm still unable to compile it

99% of my S/W development happens in Linux. I'll have to dig out my old copy of XP and Visual Studio 2008 and stick it in a virtual machine to do that. I'll post a Win32 when I get the time to do that.

truth5678 wrote:

Edit2: Scandisk is working on the disk images which is another advantage of your IDE emulation. 😀

How about the Defrag tool? I've defragged the C: and D: drives with IDE emulation enabled with no issues whatsoever 😀

I just tried the defrag tool and it worked perfectly. Thank you for developing the IDE emulation and also all the other pieces, like the PnP code. 😀 I've been studying the code as a learning exercise; I noted that your emulation has the minimum PIO transfer cycle time set according to PIO mode 2 specification, 240ns, yet the PCI-based IDE emulators typically show a value of 512ns. Given they intentionally set the value high, I've wondered if it has little or no effect on the disk speed or stability.

Important bugfix: I made a mistake in src/ints/bios.cpp. IRQ 14 and 15 interrupt vectors need to be associated with INT 0x76 and 0x77 not 0x7E and 0x7F. That fix allows IDEDIAG.EXE and MHDD.EXE to startup and detect without crashing and hanging since there now exists a valid interrupt handler for IRQ 14 and 15.

IDEDIAG.EXE unfortunately won't do a read test because the NOP command is unsupported (wait, what?)
MHDD.EXE seems to have other issues with the IDE emulation and will always get garbled results.

truth5678 wrote:

I just tried the defrag tool and it worked perfectly. Thank you for developing the IDE emulation and also all the other pieces, like the PnP code. 😀 I've been studying the code as a learning exercise; I noted that your emulation has the minimum PIO transfer cycle time set according to PIO mode 2 specification, 240ns, yet the PCI-based IDE emulators typically show a value of 512ns. Given they intentionally set the value high, I've wondered if it has little or no effect on the disk speed or stability.

The PIO transfer cycle time is per I/O instruction I think, not per sector transfer. I chose the small values I did to help performance in Win9x, since the older larger values made Win9x unnecessarily slow.

Thank you for the helpful explanation on that PIO parameter. 😀

Also, that's interesting about the DOS-based IDE tests. I wonder if MHDD.EXE is non-PCI bus friendly; I tried the other and had the same result (data transfer test). I'll test the tool further.

Edit: additional details, partly from here.
Read Verify Sector with Retry (0x40): "The execution of this command is identical to the Read Sectors command but the Read Verify command does not cause the drive to set DRQ, and the drive transfers no data to the host. On receipt of Read Verify command the drive sets BUSY. When the requested sectors have been verified, the drive clears BUSY and generates an interrupt. Upon command completion the Command Block Register contains the cylinder, head, sector of the last sector verified."
Nop (0x00): "This command carries out no action other than to return an error consistent with an invalid command code. The intent of this command in the standard is to allow hosts that can only write 16 bits at a time to be able to check the drive status."

Edit2: is it possible that the data transfer test is for DMA modes only? I tried to add 0x00 (NOP capability) to the IDE code, but IDEDIAG still generates the NOP error (actually that the device doesn't have NOP even though the controller does(?)). 🙁 Also, I added 0x40 (Read Verify) command to the code but the test iterates through the cylinders only (heads/sectors showing as 0); I'm sure it isn't correct - I copied the Read command lines from the three relevant functions and removed the DRQ flag and attempted to remove lines associated with data transfer to the host. (Win95b takes a long pause on boot after adding 0x40).

I edited the Identify bytes according to this: http://smartmontools.sourceforge.net/doxygen/ … cpp_source.html. Some of these lines/edits corresponded to NOP capability (verified by IDEDIAG, as far as that's a verification of true NOP capable):

1host_writew(sector+(80*2),0x0006);	
2host_writew(sector+(81*2),0x0001);
3host_writew(sector+(82*2),0x4000);
4host_writew(sector+(83*2),0x4000);
5host_writew(sector+(84*2),0x4000);
6host_writew(sector+(85*2),0x4000);

IDE emulation update.

Looking at the ATA standard, the NOP command is supposed to error out, but in a specific way. It's also supposed to leave all but the error and status registers untouched. Modifying the code to emulate NOP that way fixed the error message. Apparently by "data transfer test" IDEDIAG means a test where it NOPs the ATA drive and checks to see if only status & error changed. All other registers are NOT supposed to change.

As for MHDD.EXE, it looks like it gets confused because the IDE emulation does not emulate the RECALIBRATE command (command 0x10). The "CX" command (seek & read test0 works fine now. The IDE emulation is also reporting MHDD,EXE is sending command 0xEC while the IDE emulation is still working out command 0xEF.

I will follow your guide to implement NOP. 😀 That's also very good news that MHDD is working; additional documentation is here: http://real-world-systems.com/docs/MHDD_en_manual.html. (I'm hoping to try UHDD.sys in freedos: http://johnson.tmfc.net/dos/driver.html).

truth5678 wrote:

I will follow your guide to implement NOP. 😀 That's also very good news that MHDD is working; additional documentation is here: http://real-world-systems.com/docs/MHDD_en_manual.html. (I'm hoping to try UHDD.sys in freedos: http://johnson.tmfc.net/dos/driver.html).

The code is simple:

1                case 0x00: /* NOP */
2                        feature = 0x04;
3                        status = IDE_STATUS_DRIVE_READY|IDE_STATUS_ERROR;
4                        controller->raise_irq();
5                        allow_writing = true;
6                        break;

Thank you for the NOP code! 😀 That would taken me a lot of trial-and-error. With your help, I was able to run the IDEDIAG test - it continually called the NOP command until it was stopped - the logging showed iteration over the cylinder and sector positions only. Also, I tried MHDD with logging; seems the recalibrate command is called after the abort (related to the 0xEC/0xEF conflict). I pasted some code from 0x08 to attempt to bypass the Recalibrate command. Tried the "CX" command, too - that runs and shows iteration over cylinder and sector positions only.

For the 0xEC/0xEF line that is logged: I wonder if MHDD is trying to activate a feature on the drive and then calling recalibrate after not finding it; I'll test further. Edit: I wonder if adding the 0xEF set features command would bypass the error. I'll also try to retain just a subset of the Identify bytes.

I found this QEMU guide just now:
http://gunkies.org/wiki/Installing_Windows_95_on_Qemu

Like DOSBox-X, it seems Windows 95 on QEMU also doesn't recognize the PCI bus right off the bat. What is interesting is that the guide recommends using Intel's PCI drivers instead of the ones that come with Windows.
http://downloadcenter.intel.com/confirm.aspx? … lName=&lang=eng

Perhaps this might make some difference in regards to stability?