Re: Terminal Video Problem Solved (and sound too!)

Re: Terminal Video Problem Solved (and sound too!)

[Stas Sergeev]

Hello.

Mushroom wrote:
>> OK, try the attached patch.
> That's fixed it!!!
Great!
Hmm, that was just too easy, there
is still something fishy about that.
Do you have $_pci option disabled
or enabled?
If it is enabled, could you try to undo
the patch, set $_pci=(off) and reproduce
the problem?
Oh, please, do that carefully this time:)
The suggested way would be to just
erase and re-install the entire 1.1.3
sources with 1.1.3.7 patchset (1.1.3.7
patchset is an essential part here, as
1.1.3.0 have its own problems with some
video boards). You may also use a default
dosemu.conf as $_pci is disabled there.
That way the chances of any mistake are
minimized.
I want to be certain that it is not a
$_pci option guilty for your problems at
a first place.

> The graphic card details no longer come up when dosemu starts
Yes, it was printed by the POST routines,
which are now bypassed.

> The console is left in video mode
Could you elaborate on that?
This happens only when you terminate dosemu
while in graphics mode, right? How exactly
are you terinating it?
I've never seen such a strange behaveour
here with my Radeon unless I was playing
with VESA (which is disabled for most
dosemu users including you).

Re: Terminal Video Problem Solved (and sound too!)

[Mushroom]

Hi

>Stas Sergeev wrote:
>> Mushroom wrote:

> OK, try the attached patch.
>> That's fixed it!!!
> Great!
> Hmm, that was just too easy, there
> is still something fishy about that.
> Do you have $_pci option disabled
> or enabled?

The pci option is disabled - have never enabled it.


> If it is enabled, could you try to undo
> the patch, set $_pci=(off) and reproduce
> the problem?
> Oh, please, do that carefully this time:)
> The suggested way would be to just
> erase and re-install the entire 1.1.3
> sources with 1.1.3.7 patchset (1.1.3.7
> patchset is an essential part here, as
> 1.1.3.0 have its own problems with some
> video boards). You may also use a default
> dosemu.conf as $_pci is disabled there.
> That way the chances of any mistake are
> minimized.

I effectively have that as the builds for 1.1.3.0
1.1.3.7 and 1.1.3.7 patched are all separate and am simply copying the 
binaries to the top of the dosemu tree created by 1.0.2.1
I will however re-do it just to make sure.
 
> I want to be certain that it is not a
> $_pci option guilty for your problems at
> a first place.

I am almost certain I have never changed that flag - in my dosemu.conf I 
have ORIGINAL then a value written next to the description of everything 
I've changed. There is no marker on this line and it says off.

I shall however do as you say as I was obviously not at my most careful when 
I started on this :)
  
>> The graphic card details no longer come up when dosemu starts
> Yes, it was printed by the POST routines,
> which are now bypassed.

Thanks for the explanation.
 
>> The console is left in video mode
> Could you elaborate on that?

The visible text part of the screen is 24 characters wide with the text 
stretched. The first line appears about quarter of the way down the screen. 
If for example I do a dir it appears split into 3 sections vertically down 
the screen:

Correct version:
[root@mushroom dosemu ]#dir
bin       conf    FDChange.log  mkhdimage  README.bindist  Xfonts 
boot.log  dosemu  freedos       pauldos    xdosemu 
[root@mushroom dosemu ]#

What i see (stretched accross whole screen):
GAP
semu ]#dir
 FDChange.log mkhdimage
 freedos      pauldos
GAP
khdimage  README.bindlist
auldos    xdosemu
GAP
.bindist  xfonts
u


> This happens only when you terminate dosemu
> while in graphics mode, right? 

This happens whenever I enter dosemu on the console (as su or graphics are 
disabled) even if my only other command is exitemu. It effects all 
consoles.

>How exactly are you terinating it?
With exitemu. If I tab back to X without exiting the screen is dead as it 
was before but I can get back to x to kill the process.

> I've never seen such a strange behaveour
> here with my Radeon unless I was playing
> with VESA (which is disabled for most
> dosemu users including you).
 
It does seem very strange. I hope to get round my mum & dad's later in the 
week and try a few different hardware combinations.

Paul

Re: Terminal Video Problem Solved (and sound too!)

[Bart Oldeman]

On Mon, 2 Dec 2002, Mushroom wrote:

> I effectively have that as the builds for 1.1.3.0
> 1.1.3.7 and 1.1.3.7 patched are all separate and am simply copying the
> binaries to the top of the dosemu tree created by 1.0.2.1
> I will however re-do it just to make sure.

That works but in general you should also copy and adjust dosemu.conf (in
etc) to ~/dosemu/conf. global.conf isn't necessary anymore in 1.1.3.7 (but
it was in 1.1.3) and not used for this binary setup.

> This happens whenever I enter dosemu on the console (as su or graphics are
> disabled) even if my only other command is exitemu. It effects all
> consoles.
>
> >How exactly are you terinating it?
> With exitemu. If I tab back to X without exiting the screen is dead as it
> was before but I can get back to x to kill the process.

When DOSEMU terminates it restores the VGA registers that it knows of;
however some of the extended registers might be missed (changed by the
video BIOS but not saved by DOSEMU).

Bart

Re: Terminal Video Problem Solved (and sound too!)

[Stas Sergeev]

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

Hello.

Mushroom wrote:
> I am now ready to try any settings the 2 of you suggest in the conf 
> files.
OK, no special settings, just disabled
$_pci and $_chipset="plainvga".
To make your test more valuable, please
apply the attached patch. It disallows
any IO except for that was granted by
ioperm() for v86 mode.
This patch will prevent dosemu from
cleaning the screen properly, so avoid
killing it while in graphics mode (or
keep your X ready to switch there).
Apply this patch without anything else
like post-less "cost-less" init to 1.1.3.7.
If this, by any chance, also makes the
lock-ups to go away, then we are dealing with
some very bad bug. This patch will
produce a lot of output in your boot.log
or console or whatever you are using to
get an output from dosemu, send this log
to me.
But if you have lock-ups also with that
patch... then is seems that only touching
the VGA registers is already enough to lock
up the entire system with some video cards:(
In that case the post-less init looks like
the only solution.

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

--- src/include/port.h	Tue Mar 19 00:58:18 2002
+++ src/include/port.h	Tue Dec  3 18:33:51 2002
@@ -15,6 +15,7 @@
 #include "config.h"
 #include "types.h"
 #include "priv.h"
+#include "dosemu_debug.h"
 
 /* port i/o privileges */
 #define IO_READ  1
@@ -60,47 +61,53 @@
 static __inline__ void port_real_outb(ioport_t port, Bit8u value)
 {
   if (!can_do_root_stuff) return;
-  __asm__ __volatile__ ("outb %0,%1"
+  error("IO attempt: outb, port 0x%x\n", port);
+/*  __asm__ __volatile__ ("outb %0,%1"
 		    ::"a" ((Bit8u) value), "d"((Bit16u) port));
-}
+*/}
 
 static __inline__ Bit8u port_real_inb(ioport_t port)
 {
-  Bit8u _v;
+//  Bit8u _v;
   if (!can_do_root_stuff) return 0xff;
-  __asm__ __volatile__ ("inb %1,%0"
+  error("IO attempt: inb, port 0x%x\n", port);
+/*  __asm__ __volatile__ ("inb %1,%0"
 		    :"=a" (_v):"d"((Bit16u) port));
-  return _v;
+*/  return 0xff;
 }
 
 static __inline__ void port_real_outw(ioport_t port, Bit16u value)
 {
   if (!can_do_root_stuff) return;
-  __asm__ __volatile__ ("outw %0,%1" :: "a" ((Bit16u) value),
+  error("IO attempt: outw, port 0x%x\n", port);
+/*  __asm__ __volatile__ ("outw %0,%1" :: "a" ((Bit16u) value),
 		"d" ((Bit16u) port));
-}
+*/}
 
 static __inline__ Bit16u port_real_inw(ioport_t port)
 {
-  Bit16u _v;
+//  Bit16u _v;
   if (!can_do_root_stuff) return 0xffff;
-  __asm__ __volatile__ ("inw %1,%0":"=a" (_v) : "d" ((Bit16u) port));
-  return _v;
+  error("IO attempt: inw, port 0x%x\n", port);
+/*  __asm__ __volatile__ ("inw %1,%0":"=a" (_v) : "d" ((Bit16u) port));
+*/  return 0xffff;
 }
 
 static __inline__ void port_real_outd(ioport_t port, Bit32u value)
 {
   if (!can_do_root_stuff) return;
-  __asm__ __volatile__ ("outl %0,%1" : : "a" (value),
+  error("IO attempt: outd, port 0x%x\n", port);
+/*  __asm__ __volatile__ ("outl %0,%1" : : "a" (value),
 		"d" ((Bit16u) port));
-}
+*/}
 
 static __inline__ Bit32u port_real_ind(ioport_t port)
 {
-  Bit32u _v;
+//  Bit32u _v;
   if (!can_do_root_stuff) return 0xffffffff;
-  __asm__ __volatile__ ("inl %1,%0":"=a" (_v) : "d" ((Bit16u) port));
-  return _v;
+  error("IO attempt: ind, port 0x%x\n", port);
+/*  __asm__ __volatile__ ("inl %1,%0":"=a" (_v) : "d" ((Bit16u) port));
+*/  return 0xffffffff;
 }
 
 
--- src/env/video/vga.c	Tue Mar 19 00:58:13 2002
+++ src/env/video/vga.c	Tue Dec  3 18:45:39 2002
@@ -619,7 +619,7 @@
     error("CAN'T DO VIDEO INIT, BIOS NOT MAPPED!\n");
     return;
   }
-  if (set_ioperm(0x3b0, 0x3db - 0x3b0, 1))
+  if (set_ioperm(0x3b0, 0x3df - 0x3b0, 1))
     warn("couldn't get range!\n");
   config.vga = 1;
   set_vc_screen_page(READ_BYTE(BIOS_CURRENT_SCREEN_PAGE));

Re: Terminal Video Problem Solved (and sound too!)

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> When DOSEMU terminates it restores the VGA registers that it knows of;
> however some of the extended registers might be missed (changed by the
> video BIOS but not saved by DOSEMU).
Yes, but this doesn't effectively
explain why the problem happens even
when only a text mode was used under
dosemu, as this shouldn't touch any
extended registers. Even the VGA graphic
modes shouldn't IMO.
Also there must not be any way to access
an extended regs on the boards that have
a separate IO space for them (not accesable
via VGA regs) and the chipset is set to
"plainvga" (nvidia case).
But then it is strange why POST manages
to lock up the system. There is probably
another port leak somewhere...
extra_port_init() looks suspicious.
Anyway, the POST-less init looks like a
way to go as its problems are minor
compared to the complete deadlock.

Re: Terminal Video Problem Solved (and sound too!)

[Mushroom]

Hi All

OK I have setup a new version of Dosemu using the binary packages (freedos 
and 1.0.2.1)
Applied the patchset to a new version of the 1.1.3 download configured :) 
and made version 1.1.3.7 (w/o the post-less patch). I have not touched the 
conf files at all. I deleted .dosemu and ran xdosemu once to check that the 
warning screen and the version number were all pointing to the right place.
I have moved the old version of dosdebug and dosemu.bin out of harms way and 
put the contents of the 1.1.3.7 bin directory in their place and likewise 
replaced the commands in freedos/dosemu with their updated cousins run xdos 
to confirm update to 1.1.3.7.

I am now ready to try any settings the 2 of you suggest in the conf files. 
It would be useful to have these suggested in advance as a) I expect to be 
re-booting alot and b) you are more likely to get the settings right than 
my previous trial and error tactics.

One thing I didn't try very much of before was using svgalib (partly on Stas 
advice and partly because I was losing heart). I do notice that there have 
been reports of success using this with riva tnt 128 which is in the same 
group of cards.

Once again thank you both for your assistance so far.

Paul

Re: Newbie with terminal video problems

[Stas Sergeev]

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

Hello.

Mushroom wrote:
> Yes - the problem remains as it was. I'll try playing with some more 
> settings but it doesn't seem promising.
OK, try the attached patch.
This is a first pass of the POST-less
video init, which will be used for
the VESA driver in the future, if
someone will finally enlarge an IO
bitmap to 8K in the linux kernel.
If that fixes your problem - we'll
see. If not - you are out of luck.

[-- Attachment #2: post-less_video.diff --]
[-- Type: text/plain, Size: 3921 bytes --]

--- src/include/int.h	Mon Nov  4 02:25:59 2002
+++ src/include/int.h	Sun Dec  1 21:00:13 2002
@@ -15,6 +15,7 @@
 EXTERN void *interrupt_function[0x100];
 EXTERN unsigned int  check_date INIT(0);
 EXTERN time_t        start_time;
+EXTERN char video_ints[256];
 
 void do_int(int);
 void fake_int(int, int);
--- src/base/bios/bios.S	Mon Sep 16 04:14:05 2002
+++ src/base/bios/bios.S	Thu Oct 17 11:08:06 2002
@@ -507,16 +507,9 @@
 	.org	((INT10_SEG-BIOSSEG) << 4)+INT10_OFF
 /* ======================= Addr = F800:4200 (FC200) */
 	pushw	%ax
-	sti
-	movb	$DOS_HELPER_VIDEO_INIT,%al		/*  Start Video init */
-	int	$DOSHELPER_INT
-	.byte	0x9a   /* call far 0xc000:3  or call far 0xe000:3 */
-/* More general than just c000 or e000 ??? */	
-	.globl	CISH(bios_f000_int10ptr)
-CISH(bios_f000_int10ptr):
-	.long	0xc0000003
-	movb	$DOS_HELPER_VIDEO_INIT_DONE,%al		/* Finished video init */
-	int     $DOSHELPER_INT
+	cli
+	movw	$2,%ax
+	int	$0x10
 	popw	%ax
 	sti
 	lret
--- src/base/init/init.c	Sun Sep 29 23:45:30 2002
+++ src/base/init/init.c	Thu Oct 17 09:27:44 2002
@@ -227,6 +228,9 @@
 static inline void map_video_bios(void)
 {
   extern int load_file(char *name, int foffset, char *mstart, int msize);
+  __u32 int_area[256];
+  __u16 seg, off;
+  int i;
 
   v_printf("Mapping VBIOS = %d\n",config.mapped_bios);
 
@@ -252,6 +256,19 @@
 
     memcheck_addtype('V', "Video BIOS");
     memcheck_reserve('V', VBIOS_START, VBIOS_SIZE);
+    load_file("/dev/mem", 0, (char *)int_area, sizeof(int_area));
+    for (i = 0; i < 256; i++) {
+      seg = int_area[i] >> 16;
+      off = int_area[i] & 0xffff;
+      g_printf("int0x%x was 0x%04x:0x%04x\n", i, seg, off);
+      if (seg == VBIOS_START >> 4) {
+	v_printf("Setting int0x%x to 0x%04x:0x%04x\n", i, seg, off);
+	SETIVEC(i, seg, off);
+	video_ints[i] = 1;
+      } else video_ints[i] = 0;
+    }
+    v_printf("Now initialising 0x40:0-ff\n");
+    load_file("/dev/mem", 0x40 << 4, (char *)(0x40 << 4), 0x100);
   }
 }
 
--- src/base/async/int.c	Mon Sep 16 04:15:56 2002
+++ src/base/async/int.c	Wed Oct 23 17:40:24 2002
@@ -2120,7 +2134,7 @@
     interrupt_function[i] = default_interrupt;
 
     /* don't overwrite; these have been set during video init */
-    if(i == 0x1f || i == 0x43) continue;
+    if(video_ints[i]) continue;
 
     /* interrupts >= 0xc0 are scratch (BIOS stack), 
        unless defined by DOSEMU */	
--- src/env/video/vc.c	Sat Sep 21 07:27:17 2002
+++ src/env/video/vc.c	Wed Oct 16 16:49:11 2002
@@ -1139,57 +1139,5 @@
 void 
 install_int_10_handler (void)
 {
-  unsigned char *ptr;
-
-#if 0
-  if (!config.usesX)
-    {
-      /* Wrapper around call to video init c000:0003 */
-      ptr = (u_char *) INT10_ADD;
-
-      *ptr++ = 0x50;		/* push ax          */
-      *ptr++ = 0xfb;		/* start interrupts STI  */
-
-      *ptr++ = 0xb0;
-      *ptr++ = 0x08;		/* mov  al,08  ; Start Video init     */
-
-      *ptr++ = 0xcd;
-      *ptr++ = DOS_HELPER_INT;		/* int  e6          */
-
-      if (config.vbios_seg == 0xe000)
-	{
-	  *ptr++ = 0x9a;
-	  *ptr++ = 0x03;
-	  *ptr++ = 0x00;
-	  *ptr++ = 0x00;
-	  *ptr++ = 0xe0;	/* call e000:0003   */
-	}
-      else
-	{
-	  *ptr++ = 0x9a;
-	  *ptr++ = 0x03;
-	  *ptr++ = 0x00;
-	  *ptr++ = 0x00;
-	  *ptr++ = 0xc0;	/* call c000:0003   */
-	}
-      *ptr++ = 0xb0;
-      *ptr++ = 0x09;		/* move al,09   ; Finished video init    */
-
-      *ptr++ = 0xcd;
-      *ptr++ = DOS_HELPER_INT;		/* int  e6          */
-
-      *ptr++ = 0x58;		/* pop ax           */
-      *ptr++ = 0xfb;		/* start interrupts STI  */
-      *ptr++ = 0xcb;		/* retf             */
-    }
-#else
-  if (config.vbios_seg == 0xe000) {
-    extern void bios_f000_int10ptr();
-    ptr = (u_char *)((BIOSSEG << 4) + ((long)bios_f000_int10ptr - (long)bios_f000));
-    *((long *)ptr) = 0xe0000003;
-    v_printf("VID: new int10 handler at %p\n",ptr);
-  }
-  else
     v_printf("VID: install_int_10_handler: do nothing\n");
-#endif
 }

Terminal Video Problem Solved (and sound too!)

[Mushroom]

>Stas Sergeev wrote:
>> Mushroom wrote:

>> Yes - the problem remains as it was. I'll try playing with some more
>> settings but it doesn't seem promising.

> OK, try the attached patch.
> This is a first pass of the POST-less
> video init, which will be used for
> the VESA driver in the future, if
> someone will finally enlarge an IO
> bitmap to 8K in the linux kernel.
> If that fixes your problem - we'll
> see. If not - you are out of luck.

That's fixed it!!!
The graphic card details no longer come up when dosemu starts and vga is 
perfect!
The console is left in video mode but easily readible and clears after going 
to x and back.


>> BTW the sound which was working 
>> well in 1.1.3.0 seems partly broken again in 1.1.3.7
>Fine :-/
>Now, when my new sound engine finally
>made it in (which was the one of the
>top requested features), there will
>surely be someone who will call it
>broken:)

Glad to be of service :)

>> but that's not something that really concerns me.
>That is important and concerns me.
>My sound engine is not perfect overall,
>but compared with an old crap, I
>don't want to have any drawbacks.
>Please open the bug report on dosemu
>SourceForge BTS and attach you program
>to that report so that I can reproduce
>and fix the problem.

After the efforts you have gone to sort me out I thought I'd better do some 
testing of my own. So I had my brother re-build an old 386, put a decent 
soundcard in and try it through my current sound system. Same result.

It is really weird that the old dosemu sound system sounds exactly like 
playing it through some desktop speakers with a nasty soundcard which is as 
I remember it!

I am very sorry for raising concerns it seems that original program did not 
allow for being played through decent equipment.

Many many thanks for your help and I hope that patch assists others in the 
same way.

Paul