DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby beard » 2012-10-31 @ 13:35

Maybe that's the way:

keyboard.cpp:
Code: Select all
case 0xff:   /* reset */
               LOG(LOG_KEYBOARD,LOG_NORMAL)("AUX reset");
               KEYBOARD_AddBuffer(AUX|0xfa);   /* ack */
               Mouse_AutoLock(false);
               AUX_Reset();
          PIC_AddEvent(AUX_ResetDelay,RESETDELAY >> 1);
               break;
         
         
         
static void AUX_ResetDelay(Bitu val) {
//   keyb.reset=false;
   KEYBOARD_AddBuffer(AUX|0xAA);   /* BAT */
  KEYBOARD_AddBuffer(AUX|0x00);   /* ID */
}

Not tested, only an idea.

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

Re: DOSBox-X branch

Postby beard » 2012-10-31 @ 13:51

I also found something strange in keyboard.cpp

Code: Select all
case 0xf2:   /* Identify keyboard */
         KEYBOARD_AddBuffer(0xfa);   /* Acknowledge */
         KEYBOARD_AddBuffer(0xab);   /* ID */
         KEYBOARD_AddBuffer(0x41);
         break;

In my opinion it should be:
Code: Select all
case 0xf2:   /* Identify keyboard */
         KEYBOARD_AddBuffer(0xfa);   /* Acknowledge */
         KEYBOARD_AddBuffer(0xab);   /* ID */
         KEYBOARD_AddBuffer(0x83);
         break;

0xAB 0x83 is the answer of a standard Cherry keyboard.
I don't know which keyboard answers with 0x41.

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

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-1-12 @ 23:04

danoon wrote: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.


That's what I thought. Did you see anything that clues you in on what Windows 95 is looking for? Is it a signature or interrupt call of some kind? Is it something DOSBox can stick in the 0xF000:0x0000 area to make Win95 happy?

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);
    }


I will add that to my branch and test it to make sure it works with Win95.

How did you get the Bochs BIOS to run in DOSBox? Did you use the megabuild branch or did you hack the ROM image into 0xF000:0x0000 or what?
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-1-12 @ 23:10

Daniel_30_Aus wrote: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???


You have to specify a drive letter at the moment (C, D, E, etc.). The reason for this has to do with how I tied the IDE ATAPI CD-ROM emulation into DOSBox's MSCDEX.EXE drive mapping to make it work, which I intend to clean up when I get the chance.

However, there is an option (I don't recall at the moment the name) that I added that lets you control whether the CD-ROM or hard drive is attached to IDE as primary/secondary and master/slave.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-1-13 @ 02:33

That sounds about right. I figured there were a few places where I got sloppy. Although some of it comes from testing the keyboard test code in DOSLIB on some clone systems that aren't quite compatible---especially laptops, or worst of all, modern BIOSes in USB "legacy mode" (emulating a PS/2 mouse & keyboard using a USB mouse and keyboard). The USB legacy mode emulation on most BIOSes I could find is atrocious, though it happens to work well enough for basic system operation.

I updated the code to correct that, though I have not yet added realistic delays between the ACK and the 0xAA response.

I know that PS/2 mice support a "get device ID" which is normally 0x00 unless you ask for a scrollwheel mouse. Have you seen any case where the scrollwheel mouse responds with 0xAA 0x03 rather than 0xAA 0x00 on reset?

beard wrote: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
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby danoon » 2013-1-16 @ 04:36

I'm not sure what about the Dosbox bios Win95 didn't like. I actually tried pretty hard to get it to work before I resorted to trying Bochs BIOS. As for getting Bochs to work, it took some effort, basically loaded bios.bin and video.bin into their addresses, setup the cmos and installed some handlers for the bios. But this was all in my java Dosbox port so it may help give you some ideas if you want to look at my code (around line 800 in Dos_programs.java), but I don't have a patch you can use.
danoon
Member
 
Posts: 129
Joined: 2011-1-04 @ 19:12

Re: DOSBox-X branch

Postby masaykh » 2013-1-24 @ 01:21

i almost succeded to run linux in dosbox.

ftp://distro.ibiblio.org/pub/linux/dist...floppy.img
or
http://www.zelow.no/floppyfw/download/f...2.0.11.img
or
http://heanet.dl.sourceforge.net/projec...8-boot.img

using YKhwong build (with dosbox-x patch version 117)

and got some unxpected results :
if you set sblaster for sb16 - no device found
if you set for sb16vibra device found but unknow and with errors

It found PIIX/ICH pci bridge but cannot configure it

ide device found as general scsi device ata_piix.o dont see it
so i think it is good way to look at this)
masaykh
Newbie
 
