MBBSEmu News - January 4th, 2021

Happy Anniversary MBBSEmu!

It was one year ago that I made the official announcement of the crazy, hairbrained project, MBBSEmu on Reddit in the /r/bbs subreddit. The past year itself has been a wild ride. MBBSEmu has grown from a closed source pet project, to a community maintained Open Source project. It has grown from an initial prototype partially supporting one module, to supporting well over 35 modules which are all fully playable. CPU Performance has grown from an 2Mhz 8086 to a 486DX2 on modern hardware. It has grown to have robust support for Windows, OSX, Linux and is flexible enough to even run on a Raspberry Pi! These accomplishments are not mine alone, but belong to our community of contributors both in development and testing. I'm so thankful for our initial group of Patreon backers who saw the potential in the project and made a direct contribution to get it off the ground. We had so much community support over the past year that the Patreon was no longer needed as all costs had been covered thanks to everyone's support.

I'm very excited to see what the coming year holds for MBBSEmu and our small, passionate community of individuals who all fondly remember a simpler time and games that were made great by their engaging experience, without having to rely on fancy schmancy graphics.

My goal for MBBSEmu in 2021 is to continue to involve our community as much as possible, as transparency and open involvement is what makes a community project thrive and grow.

Here's to another year of awesomeness! And with that, I'm very excited to share the latest additions in the most recent tagged release of MBBSEmu!

Event Driven Architecture -- BYE BYE 100% CPU!

The Major "Breakthrough" in Galacticomm's Software Breakthrough Library was its ability to rapidly poll many serial ports in order to support up to 256 lines on consumer PC hardware. A drawback to this architecture was that the main loop within The MajorBBS/Worldgroup would continually run to process incoming events. IN FACT, the reason 38400 baud was the maximum bitrate supported by The MajorBBS and Worldgroup is that this was the fastest data rate it could support without losing data due to the limited polling rate of CPU's at the time. Back in 1986, this was more than enough. These days -- it just means a single core of your system sits pegged at 100% doing basically nothing most of the time.

With the latest release of MBBSEmu, we have done away with the constant main loop concept similar to MajorBBS/Worldgroup and transitioned to an Event Driven Architecture where the main loop is only executed as needed, either by the notification of incoming data or a timer needing to be fired. This is possible within MBBSEmu as we handle incoming socket data on a dedicated thread per socket, so there is no blocking within the main loop. We can be processing data in the main loop and incoming data on the socket will just queue up.

Some applications require more events per second, so for this we've introduced the appconfig.json option for Timer.Hertz which you can specify how often this event fires even if there is no incoming data to process. This allows you to have better response times for games that might rely on a higher frequency timer, such as an RTIHDLR routine. We've found a value of 18 cycles per second (every ~55ms) results in very performant modules and a HUGE reduction in CPU load. Just how much does this reduce the CPU usage?

The below screenshot is from a test system running 34 modules with a Timer.Herz value of 18. As you can see on this system, it results in a 3.3% CPU load. This makes MBBSEmu a viable alternative to host MajorBBS/Worldgroup Modules on Cloud Providers that would otherwise bill/throttle you for excessive CPU use. Very Cool!

MBBSEmu running with new Event Driven Architecture
MBBSEmu running 34 modules using the new Event Driven Architecture


To date, MBBSEmu has only supported the loading and playing of MajorBBS/Worldgroup Modules which were comprised of a single DLL. The vast majority of still available modules fall into this category. The only mass distributed, popular Module which uses multiple DLL's which cross reference one another is Farwest Trivia. For reasons that I suspect were around selling components of Farwest Trivia or using it for other systems, the Question Server, Teleconference Actions, and Main Module are all independent Modules with the Main Module importing functions from the other two. These DLL's are listed in the REQUIRES section of the Farwest Trivia MDF file.

The trick with modules such as these is the x86 CALL FAR opcodes reference the imported DLL functions within the same memory space as the main module. This is how modules would be loaded and relocated running in x86 protected mode within the full 32-bit address space. Segment 1 of the Farwest Trivia Question Server might be loaded and relocated to actual memory Sector 52. Then, when Farwest Trivia was loaded, calls to the Question Server would have the Sector on the CALL FAR patched from the relocation information, now referencing the proper sector. This is how the CPU was able to continue execution without missing a beat.

With the latest release of MBBSEmu, we've implemented similar loading logic where now all components for a MajorBBS/Worldgroup Module, including imported DLLs, are loaded into the same memory space with relocation information applied properly. The result is initial support for Farwest Trivia in MBBSEmu! It still has some crashes that we're working on, and you will only get one question served up, but it's a very promising first step!

MBBSEmu running Farwest Trivia
Farwest Trivia running within MBBSEmu!
MBBSEmu running the Farwest Trivia Question Server
MBBSEmu running the Farwest Trivia Question Server!

Latest MBBSEmu Alpha

The latest tagged Alpha has 23 Pull Requests that have been merged in over the past month and represents the work of several folks all contributing to the project through testing as well as development.

You can get the latest Alpha release on GitHub (Link)