VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 80 of 2397, by beard

User metadata
Rank Newbie
Rank
Newbie

Maybe that's the way:

keyboard.cpp:

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

Reply 81 of 2397, by beard

User metadata
Rank Newbie
Rank
Newbie

I also found something strange in keyboard.cpp

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

In my opinion it should be:

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

Reply 82 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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. […]
Show full quote

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.

/* 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?

Reply 83 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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 […]
Show full quote

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.

Reply 84 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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, […]
Show full quote

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

Reply 85 of 2397, by danoon

User metadata
Rank Member
Rank
Member

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.

http://www.boxedwine.org/

Reply 86 of 2397, by masaykh

User metadata
Rank Newbie
Rank
Newbie

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)

Reply 87 of 2397, by danoon

User metadata
Rank Member
Rank
Member

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.

http://www.boxedwine.org/

Reply 88 of 2397, by telanus

User metadata
Rank Newbie
Rank
Newbie

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

Reply 89 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
telanus wrote:
I know I'm nit-picking here […]
Show full quote

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.

Reply 90 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 91 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
masaykh wrote:
i almost succeded to run linux in dosbox. […]
Show full quote

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.

Reply 93 of 2397, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Moved to the patches forum DOSBox Patches

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 94 of 2397, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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 😁) - 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 😀) 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:

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 😉). 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...

Attachments

  • Filename
    dosbox_bochs-bios.diff
    File size
    6.32 KiB
    Downloads
    97 downloads
    File license
    Fair use/fair dealing exception

http://www.si-gamer.net/gulikoza

Reply 96 of 2397, by truth_deleted

User metadata

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/iosguide95_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.

Reply 98 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

[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.

Reply 99 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.