Posts: 9
Joined: 2012-12-22 @ 22:48

Re: DOSBox-X branch

Postby danoon » 2013-1-24 @ 03:27

My java port runs Linux pretty well now. As for getting Dosbox to run Linux I think the only 2 major hurdles will be Page Fault handling and the IDE controller. Dosbox assumes the page fault will be handled and the program will resume where it left off, this is definitely not true for Windows 98 and I wouldn't be surprised if Linux has the same issues.
danoon
Member
 
Posts: 129
Joined: 2011-1-04 @ 19:12

Re: DOSBox-X branch

Postby telanus » 2013-1-24 @ 09:26

I know I'm nit-picking here
readme wrote:DOSBox seems to be the only emulator capable of emulating 160KB 5.25" floppy disk images and therefore booting PC-DOS 1.0.


this isn't really true. Both PCEM and MESS emulate it and on both PC-DOS 1.0 starts.

On MESS: http://imgur.com/ReiCqW5
On PCEM: http://imgur.com/SNuwD8U

I'm using using a dump of a 160kb disk in both screenshots
My Retro PC:
Spec: PII400 with 400MB, Riva128zx and C-Media soundcard
OS: Win 98SE
Main:
Spec: Dual-Core 2.60, GeForce GT 240 3Gb Ram & Creative Audigy
OS: Win XP Pro (SP3)
User avatar
telanus
Newbie
 
Posts: 83
Joined: 2007-10-03 @ 14:20

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-1-26 @ 21:44

telanus wrote:I know I'm nit-picking here
readme wrote:DOSBox seems to be the only emulator capable of emulating 160KB 5.25" floppy disk images and therefore booting PC-DOS 1.0.


this isn't really true. Both PCEM and MESS emulate it and on both PC-DOS 1.0 starts.

On MESS: http://imgur.com/ReiCqW5
On PCEM: http://imgur.com/SNuwD8U

I'm using using a dump of a 160kb disk in both screenshots


Yeah, sorry :) I've never used those emulators, I tend to focus on QEMU and Virtualbox.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-1-26 @ 23:06

danoon wrote:My java port runs Linux pretty well now. As for getting Dosbox to run Linux I think the only 2 major hurdles will be Page Fault handling and the IDE controller. Dosbox assumes the page fault will be handled and the program will resume where it left off, this is definitely not true for Windows 98 and I wouldn't be surprised if Linux has the same issues.


I'm not sure what you mean by that. A page fault handler HAS to either return to the fault or jump elsewhere. It is possible for the OS to modify the return address on the fault stack. I know from experience that Win 95 and Win 98's GPF handler will do just that to silently ignore faults caused by user-space attempting to execute certain privileged instructions.

I do know from programming experience that there is something not quite right with DOSBox's page fault emulation. It seems to mostly affect page faults that happen with 16-bit code especially Windows 3.1, while 32-bit page faults seem to work fine. I'm guessing that since Windows 95 is also mostly 16-bit it might explain a lot of weird crashes that I've seen.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-1-26 @ 23:14

masaykh wrote:i almost succeded to run linux in dosbox.

ftp://distro.ibiblio.org/pub/linux/dist...floppy.img
or
http://www.zelow.no/floppyfw/download/f...2.0.11.img
or
http://heanet.dl.sourceforge.net/projec...8-boot.img

using YKhwong build (with dosbox-x patch version 117)

and got some unxpected results :
if you set sblaster for sb16 - no device found
if you set for sb16vibra device found but unknow and with errors

