This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
doors:tutorials:dos:dosonpi [2021/01/25 07:56] avon |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Run DOS BBS DoorGames on the Raspberry Pi ===== | ||
- | |||
- | //Article 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 | ||