Everyday Retrocomputing Architecture | 2020-08-10

Keeping in mind my idea that “everyday retrocomputing” encompasses my ability to do things like read my email, update blog posts, hack, and do at least some aspects of my job, I started with a review of what it would take to do these sorts of things using a classic 1980s computer. Obviously, this project is dead without some kind of telecommunications, or I’m never getting my email or making blog posts.

This led to a few angles of attack:

I was initially very enthused about the idea of plugging an Apple //e directly into the Internet with its own Ethernet card and declaring victory. My excitement was blunted, though, by the realization of two critical facts:

It’s the latter point that was the harder pill to swallow. No SSL means no web browsing (even if it’s a text browser), no email, etc. I’d started to ponder on the idea of making a general-purpose proxy server that would basically run encrypted sessions on behalf of my mythic retrocomputer, bridging my world of the world of insecure 1980s telecommunications to the modern world. This ultimately led me to remember and realize that I’d really forgotten a few things about how access to the network used to work. Indeed, there was another way to go about things.

Consider for a moment that, even before my little rural town got dial-up Internet in 1996, I was making use of mail and news services via BBS systems. Even after I went away to school in 1997, it was exceptionally common for me to use Internet services through a telnet session. Browsing the web or using a local email client require rapid-access storage for cookies, for downloaded emails, etc. I’m not going to have this on an Apple //e; floppies aren’t really practical for that kind of fast-access storage and hard disk drives weren’t in consumer markets until the late 1980s and could cost upwards of $4,000 inflation-adjusted dollars, a price that would easily rival the cost of the computer itself.

Email and other services on a local computer were far less common in this era, and that era easily lasted to the turn of the millennium. Actually, I was still accessing my university email through Pine on a shell account as late as 2005. Using the home computer as the terminal/window into “the big machine” of your university, corporation, or community BBS was the common architecture, and it’s the one I’m going to follow here.

So, where am I going to get the stand-in for the university’s big UNIX machine? A Raspberry Pi, obviously. I can set this up on an isolated LAN to keep the insecure traffic away from the rest of my network, and it can provide services, most importantly telnet, that are insecure when facing the LAN but secured as they leave for the outside world.

I see a lot of people dissing projects like RASPPLE II as being “cheating” or “a silly peripheral that’s more powerful than the main device”, but this misses the entire point. Retro home computers, especially those that lack hard drives, weren’t often used in a connected world, and when they were, they leaned very heavily on larger institutional machines. Projects like RASPPLE replicate this model. It’s not so much a cheat as a time capsule.

Anyway, that’s the model I’m going to follow. I’m not going to start with a RASPPLE if I can avoid it, and instead I’ll lean more towards a replica of what I experienced back at university, which is a UNIX machine offering a shell account. I’m going to leave the door open to increasingly native and local networking clients as I go, but you have to start somewhere.