DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-5-12 @ 06:38

Jorpho wrote:Didn't someone post a link to How To Please WDCTRL a while back? Of course, that's regarding 32-bit disk access in Windows 3.1, but maybe some of the wackiness involved held over to Windows 95. (Maybe a C/H/S read to 0,0,1 immediately following a device reset is supposed to fail or something.)


OK if I read that link properly, one of the things WDCTRL expects is old ATA behavior where the C/H/S is updated to the next sector after read/write. I got the code to emulate that properly. Now Windows 95 goes from reading and ignoring to reading, sending device identify, and then ignoring it. It still marks the controller as bad though.

So you're right, ESDI_506.PDR carries forward the same wackiness and pedantic assumptions from WDCTRL.

I also ran some quick tests with Windows 95 OSR2, Windows 98, and Windows 98 SE with similar results (Windows 98SE outright fails to list the IDE controller). I tried Windows ME as well, but the installer got into an endless loop "updating configuration" so... I don't know.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-5-12 @ 06:40

robertmo wrote:it looks swapping cds with ctrl-f4 stops working after booting.


I don't seem to recall that ever working anyway except with floppy disks. But I'll see if I can get that working.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Dominus » 2012-5-12 @ 06:42

He he, since CD images. Ever worked in Dosbox after booting, swapping never worked of course ;)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7644
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-5-12 @ 06:46

Joey_sw wrote:coincidently, the esdi_506.pdr is the file that unofficialy patched to allow LBA48 under win9x without using 3rd party drivers.

probably esdi_506.pdr requires certain handshake to determine if the IDE controller is OK.

how about using 3rd party dirvers like Intel AA, would it still saying the the IDE controller implementation is 'bad' ?

When i use IAA in real win98SE, the hardware manager doesn't report that esdi_506.pdr being used.


It's kind of difficult to make Windows 95 use those drivers when those are for PCI IDE controllers and DOSBox does not emulate PCI. :)

If you know of any ISA type drivers I can pick from Windows 95's "add/remove hardware" control panel I would try those and see if they work.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby gulikoza » 2012-5-12 @ 07:21

Dosbox does emulate PCI :wink:
User avatar
gulikoza
Oldbie
 
Posts: 1705
Joined: 2004-6-25 @ 14:53

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-5-12 @ 07:24

gulikoza wrote:Dosbox does emulate PCI :wink:


I checked: DOSBox emulates the PCI BIOS calls. It does NOT emulate the actual I/O ports 0xCF8-0xCFF, therefore Windows 95 won't use it.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby robertmo » 2012-5-12 @ 07:31

TheGreatCodeholio wrote:If you know of any ISA type drivers I can pick from Windows 95's "add/remove hardware" control panel I would try those and see if they work.


I just recalled that windows was installing drivers for ide interface in the past but they were with exclamation. So hal made a special patch that prevented windows from detecting it!
But I figured out earlier that you can set something in window's device manager ide options to hide the exclamation.
Maybe that is a source of problems?

TheGreatCodeholio wrote:
robertmo wrote:it looks swapping cds with ctrl-f4 stops working after booting.


I don't seem to recall that ever working anyway except with floppy disks. But I'll see if I can get that working.


Actually it is floppies swapping that doesn't work before booting and you could look into that too ;)

TheGreatCodeholio wrote:It's kind of difficult to make Windows 95 use those drivers when those are for PCI IDE controllers and DOSBox does not emulate PCI. :)


I think PCI is emulated just check the latest SVN - it was added for voodoo emulation. Not sure if all the changes were introduced there, maybe ask wd. 0.74 code you use is 2 years old.
User avatar
robertmo
l33t
 
Posts: 4396
Joined: 2003-6-18 @ 10:35

Re: DOSBox-X branch

Postby robertmo » 2012-5-12 @ 07:57

here is hal's patch i was talking about, don't know if it went into main source though, anyway maybe there is sth usefull there

viewtopic.php?p=197969&highlight=#197969
User avatar
robertmo
l33t
 
