Around about 1985/6 when I was doing my electronic engineering apprenticeship at Link-Miles in the UK (flight and vehicle simulation), we had a requirement to link together various bits of RS232-connected equipment as needed and between rooms and labs that were spread around the site - for example, we needed terminal comms from our PCs to a VAX 11/750 and various serial printers, plus we had custom equipment racks around the place (including Meiko Transputer development systems!) and also serial-connected device programmers (PROM/EPROM/PAL/GAL) and so on.
After a bit of digging, I found 'Infa Communications' and their 'Infaplugs', which carried serial traffic round a ring of 75 ohm coax between the plugs. The system also had a simple connnect/disconnect command language (similar in principle to the Hayes/AT modem command set), so I wrote a TSR (terminate and stay resident) 'switchboard' program in Turbo Pascal, which allowed users to change link destinations as required, and could also intercept terminal comms so that print streams coming from the VAX to the local terminal could be grabbed and redirected to elsewhere - you could even program an EPROM in the lab from your office desk (although you'd have to phone and ask someone to pop one in the Stag programmer!).
It was all very cool for its time and avoided the need for dozens of long runs of screened multicore cable and multiplexers all over the place - it all worked very well, but then came the familar sight of thick yellow Ethernet coax everywhere and the writing was on the wall for the Infaplugs.
...not SLIP, as knee-jerk might assume (I did). This is a clever hack to use RS-232-as-a-bus plus all of the trimmings of a networked filesystem. Pretty impressive!
SLIP, being just a simple encapsulation for IP packets, might even work on this shared serial bus. Provided that some sort of collision detection would be implemented, so not to waste too much time transmitting corrupted packets.
Econet was awesome --- by default the Econet ROM for BBC Micros ran a server which supported a variety of useful RPCs. These included:
PEEK - allows one machine to read an arbitrary chunk of memory from another.
POKE - allows one machine to write an abitrary chunk of memory to another.
JSR - allows one machine to send an executable chunk of memory to another station, which then executes it (max size 128 bytes).
HALT/CONTINUE - allows one machine to freeze another (so that you can use the above calls to fiddle with its memory).
These were system calls and required programming skills to use, but the ROM provided various human-usable commands like * VIEW (which copies a remote machine's screen to yours), or * REMOTE (which slaves a remote machine's keyboard to yours). You could tell your machine to stop listening to all this stuff with * PROT, but it was all on by default. (And * PROT wouldn't protect you from commands sent from particular privileged addresses.)
[Note: system shell commands on Acorn operating systems traditionally started with a * , but HN is having trouble rendering it. Ignore the spaces between the * and the command name above.]
It's not like they weren't aware of the security issues; you only found out about the commands above if you looked at the special manual (http://chrisacorns.computinghistory.org.uk/docs/Acorn/Manual...). Or, you know, if you looked at the ROM, which had a handy list of all the commands in the table at the top. Did I mention that Econet was heavily used by schools?
Oh, and the file server sent all authentication information over the wire in plain text, but if you got far enough into the system to realise this, you were already past the point where hashing the passwords would have been useful.
It was a different age.
To be fair, for the early 80s, Econet was pretty awesome. With care you could run it up to 60kB/s, which was blisteringly fast for an 8-bit system; faster than the BBC Micro's floppy disk, which was already pretty fast (10-20kB/s; C64 users would weep when they saw how fast a BBC Micro could load off disk); at the low level it supported multiple networks with bridging, individual machine addresses and ports, allowing you to write proper client/server code --- a printer server came as standard; the built-in network file system was superb, supporting multiple users with authentication and unix-like file permissions; and it was properly hierarchical, of course. Its comfort zones was big networks of BBC Micros (and, later, ARM machines) all talking to a central file server, and it did that pretty well. But secure it wasn't.
Sadly I didn't get to play with EcoNet even though our school had a computer room full of BBC B micros (and one 380Z).
Having been deprived, I am wondering how Econet actually was supposed to be wired up. Was it like early thin net ethernet with DIN instead of BNC cabling? Or was it 'hub and spoke'? I can't imagine there were ethernet style routers/hubs for EcoNet but the teachers were supposed to have some type of god-like power over pupils' machines so I would like to know how that was supposed to work too.
The bus itself was two twisted pairs, one for clock and one for data (he says after looking it up), mediated by a MC68B54 data controller. Computers appear to have been patched in in parallel.
Each segment had to have a terminator at each end plus a powered clock driver, which meant that setting up ad-hoc Econet links was basically too hard. The speed of the clock determined the transfer rate of the network.
There were routers, which would bridge between multiple networks --- they connected to multiple Econet segments and just relayed packets addressed to the other network. Apparently their primary purpose was to speed-match between BBC Micro networks, which had to be quite slow, and Archimedes networks, which could be much faster.
The hardware's painfully antiquated by modern standards, of course; I2C is faster and cheaper and doesn't need clocks or terminators or any of that nonsense. Also, from flipping through the Advanced User Guide, it looks like it's entirely packet based, but it does a four-way handshake for every packet --- effectively setting up a connection and tearing it down again! Which gives you reliable delivery but at a huge cost. We forget just how good TCP/IP is.
I suspect the god-like power mentioned was simply having a copy of the Advanced Users Guide and knowing about * VIEW and * REMOTE. Also apparently there was an Econet interface available for the 380Z, so your school was totally missing out there.
> You might have noticed that the hardware we used was a nasty hack – the shared bus was floating around 0V when nobody was transmitting or when someone was transmitting a zero (which would be -12V on a regular RS-232 connection), so it was extremely prone to electromagnetic noise.
A simple pull down resistor would have helped in this case.
For sure they will have used this (and just not have drawn it in the simplified diagram) as RS232 receivers would be very bad at pulling down the line, even to 0V. I cannot believe that this would have worked, even at slower baudrates, without any pulldown.
But even with the pulldown, you will be limited in speed as you have to charge up the capacity of the "network cabling" to the idle level. Any resistor (high enough so that the RS232 drivers still can drive the cable to a sufficient "high" level) will need some time to reach the threshold of the RS232 receivers.
A million years ago I was an Atari ST user. I recall my roomie and I had a LAN between our computers, using the ST's MIDI interface. At the time, MIDI's 31kbps was blazing!
I just did some searching to see if I could find that software, but can't nail it down. I did find that hackers have taken it much farther. Apparently it's been developed to the point that you can do Ethernet, as referred to here: http://paradize.final-memory.org/sting1.shtml
I fondly remember playing 'Midi Maze' on the ST back in the 80's. LAN gaming has moved on a little, but I remember the joy and amazement of playing it :-)
I love these old timey hacks, back when people had to be clever to get anything to work because the computers were so pitiful. I'm really impressed how he implemented not only networking, but OS integrated network storage in only a handful of kilobytes on a machine that is thousands of times slower than a smartwatch.
This brings back some ancient and hazy memories. Some time between 1986 and 1987 we installed these Sage (yes the same Sage that sells accounting software) "network" cards in a bunch of machines running DOS. The cards had two RS-423(?) interfaces presented on DE-9 connectors. You daisy chained machines with what appeared to be pretty standard looking serial cables and terminated each end of the network with a termination plug.
There was a redirector which loaded as a TSR (I think) and you could map drive letters to disks and folders on different machines. It wasn't terribly quick, and could sometimes be a bit temperamental, but it certainly helped with squirting files around our office and workshop.
I wonder if any older members of the HN community remember these things and could fill in on any gaps.
Yep certainly do. The cards and software were written for Sage by a company called Alfa Systems formed out of the remains of Sinclair (David Karlin who designed the QL, Rupert Goodwins who wrote bits of Spectrum ROM and few others) with an ex-Amstrad employee called Vik Olliver who now works doing various things with 3D printers in New Zealand.
The product was called MainLan and I started working for Alfa working on an integrated Ethernet chip called Enzo (mentioned in Byte April 1990) which needed very few extra components (chip nearly worked first time apart from an address decoding bug which was fixable with a PAL, I think from memory the PS/2 MCA version was correct)
Dunno how many Sage sold but we did a few revisions eventually making a 10BASET version and a parallel port one.
At the time it could send packets faster than some 8390 based cards could receive crashing the receiver (I suspect it was DMA timing problem)
When we developed the Novell IPX driver for the card the driver software was uploaded to the Novell test site via a 2400bps modem with a IPX packet driver so we just copied the files to a file share on a box in Utah from London.
At the time the biggest problem was the lack of documentation on how the MSDOS network redirector worked which meant we had to roll our own, we also found that Norton commander used some really obscure FCB calls to change directories rather than dos 2 and later handle based calls.
Brings back many memories of being a young 20 year old.
"MainLan" - thank you! I'd been racking my memory cells for the name of the product. In the original mid-80's product with the DE-9 connectors, was it RS-423 that was used, or something proprietary?
The DE-9 version was before my time (in development terms) I think it used RS485 and a Z8530 but the 4Mbps speed feels a bit quick for those technologies.
I can still remember the prefix 00802C which we used for Ethernet addresses and at one point I ended up decoding Ethernet packets from an oscilloscope to make sure we were getting the CRC calculation correct. There are a few ways to compute a CRC and some books incorrectly say that starting the shift register with all ones is the same as inverting the first 32 bits into the register, I suspect this is because the error detection effect is the same.
Somewhere I probably have a card or two and I might have the schematics lurking around but they'll be in the basement somewhere.
If that was SageNet, I had moved on when that came out and had been headhunted by the VAR that supplied our IT kit. I went to the SageNet launch event, but we were already with Novell - yay for Netware Lite!
The SageNet name rings a big bell. We only ran this thing for about 12-18 months and by then the price of NE1000 and NE2000 cards had dropped in price so we went ethernet + Netware 286. I ended up working part of my time as a Netware field engineer from 1989 to 1997. Oddly I only ever encountered Netware Lite in my travels a handful of times over the years.
> it was neigh impossible to get custom hardware into that computer (it had no expansion slots)
This really does not do justice to the fact how incredibly frustrating it was to work with this hardware. Not only expanding it, also servicing. I can't find a photo of a disassembled Partner on-line, but the white box with monitor you see in the article: it's crammed chock full of loose wires, small boards, individual components, high voltage stuff pressed against low voltage (blew up a multimeter once because of that)... Once it was assembled in factory it was almost impossible to take it apart, much less run or test in a disassembled state.
PLIP, SLIP, PPP ... those were the days. Linux could do anything, and *BSD still had a defensible set of PC hardware drivers! TCP/IP was fascinating, implementations were buggy as hell, and the internet was yet to be militarized! Telnet BBS still existed! What on earth were we thinking back then? Acoustic coupling? Infra-red networking? PCMCIA cards? Serial and PS2 ports? Hah! Glad to have USB, wireless networking, less cables, higher speeds. Kids these days don't know how good they have it...
Coincidentally I'm currently in the process of networking 2x 80s micro computers (an Amstrad CPC 464, Dragon 64) and a raspberry Pi together via RS-232.
The PCs run BASIC (Locomotive and Microsft, respectively) rather than CP/M. Though there's certainly CP/M and DOS ports.
The eventual end go would be having full SSH capabilities (using the Raspberry Pi to offload the encryption side of things) on 8bit machines so I can work from home on 80s hardware.
I'm sure the novelty will wear off quickly, but I enjoy these little technical challenges.
I'd echo that request, I love reading about things like this - that era of computers from my youth, and forcing them to do some useful work today. I have an Olivetti M15 that I plan on connecting to the internet via a pi at some point...
Recently I had to do some work on a small embedded system. During development, we had an Ethernet port with associated magnetics on a riser board. But once it went to production, we couldn't fit that so there was only a UART serial port. Through use of PPP and a Linux laptop, it was like the machine was on the network as far as use for ssh, gdb, etc. I thought it was a pretty cool trick going back to the 56k modem days!
In 90's I did something similar (hardware wise), only not with bus, but with central "hub" consisting of matrix of diodes (arranged such that each station would send data to each other, but not back to itself).
As for framing I used two upper bits of byte as overhead and only transferred six bits per physical 10bit UART frame (original inspiration was 8051's "9-bit networking").
That's slightly different, in that Starcraft's system used RS232 in a standard point-to-point fashion. If you wanted to play with three or four people you had to daisy-chain and the one or two in the middle were effectively acting as routers.
This is hacking RS232 in to a bus network more or less.
I remember doing plans of something similar to this with PIC 16Fxxx to have some machines on some kind of cheap small LAN. I remember even writing the protocol on paper...
Extra: The Sinclair ZX Net was some kind of cheap like RS-232 on a single wire plus ground (using audio wire!). Take a look to the schemes of Sinclair Interface 1
I remember doing the exact same thing as a group project while in University. Anybody else remember writing Terminate and Stay Resident (TSR) DOS programs?
After a bit of digging, I found 'Infa Communications' and their 'Infaplugs', which carried serial traffic round a ring of 75 ohm coax between the plugs. The system also had a simple connnect/disconnect command language (similar in principle to the Hayes/AT modem command set), so I wrote a TSR (terminate and stay resident) 'switchboard' program in Turbo Pascal, which allowed users to change link destinations as required, and could also intercept terminal comms so that print streams coming from the VAX to the local terminal could be grabbed and redirected to elsewhere - you could even program an EPROM in the lab from your office desk (although you'd have to phone and ask someone to pop one in the Stag programmer!).
It was all very cool for its time and avoided the need for dozens of long runs of screened multicore cable and multiplexers all over the place - it all worked very well, but then came the familar sight of thick yellow Ethernet coax everywhere and the writing was on the wall for the Infaplugs.