DOS ain't dead

Hello,

Qemu supports an UDMA Busmaster IDE controller. However, due to a BIOS limitation, the current X drivers (XDMA, XDMA32, XCDROM, XCDROM32) don't recognize it. This gives DOS running inside Qemu a disadvantage compared to Windows or Linux. Therefore a new option /P has been added to XDMA32/XCDROM32 to set the vendor and device ID of the Busmaster IDE controller. This allows to overcome the BIOS restriction and gives DOS in Qemu a speed boost for disk + dvd i/o.

How to use it?

1. download the modified X JLMs from XJLM.ZIP
2. add the /P option to XDMA32/XCDROM32 in CONFIG.SYS:
DEVICE=JLOAD.EXE XDMA32.DLL /P:80867010 /F
DEVICE=JLOAD.EXE XCDROM32.DLL /P:80867010 /F

the /P option needs a parameter, which is the vendor (8086) and device ID (7010) of the Qemu IDE controller.

Other Changes:

1. There has been a bug fixed in XDMA32. The previous version didn't work with devices attached to the secondary IDE channel!

2. The /F option: This was the /UF option in the last versions of XDMA32/XCDROM32, but has been changed to /F.

Please be aware that the binaries in the XJLM.ZIP package are preliminary.

---
MS-DOS forever!

As only registered users can post here, Jack has asked me to post his following note:

"Intel, VIA or other chipset makers do not discuss 'errata' except with mainboard vendors. One is that a few older chipsets CANNOT handle /F or /UF. As full data is 'unavailable', UIDE and prior drivers have used no such switches since 2006. They and /O must NOT be viewed as 100% reliable for all mainboards or DOS systems."

> "Intel, VIA or other chipset makers do not discuss 'errata' except with
> mainboard vendors. One is that a few older chipsets CANNOT handle /F or
> /UF. As full data is 'unavailable', UIDE and prior drivers have used no
> such switches since 2006."

Translation: Some switches do not work with all (old) hardware, therefore are not available for any (new) hardware.

> "They and /O must NOT be viewed as 100% reliable for all mainboards or DOS systems."

If 100% reliabiltiy with all hardware/systems is a requirement, then every device driver is garbage.

> "Intel, VIA or other chipset makers do not discuss 'errata' except with
> mainboard vendors. One is that a few older chipsets CANNOT handle /F or
> /UF. As full data is 'unavailable', UIDE and prior drivers have used no
> such switches since 2006. They and /O must NOT be viewed as 100% reliable
> for all mainboards or DOS systems."

There is an appropriate note already in the readme. Inside Qemu, /F works.

---
MS-DOS forever!

> Please be aware that the binaries in the XJLM.ZIP package are preliminary.

More peas to count for me:

GNU_GPL.TXT should have this address:

> Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
> 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

VirtualBox is based on Qemu. It uses a different BIOS which apparently hasn't Qemu's problem and allows to find the UDMA IDE controller without using XDMA32/XCDROM32's /P option. However, there's a problem with DMA in VirtualBox v1.52. I could only run XDMA32 reliable when using the new /B switch, which causes all reads to use the XMS buffer. Speed boost is still significant, fortunately (> 200%). Sample:

DEVICE=C:\JLOAD.EXE XDMA32.DLL /B


MS's VirtualPC 2007 is also somewhat strange. It's IDE controller supports DMA, but not UDMA. Therefore, to use XDMA32 and XCDROM32, one has to use the new /W switch, which allows the drivers to accept devices capable of "Multiword"-DMA only. For XDMA32, the speed increase is not significant (about 10%-15%), but using XCDROM32 with /W option boosts speed more than 100%. Sample:

DEVICE=C:\JLOAD.EXE XCDROM32.DLL /W

(use the drivers found in XJLM.ZIP)

---
MS-DOS forever!

What about Bochs?

I could provide much faster binaries (~40% compared to Bochs 2.3.5) built from CVS code.

---
Forum admin

> I could provide much faster binaries (~40% compared to Bochs 2.3.5) built
> from CVS code.

Is the boring "qemu images" bug fixed there? As long as this bug persists, I will DEFINITELY ignore Bochs.

The older versions (v2.3 and below) BIOSes (64 kB) don't support UDMA.

---
MS-DOS forever!

> Is the boring "qemu images" bug fixed there?

How? You or the original poster didn't submit further information.

> The older versions (v2.3 and below) BIOSes (64 kB) don't support UDMA.

Yes, I know.

---
Forum admin

> > Is the boring "qemu images" bug fixed there?
>
> How? You or the original poster didn't submit further information.

This is not just a "Qemu related" bug. If I create a "standard" C.IMG HD image with bximage and then install MS-DOS 7.1 on it with "sys c:", Bochs v2.35 reports error "LBA out of range" during the boot process when I boot from disk. I somehow doubt that the bug is in the MS-DOS HD boot sector and ... Bochs v2.3 works.

So there is a severe regression in v2.35 and apparently noone cares.

---
MS-DOS forever!

> This is not just a "Qemu related" bug. If I create a "standard" C.IMG HD

Which size? I'd like to verify that here.

> So there is a severe regression in v2.35 and apparently noone cares.

Let's see.

---
Forum admin

> > This is not just a "Qemu related" bug. If I create a "standard" C.IMG HD
>
> Which size? I'd like to verify that here.
>

It's "standard", that is, I always took the values suggested by the prog.

