I spent the past week reading articles on wikis and websites, scans of technical manuals and reports, and emailing smart old men about their computers back in the 1960s.
At some point I bought the game Tunnet, which is an addicting indie horror-incremental game about building an underground computer network after some apocalyptic scenario, and dodging a few monsters while you do it. You drill your own tunnels and lay miles of wires and build networks and subnetworks using a limited set of upgradeable tools. It is a 'zach-like' game, which I think is a funny name. It is unique and atmospheric and I enjoy a lot of things about it. However I became frustrated enough with its design that I wanted to design my own. Your focus is on building and optimizing a network. You can do stuff like yank all the wires up every time you want to optimize the whole thing again. But there are fundamentally only two shapes a network in Tunnet can be: a tree or a straight line. There’s no realistic way to create a graph or route packages non-linearly. There also isn’t any risk to stopping everything and redoing it again.
There is money in the game, but you can only earn it and spend it, you can’t lose it through poor performance or inaction. You earn lots of money which never stops flowing in as long as one mainframe is hooked up, even if it is inefficient. That bothered me, because I like tycoon games with a creative element, but also potential risk and competition. The idea that was percolating in my head and across a few notes grew really large, because in real computer networks there are a lot of moving parts, and I wanted a very granular level of control over both the WAN network and the node LAN networks. For me, a total novice, it would be too big. So I split it in half, a 'state networking' game and a timesharing game, and I’m focused on the latter right now, and spent my time researching for.
I had no idea how old computer networks and timeshares worked logistically, so I started reading about the earliest ones. Things like what they charged for and what costs of running were like. I aimed at the earliest systems from the 60s and 70s because that felt like a very ‘ripe’ moment where a player could realistically take over a position managing the bills, what equipment should be bought, which terminal goes to who, negotiating with the phone company, etc. Where Wizards Stay Up Late is a great book for learning about ARPANET, and I have liked reading it so far. It goes for a very nice level of detail in terms of the overarching design, person-to-person interactions, who influenced who, reasons for the network coming to be and the early history and character of ARPA. More technical information about how the network functioned is fairly well documented too.
But learning about the nitty-gritty of how early timeshares operated and in particular handled remote connections was more spotty, though. I ended up focusing on CTSS the most so far, because there is a lot of information about it and Multics on multicians.org; But plenty of questions left unanswered. I was compelled by the idea of people remotely accessing CTSS from home via modem, but had no idea how they did it. I emailed Tom van Vleck about it and it turns out, they had a PBX for the local telephone network, and opened a second ‘Data PBX’ specifically for interfacing with computers, that users could dial into from as far away as Europe. If you wanted a terminal in your home office, or the university wanted you to have one, you could buy a second phone line and have the cost reimbursed, then call in with your terminal of choice. Engineers would ‘break in’ the lines when they were installed to reduce echo and noise.
The Data PBX was automatic and when you dialed in, it would search for an open line in ‘hunt groups’ until it either found one or had to report back that number was all tied up. I have to imagine there were callers fighting to get online once the system got popular. CTSS’ hardware and surrounding infrastructure is neat. They had European calls they occasionally received and had to set up in advance, and weird modems they had for various network related experiments which weren’t wired into the normal system. Their mess of modems were all on the floor behind their communications controller, the IBM 7750, because every remote connection needed it’s own receiving modem at the mainframe.
I found the naming conventions of this old computer hardware confusing. The 7090/7094 CPU had ‘data channels’ which seems to refer to both the connection type and the units attached to the CPU which handled peripherals or tertiary units. As of 1963 the 7090 had five Data Channel units of different types delegated to different responsibilities. All of the networking duties were handled by a 7909 labeled channel E, which connected to the 7750 communications controller that handled teletypes. Also of note, was a project that used the 7750’s high-speed 1200 bits-per-second adaptor to connect to a PDP-1. It was a project for Alan Kotok’s master thesis and according to Stan Dunten, who I emailed to ask about the 7750, was never used and barely worked. I will be emailing Alan with questions about it.
The 7750 is neat, both because of it’s weird 48-bit word length and split memory, and because the one at MIT at the time was only outfitted with two 28 channel multiplexing channel adaptors. It had a total of 56 connections, but it could handle as many as 16 MCAs, so up to 448 possible connections! CTSS could only handle thirty concurrent users due to memory and processor limitations, but a beefier computer could theoretically handle many more through that interface.
All this information is being poured into a game I am cooking. It's been a good time. But I have a lot of work to do. I’ll post with new information and progress on my game. Right now, I’m designing a UI library
. I want it to look like smalltalk on a Xerox Alto, black and white with maybe some splashes of primary colors for style.
