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

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

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> 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).
OK, but the point is that I haven't specified
these flags by hands, so they might be a default
for dosemu right now. So it have to became sse-safe.

> The "fnsave" instruction really
> re-initializes the FPU (it's documented),
I know it does, but the comment I was referring to,
also says:
---
which is good enough for calling FPU-using routines.
---
and that appeared to be false.

> but with SSE one needs to
> use "fxsave"
Hmm, why does'n it use fxsave right now?

> and "fninit", and that still doesn't reinitialize the
> SIMD part. Adding an "ldmxcsr" instruction solved that problem.
I guess this might be a good work-around, at
least till they invent yet another FP technique. :)

> 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.
What if the DOS code (by some crazy chance) also
uses sse?

> 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.
Indeed - so what was the problem with fninit/ldmxcsr then?
Looks like it would load only the control/status word, so
that might not be as expensive as the full reload?
Also, I think fxrstor doesn't wait for completion, so
the careful implementation may not be too expensive.
There are also some tricks possible, like, for example, set
FPU to something that will SIGFPE on any FP, and initialize
it properly in a signal handler, but I guess this would
be an overkill.

>> 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.
Have you had a look into that? I only zero out a
few fields, I guess more should be re-set on a
hardware reset (or via port I/O). I even thought
this ought to be entire bzero() except for the few
fields with pre-defined values, but it appears
not, which I don't quite understand... and found
no docs.

>> write something meaningfull about SIGFPE
>> instead of "Unknown exception".
> I've done that now.
Any idea why I am not receiving the SF e-mails for
a long time now? I thought dosemu is long ago dead,
but instead there might just be some problems with
the notification messages...

Re: freezes when not emulating CPU

[Samuel Bronson]

Whoops, sent this to just Stas the first time ... sorry, Stas!

On Mon, Sep 14, 2009 at 11:26 AM, Stas Sergeev <stsp@aknet.ru> wrote:
> Hello.
>
> Bart Oldeman wrote:

>> 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.
>
> Indeed - so what was the problem with fninit/ldmxcsr then?
> Looks like it would load only the control/status word, so
> that might not be as expensive as the full reload?
> Also, I think fxrstor doesn't wait for completion, so
> the careful implementation may not be too expensive.
> There are also some tricks possible, like, for example, set
> FPU to something that will SIGFPE on any FP, and initialize
> it properly in a signal handler, but I guess this would
> be an overkill.

Well, I believe that's essentially what Intel suggests OSes do on
task-switch -- leave some flag set/cleared that will cause the next FP
operation to give an exception so that it can switch the FP registers
at that time. Whether or not this would be a good idea for DOSEMU
depends on how often you do a vm86 call vs how often the FP registers
are needed, and on how expensive it is to actually enter a state from
which the next FP access will cause a signal compared to just doing
the reload each time.

Re: freezes when not emulating CPU

[Stas Sergeev]

18.09.2009 00:37, Samuel Bronson wrote:
> Well, I believe that's essentially what Intel suggests OSes do on
> task-switch -- leave some flag set/cleared that will cause the next FP
> operation to give an exception so that it can switch the FP registers
> at that time. Whether or not this would be a good idea for DOSEMU
> depends on how often you do a vm86 call vs how often the FP registers
> are needed, and on how expensive it is to actually enter a state from
> which the next FP access will cause a signal compared to just doing
> the reload each time.
dosemu is not interrupted by the DOS
code, so the full reload is never really
needed. You just need the "known good state",
rather than the "full previous state".
If whatever is needed is only fninit/ldmxcsr,
then I guess it is just cool.

Re: freezes when not emulating CPU

[Bart Oldeman]

Hello,

> OK, but the point is that I haven't specified
> these flags by hands, so they might be a default
> for dosemu right now. So it have to became sse-safe.

Yes, dosemu needs to be sse-safe. In fact that was the intent of a
change to cpu.h that I already made in April 2007, using fxsave+fninit
when available. But I forgot about ldmxcsr. So I added the ldmxcsr on
Monday.

