A while back I had seen this fantastic site, “Hates the internet” with a greatÂ write upÂ on setting up a BBS on Qemu. Â In retrospect it did inspire me a bit later to get my BBS going with Qemu, but I chose to use OS/2 once I found out about SIO’s vmodem feature.
HTI (Hates the internet) chose this program called rlfossil, which is for MS-DOS..
RLFOSSIL is an implementation of multi-line serial port driver corresponding to the Fido/Opus/Seadog level 5 specification and a simple HAYES-compatible modem emulator. It allows applications usually worked through BBS’s to run on the Internet, or in IP-based local net.er, and rlogin and telnet emulation using IP services numbers 513 & 23. RLFOSSIL allows combined work with other FOSSIL drivers (X00,BNU etc.).
So I thought between that, and all the Windows/386 excitement I’d try for something even more insane. Â How about running a multiline BBS on Windows?
So in the same effort, I was going to use Qemu 0.14.1, with MS-DOS 4.01 (the first version I could find that came with share.exe), and Windows/386 2.11. Â The installation of MS-DOS 4.01 worked fine on an 80MB disk image, thankfully it was one of the things that DOS 4 could do better then 3 is large disk images… Yes I know 3.31 could as well, but it didn’t come with share so it was out. Â One strange thing after install was this message…
It is kind of forboding that DOS is warning me that because of my “large” disk I better run share. Â Since I plan on having a multi node BBS all in one computer, I need to run share anyways.
The next exciting part was installing Windows/386 2.11. Â The installation went pretty smooth, and with Qemu the mouse worked fine. Â So far, so good. Â I couldn’t use himem.sys that comes with Windows/386, nor could I use the himem.sys that comes with MS-DOS as the Windows/386 version complains that that A20 line is already active (?) and the MS-DOS one has Windows complaining that the HMA is already in use. Â Sadly then my conventional memory footprint will beÂ unsatisfactory, but I don’t see any way around it.
The next part is configuring rlfossil. Â rlfossil needs a driver to talk to the network card, and you can find them on crynwr, namely the ‘other‘ packet archive, which contains NE2000 drivers. Â Keeping with HTI, I’m going to use the NE2000 and configure Qemu with the PCI NE2000 driver.
Packet drivers are loaded from the command line something like this:
ne2000 0x60 11 0xc100
This loads the driver on software interrupt 0x60, and by default the PCI NE2000 is configured for IRQ 11, port 0xc100. Â Qemu 1.6.0 changed the PCI NE2000 to use port 0xc000 for what it is worth..
So keeping with the HTI tradition, I’m going to put my packet driver (ne2000.com) and unpack the rlfossil archive in c:\packet. Â The next thing to do is configure rlfossile which uses the wattcp configuration file. Â Since I’m going to use the usermode NAT and a redirect, I configure my VM like this:
With that all in place now it’s time to configure the config.sys/autoexec.bat. Â Some things are going to be different from a normal install because we plan to run a BBS, and multiple instances of it!
So my config.sys looks like:
SHELL=C:\COMMAND.COM /P /E:768
And my autoexec.bat is like this:
NE2000 0x60 11 0xC100
RLFOSSIL 0 4 WIN386
And of course launching Qemu I do it like this:
qemu.exe -L pc-bios -m 16 -net nic,model=ne2k_pci -net user-redir tcp:23::23 -hda telegard.qcow2
This configures the VM for 16MB of ram (which would have cost a FORTUNE back then), the PCI NE2000, and it’ll redirect telnet from my host machine into the VM.
And just like HTI, I went with telegard, because it supports fossil based ports.
Well that sure was a *LOT* of work, andÂ surprisingly testing it with a single node, actually works. Â And you can bring up a few other MS-DOS prompts and it’ll work fine. But if you launch the second node…
Disaster struck. Â So needless to say, while Windows/386 was pretty slick for the day it just couldn’t measure up. Â So I figured for the hell of it, I’d try Windows 3.0 Â I mean I would have imagined that Windows 3.0 most certainly could NOT handle this kind of challenge.
So with some disks shuffled, I fired it up and..
It actually worked! Â So with a LOT of chaos going on I managed to get Trade Wars 2002 running, although I couldn’t figure out how to automatically figure out the node.. Hell the whole door configuration thing is..Â bizarre. Synchronet really kicks ass in regards to easy of configuration.
And using PIF’s to configure each node for some easy of launching, and some reduced memory, I could easily run all four nodes that rlfossil can support.
I have to admit, Windows 3.0 really is impressive considering all the UAE’s and how generally crappy we thought it was at the time. Â I’m sure even emulated having a multiple Ghz cpu helps quite a bit.
And look at all that memory.. I guess it’s pretty impressive it even works. Â Since Windows anything throttles the CPU at 100% I’m not going to put this online…. Although at the same time combined with an CPU idle program (is there a Windows 3.0 idle vxd?) it sits ok, but who wants a single user system in 2011?
“I couldn’t use himem.sys that comes with Windows/386, nor could I use the himem.sys that comes with MS-DOS as the Windows/386 version complains that that A20 line is already active (?) and the MS-DOS one has Windows complaining that the HMA is already in use.”
It seems you’re not supposed to use HIMEM.SYS with Windows/386:
“In Windows/286 version 2.10 or later, Windows has the
capability of putting part of itself in extended memory with
the help of a driver called HIMEM.SYS. In Windows/386, the
HIMEM capability is built-in and HIMEM.SYS should NOT be
placed in the config.sys.”
Windows 2.x was a strange time indeed. But as we all know it didn’t get interesting until Windows 3.0 with the introduction of DPMI.
wow, Trade Wars 2002 and BBS brings back so good ole’ memories.
check out my bbs for more nostalgia… 🙂
Hello, I was wondering if you could share a little more information about rlfossil and what you learned from (HTI)? I too am trying to get a BBS working and the first node works like a champ. When I start the second node the socket fails on the first one and the second never waits for a call. My setup is a 6.22 DOS with DV in a virtualbox VM, and I’m starting DV with a batch that calls “rlfossil.exe 4 4 DV” as the document states but I’m not sure about the mention of BBS.bat in the rlfossil doc and I’m hoping you might know? Unfortunately HIT no longer has the documents on line 🙁
Sure The first thing I didn’t notice though is what kind of MS-DOS multitasker are you using? Or what BBS?
Also I run rlfossil as:
rlfossil 0 4 win
Since I’m using Windows…
It may be easier to work back through a working example.
Hey! This post and your blog in general, made my day. Thanks man. I currently run a bbs I coded in Linux during most of the 90s. But it compiles on modern linux, anyway.
I used to code RA tools with their sdk in C and Turbo Pascal 😀
On the BBS server side of things I used to like RemoteAccess, PCBoard, and there is one I cant recall right now. In between RA and PCBoard, we could say.
Have a really nice 2015!
Thanks! Although the only thing you forgot to do was plug your BBS, bbs.buanzo.org!
Oh and the bbs software I did not recall was ProBoard.
I just telnetted into bbs.buanzo.org and it is working fine. The web interface with the old java client on http://bbs.buanzo.org might definitely not work. Nor do I really support it. Java not my cup of coffee 😛
You’re the man! Thank you for that.
This is some amazing work. Thanks so much for that. I managed to start Remote Access (RA.EXE) and get it waiting for calls. It even mentions the correct fossil driver name on the waiting screen.
The only problem however is that, somehow, I cannot do anything with the IP of my host, even though my host can reach other IP addresses. Say that my local IP of my VM is 192.168.1.10. I can ping and reach other IPs, but I cannot do anything with the IP 192.168.1.10 – neither from the VM itself nor from another host.
Does anyone has any ideas of what might be wrong?