Posts: 4396
Joined: 2003-6-18 @ 10:35

Re: DOSBox-X branch

Postby Joey_sw » 2012-5-12 @ 08:17

ISA type IDE drivers should exist.

iirc i tried to connect the CD-ROM Drive's IDE(ribbon)-Cables to IDE controler that bundled/built-in on ISA sound-card under win95.
The CD-ROM drive able to read the disc properly, but i never tried that with HDD cables though.

The sound card was ESS Tech but i don't remember what the exact version of it.
-fffuuu
User avatar
Joey_sw
Oldbie
 
Posts: 554
Joined: 2011-8-17 @ 12:03

Re: DOSBox-X branch

Postby robertmo » 2012-5-12 @ 08:19

and here is how it looked before and after I switched "Dual IDE Channel Settings" from "default" to "Both IDE Channels enabled".
(before hal's patch was added to the dosbox_voodoo source)

Not sure if that is of any use but just in case ;)
You do not have the required permissions to view the files attached to this post.
User avatar
robertmo
l33t
 
Posts: 4396
Joined: 2003-6-18 @ 10:35

Re: DOSBox-X branch

Postby jefferl » 2012-5-12 @ 13:16

below link is about nt/2000/xp/vista/7/reactos universal open source ata/sata driver , not sure for win9x , since windows 98 & 2000 care about little point had wdm driver source code compatible . hope this helpful for ATA emulation.

http://alter.org.ua/soft/win/uni_ata/
jefferl
Newbie
 
Posts: 27
Joined: 2006-1-10 @ 05:35
Location: Taipei

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-5-20 @ 22:04

Hi guys. I've been busy with life the past week but I'd thought I'd share my findings with the issue so far:

- I already tried copying an IDENTIFY DEVICE response from another drive. That doesn't work. I'm convinced that whatever I'm doing in IDENTIFY DEVICE is not the problem preventing Win95's IDE driver from working.
- I'm wondering if there is something about the BIOS INT 13h emulation that might trigger the problem, although adding trace code to INT 13h only shows read, write, and get device geometry calls, so it might be some other part of the BIOS
- I loaded Windows 95 into VirtualBox and then forcibly replaced the Intel PCI driver that it normally uses from within VirtualBox by removing the PCI bus driver and forcibly installing the "Standard ESDI/IDE" driver. No problems. So whatever VirtualBox is doing, it's doing it right. The VDI image associated with the VM had way more than 1024 cylinders, so it can't be the 1024 cylinder limit that Windows 3.11 for workgroups is said to have, and it can't be BIOS geometry translation.
- ESDI_506.PDR does however expect ATA-1/2 behavior where after a read or write the C/H/S or LBA value is updated by the drive to point to where the read stopped. As I stated in a previous post, writing the emulation to do just that seemed to satisfy Win95's CHS read sector test. The remaining issue seems to be whatever I return from the "IDENTIFY DEVICE" command it doesn't like, probably since again it doesn't match up with the BIOS somehow.

I would also like to say that I'm all for adding PCI bus emulation, but I'd rather have IDE emulation start out as an ISA type device, the kind you used to find in 386 and 486 systems, before adding PCI IDE emulation.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Jorpho » 2012-5-21 @ 03:07

TheGreatCodeholio wrote:- ESDI_506.PDR does however expect ATA-1/2 behavior where after a read or write the C/H/S or LBA value is updated by the drive to point to where the read stopped. As I stated in a previous post, writing the emulation to do just that seemed to satisfy Win95's CHS read sector test. The remaining issue seems to be whatever I return from the "IDENTIFY DEVICE" command it doesn't like, probably since again it doesn't match up with the BIOS somehow.
Well, perhaps the driver is comparing the device geometry it gets from INT 13h to what it gets from Identify Device, and deciding that they don't match?

What happens if you copy the INT 13h geometry information from that other drive along with the Identify Device response?