[edit]
btw., I just booted v2.35 with a floppy. There IS support in v2.35 for UDMA now (apparently for HD only, not for CD, although they are "attached" to the very same controller). I don't know whether it's faster to use XDMA32, though, because the Bochs timer is absolutely unreliable and the image is 10 MB only, too small to count time "manually".
[/edit]

---
MS-DOS forever!

> More peas to count for me:
>
> GNU_GPL.TXT should have this address:
>
> > Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
> > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

Rug, your email is an obvious troll. If you don't have anything of
substance to contribute, don't try to stir up trouble. Please stop
this.

-jp

---
MS-DOS forever!

> > GNU_GPL.TXT should have this address:
> >
> > > Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
> > > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
>
> Rug, your email is an obvious troll. If you don't have anything of

Sorry, but I agree to Rugxulo, because "Franklin Street" is in the official version: http://www.gnu.org/licenses/gpl-2.0.html

---
Forum admin

> > Which size? I'd like to verify that here.
> >
>
> It's "standard", that is, I always took the values suggested by the prog.

I'll have a look later.

> [edit]
> btw., I just booted v2.35 with a floppy. There IS support in v2.35 for
> UDMA now (apparently for HD only, not for CD, although they are "attached"
> to the very same controller). I don't know whether it's faster to use
> XDMA32, though, because the Bochs timer is absolutely unreliable and the
> image is 10 MB only, too small to count time "manually".
> [/edit]

I see, that's pretty bad.

---
Forum admin

> Sorry, but I agree to Rugxulo, because "Franklin Street" is in the
> official version: http://www.gnu.org/licenses/gpl-2.0.html

Sorry, but XDMA32/XCDROM32 contain an unchanged copy of GNU_GPL.TXT of XDMA/XCDROM. So please complain first to the author of these programs. If he agrees, I will change it as well.

---
MS-DOS forever!

> What about Bochs?
>
> I could provide much faster binaries (~40% compared to Bochs 2.3.5) built
> from CVS code.

What was your trick? :)

I don't run Windows, so your binaries wouldn't bee too helpful...

> Sorry, but XDMA32/XCDROM32 contain an unchanged copy of GNU_GPL.TXT of
> XDMA/XCDROM.

I'm not a lawyer, but XDMA32/XCDROM32 is derived from XDMA/XCDROM only. So you are responsible now. You will not change the entire license by adjusting a wrong address.

> So please complain first to the author of these programs.
> If he agrees, I will change it as well.

You know, that Jack abandoned these drivers. So this will not happen until hell freezes over.

---
Forum admin

> What was your trick? :)

Not my trick: http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markup

---
Forum admin

> I'm not a lawyer, but XDMA32/XCDROM32 is derived from XDMA/XCDROM only. So
> you are responsible now. You will not change the entire license by
> adjusting a wrong address.

Changing the address would be breaching the license, though he'd never get in any legal trouble for it.

> Rug, your email is an obvious troll. If you don't have anything of
> substance to contribute, don't try to stir up trouble. Please stop
> this.

Okay, after having read this a few times, I think I understand why you're so wary. But by now you should've known that I'm quite obsessed with keeping updated info everywhere. There is no trouble, I just quite expected you'd easily agree to change the old address (since I assume by now the USPS has stopped forwarding any mail to that old location). Feel free to ignore if you're so inclined.

P.S. This isn't a huge deal since various other GPL software still has the old address. So, I guess many people these days prefer online access over manually writing to the FSF. And the GPL3 doesn't have an address at all! But, for the record, I personally would change it, and no, I don't think anybody would complain about correcting an invalid address. Yes, the license is still valid either way, obviously.

EDIT: I am highly impartial to all of the gripes on this board. No trolling / flaming / arguing here, just wanting everything to be okay and updated. Sorry, but my only interest in this forum is (gasp) DOS.

> So this will not happen until hell freezes over.

I think you are too pessimistic. You might be able to control him, but you are one of the "untrusted" guys, so it won't work to be just straight-forward, because he will always do the opposite of what you are asking him. Knowing this, the strategy is to tell him "occasionally" that you are interested in the license text to be left UNCHANGED. Use your brain and Good luck!

---
MS-DOS forever!

> VirtualBox
> DEVICE=C:\JLOAD.EXE XDMA32.DLL /B

> MS's VirtualPC 2007
> DEVICE=C:\JLOAD.EXE XCDROM32.DLL /W

of course preferred if this would be done automatically

this link
http://www.forum.joebox.org/viewtopic.php?pid=26

gives an idea (and windows code), how to detect QEMU/VMWARE/virtual
PC/Virtual box, and possibly amy more.

basically:
get the 'manufacturer name' of the first hard disk.
check if the drive is named
{"VBOX HARDDRIVE",
"QEMU HARDDISK",
"VMWARE VIRTUAL IDE HARD DRIVE",
"VIRTUAL HD"
}

> check if the drive is named
> {"VBOX HARDDRIVE",
> "QEMU HARDDISK",
> "VMWARE VIRTUAL IDE HARD DRIVE",
> "VIRTUAL HD"
> }

But these names could change. IIRC Bochs allows that via its config files ("model").

---
Forum admin

> > VirtualBox
> > DEVICE=C:\JLOAD.EXE XDMA32.DLL /B
>
> > MS's VirtualPC 2007
> > DEVICE=C:\JLOAD.EXE XCDROM32.DLL /W
>
> of course preferred if this would be done automatically

Maybe this will help (more)??

http://bos.asmhackers.net/forum/viewtopic.php?id=59

> of course preferred if this would be done automatically

It's just an optimization, intended for experienced users. The rest is to stay out.

---
MS-DOS forever!