Bulletin boards were remote computer systems reachable by modems. They were most active as a phenomenon long before dedicated connections were available outside of universities - they began to die out in the mid 90s as SLIP/PPP connections became widely available. I started using them in middle school, initially following in the technical footsteps of my father.
When I started, text and ANSI graphics were the norm for bulletin boards - PCs were the norm but there were a number of other systems out there, so text was considered a baseline with ANSI the higher-up option. People connected to bulletin boards using a terminal program, which typically did at least three things:
- managed the modem, meaning it had a database of init strings for a lot of modems and had the capacity for user-entered strings if they had something unusual. This was not at all uncommon, as hardware was a lot more diverse at the time and anyone using a modem was usually both fairly technical and willing to accept their hardware not working quite correctly
manage phonebook - most people who used a modem used more than one BBS - a lot of people had a "top five" or so that they'd use regularly and they'd occasionally show up on others. Getting status on the BBS's one cared about was a matter of providing more information, meeting some sysops, and often uploading files
- manage terminal stuff while conntected - typically this meant maintaining the normal interface of the remote site while allowing the user to perform some local tasks too, keeping the terminal in a consistent state between these. Text-menus were a regular way to do this
- Terminals also would typically, either internally or by calling external programs, manage file transfers - XModem and YModem were both popular, while variants on these (like ZModem) allowed interrupted transfers to resume and (theoretically, although no BBS I ever saw permitted it) background transfers. Telix was particularly popular, although my dad chose Boyan because he liked its interface better.
Dialup connections with a terminal program were much simpler than PPP or SLIP (two popular IP-over-modem protocols still seeing some use today when people dial up) - apart from when files were being transferred, the bits for whatever was being transferred were sent right across the channel - typically ASCII data, marred only by ANSI escape codes (if used). Terminal software typically did not shield its user from entering Hayes modem escape codes either - typing +++ would tell the modem to stop transmitting data and wait for a command. Although it was considered polite to disconnect from a BBS using the menus, some people would just type +++ATH0 wherever they finished with whatever they were doing.
BBSs would typically display some kind of a text-graphics (meaning an ANSI-graphics-based colour interface with tabs and arrows supported) login right after connection - friendly BBSs would tell users a special username to register a new account, closed BBSs would typically not offer this. After a successful login, people usually reached a front menu of some kind, leading people to forums, doors, files, and occasionally other things. Each "page" of a BBS was typically another ANSI screen - some layered the screen automatically to provide menu-like effects, some did not. Forums were not substantially different in form from what's available in today's web forum software - people would post, reply, etc. Well-connemcted BBS's occasionally would sync their forums with each other every night at a given time (again, over a modem connection during scheduled downtime). Very well connected BBS's occasionally had BITNET or Usenet feeds, either read-only or occasionally read-write. Doors were external programs the BBS server software could run, typically games. Some games were very simple, saving no state information (e.g. tic-tac-toe), some more complex, letting the user play a certain number of turns every day and progressing slowly, possibly playing against other players on the BBS. Occasionally, well connected BBSs would have inter-BBS doors, syning the day's turns with each other (by having, during nightly maintenance, a BBS turn one of its modems from listening on a phone line to dialing another BBS for the transfer). BBSs usually had a file library, with the sysop(s) vetting each upload before making it public. Many BBSs required users to maintain a good upload/download ratio so the BBS would keep getting new stuff rather than have all its members only leech the content. Broken files were unfortunately common - file transfer software was often not entirely reliable, and modem connections often dropped over the sustained use of bandwidth that transfers required, as normal connection use was much lighter. Intellectual property and licenses were generally ignored in BBS culture - while a few BBSs were more discriminating, most would accept cracked content and ignore licenses with little hesitation (very occasionally restricting these file areas to longer-term registered users). A few BBSs supported other things, particularly the well-connected ones (often those that required a monthly fee for membership) -- usenet, telnet, uucp, and occasionally ftp were not unheard of - external email was also occasionally seen. Multi-user BBSs usually also allowed a 2-way chat mode - even single-user BBSs generally supported chatting with the sysop (should they be around and answer the request).
Basic BBSs were single-user - they were run by light hobbyists who would get an extra phone line for BBS use and leave a spare computer with a regular modem running a light version of some BBS software. This was simple to set up, didn't require any unusual software or hardware, and was inexpensive. Scaling up any further typically required a few things - a multimodem device (more than two modems was difficult on a PC as COM1/COM3 shared an interrupt by default, likewise with COM2/COM4. People usually used a digiboard for this), multitasker (to run a copy of the BBS software for each modem - QNX was popular, some people used OS/2, and a very few pieces of BBS software did their own multitasking (although this generally limited door support)). Most BBS software had a license cost depending on the number of nodes supported - contrary to the general attitude on file sharing on BBSs, most sysops were willing to pay the requested fees on BBS software and other things needed for their BBS (sometimes passing these costs on to their users). Many door games (such as Barren Realms Elite or Legend and the Red Dragon) cost money for a sysop to register, occasionally also with different costs on the number of BBS nodes.
BBS software was quite varied, giving BBS owners varying amounts of control and varying default interfaces to their capabilities. As people often dialed in from non-PC systems, some BBSs also ran on unusual systems. I recall one single-node BBS called the Black Hole (Cleveland area) that ran on an Atari of some kind (probably an ST), along with a few unix systems.