It found PIIX/ICH pci bridge but cannot configure it

ide device found as general scsi device ata_piix.o dont see it
so i think it is good way to look at this)


That doesn't surprise me (sb16vibra issue). So far I have only tested the sb16vibra mode with Windows 95 to make sure it is able to pick it up through the PnP emulation. I'll have to look into what the Linux kernel is doing.

The IDE emulation is generally incomplete, in fact, it doesn't even emulate the write command yet since I had gotten hung up with Windows 95.

I can't speak for the PIIX/ICH emulation since I'm not the one who wrote it. I'm sure it's the same problem as DOSBox's cheesy CMOS emulation where they hard-coded reads and ignore writes.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby yahma » 2013-3-27 @ 17:07

Anyone else notice instability in Windows 98 when using more than 64MB of RAM? Tried using 256MB and after about 5 minutes Win98 just froze and the cursor was stuck.
yahma
Newbie
 
Posts: 15
Joined: 2012-2-20 @ 20:16

Re: DOSBox-X branch

Postby Dominus » 2013-5-09 @ 20:15

Moved to the patches forum viewforum.php?f=41
User avatar
Dominus
DOSBox Moderator
 
Posts: 7618
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: DOSBox-X branch

Postby gulikoza » 2013-7-26 @ 12:46

I tried looking at the IDE problem myself. I was able to port jDosBox ability to load and boot Bochs bios, unfortunately the IDE emulation is too incomplete to be able to compare the results.

Loading a different bios obviously replaces the in13 handler. Dosbox int13 handler does not go through IDE and that's a problem for WDCTRL (I've traced the WDCTRL loading since source is available in W31 DDK :-D) - it reads a sector through int13 and then compares the sector no. with 0x1f3/4/5/6 and expects the c/h/s to match. Perhaps something similar is with ESDI since it's been shown they have similar quirks?

Since Bochs INT13 goes through IDE, the WIN95 boot doesn't get very far...
I have observed the following problems:
- host_reset needs to be delayed (BIOS checks that BUSY is set first and then READY returned later, only 0x00 is returned here)
- 0x1f6 is written after 0x1f2/3/4/5 so the bios programs the wrong (non-existing) device when trying to read the boot sector (it scans through devices on post, then programs cylinder and sector, drivehead is the last, but reading will fail as the boot device was not programmed)
- writes are not supported so it dies pretty soon

I have patched those issues with quick & dirty fixes so that I was able to get further into the boot process (but not complete it). Comparing the resulting image (to see if something is written to my image :happy:) I noticed there is an additional log in Windows98: ios.log. Now here's where it gets interesting - using Dosbox to boot, the IOS.Log will read:
Code: Select all
ESDI trap handler not called
Unit number 00 going through real mode drivers.
Unit number 01 going through real mode drivers.
Unit number 02 going through real mode drivers.


Using BOCHS (full Bochs, not just the Bios and booting the same image file), the "ESDI trap handler not called" error is not there! Is it possible this is the cause Win9x is ignoring current IDE emulation?

Here's the code for loading the Bochs bios (ported from jDosBox, thanx danoon :wink:). It includes some ps2 keyboard fixes (you also need the base PS2 patch from dosbox-x) to satisfy the bios. VGABIOS is also needed if you want so see anthing (but I've also patched to VGA ROM Init so the bios will not hang w/o the additional vgarom it just won't show anything - it boots, but the most I've seen is a pretty scrambled scandisk image). It does not include the ide fixes so it will only detect an unknown ATA device (reset issue) and then fail with boot failure. My quick&dirty IDE version dies after scandisk, but still before anything useful is seen, probably the writes are not entirely correct...
You do not have the required permissions to view the files attached to this post.
User avatar
gulikoza
Oldbie
 
Posts: 1704
Joined: 2004-6-25 @ 14:53

Re: DOSBox-X branch

Postby gulikoza » 2013-7-26 @ 17:08

