freezes when not emulating CPU (was: MIDI input patch)

freezes when not emulating CPU (was: MIDI input patch)

[x.zupftom]

There is another problem with Score that only occurs when the CPU is not emulated.  I have a workaround now, but it would certainly still be good to spot the problem.  Maybe the two problems are related?

This time the problem occurs in some situations when switching from text to graphics mode.  Sometime Score freezes, just like when trying to get into input mode a second time.  

I ran 
  dosemu -D+v -input 'd:\\scor4\\scor4\r\^[1 1\r\F1;'
With F1 a help text is called and the display is set to "console mode" or however you would call it.  Then I manually pressed escape (because \^[ for some reason was not recognized as escape key).  The screen returns to graphics mode and results in a freeze when run natively.  The screen isn't fully redrawn yet at this point.  Score manages to write some text in "DOS font" at the bottom of the screen and redraws all the music, but fails to write missing "DOS text" at the top of the screen.

I thought this might have something to do with video.  However, I did a diff to the logs and there is hardly any difference, only some update_graphics_screen messages at different places - I guess this is normal.

If anyone wants to investigate this further, I am happy to help as good as I can.

Thomas W.
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: freezes when not emulating CPU (was: MIDI input patch)

[x.zupftom]

Hi all,

Stas Sergeev has once more offered his help offlist, and he's again done a great job.  It turned out that my problems were FPU related.  Stas worked out the patch below to fix them.  The patch has been tested without problems in every day use on two machines so far, on a Pentium III ThinkPad and in a virtual Linux box in VMware on a Mac.

And here is the patch.  I hope it's good for application to the trunk.




Index: src/include/memory.h
===================================================================
--- src/include/memory.h	(revision 1905)
+++ src/include/memory.h	(working copy)
@@ -118,6 +118,10 @@
 #define INT70_OFF	0x63f0
 #define INT70_ADD	((INT70_SEG << 4) + INT70_OFF)
 
+#define INT75_SEG	ROMBIOSSEG
+#define INT75_OFF	0x7f00
+#define INT75_ADD	((INT75_SEG << 4) + INT75_OFF)
+
 #define INT1E_SEG	ROMBIOSSEG
 #define INT1E_OFF	0x6fc7
 #define INT41_SEG	ROMBIOSSEG
Index: src/base/bios/setup.c
===================================================================
--- src/base/bios/setup.c	(revision 1905)
+++ src/base/bios/setup.c	(working copy)
@@ -127,16 +127,13 @@
   SETIVEC(0x1e, INT1E_SEG, INT1E_OFF);
   SETIVEC(0x41, INT41_SEG, INT41_OFF);
   SETIVEC(0x46, INT46_SEG, INT46_OFF);
-
-  /* This is an int e7 used for FCB opens */
-  SETIVEC(0xe7, INTE7_SEG, INTE7_OFF);
-  /* End of int 0xe7 for FCB opens */
-
+  SETIVEC(0x75, INT75_SEG, INT75_OFF);
 #ifdef IPX
   /* IPX. Dummy but should not crash */
   if (config.ipxsup)
     SETIVEC(0x7a, BIOSSEG, INT_OFF(0x7a));
 #endif
+  SETIVEC(0xe7, INTE7_SEG, INTE7_OFF);
 
   /* Install new handler for video-interrupt into bios_f000_int10ptr,
    * for video initialization at f800:4200
Index: src/base/bios/bios.S
===================================================================
--- src/base/bios/bios.S	(revision 1905)
+++ src/base/bios/bios.S	(working copy)
@@ -947,7 +947,18 @@
 	iret				/* return to interrupted code	*/
 	.globl  CISH(INT08_dummy_end)
 CISH(INT08_dummy_end):
-        
+
+/* ----------------------------------------------------------------- */   
+	.org	((INT75_SEG-BIOSSEG) << 4)+INT75_OFF
+/* ======================= Addr = F800:7F00 (FFF00) */
+	xorb %al, %al
+	outb %al, $0xf0
+	movb $0x20, %al
+	outb %al, $0xa0
+	outb %al, $0x20
+	int $2		/* bochs does this */
+	iret
+
 /* COMPAS FFEF3		vector table for INT08-INT1F */
 /* COMPAS FFF23		vector table for INT70-INT77 */
 /* COMPAS FFF33-FFF53	reserved */
Index: src/base/dev/sb16/dspio.c
===================================================================
--- src/base/dev/sb16/dspio.c	(revision 1905)
+++ src/base/dev/sb16/dspio.c	(working copy)
@@ -288,7 +288,6 @@
 {
     int dma_cnt, fifo_cnt;
     unsigned long long time_dst;
-    double period;
     Bit16u buf;
 
     dma_cnt = fifo_cnt = 0;
@@ -298,7 +297,6 @@
 	state->dma.stereo = sb_dma_samp_stereo();
 	state->dma.rate = sb_get_dma_sampling_rate();
     }
-    period = pcm_samp_period(state->dma.rate, state->dma.stereo + 1);
 
     while (state->output_running && (state->output_time_cur <= time_dst ||
 				     fifo_cnt % (state->dma.stereo + 1))) {
@@ -321,7 +319,8 @@
 						     samp_signed),
 				      state->dma_strm);
 	    }
-	    state->output_time_cur += period;
+	    state->output_time_cur += pcm_samp_period(state->dma.rate,
+		    state->dma.stereo + 1);
 	    fifo_cnt++;
 	} else {
 	    if (!sb_dma_active()) {
@@ -359,7 +358,8 @@
 	    dspio_run_dma(&state->dma);
 	    dma_cnt++;
 	}
-	state->input_time_cur += period;
+	state->input_time_cur += pcm_samp_period(state->dma.rate,
+		state->dma.stereo + 1);
 	fifo_cnt++;
     }
 
@@ -368,9 +368,9 @@
 	    dspio_fill_output(state);
 
     if (fifo_cnt || dma_cnt)
-	S_printf("SB: Processed %i FIFO, %i DMA, or=%i dr=%i time=%lli period=%f\n",
+	S_printf("SB: Processed %i FIFO, %i DMA, or=%i dr=%i time=%lli\n",
 	     fifo_cnt, dma_cnt, state->output_running, state->dma.running,
-	     time_dst, period);
+	     time_dst);
 }
 
 static void dspio_process_midi(void)
Index: src/arch/linux/async/sigsegv.c
===================================================================
--- src/arch/linux/async/sigsegv.c	(revision 1905)
+++ src/arch/linux/async/sigsegv.c	(working copy)
@@ -110,6 +110,7 @@
 		 return 0;
 
       case 0x10: /* coprocessor error */
+		 print_exception_info(scp);
 		 pic_request(PIC_IRQ13); /* this is the 386 way of signalling this */
 		 return 0;
 
@@ -252,7 +253,7 @@
 
     int retcode;
     if (_trapno == 0x10) {
-      g_printf("coprocessor exception, calling IRQ13\n");
+      print_exception_info(scp);
       pic_request(PIC_IRQ13);
       dpmi_return(scp);
       return -1;
Index: src/emu-i386/cpu.c
===================================================================
--- src/emu-i386/cpu.c	(revision 1905)
+++ src/emu-i386/cpu.c	(working copy)
@@ -235,6 +235,56 @@
   REG(eflags) = 0;
 }
 
