Re: 1.1.5.1-5 regressions and other bugs

Re: 1.1.5.1-5 regressions and other bugs

[Stas Sergeev]

Hello.

Vedran Rodic wrote:
> Quake (I use 1.08) doesn't have sound anymore.
Is it possible to see a -D9+S log?
Would be better to open a bug-report on SF.

> I've tried that uses the mouse. Turning of the mouse input support 
> helps
Have you set $_hogthreshold=(0) ?

Re: 1.1.5.1-5 regressions and other bugs

[Vedran Rodic]

On Thu, Jul 17, 2003 at 07:52:24PM +0400, Stas Sergeev wrote:
> Hello.
> 
> Vedran Rodic wrote:
> >Quake (I use 1.08) doesn't have sound anymore.
> Is it possible to see a -D9+S log?
> Would be better to open a bug-report on SF.
 
Sure. It's at http://quark.fsb.hr/vedran/dosemu/boot.log.bz2


> >I've tried that uses the mouse. Turning of the mouse input support 
> >helps
> Have you set $_hogthreshold=(0) ?

I've tried now. It cures the problem. I've read about Mouse Garrot. Is there
a way to disable it? Is there a way to disable internal dosemu mouse driver
and use mouse.com in xdosemu? 


Vedran

Re: 1.1.5.1-5 regressions and other bugs

[Stas Sergeev]

Hello.

Robert Komar wrote:
> I'm curious as to why mouse events have this effect but 
> keyboard events don't.  I'm constantly hitting keys when 
> the slowdown occurs, but it takes a mouse event to break 
> out of it.  Is there something special about mouse 
> events?
That's how the hogthreshold code works.
When the program is polling the keyboard
and there are no keypresses, dosemu gives
up the CPU time. When the program is polling
the mouse and the mouse is inactive (you are
not moving it), same thing happens. dosemu
is not aware that you are targeting at a
monster so it is not an appropriate time to
release the CPU. Just disable the hogthreshold
for that.
Well, it happens that such a heuristic works
remarkably perfect with keyboard, but not with
the mouse. The solution I can think of, is to
make hogthreshold configurable separately for
keyboard, mouse and all other things and make
it disabled by default for mouse but not for
keyboard. There was someone wolunteering to do
that change but this didnt happen yet.

> I saw that the dosemu SB emulator had a sampling rate of 
> 11000 Hz, while I had Duke3D setup to use 44000 Hz.
You might be too lucky - my Duke's setup doesn't
allow me to set the rate above 22KHz even if
I choose AWE32 (setup version is 1.3D). I guess
you are either cheating your setup somehow
(probably with an incorrect settings of a
BLASTER var?) or maybe your setup program is newer?

> If this sounds like the sort of problem that many others 
> might have
Probably you are alone with that as normally
Duke's setup doesn't permit such a rate (for me
at least).

Re: 1.1.5.1-5 regressions and other bugs

[Stas Sergeev]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

Hello.

Robert Komar wrote:
> The times between the slowdowns would get longer as I
> increased the hogthreshold, but would never go away
> entirely.  Is this expected or a bug?
I guess the "bug" is too rough definition
for such a small issue.
Anyway the attached patch will probably make
it a bit better.
Does it help?