IDE should call INT76 at the completion of a disk operation and in Bochs BIOS int76 calls int15 ax=9100h. Is this hooked by the ESDI driver?
User avatar
gulikoza
Oldbie
 
Posts: 1704
Joined: 2004-6-25 @ 14:53

Re: DOSBox-X branch

Postby truth_deleted » 2013-7-27 @ 10:10

It may be worthwhile to disable real-mode access to the cdrom drive, just in case it could cause the protected mode IDE driver to fail. However, this behavior was not seen earlier in this thread with Win95 in another emulator. Post about this possibility:
http://www.budallen.com/01_98/98_msdos_compat.html

Also, the NT4 DDK has an open source driver (ATAPI miniport) which may share relevant code with the Win95 IDE driver (ESDI_506.pdr):
http://www.osronline.com/DDKx/w98ddk/io ... 5_9tpl.htm

I was unable to find the NT4 DDK to verify its usefulness.

From reading other parts of this thread, it contrasts LBA48 and LBA28. I've tried to interpret the dosbox-x IDE code: it "identifies" the drive as LBA48, yet Win95 / ESDI_506.pdr would use LBA28 (have to verify for all OSR versions). Win98SE would support LBA48.
truth_deleted
 

Re: DOSBox-X branch

Postby SA1988 » 2013-8-03 @ 20:56

when I use the boot command, along with the CD-ROM ISOs I have, I can't switch them anymore with ctrl-f4 once drive D is accessed for the first time.
SA1988
Member
 
Posts: 184
Joined: 2013-7-16 @ 21:09

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-10-23 @ 07:53

[quote="gulikoza"]IDE should call INT76 at the completion of a disk operation and in Bochs BIOS int76 calls int15 ax=9100h. Is this hooked by the ESDI driver?[/quote]

INT 15h AX=0x9100 is the AT device POST callback. I doubt it hooks it, but when I get around to it, I'll code in default IRQ handlers for IDE that call INT 15h that way for completeness.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2013-10-23 @ 08:05

Hi guys, sorry for the long delay.

I still haven't quite cracked Windows 95, so to better develop the IDE emulation I went ahead and set up a Windows 3.11 Windows for Workgroups VM and developed it against the WDCTRL driver mentioned in this forum some pages ago. It turns out that among the piles of CDs I've collected over the years, I have a copy of the Windows 3.1 DDK and the source code for WDCTRL is included, which confirms what the WDCTRL article is talking about. One afternoon later, I succeeded in getting 32-bit disk access enabled in WfW and getting it to work with DOSBox-X.

Hopefully this is one step closer to getting 32-bit disk access working with Windows 95.

I will post the updated source code to the branch this weekend when I have more time.

Changes:
- IDE emulation: added entry points for BIOS INT 13h emulation which allows IDE emulation to "track" the state changes that would occur if the BIOS were actually talking to the controller. That means that if you issue INT 13h AH=0x00, the IDE controller code acts as if you sent DEVICE RESET, and if you issue INT 13h AH=0x02 (read disk), the IDE code changes it's registers to act like the BIOS had issued a READ SECTOR command. These commands are vital to get DOSBox-X to work with the WfW WDCTRL driver because WDCTRL expects to issue INT 13h and then read back the same sector numbers from the IDE registers.
- BIOS INT 13h emulation: Added "reserved cylinders" setting. By default this is zero, but if you want to make a bootable hard disk that is compatible with WDCTRL and Windows 3.11, you can specify a parameter with imgmount to specify how many "reserved" cylinders to emulate when INT 13h AH=8 GET GEOMETRY is called.
- IMGMOUNT command addition: if you want to emulate a hard disk where INT 13h counts "reserved cylinders" against the total, you can pass -reservecyl <X> to set that parameter. Most common use would be -reservecyl 1 for Windows 3.11 32-bit disk access driver WDCTRL.

Also taken from the Daum DOSBox-X branch:
- Voodoo emulation (software only)
- NE2000 emulation
- "goldplay" as an option (instead of always on as my original code did it)
- Pentium MMX core

Some code has been removed, because I intend to do some refactoring of the DOSBox-X code to clean it up a little bit.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest