• Dosemu stability problems

    From StoneC0ld@VERT to All on Wednesday, October 17, 2007 15:09:01
    Hi,

    I've got Lord (4.06) and BRE setup on my linux-based Synchronet (currently not public), but both games randomly freeze--usually when the game is sending text, haven't noticed it freeze while waiting for input... There's no apparent pattern, just random.

    I'm using Dosemu 1.3.3.0, using the default emusetup.bat (with only a change in the PATH variable, and which fossil driver..)

    Any ideas? Any more information required?

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Robert LaPrise@VERT/COSMELON to StoneC0ld on Sunday, October 21, 2007 16:16:00

    I've got Lord (4.06) and BRE setup on my linux-based Synchronet (currently n public), but both games randomly freeze--usually when the game is sending text, haven't noticed it freeze while waiting for input... There's no apparent pattern, just random.

    Earlier testing I did makes me suspect the configuration in scfg has
    Intercept Standard I/O set to Yes. That would be the first thing to check if it is set to No, then check the door setup programs and verify they are set
    to use a fossil and not their internal com routines. This is my LORD II node setup. It's not optimized but it works fine, I setup the board mainly to log in from work and play games while I wait on backtraces to complete when debugging product crashes, so far I've had no issues with any of my DOS
    games:


    (1) Node Number : 1
    (2) BBS Name :
    (3) BBS Software : DOORSYS
    (4) Path To Drop File: D:
    (5) Fossil/Internal : Using Regular Fossil Driver
    (6) Locked Port Speed: Port Not Locked
    (7) Comport : Read From Drop File
    (8) Send Open Comports Command? : No!
    (9) Send Reset Comports Command? : No!
    (A) Use Special ANSI Settings? : No!
    (B) Use direct screen writes? : No!
    (C) Copy setup from another RT game. (LORD & RTREADER)
    (D) Use secondary ASYNC commands?: No!


    I'm using Dosemu 1.3.3.0, using the default emusetup.bat (with only a
    change in the PATH variable, and which fossil driver..)

    DOSEMU 1.4.0 is out now and I believe the version of FreeDOS that comes with it is 1.0 where the version with some of the earlier DOSEMU releases was slightly older. If you are getting the games to run at all I would suspect it's more of a configuration issue but updgrading to the latest release would not be a bad idea. Contrary to the misleading name you are not emulating
    DOS, you are booting a DOS OS with hardware virtualization so the bios
    calls can route through Linux.

    I've been using Ray Gwinn's X00.EXE for a fossil driver since the old days when I ran an RA board. When I moved the system to OS/2 Ray had the best
    comm driver out there so I stayed with his stuff. Some people prefer BNU and I never had any issues with it either.

    What I have done is created a subdirectory under sbbs/exec/ called dosutils and I put nnansi.com and x00.exe in it. nnansi.com you only need for local DOS work so YOU have the ansi handling in place. x00.exe (or BNU) you only need for accessing the game from the board.

    Assuming you have an sbbs user and the bbs is installed in that users home directory you can su to the sbbs user, change to their home directory, then type dosemu (assuming you know this but covering it to be thorough). Under the sbbs directory there should then be a .dosemu subdirectory which has a drive_c subdirectory. this is where your autoexec.bat file goes for local
    DOS work. This is the one I use:



    echo off
    path c:\bin;c:\gnu;c:\dosemu
    set HELPPATH=c:\help
    set TEMP=c:\tmp
    rem ----------------------------------

    prompt $P$G

    CHOICE /C:12 /N /T:1,20 E: 1 - \home\sbbs 2 - \home\sbbs\xtrn:

    IF ERRORLEVEL 2 GOTO XTRN
    IF ERRORLEVEL 1 GOTO ROOT

    :ROOT
    lredir E: linux\fs\home\sbbs
    GOTO NEXT

    :XTRN
    lredir E: linux\fs\home\sbbs\xtrn


    :NEXT
    lredir H: linux\fs\home\sbbs\exec
    set PATH=%PATH%;h:\dosutils

    rem uncomment to load another bitmap font
    loadhi display con=(vga,437,2)

    share.exe
    nnansi.com


    E:



    The choice selection is due to running IceEdit as my editor and the way
    DOSEMU works under synchronet E: gets mapped to /home/sbbs/ where all the doors have E: mapped as /home/sbbs/xtrn/ The choice option lets me map the
    E: appropriately for local DOS work so the program I need to adjust settings on can find all of its files.

    share.exe is part of FreeDOS and needed for doors that can have multiple users. It's not really needed for the local DOS work if all you'll be doing is maintenance/configurtion work, but it doesn't hurt aything either.


    As for actually running the door, when the DOSEMU mod is enabled and you run
    a DOS program Synchronet will write an external.bat file in the node directory the door is being called from. This file will stay around after you exit the door so you can look at it and see what is happening. The last line of the file (the REM'ed out line) contains the actual Linux commands that are executed when the door is called. In effect this is the "autoexec.bat" file being used by DOS when it boots up and calls the door.

    In sbbs/ctrl/ (or in the individual doors directory) you need the
    emusetup.bat file. If Synchronet detects one in the doors startup directory it will write out a call to that file in the external.bat otherwise it will look in sbbs/ctrl/ and write a call to that file, if neither exists it won't write a call to emusetup.bat into the external.bat file.

    This is the global (in sbbs/ctrl/) emusetup.bat file I use with all the DOS programs that run from Synchronet:


    @echo off
    path c:\bin;c:\gnu;c:\dosemu;h:\dosutils
    x00.exe E
    share.exe


    Since H: is always mapped by Synchronet with the DOSEMU mod to sbbs/exec/ the sbbs/exec/dosutils/ directory I have needs to be included in the path so emusetup.bat can load the fossil before the door is called.

    Any ideas? Any more information required?


    Go through the above, if you're still having trouble you can check out a document I'm putting together to cover this here:

    www.testing-solutions.org/Synchronet/DOSEMU-HandBook.html

    If you still can't get it go to the main page on my site and email me with
    the Email Admin link and we'll get you sorted. DOS doors are text mode console programs, there's nothing complicated going on where FreeDOS under
    the DOSEMU virtualization should have problems. If you were having issues getting Wolfenstein to run under it that I could see, but for doors, if they're acting flakey it's either the configuration or the door itself. If you can load a local DOS session and run the door in a local mode then you should have no problems running it from the bbs, just need to tweak your config at that point.

    So far I have:

    Arrowbridge I
    Arrowbridge II
    Baron Realms Elite
    Falcon's Eye
    LORD II
    Planets: TEOS
    Usurper

    all running fine.

    Finally for your users, PuTTY sucks, it doesn't handle the ANSI very well at all. Windows Telnet is limited but the games display correctly, SyncTerm
    also displays the games correctly, I use CygWin and the default BASH shell with an alias in the .bashrc to let me type "bbs" from the command prompt and have it load the telnet client with the bbs address and whatnot supplied.
    The key mapping (when I shell out from the board) needs some work but the games play perfectly and the screens don't get all mucked up.


    Regards,
    Rob

    ... "The answer to the Great Question is 42."
  • From StoneC0ld@VERT to Robert LaPrise on Monday, October 22, 2007 02:18:51

    I've got Lord (4.06) and BRE setup on my linux-based Synchronet (currently n public), but both games randomly freeze--usually when the game is sending text, haven't noticed it freeze while waiting for input... There's no apparent pattern, just random.

    Earlier testing I did makes me suspect the configuration in scfg has Intercept Standard I/O set to Yes. That would be the first thing to check if it is set to No, then check the door setup programs and verify they are set to use a fossil and not their internal com routines. This is my LORD II node setup. It's not optimized but it works fine, I setup the board mainly to log in from work and play games while I wait on backtraces to complete when debugging product crashes, so far I've had no issues with any of my DOS games:

    Synchronet and the doors are all correctly configured, and they do work--dosemu was just randomly freezing (though it closed cleanly when we killed the connection)...

    The problem appears to have been either in dosemu 1.3.3, or in the default configuration for dosemu 1.3.3 provided by Gentoo, or in a patch by Gentoo....
    I unmerged it, and manually installed 1.4.0, and everything seems to be running much more stable.... I was even able to get past the NPC activity part of Usurper maintenance, which I never got past 5% under 1.3.3 before freezing...

    Thanks! :)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Robert LaPrise@VERT/COSMELON to StoneC0ld on Monday, October 22, 2007 10:58:00

    The problem appears to have been either in dosemu 1.3.3, or in the default configuration for dosemu 1.3.3 provided by Gentoo, or in a patch by Gentoo.. I unmerged it, and manually installed 1.4.0, and everything seems to be

    I would suspect the default configuration and the old version. I'm running 1.4.0 as well and never changed anything in the /etc/dosemu/dosemu.conf file.

    running much more stable.... I was even able to get past the NPC activity part of Usurper maintenance, which I never got past 5% under 1.3.3 before freezing...

    The DOSEMU document I'm working on has a timed event example for running the Usurper maintenance so the first player in each day doesn't have to sit through that. There are a lot of interesting possibilities with the DOSEMU mod once you start playing with it.

    Thanks! :)

    Not a problem, glad to help.

    Regards,
    Rob

    ... "Spare no expense to save money on this one." -- Samuel Goldwyn