9 Problems and fixes

Contents of this section

9.1 Why does dosemu lock up after one keystroke?

(12/17/93)

You need to turn on the keyboard interrupt in the dosemu config file. Add a line to the config file:

   keybint on

Shouldn't be a problem in dosemu0.52.

9.2 Why are my keystrokes echoed ttwwiiccee??

Nick Holloway (alfie@dcs.warwick.ac.uk) reported (2/22/94) that

After running dos after playing with some stty settings, I was getting doubled key presses. I can now reveal what the reason is!

It only happens when dos is run on the console with 'istrip' set. This is (I think) because the raw scancodes are mutilated by the 'istrip', so that key release events look like key press events.

So, the input processing needs to be turned off when using the scan codes on a console (it wouldn't be a good idea to do it for tty lines).

9.3 Why does dosemu give "divide overflow" errors after running for more than 24-hours?

(1/17/94)

This is a known bug. It will (hopefully) be fixed in an upcoming release. For now, you can simply exit dosemu and start it again.

9.4 Where did the debugging output go?

As of dosemu0.49pl4, stderr is automatically redirected to /dev/null. Try "dos -D+a 2>debug" to turn on debugging information and redirect it to the file "debug".

9.5 Why are characters < 128 highlighted and blinking?

Chris Kuehnke (Christian.Kuehnke@Informatik.Uni-Oldenburg.DE) reported (3/21/94) that

I think I've found a bug in dosemu0.50pl1; with a MDA card displayed characters > 128 automagically appeared as highlighted and blinking.

This patch fixed the problem for me [but on the other hand, maybe I'm totally wrong ;-)]:

--- video.c~    Sat Mar 19 00:50:25 1994
+++ video.c     Sat Mar 19 20:36:10 1994
@@ -721,7 +721,7 @@
   int x, y, i, tmp;
   unsigned int s;
   static int gfx_flag = 0;
-  char c;
+  u_char c;
   us *sm;
 
   if (d.video >= 3)

9.6 Why will dosemu run in a term but not in the console?

JyiJiin Luo (jjluo@casbah.acns.nwu.edu) reported (4/19/94) that

I experienced exactly the same problem before. I figured out all the video shadow in my AMI BIOS must be disabled. Now dosemu runs fine on my system.

9.7 How can I speed up dosemu?

Mark Rejhon (mdrejhon@undergrad.math.uwaterloo.ca) reported (4/7/94) that

TIP: Speed up your DOS "dir" listings by about 25%-50% or so by typing break off at the DOS prompt or including it in autoexec.bat.

TIP: Use the nnansi.com ANSI driver to speed up the "dir" output even more at roughly 50%-100% more. It works properly in non-graphics mode, unlike turbo.com.

Joel M. Hoffman (joel@rac1.wam.umd.edu) reported (4/23/94) that

Ironically, I've found that it's sometimes faster to run dosemu in an Emacs terminal emulator rather than directly to the console. Emacs's output optimization is what makes the difference here.

Put the following in your .emacs:

        (defun do-dos ()
          (interactive)
          (terminal-emulator "dos" "/usr/local/bin/dos" ()))
and then "emacs -f do-dos" will run the dosemu inside the buffer. Make sure you emacs window is 25x80, of course.

Pete Heist (heistp@rpi.edu) reported (5/13/94) that

If you compile it with the "-funroll-all-loops" option you will get MUCH faster screen output. Some other parts of the emulator will run much faster as well. Realize that the consequence of this is a larger executable which eats a little more memory, even though it's demand loaded.

Georg Wiegand (gw@gwcomp.e.open.de) reported (5/16/94) that

You also can use the keyword HogThreshold in /etc/dosemu.conf. The greater the following number the more calculating-time dosemu gets. For example, I use "HogThreshold 60000" on my 386/87-20 laptop.

9.8 My CDROM drive has problems reading some files under dosemu.

Vinod G Kulkarni (vinod@cse.iitb.ernet.in) reported (4/7/94) that

When a CDROM is mounted from linux and used from within DOSEMU (mapped drive), there could be some problems. The cdrom driver (iso9660) in the kernel tries to find out the type of the file (i.e. binary or text). If it can't find, it tries to guess the type of the file using a heuristic. This heuristic fails under some circumstances when a (almost) text file is to be treated as binary. (I do not know if it is a bug or feature.)

The result of this is that if you copy such a file from cdrom (from linux itself, and not necessarily dosemu), the resulting file will be usually bigger than original file. (Blanks get added before ^J,^M.) So a program running in dosemu gives error or hangs, which you may mistaken as problem of dosemu.

I could verify that this kind of heuristic is not used when the cdrom is used from DEC ALPHA system. (I nfs mounted the exported cdrom drive and used under dosemu as a drive.)

To correct the behavior, you can force the iso9660 file system not to use heuristic at all. Make the following change and then recompile your kernel.

File: /usr/src/linux/fs/isofs/file.c
In Function: static int isofs_file_read ()
  ...
           if (inode->u.isofs_i.i_file_format == ISOFS_FILE_UNKNOWN) {
                inode->u.isofs_i.i_file_format = ISOFS_FILE_BINARY ;
                /* ORIGINAL: isofs_determine_filetype(inode);  */
           }    
  ...

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter