I've been running a BBS off and on since the mid-90s, and have tried a variety of methods to do so: OS/2 on real hardware, DosBox on Linux, a VM running OS/2, and more modern software that runs fine on modern Windows without the need of dealing with any sort of hardware or software emulation.
I've never really been happy with any of these: they're either not particularly authentic and don't quite scratch the nostalgia itch properly, or they're just so flaky they're almost impossible to set up and keep running reliably.
I originally ran my BBS on OS/2 2.1 with Telegard/2, and that's been the setup I've tried to replicate, with fairly poor success.
Poor, mostly, because OS/2 on real hardware is at the mercy of 25+ year old hardware (which is all it really supports), or it's in a VM and while it technically works, I've never had it be stable and reliable enough to run something that's hosting a BBS that I actually want people to be able to connect to and use.
But, as it happens, there's a OS/2 successor available: ArcaOS. I've attempted a setup on ArcaOS 5.0, but that failed because of issues with the DOS subsystem and video calls for DOS-based software. The OS/2 stuff worked fine, but if there's no door games, well, it's not really a complete solution.
The good news, however, is that ArcaOS 5.1 has completely resolved that issue and every door I've attempted to install and run has worked perfectly, or at least has run in a manner that's perfectly adequate for what it's supposed to do. Some things seem to run at a performance level that is way under what I'd expect, but I haven't actually identified a single specific issue that might be causing some things to execute a little slowly.
But, still, I'm not happy with this setup either. It's running on an old quad core AMD Jaguar-based APU, and is both slow and power hungry compared to modern CPUs - the power usage of the whole system sitting in the 40-50w range.
I suspect that most of my performance issues are related to the platform as well as my power bill not needing something this old and slow sucking down that much power and still being a little flaky.
So, I've decided to rebuild this (again!) on a low-power MiniPC.
It's got wildly better single-thread performance (by dint of better IPC and much higher clock speed), which is the only thing that particularly matters for this use case, and in Fedora during some testing it was pulling 4w at the wall, which is, essentially, a 90 to 95% reduction in power usage over the current hardware.
That said, the install did not go well. First, it turns out the included storage is eMMC, and not any sort of SATA or nVME drive, and ArcaOS does not support eMMC storage.
No problem, you may think, as the computer has a nVME slot. Well, again, no: the nVME slot appears to be entirely cosmetic and non-functional. It's a M-key, so it SHOULD be nVME but two SSDs I attempted ended up not working - the BIOS at no point detected any sort of nVME device.
It may be a BIOS issue as it's both a generic BIOS and is a pirated version, as one could tell from the EVALUATION VERSION stamped all over everything.
At that point I figured that there was no way ArcaOS would run natively, and that I could perhaps just run it in a VM, and started the Linux install.
Which also immediately ran into a problem, because of course it did: the ethernet port on this thing is provided by a Motorcomm YT6801, which, shockingly, does not actually have drivers in the mainline kernel tree, so no working Ethernet. The wifi, thankfully, was detected, so I did the install, and a short time later I had a nice shiny Ubuntu 24.04 install.
Thankfully Arch (of all things) had an AUR entry that has working drivers for the Ethernet, and a quick compile-and-install later I had a working Ethernet connection.
Next up was Virtualbox, which has a supported install target for ArcaOS. A quick apt later, and a new VM create later, I was able to run through the ArcaOS install. The only caveat here is outlined in the ArcaOS documentation: you can only use a single-cpu VM, and doing more than one results in a non-booting, crash-prone slow install. I missed that the first time around, and the installation was succesful but it never managed to actually boot all the way to the desktop until I spotted the issue and fixed it.
This took the entire evening, and was far, far more complicated than I was initially expecting, but that's my fault for not reading deeper into the specific hardware and not expecting nothing to actually work.
The only thing at this point that I needed to do was setup the VNC server, and make sure it starts at boot and then configure SIO2K which provides the telnet -> serial translation layer.
PM VNC is under the Programs -> Installed Software -> PMVNC folder and you just need to run the 'Start PM VNC Server' program, then use the Server Settings to set a password.
You probably want this to start on boot, so you should make a Shadow (basically an OS/2 symlink) of the 'Start PM VNC Server' program, and then move that Shadow to the Programs -> Startup folder.
I did a quick reboot to ensure the VNC server came up as expected, and yep, it worked fine.
SIO2K is a neat piece of software that emulates an arbitrary number of serial ports, and allows inbound and outbound telnet connections from them. This is good, because Telegard/2 knows absolutely nothing about the internet, and doesn't want to learn anything and thus only speaks serial.
SIO2k has been officially blessed as abandonware by it's author and thus there's no reason it can't be freely shared, so here you go.
Unzip, run the installer and then reboot. On reboot you should see a bit of text during the boot process about the SIO drivers being installed.
If everything has worked so far, you'll still need to make a couple of changes. The config.sys on the root of the system drive will have six lines at the bottom of it related to the SIO2K install, and you'll want to make a couple of minor changes to make it look thus:
rem device=E:\sio2k\esp.sys logfile=E:\sio2k\sio2k.log NoPause
device=E:\sio2k\vmodem.sys logfile=E:\sio2k\sio2k.log NoPause nPorts=4
device=E:\sio2k\uart.sys logfile=E:\sio2k\sio2k.log
device=E:\sio2k\sio2k.sys logfile=E:\sio2k\sio2k.log OS2SHARES
device=E:\sio2k\vsio2k.sys logfile=E:\sio2k\sio2k.log vIrqList(3,4)
device=E:\sio2k\vx00.sysE: is my system drive, so that will be different for you. The three important changes are:
- on the vmodem.sys line, you want nPorts to equal however many ports you need
- you need to add OS2SHARES to the end of the sio2k.sys line
- you need to uncomment the vx00.sys line
The first change defines the total number of com ports (starting at COM3) you'll have available, the OS2SHARES allows you to use OS/2 and DOS software on the same COM port, which is important because Telegard/2 is OS/2 native, but all door games are almost exclusively DOS-base.
The last line enables the FOSSIL layer, which is also required in almost every case for COM port access for BBS and door software.
After those changes are made, another reboot is required.
After the reboot, in your sio2k folder, you'll find a VMODEM.EXE file. You'll want to run that and verify that all your ports are detected and usable:
You should see a number of lines equal to however many ports you defined, and some combination of DTR/DSR/CTS lights. I've got an active BBS session on all 4, so your appearance will vary.
You also probably want to make a Shadow and move the Shadow to the Startup folder, like you did with PMVNC, since the vmodem.exe app needs to be running for the SIO drivers to do any modem related things.
At this point, it's just a matter of installing your BBS software of choice, pointing them at your virtual modem ports (defaults to COM3 for the first port and goes up from there) and then doing whatever your software requires you to do to get up and running.
As a side note, while I'm using a OS/2-based BBS software, there's no real reason you need to do so: anything DOS-based will work just as well, since the transition between OS/2 and DOS software in this configuration is completely seamless.
However, this is not true the other way around: you can't have a DOS-based piece of software call an OS/2 based piece of software due to how the modem sharing works. If the COM port is initialized in OS/2, you can share it with DOS, but if it's initialized in DOS, you cannot share it with an OS/2 app. Why? No idea, but it doesn't work.
So, after all that configuration (and a bit more I covered here) we arrive with the ability to simply go to a website, click a button, and connect to old software running natively on a modern implementation of it's OS.