Please excuse me if I'm stating the obvious. :sweatdrop:
User avatar
Jorpho
l33t++
 
Posts: 7043
Joined: 2003-2-14 @ 19:50
Location: Canada

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-6-03 @ 06:13

I haven't had time to focus on the IDE ATA issue, but I have added some new code to the doslib library that might be useful.

- HEXMEM for Windows, a tool to poke around application-visible memory regions. Under Windows 3.1/9x/ME, this is a great way to peek into DOS memory from Windows or look into the Win9x/ME kernel's space at 0xC0000000. Apparently it even manages to work under Windows 3.0 real mode (where most of the Windows test code crashes).
- DISPDIB library and test program, to use the Microsoft DISPDIB library to do full-screen VGA graphics from Windows (think of it as a crude precursor to WinG and DirectX).
- WIN16EB library: A library for Win16 programs to execute run-time-generated code, and a library that Win32 programs can use to execute run-time-generated Win16 code (yeah I know, ick :). The DISPDIB support library uses this to call BIOS INT 10h from within Win32 applications without having to carry around an external Win16 DLL.
- OS/2 build support. The HW/DOS and HW/CPU code has been updated to compile for OS/2. So far they work well, except 16-bit builds under OS/2 2.x and Warp 3 where the DOS VM interferes with EFLAGS and effectively prevents CPUID detection.

I have no doubt Windows 95's ESDI/IDE driver is comparing geometry, I just don't have the drive and initiative to work on that right now. But when I have a longer stretch of free time, I will try it out.

Final note: HEXMEM Win16 builds attempt to hook the Page Fault interrupt to safely recover when you (inevitably) access portions of linear memory Windows 3.x 386 enhanced mode has not mapped. It seems to work perfectly under Windows 3.1/9x/ME in QEMU and VirtualBox, but DOSBox appears to mis-emulate the page fault for 16-bit protected mode code and Windows 3.1 hard-crashes as a result, while Win32s applications are able to page fault and recover just fine under DOSBox. I might write a test program under HW/CPU to deliberately cause page faults and recover from the exception handler to gain greater insight sometime if I have time in the next couple months. If anyone has any insight on the issue I'd like to hear it.

http://jon.nerdgrounds.com/doslib/1462/
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-6-11 @ 06:56

DOSBox-x update:

OK. I checked all disk geometry information to ensure it was correct. I added a test program to the DOSLIB who's job is to query Drive C using INT 13h, Fixed Disk Parameter Table, and CMOS, and show all the geometry obtained for comparison. It all matches the behavior I see in VirtualBox and QEMU: All three sources show the geometry or if >= 512MB, translated versions of the geometry, while querying the IDE controller shows the actual geometry. I also modified the hard disk emulation to remove as many of the fields as possible to emulate only what ATA-2 describes. So at this time, I'm still at a complete loss what the hell Windows 95 doesn't like about the IDE emulation.

As for DOSLIB, I will be hosting it on my website http://hackipedia.org from now on and posting updates there, instead of filling this thread with updates. This thread covers DOSBox-x not DOSLIB. Right?

Last non-hackipedia posted link: http://jon.nerdgrounds.com/doslib/1477. Future versions will appear on the hackipedia website when they are released.

What's new in this DOSLIB release:

2012/06/10
- Added PCI Express support library.

- Added code to ACPI demonstration program to show PCI Express MCFG tables.

- Fixed bug in SMBIOS program that prevented reading SMBIOS data from 32-bit
protected mode.

- Fixed makefile mistake that caused both TEST and MODESET programs in hw\vesa
to be the test program.

- Started experimental USB OHCI Host Controller library in hw\usb\ohci to
demonstrate programming and communicating with USB controllers. The program
is able to scan PCI and PCI-E busses to locate OHCI controllers, and then
query, reset, and change ownership to/from the BIOS as well as detect cases
where the BIOS may be using the USB controller for "Legacy Keyboard/Mouse"
emulation. All I have yet to figure out is why an ancient (2000-ish) IBM
NetVista is having no problem handing off OHCI control, but having problems
taking back control when we want it to. To put it another way, if you're
using a USB keyboard on the thing don't expect a responsive keyboard after
you run the test program.

