After three parts dealing with CoCo cross development, I thought I’d change direction for a bit and discuss something completely different. We’ll get back to cross development once we have something to develop.
Before WWW was BBS
The story so far…
My first exposure to computer bulletin board systems (BBSes) was in Houston, Texas around 1981. I had become friends with a kid who sat in front of me in 7th grade English. He, somehow, managed to turn me on to computers, BASIC programming, BBSes, Hitchhiker’s Guide to the Galaxy,
phone phreaking and more things that defined my teenage years.
At the time, neither of us owned a computer, though that would change when he would get a Timex Sinclair and I would get a Commodore VIC-20. But before then, we would write out BASIC programs on paper and visit the local Radio Shack to type them in on their TRS-80 Model III computer. It was at Radio Shack that I also went online for the first time, using their second phone line and modem to dial in to local BBSes.
Those early days were exciting and fun, and I wished I could run my own BBS. Unfortunately, my allowance was not enough to let me pay for a phone line, auto-answer modem and disk drives. I was actually eventually able to borrow a disk drive, but all the Color Computer BBS software of the day required “3-4 disk drives” to operate.
Being a SysOp (system operator) was quite the investment!
Somehow, I got the idea that it should be completely possible to run a small BBS without any disk drives by using RAM to hold the messages. At the start of the day, the messages and user log could be loaded from cassette, and when the board was shut down, they could be written back out again.
And that was the birth of the “*ALL RAM* BBS”.
If you would like to take a look at this, you can find the original program, editor and documentation (misspellings and all) posted over at the wonderful BBS Documentary website. Just be gentle. A young kid wrote it…
I thought it might be fun to revisit this project, and perhaps see if it could be done better today.
*ALL RAM* was designed to run on a Radio Shack Color Computer with at least 32K* of memory and a cassette recorder.
Side Note: *While you could expand the original CoCos to 64K, BASIC still only used the first 32K since the BASIC ROMs started at the 32K mark, and covered up the higher 32K of RAM. Assembly code that did not require the ROMs could bank in the full 64K and use it, but I was just a kid that had never touched assembly language so I stuck with BASIC.
To put the BBS online, you would obviously need a modem (preferably a smartmodem one that could answer the phone on its own) and a “remote terminal driver” program that interfaces between BASIC’s PRINT and INPUT commands and the RS232 serial port. I did not provide one of these, as they were freely available (with one popular one called REMOTE printed in Rainbow magazine*).
Side Note: *A remote terminal driver program appeared in the November 1983 issue of Rainbow (“Remote Operation Of The Color Computer” by Dan Downard on page 118). It was updated again in November 1985 issue (“More Power And Protection For Your BBS” by Scott M. Taylor on page 107), and even more in November 1986 issue (“The Evolving REMOTE” by Mark Crosby on page 70).
Since no direct access storage was available, all messages and the userlog would be contained in RAM. On startup, *ALL RAM* would load the userlog and message base from cassette. Before the system was shut down, you would save them back to tape.
If power were lost or the system were shut off before saving, any new users or changes to the message base since startup would be lost. But hey! You could run a small BBS without needing expensive disk drives!
The amount of users and messages was based how much free memory was available. *ALL RAM* could support up to 201 users (user 0 was the SysOp) and a tiny message base of 20 messages (10 lines of 64 characters each, basically the size of four tweets).
In a future article, I will walk through all the technical details of how this worked out.
To save memory, the BBS was split in to two programs. EDITOR.BAS was for creating and editing the userlog and message base (features not normally needed during operation). ALLRAM.BAS was the main BBS that handled new user registration, login, messages and chatting with the SysOp.
Side Note: Since the CoCo did not have lowercase, you will notice that the SysOp-facing EDITOR program presents text in all UPPERCASE. But, the user-facing BBS used mixed case (which appeared as inverse video on the CoCo) so callers using computers with lowercase would see nicer text.
Before the BBS could run, a userlog and message base had to be created and saved to tape. This was done by running the EDITOR program:
The first step would be to Create Userlog:
This allowed creating User #0, the SysOp, by entering a name (up to 20 characters) and password (up to 8 characters).
Once created, the userlog and an empty message base needed to be saved to cassette:
Once done, the main ALLRAM.BAS program could be run. (For online operation, there would have been another step of loading the machine language remote terminal driver first.)
Upon running, the BBS would prompt you to load in the userlog and message base:
Once loaded, the BBS was ready:
When a user connected, they would press ENTER (as was common in those days) to let the BBS know someone was there. The welcome and login screen would be displayed, and the user could enter their password*.
Side Note: *Yes, that’s right! JUST the password, without a username! It was very common in those days to login with just a password, which meant that each user had to have their own unique password. When creating a new account, if you chose a password that already belonged to someone else, a BBS would reject it (and thus, you knew it was someone else’s password!). Security wasn’t really a thing back then.
Once logged in, the user saw a small main menu of options:
*ALL RAM* provided most of the basic features of a BBS back then:
- Call Sysop – The BBS would beep to alert the Sysop that a user wanted to chat. The Sysop could answer and “instant message” with the caller.
- Goodbye – This would log the user off, and reset the BBS for the next caller. If a user just hung up, many systems would just sit there, and the next person who called in would be them! Security wasn’t really a thing back then. (More advanced BBBes with modems that had “carrier detect” could tell when a user hung up and log them out automatically, but it was generally a good idea to always log off properly since so many systems did not do this.)
- Userlog – This would show a listing of all users of the system.
- Post Msg – This allowed entering a message for all to see, or a private message for a specific user.
- Read Msg – This would allow you to read any of the “up to 20” messages on the system.
- Scan Titles – This would show you a summary of messages available with their subject and who posted them.
And that was it! Pretty simple.
The CoCo did not have a hardware clock, so there was no concept of time. Messages did not have any date or time in them, and there was no caller time limit. The BBS would count how many commands the user gave, and disconnect them after a certain count, but that was the only thing that kept a user from staying on for hours (not that they would try).
Posting a message looked like this:
When posting a message, if you made a mistake all you could do was retype a specific line. Things were much simpler back then :)
*ALL RAM* Legacy
This little cassette-based BBS is unique footnote in the history of bulletin board software. At the time of its creation, a “grown up” I knew who ran a large CoCo BBS in Houston liked the idea and was going to help me get it sold through a software company. He was in negotiations with them but, ultimately, the deal fell through and it was never sold commercially. It makes me wonder “what if…”
*ALL RAM* did operate in Houston as “Cyclops’ Castle“. It was a special version customized to load and save the userlog and message base from disk. This may seem to defeat the purpose to make a disk-version, but it enabled something useful: Dozens of message boards on one floppy disk!
I added the ability to save the current message base and load a different one, thus having different topics. Because it was very unlikely that any message base would ever be 100% full (all ten lines of every message using all 64 characters), we were able to have many more message boards than the 12 or so that should actually fit on a 156K floppy disk. We had more than systems running off of multiple drives thanks to this trick!
Fortunately, no one ever tried to crash the system by filling up every message.
This disk upgrade also had the ability to display text files (bulletins, BBS listings, etc.) and other improvements, but the code has been lost*.
Side Note: *Just last week, I ran across an old, faded printout that Graham, the SysOp of Cyclops Castle, must have sent me (I didn’t have a printer at the time). I have found two different versions of the disk-based *ALL RAM* BBS, and sometime I hope to type them in and see what else it did. I also found original notes, the hand-written instructions and other goodies from early development.
*ALL RAM* Future
“Knowing what I now know,” if I were to re-write *ALL RAM*, I would do some things differently:
- For security, I would require both username and password to login. I’d also see if there was an easy way to not store the passwords in plaintext, possibly by implementing some simple hash mechanism in BASIC.
- Rather than allocating 10 lines for every message whether it used them or not, I would just allocate a block of lines and let messages use up only as many lines as they really needed. This means, with the same memory, the BBS might be able to have 200 tweet-sized messages, or a few HUGE messages ;-)
- I would give each message a unique ID number, and remember the highest message read by the user. That way, the next time they logged in they could read new messages without having to manually scan them to find what was new.
- I could easily implement different message board topics, all using the same pool of message lines.
- I have many ideas on how I could save memory with the TO and FROM of messages as well.
And that sounds like a nice project. Over on my other site, I have been experimenting with things that might help with a rewrite of *ALL RAM*. When I figure out what I am doing, I will share the results here.
- *ALL RAM* BBS for Arduino. In 2013, I came across my *ALL RAM* source code and decided to try to port it to an Arduino. The Arduino only had 2K of RAM, so it would be little more than a proof-of-concept, but… I did it! It is a LITERAL translation from Color BASIC to C, so it’s some of the most horrendous C you will ever see!