2

Recently, I've been very interested in old-school bulletin board systems (BBS) from the 90s. I'm interested in building my own (mostly as just a fun challenge), but to be honest, I'm not totally sure where to begin. I was wondering if anyone knew of any resources out there on the web that maybe have details how these things operate.

From a lot of BBSs I've been on, it seems like a lot of them use some kind of TUI to output information and menus to the user. I also would have no clue how to link Door Games/MUDS to my software.

I'm relatively experienced with programming, but not as experienced dealing with stuff like sending data over telnet, and how that protocol works, so if anyone could point me in the right direction or have any resources on how the older BBSs were built, that would be great!

Any help is much appreciated! :D

|improve this question|||||
  • 1
    BBSs go back at least a decade before the 90s. I remember hooking up with my 300 Baud Radio Shack modem in the early 80s at college. It was actually impressive with the limited memory and CPU power at the time that they could have a system responsive to the various requests of multiple users at once. Five folks chatting, two downloading files, three reading online documentation, etc. Executable downloads, once unpacked, even had a layer of protection. CP/M and DOS files could not run without changing their names. For example ".cm" needed renaming to ".com", ".ex" to ".exe", etc. – RichF Jan 21 '19 at 22:05
  • 1
    sending data over telnet, and how that protocol works, so if anyone could point me in the right direction or have any resources on how the older BBSs were built Actually, in the old days (1980s, even late 1970s), telnet was not how you connected to a BBS. You used a serial connection over dialup modems. Telnet is when you are communicating over a network (either computer directly via networking protocols, or a magic box translating your serial I/O into the network). – manassehkatz-Moving 2 Codidact Jan 21 '19 at 22:12
  • 1
    I'm voting to close this question as off-topic because it's more of a generic programming question about handling a terminal based UI over Telnet (or other character orientated interfaces). Also, doing a program for such, which a BBS would be, isn't anything retro, but a regular new application. Maybe ask on StackOverflow instead how to program Telnet. There are also plenty great books and online resources about programming. – Raffzahn Jan 21 '19 at 22:18
  • 1
    @Raffzahn Actually, if I understand the sense of the question correctly (which I might not), it is Retro in nature. However, you could also argue that it is too broad a question and close it on that basis. – manassehkatz-Moving 2 Codidact Jan 21 '19 at 22:25
  • 1
    I've voted to close this question because it cannot be answered in the space of a typical StackExchange answer. You can tell your question is too long when the answer would fill an entire book. As such, this question is too broad. I do think that the topic is relevant to Retrocomputing, and a narrow question on the topic would be fine. – DrSheldon Jan 21 '19 at 23:49
3

Back before the Internet, BBS systems were accessed by dialup modem connections. The caller would dial the phone number of the BBS, where it would connect to a modem (and then to the computer through the modem serial port).

A simple BBS might have one phone line, so only one caller could connect at any given time. If the phone line was busy, you would try again later.

A larger system might have more than one phone line, and therefore more than one modem. Sometimes the BBS operator would install extra serial port cards in a single computer to control multiple modems, or other systems would have one modem per computer and the computers would talk to each other via a LAN.

If there was more than one phone line, a simple setup would have different phone numbers to call for each line. A more sophisticated setup would have a single "rollover" number set up with the phone company which would automatically find the next available line.