- Added code to IDE test program to show C/H/S geometry and total sectors counts
from "Identify Device" command.

- Added test program to hw\biosdisk to read drive C geometry via INT 13h, through
the Fixed Disk Parameter Table, and from CMOS, and show them all to you so that
you can do comparative analysis and look for flaws. Helped me verify that DOSBox-x
is returning values correctly, but still didn't help with the problem of Windows
95 refusing to talk to my IDE emulation
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2012-6-11 @ 08:20

User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Jorpho » 2012-7-23 @ 12:59

At the risk of saying something silly and redundant, I thought this bit about how the Linux kernel handles drive identification looked pertinent:
http://tldp.org/HOWTO/Large-Disk-HOWTO-10.html
User avatar
Jorpho
l33t++
 
Posts: 7043
Joined: 2003-2-14 @ 19:50
Location: Canada

Re: DOSBox-X branch

Postby Daniel_30_Aus » 2012-10-16 @ 08:04

Ok I have download the latest version of DosBox X (even compiled the code myself from source). With both versions I can not get

imgmount 3 "ISOFILE.ISO" -t iso -fs iso -ide 2m

this will not work!!

what the am I doing wrong???
Freeware :) Dools Productions
User avatar
Daniel_30_Aus
Newbie
 
Posts: 11
Joined: 2008-3-21 @ 08:48
Location: Australia

Re: DOSBox-X branch

Postby danoon » 2012-10-27 @ 05:36

Thank you for sharing your code. I have been messing around with porting parts of it to jDosbox and wanted to share my findings.

I messed around with your IDE code and even ported QEMU IDE to java and saw the same thing you did. But I was able to get Win95 to see the IDE when I use the bochs bios. I thought you would be interested in knowing this since it proves that the bug preventing Win95 from using your IDE is in the Bios area of Dosbox.

Here are two things I had to change in your code to get ps/2 mouse and bochs to work.

1) Reset AUX needs to send 0xFA, 0xAA and 0x00 as a response instead of just 0xFA (this caused Win95 to hang).

2) Bochs bios would hang unless I changed the keyboard reset to return 0xFA, delay, 0xAA instead of 0xFA, delay, 0x00

Here is the Bochs bios code, notice that it will tolerate a delay based on how fast it can loop 64k times. A delay of 400 was too long in my tests.

Code: Select all
/* Wait for data */
    max=0xffff;
    while ( ((inb(PORT_PS2_STATUS) & 0x01) == 0) && (--max>0) ) outb(PORT_DIAG, 0x31);
    if (max==0x0) keyboard_panic(31);

    if ((inb(PORT_PS2_DATA) != 0xaa)) {
        keyboard_panic(994);
    }
danoon
Member
 
Posts: 132
Joined: 2011-1-04 @ 19:12

Re: DOSBox-X branch

Postby beard » 2012-10-30 @ 10:44

Hi,

since I developed software for KVM systems which have to emulate keybord and mouse, I can tell you the following:

PS/2 Keyboard:
After power on it sends 0xAA after finishing the selftest.
On a reset command (0xFF) it responce with 0xFA (ACK) and after a short time with 0xAA for a good selftest.
The keyboard is enabled after a power on or reset.

PS/2 Mouse:
After power on it sends 0xAA 0x00.
The 0x00 is to tell the PS/2 'bus' that it is a mouse.
So on a reset (0xFF) it responce also with 0xFA (ACK) and 0xAA 0x00.
The mouse is disabled after a power on or reset.
An enable command (0xF4) is required to enable mouse output.
Ofcourse 0xF4 have to be ACKed (0xFA).

If someone has further questions to PS/2 protocol, let me know.

Beard
beard
Newbie
 
Posts: 14
Joined: 2009-8-17 @ 11:13

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest