DOS ain't dead

... and needs hxrtd to run in DOS.

Also, since there is no Win32 binary available yet, I compiled it on my own and experienced a small regression: Commander Keen doesn't recognize the SB card, although the hxrt tool GETSB has no problems to find it. But I just might have made a mistake and forget to activate this and that option when running CONFIGURE.

http://fabrice.bellard.free.fr/qemu/download.html

[edit]
what should be mentioned as well: the bad keyboard emulation hasn't improved in v0.9.1.
[/edit]

---
MS-DOS forever!

> Qemu 0.9.1 is out ...
> what should be mentioned as well: the bad keyboard emulation hasn't
> improved in v0.9.1.

Thanks for sharing ... no point to download it then

> > Qemu 0.9.1 is out ...
> > what should be mentioned as well: the bad keyboard emulation hasn't
> > improved in v0.9.1.

I never had any keyboard trouble ;)

> I never had any keyboard trouble

IIRC it was also only you who confirmed the 40% "speedup" of BOCHS

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> IIRC it was also only you who confirmed the 40% "speedup" of BOCHS

Perhaps I'm the only one who knows how to use a pc :)

> I never had any keyboard trouble ;)

What do you want to tell us with this fact?

There IS a problem with Qemu's keyboard emulation, and the reason isn't unknown. As you surely know, the keyboard controller device regards a read of port 60h as "interrupt acknowledged", allowing it to continue to send data. However, "real" keyboard controllers will wait "some time" until they indeed continue to send. This behavior makes it safe for DOS TSR programs, which have hooked interrupt vector 9, to read port 60h and then call the old interrupt handler (which will repeat the port 60h read access and get the very same data).

Qemu's keyboard emulation, however, lacks this small delay. This causes troubles only if

1. more than 1 program hooked IRQ 1 and reads port 60h AND
2. the keyboard controller has more than 1 byte to send

The second condition is true for "enhanced" keys, which consists of 2 bytes (E0 xx or E1 xx).

The fix is to use a timer to emulate the delay. DosBox shows how it is to be done. However, since this is virtually a problem for DOS guests only, I doubt that we'll see a fix unless it is done by ...

---
MS-DOS forever!

> This behaviour makes it safe for DOS TSR programs, which have hooked
> interrupt vector 9, to read port 60h and then call the old interrupt
> handler (which will > repeat the port 60h read access and get the very same
> data).

Hmm, sounds to me like it's really a bug of any DOS TSR that relies on this rather precarious assumption, especially if it enables interrupts before calling the old handler. Either way, multiple accesses to ports that have "side-effects" like this is always asking for trouble.

> > I never had any keyboard trouble ;)
>
> What do you want to tell us with this fact?

The response wasn't directed at you - but rather at DOS386, who's post was suggesting it wasn't worth downloading simply because of a small keyboard issue :P

> Hmm, sounds to me like it's really a bug of any DOS TSR that relies on
> this rather precarious assumption, especially if it enables interrupts
> before calling the old handler. Either way, multiple accesses to ports
> that have "side-effects" like this is always asking for trouble.

You can define it as bugs in DOS TSRs, but these TSRs are unlikely to be adjusted. Also, it was and still IS stable to do such hooks in real machines. (Of course, enabling interrupts BEFORE calling the old handler would be a bug, but nobody was talking about that).

btw., it's not just TSRs which hook IRQ 1. MS Scandisk does as well, for example.

---
MS-DOS forever!

> Also, since there is no Win32 binary available yet, I compiled it on my
> own and experienced a small regression: Commander Keen doesn't recognize
> the SB card, although the hxrt tool GETSB has no problems to find it. But
> I just might have made a mistake and forget to activate this and that
> option when running CONFIGURE.

I briefly browsed the online QEMU forum, and it seems someone has compiled a Win32 version for us (though I haven't tried it yet, caveat emptor):

http://hpoussineau.free.fr/qemu/

qemu-0.9.1-windows.zip    06-Jan-2008 22:23   1.7M
qemu-0.9.1-windows-2.zip  08-Jan-2008 14:24   7.5M

---
Know your limits.h

> Also, since there is no Win32 binary available yet, I compiled it on my
> own and experienced a small regression: Commander Keen doesn't recognize
> the SB card, although the hxrt tool GETSB has no problems to find it. But
> I just might have made a mistake and forget to activate this and that
> option when running CONFIGURE.

I also compiled my own QEMU binary and tried the Commander Keen 4 demo. Don't know about sound, but music works. (I already configured with '--enable-adlib'.)

Does Keen's configuration screen look OK for you? Mine shows some artefacts.

I noticed a very annoying white jitter while playing, but it vanishes, when I turn "SVGA compatibility" in the options menu off on.

> [edit]
> what should be mentioned as well: the bad keyboard emulation hasn't
> improved in v0.9.1.
> [/edit]

Is it hard to fix (for you)?

---
Forum admin

> I also compiled my own QEMU binary and tried the Commander Keen 4 demo.
> Don't know about sound, but music works. (I already configured with
> '--enable-adlib'.)

This might be the reason why SBGET finds the SB card (at port 220h), but Keen sound doesn't work because the Adlib port is 38xh.

> Does Keen's configuration screen look OK for you? Mine shows some
> artefacts.

I didn't notice any.

> Is it hard to fix (for you)?

It's not annoying enough to invest time. I also tried setting "SDL_VIDEODRIVER=windib", which improves keyboard handling a lot, but OTOH has problems with the screen update (at least in text mode emulation). Regrettably there is no option to tell SDL to use DirectX for output and "WinDib" for input.

---
MS-DOS forever!