The software running on the BBS would communicate with the caller through the serial port. To draw screens, the BBS would send ANSI escape codes which pretty much all terminal programs (that's the software the caller runs) supported. The BBS could then move the cursor around, draw lines, use colours, etc.

A "door game" was a separate program from the main BBS. When the caller chose to enter a door game, the BBS would effectively unload itself, and run the door game program, telling it to communicate with the same serial port. The BBS would be out of the picture for a while, until the caller chose to exit the door game and return to the BBS.

With the advent of the Internet, all this changed because you no longer needed a point-to-point modem connection for each caller. Many callers could simultaneously connect over the same net connection. Of course, the BBS software had to change a bit to accommodate this new way of working, and the whole mechanism that door games were run had to change too.

There are a handful of traditional BBS systems still out there today, but I doubt any of them actually support dialup modem connections. They probably all support telnet connections, using appropriate software that actually understands the internet.

I'm not sure whether there are any particular resources I could point you to, but I happen to know a thing or two about doing this from writing BBS systems a few decades ago.

|improve this answer|||||
  • That's pretty awesome! Also gives me good insight into how the door games worked. Thank you! – pinecat Jan 22 '19 at 1:14
  • If you can find a copy, or locate it online, you might be interested in watching BBS The Documentary, which is a DVD set with a lot of historical content and interviews with the folks that were real movers and shakers back in the day. More info here en.m.wikipedia.org/wiki/BBS:_The_Documentary – Geo... Jan 23 '19 at 5:38
  • Since I'm in about 6 of those episodes, I have to agree, there Geo! :) The official web site is here: bbsdocumentary.com . I earned a living in the 90's off working for a major BBS company, and I think the history of BBS's should be preserved as much as possible. On the terminal side of things, I know there is an active open source project to preserve the terminal program Qmodem (qodem.sourceforge.net) that most DOS users used to use to connect to said BBS's back in the day. – LarryF Jan 23 '19 at 5:45
  • Actually a very well put together piece of film. Thanks for the recommendation! – pinecat Jan 24 '19 at 21:27
1

Preface: That question is not only way to broad, but also not RC related in any way. A BBS is, per se, not more retro than word processing or a GUI. To make it retro, some genuine product from back then would need to be incorporated - and the question being about that, not generic.

Having said that, it feels as there is a very specific misconception about a BBS as being something special. But it isn't.

A BBS is a standard user program acting with its user.

There is no principal difference if the terminal is connected directly to the serial port of that machine, or via a modem. Depending on the modem setup, it might not even have to know about (*1). Of course, it may help. So a BBS program is nothing else than some application to access to the data stored via whatever user interface the programmer has in mind. Menu driven, command line or some weird control codes, pick your favourite.

Maybe think of it as a shell.

Doing the same via Telnet is no difference except for the programming interface. If at all. For example when using Unix, one can write a BBS application complete agnostic, by just reading from standard input and writing to standard output. BBS users get your BBS application set as shell in their /etc/passwd entry. Using this way even adds multi user capabilities.

Or go the 'hard' way and replace getty for all modem interfaces by your application. Now you can manage users on your own and don't have to add each as system user. For Telnet it's mostly the same, just a bit more configuration magic (like entries /etc/services and so on).

On non-Unix-systems it's no difference. Sure, if you want to support multiple lines under a non-multitasking system you may have to add some thought about managing concurrent interfaces and sessions. But that's no big deal either. The application itself will be way more code than a user or process management.

Bottom line: To write a BBS, write a program doing the interface and processing and offer it to the world.

*1 - Basic modems communicate over RS232/V.24 signal lines to signal and accept a call or hang up. So if these signals are handled correctly by the serial driver, any application can be operated remote. Smart modems (Hayes et.al.) can be even set up to take of more complicated load than answering.

|improve this answer|||||
  • Perhaps this question is too broad, but this actually helps as well. To be honest, I felt like these systems were more complicated than I had initially imagined, but perhaps there are some simpler ways to flush them out. – pinecat Jan 22 '19 at 0:44
  • 1
    @pinecat Belive me, computing is always quite simple and straight forward. After all, the whole trick is to break down seemingly complex things into tiny little instructions of adding two bytes, comparing them and so on. No magic. And most concepts that aper to be large are even simpler than that. – Raffzahn Jan 22 '19 at 0:48
  • A lot of pain experienced in the MS/PC/DR-DOS BBS world was because serial I/O was not either the same as or similar to the everyday way that ordinary application UIs worked. OS/2 was less painful, but even it was not the same terminal I/O paradigm as (say) Xenix. – JdeBP Jan 25 '19 at 18:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.