= FSX_MYS (21:1/105)==========================================================
Msg : 1815 of 1822 From : Avon 21:1/101
09 Jan 17 14:12:00 To : All
Subj : Re: Run DOS BBS DoorGames on the Raspberry Pi =============================================================================== On 12/09/16, Gryphon pondered and said...
Of course you can run DOS doors on the Pi. I wrote a HOWTO. It uses QEMU.
For those of you who are looking for info on how to run DOS doors on a Raspberry Pi I am posting the often referred to how-to document that Gryphon has kindly written and published on his website here as well as a reference post for others looking for this information. Big thanks to Gryphon for his work in creating this document.
You can find this document online at
http://cyberia.darktech.org:8080/articles/qemu-howto.html
[snip]
Run DOS BBS DoorGames on the Raspberry Pi:
by Darryl Perry 2016
This tutorial is intended for BBS sysops who wish to run DOS door games
on their Raspberry Pi (or other ARM device)
This tutorial is developed with Mystic BBS as the default BBS to use. If
you wish to use another BBS package, you will need to fix up the parts
that are specific to the package you wish to use.
How does this work?
We will be creating an emulated virtual DOS environment from which to run
our DOS door games. To do that, we will be creating a serial port into our
VM and attching it to a computer port so that we can communicate via socat.
Since we can mount host file systems into the DOS VM, we will not need to
populate the VM file system with doorgame programs. This means we only need
the bare minimum to boot and run the dos environment.
Each time a door is ran, the script will build a batch file (run.bat) in
the main bbs directory. When the VM boots, it will run that run.bat
batch file to run the doorgame.
These methods have worked for me on the following devices:
1) Raspberry Pi B+ (raspberrypi.org)
2) Raspberry PiB3 (raspberrypi.org)
3) ODROID XU3-Lite (hardkernel.com)
Caveats:
The Raspberry Pi B+ is the least robust device I've attemted this with
and I've had some good success with it. However, the device is inherently
slow, so do not expect high-speed game-play like you do with traditional
telnet doorgame activity. I would say that the speed of the display would
be equivalent to a 1200 Baud modem.
The Raspberry Pi B3 is a much faster device and the speed lag is not
noticable at all.
The ODROID XU3 is a much more robust device and the speed delay seems
almost unnoticable.
Required packages:
qemu: apt-get install qemu
socat: apt-get install socat
todos: apt-get install tofrodos
Create freedos image:
We will be creating a FreeDOS image to be used in our VM.
I find it helpful to follow this howto when creating a FreeDOS image.
https://en.wikibooks.org/wiki/QEMU/FreeDOS
Then I use this link as a HOWTO to install FreeDOS on the newley created
image.
http://how-to.wikia.com/wiki/How_to_install_FreeDOS_in_QEMU
I made my image to be 100MB. I think that it may be quite a bit
larger than I need so you may be able to use something much smaller.
Configure 4DOS:
Once you have a working FreeDOS VM, you will need to configure the boot
files for your needs:
I find it easier to mount the image onto the local file system, and edit the
files with VI. To mount the image:
1) Create a mount point:
mkdir /mnt/freedos
2) mount the image
sudo mount -t msdos -o loop,offset=32256 ./freedos.img /mnt/freedos
You can then cd to /mnt/freedos/ and edit your files. You can also use
this method for copying files to the DOS filesystem. Don't forget to
unmount the image before running the VM.
sudo umount /mnt/freedos
The default boot scripts are C:\FDCONFIG.SYS and C:\FDOS\FDAUTO.BAT.
The following has worked for me. You will want to play with your own
configuration to meet your own needs.
C:\FDCONFIG.SYS
---------------------------------------
!COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS
!SET DOSDIR=C:\FDOS
!LASTDRIVE=Z
!BUFFERS=20
!FILES=40
DOS=HIGH
DOS=UMB
DOSDATA=UMB
DEVICE=C:\FDOS\BIN\HIMEMX.EXE
DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\FDOS\FDAUTO.BAT
---------------------------------------
C:\FDOS\FDAUTO.SYS
-------------------------------------
@echo off
SET LANG=EN
SET MTCPCFG=C:\FDOS\MTCP.CFG
REM SET WATTCP.CFG=C:\FDOS
SET PATH=%dosdir%\BIN
SET NLSPATH=%dosdir%\NLS
SET HELPPATH=%dosdir%\HELP
SET TEMP=%dosdir%\TEMP
SET TMP=%TEMP%
SET DIRCMD=/P /OGN /4
SET COPYCMD=/-Y
FDAPM APMDOS
LH SHARE
DOSLFN
MEM /C /N
SET AUTOFILE=%0
SET CFGFILE=C:\FDCONFIG.SYS
alias reboot=fdapm warmboot
alias reset=fdisk /reboot
alias halt=fdapm poweroff
alias shutdown=fdapm poweroff
alias cfg=edit %cfgfile%
alias auto=edit %0
CALL D:\RUN.BAT
----------------------------------------
Note how the batch file ends with CALL D:\RUN.BAT. RUN.BAT is the
dynamically created batch file that gets created each time we run the
doors.sh script.
Setting up the doorgames:
You will want to run the DOS VM initially, to setup your doorgames. To do
that, you just run qemu normally, but with the mounted local file system.
I've written a simple batch file that will load the VM. ----------------------------------------
#!/bin/sh
rm /home/bbs/temp${NODE}/run.bat
qemu-system-i386 \
-localtime \
/home/bbs/doors/qemu/freedos.img \
-boot c \
-hdb fat:/home/bbs \
-m 1024
----------------------------------------
If you are running this remotely, from a terminal like putty, you can add
the -curses flag. That will give you an interactive shell into the VM.
The method used for running the VM will mount the /home/bbs directory as
the DOS D: drive. This puts all the BBS subdirectories off of D:.
I have my doorgame files in /home/bbs/doors/ on the host filesystem.
My LORD directory is at /home/bbs/doors/lord. When viewed from the DOS VM,
it will be located at D:\DOORS\LORD
The dropfile locations will also be on your D: drive.
D:\TEMP
or for node #2:
D:\TEMP2
The working DOORS.SH script:
This is the script as I have it working for me: ------------------------------------
#!/bin/sh
## Pass the parameters for the door and the node.
DOOR=${1}
NODE=${2}
DOOR=`echo ${DOOR} | tr '[a-z]' '[A-Z]'`
## The linux path for the run.bat file
gobat=/home/bbs/run.bat
## The VM will be accessable via a computer port. I have randomly selected
## 20200 as a base port number to use. Each node will 'add' to the base
## number. IE, Node #1 will be added to 20200 and the result will be
## port 20201 (20200 + 1)
## You may change the base port to any number you wish.
portnum=`expr 20200 + ${NODE}`
case ${DOOR} in
## Operation OverKill II
OOII)
echo "@echo off" > ${gobat}
echo "D:" >> ${gobat}
echo "CD \DOORS\OO" >> ${gobat}
### Use the CALL command when calling a door batch file.
### If not used, then the door batch file will not return
### to the RUN.BAT script to complete execution. If the
### RUN.BAT script does not complete execution, then it will
### not shut down the VM. It will then just go to a dos
### prompt and the user will not see it, and will think that
### the game is hung.
echo "CALL OOIIDOOR.BAT ${NODE}" >> ${gobat}
;;
## Legend of the Red Dragon
LORD)
echo "@echo off" > ${gobat}
echo "D:" >> ${gobat}
echo "CD \DOORS\LORD" >> ${gobat}
echo "CALL START.BAT ${NODE}" >> ${gobat}
;;
## Planets: The Exploration of Space
PLAN)
echo "@echo off" > ${gobat}
echo "D:" >> ${gobat}
echo "CD \DOORS\PLAN" >> ${gobat}
echo "PLANETS.EXE /pD:\TEMP${NODE}" >> ${gobat}
;;
## Barren Realms Elete
BRE)
echo "@echo off" > ${gobat}
echo "D:" >> ${gobat}
echo "CD \DOORS\BRE" >> ${gobat}
echo "SRDOOR" >> ${gobat}
echo "BRE" >> ${gobat}
;;
# Space Dynasty
DYNASTY)
echo "@echo off" > ${gobat}
echo "D:" >> ${gobat}
echo "CD \DOORS\DYNASTY" >> ${gobat}
echo "DYNASTY D:\TEMP${NODE}\DOOR.SYS" >> ${gobat}
echo "COPY \\DOORS\\DYNASTY\\DYNASTY\\DYNASTY.SCO \\TEXT\\" >> ${gobat}
;;
# NetRunner
NETRUN)
echo "@echo off" > ${gobat}
echo "D:" >> ${gobat}
echo "D:\DOORS\bnu\bnu" >> ${gobat}
echo "CD \DOORS\NETRUN" >> ${gobat}
echo "NETRUN D:\TEMP{NODE}\DOOR.SYS" >> ${gobat}
;;
DOS)
;;
esac
## At the end of run.bat, we add this line to gracefully shutdown the VM.
## This will return the user back to the BBS.
echo "C:\FDOS\BIN\FDAPM POWEROFF" >> ${gobat}
## The batch file must be in dos format, or it will not run properly.
todos ${gobat}
### The main QEMU call.
### 1) -localtime to pass the host clock to the VM
### 2) tell it to use the freedos.img
### 3) tell it to boot to the C: drive
### 4) Turn off all displays. Otherwise it will give errors or skewed displays ### 5) How many megabytes of memory to allow for the BM
### 6) Define a serial modem connection and assign a computer port
### 7) Mount the main BBS directory in RW mode
### The qemu call is loaded into the background. We do this so that we can ### spawn a concurrent socat process.
qemu-system-i386 \
-localtime \
/home/bbs/doors/qemu/freedos.img \
-boot c \
-display none \
-m 256 \
-serial telnet::${portnum},server,nowait,nodelay \
-hdb fat:rw:/home/bbs > /dev/null 2>&1 &
### Inform the user that it will take several seconds before the game
### loads up.
clear
echo
echo "Loading door... please be patient...."
echo
sleep 3
### socat is used to communicate with the VM's serial modem.
socat -,raw,echo=0 TCP:localhost:${portnum}
if [ -f ${gobat} ]; then
rm -rf ${gobat}
fi
exit 0
------------------------------------
Using the script:
I use and have developed this method for Mystic BBS. You will need to make
appropriate adjustments if you use a different BBS package.
The script is called from a menu option. At the time of this writing,
Mystic BBS is currently at 1.12a4. At this time, each door menu option
generates a specific dropfile. Later versions of Mystic (I'm told) will
have it so there is only one doorgame menu option, and it will generate
every known dropfile in the user's temp directory.
For now, you will need to call the proper doorgame menu option for the
doorgame it is intending to launch. I try to use the DOOR.SYS dropfile
whereever possible. That Mystic Menu Option is DG.
The parameters for the script are:
doors.sh DOOR NODE# /DOS
The /DOS switch is used to create a DOS version of the drop file. That way
there is no need to run todos on the dropfile before calling the door.
Use %3 of course, as the MCI macro to pass the users' node number.
Menu: DG
Data: /home/bbs/doors/qemu/doors.sh LORD %3 /DOS
Conclusion:
That's all there is to it. Your milage may vary.
Darryl Perry
Gryphon @ Cyberia BBS
telnet://cyberia.darktech.org
[snip]
--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS |
telnet://agency.bbs.geek.nz (21:1/101)
--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: flupH | fluph.darktech.org (21:1/105)