Comspec’s Microshare: retro networking 1980–83
I thought I would write some notes on some old “networking” tech that I worked on in the early 80s. I have “networking” in quotes because it isn’t really like what you would call a modern network, this was more about sharing particular devices but in some sense the things we’re going to talk about are “switches”. This is the Microshare line of products. I’m doing this all from memory so there’s some chance I have some of the details wrong but I’m confident this is substantially correct.
The general need here was to be able to share Commodore peripherals, especially disk drives, but also printers. These are things like the CBM 2040 floppy disk drive and later the 4040, 8050, and 8250. These devices were not cheap and so when setting up a classroom it was highly desirable to have a single device shared between a bank of computers. Unlike modern computers, the Commodore PET did not use its disk constantly for things like virtual memory and so for the most part the drives were idle; sharing was very reasonable. You could even leave important floppies (or copies anyway) in the drive so they were handy for students.
These devices used an IEEE-488 variant. I’m not sure it was completely conformant to the standard, but it was close enough that standard IEEE-488 devices could be on the bus and they would generally work fine. But the CBM products were specifically designed for the PET variant of the standard in any case. The original implementation had a few very unfortunate bugs, rendering it largely useless, but a ROM upgrade (standard in the 2001-N series) made things quite serviceable and it was normal to get the upgrade with your floppy drive. Dealers did that sort of thing as a matter of course. By the time Microshare was in the picture you could count on the “good” implementation.
The first version of Microshare was an all-hardware solution. The very first version I ever saw was hand wired and full of a lot of ad hoc hardware. I’m pretty sure it was the work of Comspec’s John Lee and I hope I have that name right. The theory of operation is maybe better illustrated by the hardware design of the later versions, so I’ll jump to that, keeping in mind that electrically the devices were basically the same.
The general idea is that the devices to be shared sit on a shared bus and there are a number of inputs which can be multiplexed to the shared devices. In the later versions there was a main motherboard with common logic and a variable number of daughter boards each of which could be connected to a PET. In time Comspec also provided cheaper/longer cables to connect to the Microshare that were electrically equivalent to a standard IEEE-488 cable but lighter and lower quality. This was to reduce the expense again — the standard cables were quite costly and you would need maybe a dozen of them. Since the PET side of the device was always 1:1 you could get away with less.
John’s specialty was in analog circuitry and this was reflected in the Microshare design. You could very much view the device as a hardware switch that connected one PET to the shared side. The main trick if you will is that per the IEEE-488 standard you can stop a PET in its tracks if you assert NRFD (not ready for data) immediately when getting the ATN (attention) signal and it will stay parked there indefinitely. The device design would hold all requests if the shared side was not available. If the connection went idle for a couple of seconds the next device would be allowed to connect. All you have to do to allow the communication to proceed is change the connection to the new blade and release NRFD at the switch. The shared side would by then have already seen ATN and be either holding NRFD itself or else be ready. You could do all this without really having to decode the protocol at all and the early versions did not decode it. There was some queuing logic to keep the requests ordered and sensing to detect activity. I don’t know for sure but I’m guessing this was just some high impedance monitoring and an RC circuit that counted down the time. I don’t think there was very much digital in the whole thing. It took some testing but several units like this were built. Each was hand-crafted and the later models were a lot nicer with the shared printed board and the daughter boards replacing a lot of ad hoc wiring.
Is it a network? I guess strictly speaking it is. It’s a pretty simple one. But then basically nobody had what you would call a real LAN at that time.
Comspec made a later version of this device that was what I would call “software assisted”. The general principle of switching the computers remained but control was placed in the hands of a 6502 processor which acted as a supervisor. This largely replaced many of the functions of what was originally the main motherboard. If I remember right the switching on this beast was basically a bunch of DIACs. Again the processor did not manage the protocol but it did note who needed to be “on hold” and it did the queuing and whatnot. There were more bells and whistles because you could use the processor to manage an LED or two. But, generally, the operation was very similar to the original device. This version was largely the brainchild of Domenic Defrancesco, and I wrote the software which was very simple. I think the whole thing was less than 1k of 6502 assembly. You can think of this as the digital switch version of the original. Most Microshares that were shipped were of this type. I think that amounts to a few dozen units, something like that. Many Toronto schools had the units as school boards were good customers. And Toronto Institute of Medical Technology as well if memory serves. I’m sure there were others.
Both of these were in some sense warm up projects for the zenith of the series. The Microshare 64 which needs a lot more treatment.
As you can guess from the name, this new device was intended to work with the Commodore 64, which was already wildly popular. The C64 had a serial bus (with some extra signaling like ATN) which was kind of like a serial version of the IEEE-488 protocol. There is a bit of dance involved in this protocol where the usual NRFD, NDAC, and DAV are replaced with just CLK and DATA. The trick is that the listener is expected to lower DATA after each byte indicating data has been accepted but can hold it low pretty much indefinitely to pause the conversation. Likewise the talker can use the CLK signal to pause the conversation by holding CLK low for much longer than is necessary. This combination let the Microshare 64 effectively manage conversations on the serial bus, parking whatever needed to be parked. But there was no way any of this was going to happen in a protocol-neutral kind of way. This device was going to have to deeply understand the protocols.
The Microshare 64 (henceforth M64 even though we never called it that) had the most complex build of any of the devices. The core was a 6502a (pretty sure it was an “a”, 2Mhz) with several 6522 VIA chips for i/o support. There were 8 “input” ports where the C64s were connected and one “device” port which was an IEEE-488 port. This is already of interest. The M64 allowed you to connect PET peripherals (e.g. an 8250 drive) to C64 devices because it could map the serial protocol to the IEEE-488 protocol and back. This let you use the bigger PET drives in your lab (or keep your existing PET hardware). This mode was the preferred setup — 8 C64s sharing some number of IEEE-488 devices. However, you could also make a device change (a dip switch) such that input 7 (numbering them 0–7) would be a device port, so you could put 7 C64-s on ports 0–6 and serial devices on 7. Thus both kinds of peripherals could work. The M64 would “learn” which devices were on which port and route the traffic accordingly. Wow, this is starting to sound kind of like a network…
The M64 was configured such that each line of each serial port corresponded to a single bit of an 8 bit wide port on one of the 6522s. So for instance all 8 CLK signals were in one i/o register. Same for the rest. The processor was responsible for having the right bits set to input or output and the serial protocol demands that there are such changes — during talk/untalk switches for instance. The DATA dance for flow control that I mentioned above likewise requires input/output switching but the 6522 was well suited for this as every bit can be independently direction controlled.
The IEEE-488 bus was configured in a very normal fashion with 8 bits parallel data and a few side bits for ATN, NRFD, NDAC, and DAV. The remaining i/o was used for things like beeping (Houston we have audio) and the various LEDs on the front panel. Famously in the right debug setup you could see complex diagnostics by connecting the main LED to an oscilloscope. Or even more crazily to an RS232 printer, though I only tried that magic a couple of times and never with a production unit. The scope trick was a daily affair though. It also provided useful scope triggers sometimes — a good trigger signal makes your life a lot easier.
In addition to all of this, almost all of the 16k memory was used as a printer buffer (zero page and stack were reserved). Any of the C64s could open device 4 or 5 (dipswitch config) and their data would go to the buffer rather than directly to the printer. The printer could be on either of the “device” ports but the IEEE-488 setup was a lot better. If the buffer filled, the device would block as expected while it drained but 16k was quite a few pages of output so generally this meant you could get your output queued pretty quickly. Printer work could be interleaved with normal sharing, so if a disk request came in the buffer would temporarily pause printing while the next request was served and then resume printing when the bus became available again.
If I recall correctly, printing was suspended even if the printing was on “the other” device port. So no serial printing while doing IEEE-488 disk reads. This was because the main i/o code paths were the synchronous ones — the interrupt logic only served to quickly respond to any ATN on any port and get it in a safely held state as quickly as possible. No extended conversations happened except in the main thread of execution.
Timer interrupts provided the signal for making the various LEDs flash to show enqueued and processing status. As well as pending “megaload”. Which we come to now.
Megaload wasn’t a planned feature, but during one of our daily discussions we (me and Domenic) started thinking about the lab scenarios and how it would be normal to load various programs to get things going for the students. It could easily take 2 minutes to load the sorts of programs they were using at the time. The serial bus was just not that fast, nor were the drives. And if 8 students had to load some program that was 16 minutes shot before everyone had the code. That was far too much time and they all needed the same file. And this is where things get exciting. Because all the C64 units were set up such that each signal was a single bit of a byte you could imagine talking to any combination of them by wiggling a mask of bits rather than just one bit. It wasn’t quite as simple as that because of the DATA dance and untalk protocol and so forth but the core of the data flow really was that simple — wiggle up to 8 CLK and 8 DATA lines all at once. Megaload was born.
The protocol was pretty easy but had to sort of interoperate with normal device usage. Basically the “teacher” initiates a megaload by sending a control command (I don’t remember what it was, it’s not important) to one of the reserved device numbers. Normal devices were numbered 0–15 with 16–31 reserved, but we were renegades so we decided the teacher should send a command to device n+16 to kick things off. Something like open 1,24,0, “go_go_megaload":close 1.
This is your intent to megaload. Anyone who wants to join attempts to load from the same device with load "whatever", 24. Those that do are parked at the point where they are set to receive data and their LED flashes at double the normal rate. When the “teacher” is ready they do load “the real thing", 24and that begins the megaload. The megaload might be enqueued but as soon as it happens there will be one mega-talk-untalk session. All of the participants will get the same data signal at the same time as it comes from the device (IEEE or Serial). The “students” request information is ignored, only the “teacher” matters, it is sent to the device to get the data for the students.
The net of all this is that up to 8 computers can get the same data at the same time, so the class can be running in 2 minutes rather than 16.
And that’s the device in a nutshell. It was a long project — I think it started summer of 1982 and finished summer of 1983 with not much time to spare before I went to college. There were many protocols to debug and the tech for doing the debugging was less than great. And I still had a lot to learn about writing bug-free software. Brad Templeton’s PAL assembler was a godsend. Thanks Brad.
Domenic once again designed the hardware; it was a custom 2-layer PCB and it was hand designed with 2 color tape on some kind of plastic or mylar. I double checked every connection for him (I think I found like 2 mistakes in the whole thing). It was a work of art. The hardware was locked down long before I had debugged the software and at about 4k of code the M64 system software was easily the most assembly I had ever written. The device itself was arguably as powerful as an actual C64. Though it lacked video, it had lots of i/o and a very nice little processor.
I don’t know how well it sold. Things were changing a lot at that time and I think by 1984 it was a less interesting device generally. It was a million miles from the original Microshare, and I think a huge accomplishment in 1983.