+#if 0
+static void fpu_init(void)
+{
+#ifdef __x86_64__
+  vm86_fpu_state.cwd = 0x037F;
+  vm86_fpu_state.swd = 0;
+  vm86_fpu_state.ftw = 0xFFFF;	// bochs
+#else
+  vm86_fpu_state.cw = 0x40;
+  vm86_fpu_state.sw = 0;
+  vm86_fpu_state.tag = 0xFFFF;	// bochs
+#endif
+}
+#endif
+
+static void fpu_reset(void)
+{
+#ifdef __x86_64__
+  vm86_fpu_state.cwd = 0x0040;
+  vm86_fpu_state.swd = 0;
+  vm86_fpu_state.ftw = 0x5555;	//bochs
+#else
+  vm86_fpu_state.cw = 0x40;
+  vm86_fpu_state.sw = 0;
+  vm86_fpu_state.tag = 0x5555;	// bochs
+#endif
+}
+
+static Bit8u fpu_io_read(ioport_t port)
+{
+  return 0xff;
+}
+
+static void fpu_io_write(ioport_t port, Bit8u val)
+{
+  switch (port) {
+  case 0xf0:
+    /* not sure about this */
+#ifdef __x86_64__
+    vm86_fpu_state.swd &= ~0x8000;
+#else
+    vm86_fpu_state.sw &= ~0x8000;
+#endif
+    break;
+  case 0xf1:
+    fpu_reset();
+    break;
+  }
+}
+
 /* 
  * DANG_BEGIN_FUNCTION cpu_setup
  *
@@ -247,11 +297,25 @@
  */
 void cpu_setup(void)
 {
+  emu_iodev_t io_dev;
+  io_dev.read_portb = fpu_io_read;
+  io_dev.write_portb = fpu_io_write;
+  io_dev.read_portw = NULL;
+  io_dev.write_portw = NULL;
+  io_dev.read_portd = NULL;
+  io_dev.write_portd = NULL;
+  io_dev.irq = PIC_IRQ13;
+  io_dev.fd = -1;
+  io_dev.start_addr = 0xf0;
+  io_dev.end_addr = 0xff;
+  io_dev.handler_name = "Math Coprocessor";
+  port_register_handler(io_dev, 0);
+
   int_vector_setup();
 
   cpu_reset();
-
   savefpstate(vm86_fpu_state);
+  fpu_reset();
 
 #ifdef X86_EMULATOR
   if (config.cpuemu) {


______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: freezes when not emulating CPU (was: MIDI input patch)

[Bart Oldeman]

On Wed, Sep 9, 2009 at 3:17 PM,  <x.zupftom@web.de> wrote:
> Stas Sergeev has once more offered his help offlist, and he's again done a great job.  It turned out that my problems were FPU related.  Stas worked out the patch below to fix them.  The patch has been tested without problems in every day use on two machines so far, on a Pentium III ThinkPad and in a virtual Linux box in VMware on a Mac.
>
> And here is the patch.  I hope it's good for application to the trunk.

I applied the patch in SVN (1946,1947) with some small modifications
(move the int75 handler position in the BIOS, and disabled the part
that prints exception info for the non-fatal scenario that an FPU
exception happens -- I guess that was just meant for debugging).

Thanks (to Stas also),
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: freezes when not emulating CPU (was: MIDI input patch)

[x.zupftom]

Thanks!


> -----Ursprüngliche Nachricht-----
> Von: "Bart Oldeman" <bartoldeman@users.sourceforge.net>
> Gesendet: 11.09.09 04:56:49
> An:  dosemu <linux-msdos@vger.kernel.org>
> Betreff: Re: freezes when not emulating CPU (was: MIDI input patch)


> On Wed, Sep 9, 2009 at 3:17 PM,  <x.zupftom@web.de> wrote:
> > Stas Sergeev has once more offered his help offlist, and he's again done a great job.  It turned out that my problems were FPU related.  Stas worked out the patch below to fix them.  The patch has been tested without problems in every day use on two machines so far, on a Pentium III ThinkPad and in a virtual Linux box in VMware on a Mac.
> >
> > And here is the patch.  I hope it's good for application to the trunk.
> 
> I applied the patch in SVN (1946,1947) with some small modifications
> (move the int75 handler position in the BIOS, and disabled the part
> that prints exception info for the non-fatal scenario that an FPU
> exception happens -- I guess that was just meant for debugging).
> 
> Thanks (to Stas also),
> Bart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: freezes when not emulating CPU (was: MIDI input patch)

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
 > exception happens -- I guess that was just meant for debugging).
 > Thanks (to Stas also),
The "SB16 fixes from Stas Sergeev via x.zupftom@web.de on linux-msdos."
is actually also the related FPU fix.
There was a division by zero there in
pcm_samp_period() (when called without
the necessary checks), which I became
aware of, because it started to produce
SIGFPE when I played with vm86_fpu_state
struct. Which means that the comment in
do_vm86.c about fnsave is wrong, and the
code that restores the dosemu FPU state
should likely to be returned. You can,
for example, memset the vm86_fpu_state
to 0 in fpu_reset() and see the SIGFPE
coming from all around the sound code
(no other code use FPU in dosemu).
Also, I found no docs about this FPU
init/reset stuff, so everything in this
patch is just a wild guesses based on
a look into a bochs code.
Also, there is a need to add the handling
for exception 0x13 (SIMD FPE), which is
what the SIGFPE is about today. I mean,
at least print_exception_info() should
write something meaningfull about SIGFPE
instead of "Unknown exception".
So I guess this patch needs more work,
but it should be harmless in its current
form too.

Re: freezes when not emulating CPU (was: MIDI input patch)

[Bart Oldeman]

Hello Stas,

> Which means that the comment in
> do_vm86.c about fnsave is wrong, and the
> code that restores the dosemu FPU state
> should likely to be returned. You can,
> for example, memset the vm86_fpu_state
> to 0 in fpu_reset() and see the SIGFPE
> coming from all around the sound code
> (no other code use FPU in dosemu).

I've been looking at this. The SIGFPEs don't happen for i386 (default
FP), only for x86-64 or when explicitly compiling with SSE floating
point (using gcc -msse2 -mfpmath=sse). The "fnsave" instruction really
re-initializes the FPU (it's documented), but with SSE one needs to
use "fxsave" and "fninit", and that still doesn't reinitialize the
SIMD part. Adding an "ldmxcsr" instruction solved that problem.

I still think that a simple FPU environment reset is sufficient, no
need to restore all the registers, because the DOSEMU FPU code is not
interrupted by DOS code.

The fpu save/restore operations aren't cheap, so perhaps one could
only use them around the sound code instead of for every vm86 call.
Though that could be messy.

> Also, I found no docs about this FPU
> init/reset stuff, so everything in this
> patch is just a wild guesses based on
> a look into a bochs code.
> Also, there is a need to add the handling
> for exception 0x13 (SIMD FPE), which is
> what the SIGFPE is about today. I mean,
> at least print_exception_info() should
> write something meaningfull about SIGFPE
> instead of "Unknown exception".

I've done that now.

Bart

Re: freezes when not emulating CPU (was: MIDI input patch)

[Frank Cox]

On Mon, 14 Sep 2009 09:05:25 -0400
Bart Oldeman wrote:

> I still think that a simple FPU environment reset is sufficient, no
> need to restore all the registers, because the DOSEMU FPU code is not
> interrupted by DOS code.

Is there any chance that this issue is related to the bug I describe here:

http://markmail.org/message/bxdsyrzn6cd63fv3

I'm asking because my experimentation with Powerbasic seems to indicate that it
has something to do with the DEFINT A-Z directive in the program written in
Powerbasic -- if I remove that directive it works.  So it may be related to the
integer variable handling somehow?

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com