[-- Attachment #2: m_sleep.diff --]
[-- Type: text/plain, Size: 650 bytes --]

--- src/base/async/int.c	Thu Jul 17 20:48:51 2003
+++ src/base/async/int.c	Fri Jul 18 20:17:04 2003
@@ -1790,9 +1790,10 @@
 /* Ok now we test to see if the mouse has been taking a break and we can let the 
  * system get on with some real work. :-) */
    if (trigger1 >= config.hogthreshold*200) {
-     if (config.hogthreshold && CAN_SLEEP() && ++trigger >= config.hogthreshold)  {
+     if (config.hogthreshold && CAN_SLEEP() &&
+        trigger++ > (config.hogthreshold - 1) * 20)  {
        m_printf("Ignoring the quiet mouse.\n");
-       usleep(INT2F_IDLE_USECS);
+       usleep(INT15_IDLE_USECS);
        trigger=0;
      }
      trigger1--;

Re: 1.1.5.1-5 regressions and other bugs

[Robert Komar]

On Fri, 18 Jul 2003, Stas Sergeev wrote:

> Robert Komar wrote:
> > The times between the slowdowns would get longer as I
> > increased the hogthreshold, but would never go away
> > entirely.  Is this expected or a bug?
> I guess the "bug" is too rough definition
> for such a small issue.

It's not so small when you're trying to aim at targets
that are moving around ;).

> Anyway the attached patch will probably make
> it a bit better.
> Does it help?

It does help.  The problem is still there, in that there
are short slowdowns in the game, but it is an improvement
over the old code, where the game was unplayable unless the
mouse was moved.

I'm curious as to why mouse events have this effect but
keyboard events don't.  I'm constantly hitting keys when
the slowdown occurs, but it takes a mouse event to break
out of it.  Is there something special about mouse events?


I would have responded to this sooner but while testing, I
noticed that the sound was choppy.  The choppiness didn't
go away when I applied the patch, so I figured that it
was an unrelated matter.  Testing old versions of dosemu
showed that the choppiness started in version 1.1.5.1
(i.e. when the new SB16 code went in).  After a fair
bit of fooling around and looking at debug output, I saw
that the dosemu SB emulator had a sampling rate of 11000 Hz,
while I had Duke3D setup to use 44000 Hz.  Re-configuring
Duke3D for 11000 Hz sampling rate fixed the choppiness.
If this sounds like the sort of problem that many others
might have, perhaps it should be mentioned in the section
on "Configuring the Applications" in sound-usage.txt.

Cheers,
Rob Komar

Re: 1.1.5.1-5 regressions and other bugs

[Stas Sergeev]

Hello.

Vedran Rodic wrote:
>> #define DMA_EXCESSIVE_DEBUG in a dma.c and do the
>> -D9+Sh log?
> Sure. http://quark.fsb.hr/vedran/dosemu/boot_dma.log.bz2
There is something wrong here.
The program is programming the DMA channel 1
but is trying to use a 16-bit output.
I highly suspect your program is misconfigured.
In particular please double-check the DMA
settings in program's setup and in a BLASTER
environment variable.
Perhaps you forgot to update your BLASTER var
for the newly added SB16 support which is why
the SB used to work for you previously (only
adding T6 is not sufficient).

Re: 1.1.5.1-5 regressions and other bugs

[Vedran Rodic]

On Sat, Jul 19, 2003 at 12:11:22PM +0200, Vedran Rodic wrote:
> On Fri, Jul 18, 2003 at 08:09:39PM +0400, Stas Sergeev wrote:
> > Perhaps you forgot to update your BLASTER var
> > for the newly added SB16 support which is why
> > the SB used to work for you previously (only
> > adding T6 is not sufficient).
> 
> You're right. I didn't set 16bit DMA. Sorry for your lost time. 
> 
> Vedran

Re: 1.1.5.1-5 regressions and other bugs

[Stas Sergeev]

Hello.

Vedran Rodic wrote:
>> Is it possible to see a -D9+S log? Would be better to 
>> open a bug-report on SF.
> Sure. It's at 
> http://quark.fsb.hr/vedran/dosemu/boot.log.bz2
Hmm. DMA doesn't even start...
Could you please uncomment the
#define DMA_EXCESSIVE_DEBUG
in a dma.c and do the -D9+Sh log?

> Is there a way to disable internal dosemu mouse driver 
> and use mouse.com in xdosemu?
Practically no. You have to either plug
in a second mouse or configure your X to
not use the mouse. There should not be
multiple users for the single device, and
X server is already owning it.
You can use mouse.com under a console dosemu
however.
But what's the use? If you are unhappy with
a performance setting the $_hogthreshold=(0),
set it to another value, like 10, 50 etc.

Re: 1.1.5.1-5 regressions and other bugs

[Vedran Rodic]

On Thu, Jul 17, 2003 at 09:58:07PM +0400, Stas Sergeev wrote:
> Hello.
> 
> Vedran Rodic wrote:
> >>Is it possible to see a -D9+S log? Would be better to 
> >>open a bug-report on SF.
> >Sure. It's at 
> >http://quark.fsb.hr/vedran/dosemu/boot.log.bz2
> Hmm. DMA doesn't even start...
> Could you please uncomment the
> #define DMA_EXCESSIVE_DEBUG
> in a dma.c and do the -D9+Sh log?
> 

Sure.
http://quark.fsb.hr/vedran/dosemu/boot_dma.log.bz2

> You can use mouse.com under a console dosemu
> however.
> But what's the use? If you are unhappy with

I have an obscure game that wants to use a 'newer' version of mouse than
dosemu reports/implements. I thought this would be easy fix if dosemu
implemented some kind of generic serial mouse emulation that mouse.com code 
could talk to.


Vedran

Re: 1.1.5.1-5 regressions and other bugs

[Robert Komar]

On Thu, 17 Jul 2003, Stas Sergeev wrote:

> ... If you are unhappy with
> a performance setting the $_hogthreshold=(0),
> set it to another value, like 10, 50 etc.

I've tried playing Duke3D under dosemu with a
non-zero hogthreshold setting and always had
problems in the past.  I prefer playing with
the keyboard only, and sooner or later the
the framerate would suddenly drop drastically
(~ 1 frame per second) until I moved the mouse.
Then all would go back to normal for a while.
The times between the slowdowns would get longer
as I increased the hogthreshold, but would never
go away entirely.  Is this expected or a bug?

Speaking of Duke3D, I find that games that were
saved with older versions of dosemu (even 1.1.4)
usually start when running under newer versions,
but are very unstable.  Playing from a fresh start
works fine.  Again, is this expected or a bug?

Cheers,
Rob Komar

1.1.5.1-5 regressions and other bugs

[Vedran Rodic]

Hi. 


I've tested 1.1.5.5 and 1.1.5.1:

Quake (I use 1.08) doesn't have sound anymore. It says it detects and initializes
the device, but no sound is coming out. This stopped working in 1.1.5.1. 

Setting the BLASTER T variable doesn't help. 

Quake seems to get jerky somewhere after 1.1.5.1. I suspect that the mouse
code change in 1.1.5.3 has something to do with it, since the gameplay is
not jerky when I use the mouse for control, and I've experienced the same
issue in other games on older 1.1 versions.

BTW this (jerky game execution) is very annoying and happens in every game
I've tried that uses the mouse. Turning of the mouse input support helps
cure the problem but that's not possible in all games. It would be nice if
this got fixed before 1.2

Thanks
Vedran

Re: 1.1.5.1-5 regressions and other bugs

[Bart Oldeman]

On Wed, 16 Jul 2003, Vedran Rodic wrote:

> Quake seems to get jerky somewhere after 1.1.5.1. I suspect that the mouse
> code change in 1.1.5.3 has something to do with it, since the gameplay is
> not jerky when I use the mouse for control, and I've experienced the same
> issue in other games on older 1.1 versions.

The mouse related patch really shouldn't do this -- it just doesn't "warp"
the X mouse cursor if it's outside the "DOS in a BOX".

but I highly suspect Stas' 1.1.5.5 DPMI change (technical detail: int33 is
"REVECT"ored, which was previously ignored in certain DPMI cases).
You might want to (from dosemu 1.1.5.5)

tar xzvf patchset-1.1.5.5.tgz
patch -p1 -R < tmp/patch-1.1.5.5
rm -rf tmp

and see if that's really the one.
Stas' patch is correct though -- it makes the int behaviour for DPMI apps
consistent with real mode apps.

Only the following comment (in src/base/async/int.c) leaves me wondering a
bit:

/* Firstly do the actual mouse function. */
/* N.B. This code only works with the intdrv since default_interrupt() does not
 * actually call the real mode mouse driver now. (It simply sets up the registers so
 * that when the signal that we are currently handling has completed and the kernel
 * reschedules dosemu it will then start executing the real mode mouse handler). :-(
 * Do we need/have we got post_interrupt (IRET) handlers?
 */
/* We have post_interrupt handlers in dpmi --EB 28 Oct 1997 */

-- esp the comment from Eric Biederman. oh well I might have a closer look
this weekend.

Bart