>> 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.
>
> What if the DOS code (by some crazy chance) also
> uses sse?

Well, if no DOS code would use SSE we would only need to save and
restore the x87 FPU state, and not the SSE state. It is precisely
because of the use of fxsave/fxrstor (without the forgotten ldmxcsr)
that you saw all these exceptions on x86_64 (where SSE is the
default).

It is however possible though extremely rare to find SSE DOS code:
DJGPP gcc happily generates it and it runs. I tested that for example
with a QEMU CPU tester that I ported to DJGPP to test and fix quite a
few bugs in cpuemu recently (it's in src/tests now -- with a Makefile
changes SSE is enabled).

> Have you had a look into that? I only zero out a
> few fields, I guess more should be re-set on a
> hardware reset (or via port I/O). I even thought
> this ought to be entire bzero() except for the few
> fields with pre-defined values, but it appears
> not, which I don't quite understand... and found
> no docs.

No I have no idea either except from what you did, look at Bochs or
other emulators.

> Any idea why I am not receiving the SF e-mails for
> a long time now? I thought dosemu is long ago dead,
> but instead there might just be some problems with
> the notification messages...

I got some bounces recently for you. I'll forward privately, and will
try to add you again.

Bart

Re: freezes when not emulating CPU

[Bart Oldeman]

Hello,

On Fri, Sep 18, 2009 at 9:32 AM, Gert Koefoed Andersen <gert@kofo.org> wrote:
> Could it be a idea too to make a update update to support for the newer cpu
> as family 16 cpu's like my type there is AMD Athlon(tm) II X2 A3/2+ 245
> Familly 16 Processors.
> The should have been showin date fot 2 kind of newr processors in developper
> lists and some other list for dosemu.

These changes were made in SVN (r1869/1870) in April -- I hope to
release an official update later.

Bart

RE: freezes when not emulating CPU

[Gert Koefoed Andersen]

Hello,

> > Could it be a idea too to make a update update to support for the
> > newer cpu as family 16 cpu's like my type there is AMD
> Athlon(tm) II
> > X2 A3/2+ 245 Familly 16 Processors.
> > The should have been showin date fot 2 kind of newr processors in
> > developper lists and some other list for dosemu.
>
> These changes were made in SVN (r1869/1870) in April -- I
> hope to release an official update later.
>
Then must me Gentoo emerge then found too unstable to it like to add it and
then say 'unknow cpu type' after skipping the patch and not got into my
/dosemu/files dirctory as there only is 2 files in it, and then not do the
update from 1.4.0 to 1.4.0.1 fine.
As I make it by Gentoo portage.

I have my dosemu to run some games as a League Coordinator for 2 games and
lot of bbs igms there is runs, and it dosemu works fine before I got my pc
upgrade from a amd64 AMD Athlon I 3800 2ghz to a AMD Athlon II 2x A3/2+ 245
3ghz processor.
And the pc is the main pc for it all and lot of links is getting league
games from me and this pc.

Gert
> --
> 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

[Gert Koefoed Andersen]

Hello,

> > Could it be a idea too to make a update update to support for the
> > newer cpu as family 16 cpu's like my type there is AMD
> Athlon(tm) II
> > X2 A3/2+ 245 Familly 16 Processors.
> > The should have been showin date fot 2 kind of newr processors in
> > developper lists and some other list for dosemu.
>
> These changes were made in SVN (r1869/1870) in April -- I
> hope to release an official update later.
>
I have just gone through the updates I can find, and it is not on
sourceforge.net to find.
And this is then why dosemu not work on my amd64 pc with AMD Athlon(tm) II
X2 A3/2+ 245 Fam. 16 Processor.

I nned the udate now to run my Leagues games by dosemu.

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Athlon(tm) II X2 245 Processor
stepping	: 2
cpu MHz		: 2906.206
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt
bogomips	: 5812.40
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Athlon(tm) II X2 245 Processor
stepping	: 2
cpu MHz		: 2906.206
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt
bogomips	: 5813.23
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate


Gert
> --
> 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)

[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

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)

[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

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