BBS frontends and how they used to work

BBS frontends and how they used to work

There's a part of running a BBS which seems to be a lost art now. It's the notion of having a "frontend" which sits between your incoming calls and the actual bulletin board. On some systems, there might have been several possible routes for incoming calls to take. I'll document a few of the ones I knew about for the sake of posterity.

The normal setup most people would encounter is where the BBS software itself sits there and waits for a RING (or the equivalent numeric code, for those heathens with less-sophisticated modems). After one or two of these, it would transmit ATA, the modem would start doing its thing, and then it would get a CONNECT xxxxx along with the carrier detect (DCD) line going high.

Assuming the connection was at an acceptable speed, the BBS would send a welcome banner of some sort, prompt for whether they wanted plain old ASCII or something else. Alternatives included color ANSI stuff with those funky CP437 box drawing characters, Commodore PETSCII color graphics ("Press ✓ for color graphics!") in the case of C-64s and similar, and towards the end, RIPscrip (a graphics drawing standard).

Of course, if the sysop had set a speed limitation like "minimum 2400 bps", someone who had the gall or misfortune to connect at 1200 or 300 bps would probably get a note like "buy a better modem" and would be kicked off.

So, that's what the baseline was like. There were bunches of things which could be stacked on top of this as time went by. The most common one I would see is some kind of Fidonet frontend. There was one called FrontDoor which seemed rather popular. I also remember seeing lots of BinkleyTerm installations. There were others, too, but I never ran any of those.

These would typically come into your life when you decided you want to join Fidonet, since your system was expected to be available for mail runs most of the time. The whole point of the frontend is that it would be able to handle Fidonet protocol mail calls while also detecting humans and sending them through to your BBS.

This required some sophistication on the part of your BBS, naturally. It needed explicit support for this, where it would just start up and drop straight into the welcome screen phase. It had to just assume everything else was okay since the connection had long since been established. Likewise, it also had to cleanly quit after each call so the frontend could "recycle" and take over for the next caller.

I did this to add Fidonet to my system, but I also had the added requirement of remaining compatible with incoming GT network calls. While most of them happened during "netmail hour" which in practice for me was actually most of the time between 1 and 5 AM, a fair number would arrive at totally unexpected times. There was something built into the GT netmail software called "CRASH!mail" which was intended to be used for ad-hoc deliveries.

This sort of call worked by calling out to the target BBS, waiting for it to spew out some kind of welcome banner. On the sysop console, that usually looked like this:

Welcome to the Foo Bar BBS in West Podunkville.
 
Would you like ANSI graphics? [y/n]: 

The calling system would then proceed to blast this at you:

CQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQ CQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQ CQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQCQ{crash}

I think someone who wrote that must have been a ham radio fan. In any case, if your BBS received that, it would then drop out with an errorlevel, and you had to have your batch file deal with that and start the netmail software in "incoming crashmail" mode. It would then take the call, do its thing, and exit, and then you could loop back to running the BBS.

This was all well and good when GT itself answered the phone, but what about when you moved to FrontDoor? Now it would be the one getting all of the CQs. By the time it kicked someone into the BBS, it would be too late to possibly get those, and the call would fail.

Fortunately, better frontend programs allowed you to add magic strings to them which would cause it to drop out with various errorlevels. You could just add "CQCQCQ" and then it would go straight from the frontend to GT's netmail program (called MDRIVER, for what it's worth) without touching the BBS itself.

Then, later on, the modems we were using started getting the ability to take faxes. They also got smart enough to be able to tell the difference between an incoming fax and a typical incoming modem call and could tell the host system about this. This was called "adaptive answer" mode, and it worked by picking up on that periodic distinctive BEEP that calling fax machines generate.

So now you could get the usual "CONNECT xyz/blah/blah/blah" or you could get something like "+FCON". In the latter case, you had to drop out of the frontend into yet another program. In this case, a friend of mine wrote a great little shareware program which would take care of things. It would speak all of the magic fax lingo and would receive documents straight to your disk. It could optionally print them when done, and then it would put your BBS back online.

I think the last thing anyone worried about in this realm was handling caller ID info. This was (and still is, for land lines) a burst of data transmitted between the first and second rings. You just needed a device which was capable of listening to the line without taking it "off hook" as far as the telco was concerned. This also meant you had to defer answering the phone until the second ring.

Some lucky people had modems which would do this for them. Mine was relatively old and lacked the necessary electronics to let it snoop on the line without answering. I had to use an add-on box ordered from the back of a sysop magazine which had a phone jack on one end and a serial port on the other. You'd feed it a 9 volt battery and it would stream 1200 bps data at you. Then you just had to watch for the magic synchronization bytes from the telco (UUUUUUUUU...) and decode what followed.

If you've been keeping track, all of the following was now possible:

Pre-answer caller ID logging

Incoming fax detection and reception

Incoming Fidonet call handling

Incoming GT netmail call handling

And finally, handling of ordinary humans who just want to read their mail or shoot at aliens in Trade Wars.

In addition to the "CQCQ" for GT and "+FCON" for faxes, I had also added a secret string which would exit straight to the BBS. I did this to allow bypassing the "2400 bps or greater" limitation otherwise imposed on callers. This way, if I was out in the world somewhere and wound up on some horrible slow connection, I could still get in through that backdoor.

Despite the extreme levels of hacks on top of hacks, all of this usually worked just fine. The exceptions were people with marginal phone lines or just plain badly-implemented modems which would tend to connect and then immediately start retraining. By the time they figured out a usable rate, the frontend would have dropped into the BBS. Then I'd get a whole bunch of Fidonet spew at the "ANSI color graphics?" prompt until it booted them off as a "TWIT". (Yes, it really said that in the logs for people who couldn't figure out how to log in.)

Oh, as a random bit of trivia for anyone who still has access to an actual hard-wired phone line which gets caller ID bursts: it tells you more than just who's calling. If you have telco voicemail, there are messages for enabling and disabling your "message waiting" light. Now you know how that light on your caller ID box used to turn on and off without your phone ever ringing. If you can actually use this knowledge somehow, enjoy... I think.