The MajorBBS Emulation Project Wiki

aka “The MAJOR Update” 😉

While these official Patreon updates are becoming further apart, if you're following us on GitHub or are on the Discord Server, you're already up to date on the latest and greatest – BUT – these updates are awesome to give context to some of the changes that have been made recently!

Well – it finally happened. This past Tuesday on one late-ish night hacking session I decided to sit down and noodle out why MajorMUD was being stubborn and not handling movement properly.

MajorMUD is unique in that it handles deferred actions differently than most modules. Even user input is deferred for actions like movement, spell casting, exiting, etc. Players know these deferred commands as the pause between actions.

The processing of the deferred actions is handled within the RTKICK routine in MajorMUD, which fires every second. I stepped through a ton of code working backwards from exit to find that the player exit processing was handled in _FAST_UPDATE_CHARACTER.

The Problem? If the variable word_86FDA wasn't set to 1, it'd never execute.

So – from this point it was more working backwards to see where word_86FDA was actually set to 1. You can see in the above Screenshot from IDA it is set (OR'd) in the INIT routines…. but then in a method called _MAJORMUD_SYSCYC

Now – the SYSCYC variable has been implemented for a while now but I was never really sure how/what it did. It's not documented well/at all in the documentation available.

I found that SYSCYC was being set with a pointer to 0003:0000 in the _INIT_ routine:

Sooooo…. I guess let's just run it as often as possible? 🤣 We put calling the defined SYSCYC method in the main system loop and what do you know:

🎆🎆 IT WORKED!! 🎆🎆 This was a multi-month long, many hours spent debugging victory! Now that MajorMUD is entering a more usable state, we're starting to get some great defects logged on GitHub for MajorMUD.

Expect to see a ton of great progress in the coming weeks around MajorMUD, and other modules as well!

One area of weakness that has come from initial MajorMUD testing has been performance around the Btrieve implementation. Currently we're using JSON files that are loaded to memory and we write out an updated JSON file on every insert/update.

The problem?

For Btrieve heavy modules (MajorMUD), I/O latency becomes an issue because it's writing a ~40+ MB JSON file on each write.

The solution?

Hello SQLite! 🤓

A huge contributor to MBBSEmu, @Paladine, is working on a port where the Btrieve data is loaded from the original Btrieve .DAT files into a SQLite database for use going forward. The work he's doing will greatly simplify queries, dramatically increase performance, and make things like modifying data within the files even easier.

His work is still ongoing but the early results are very, very promising! Keep an eye on the MBBSEmu GitHub repo for progress on the SQLite conversion!

Also this past week I took some time to sit down and run some CPU profiling of not only the Benchmark program we have within MBBSEmu, but also some modules as well.

Through optimizations on the Memory Core, how pointers are handled, and some streamlining of code in the CPU Core, we were able to increase performance by 25-35% depending on your platform!

On my local machine (i9-9900), MBBSEmu clocks in at about ~14.2 MIPS which puts the performance on-par with a 486DX, which is more than enough to host MajorBBS/Worldgroup Modules! 🚀🚀

Since the last Patreon update there have been three officially tagged Releases on GitHub, with hundreds of automated builds coming out of the CI/CD pipeline as enhancements are made.

I'd list the release updates here more frequently but there are just so many PR's going into each Release! Thank you everyone for your continued direct support of the project. Getting MajorMUD working this past week was a huge moment for me as it has been my Everest since we started this journey in January.

Also a huge THANK YOU to our community members who have stepped up to help with coding, testing, and providing feedback. We're making more progress on MBBSEmu now than ever before!