Local Area Networking on RS-232
ipspace.net
ipspace.net
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.
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.
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.
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.
A simple pull down resistor would have helped in this case.
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.
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
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.
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.
I too was 19-20 years old circa '86-'87 :)
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.
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.
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.
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").
Page 10 of the manual mentions the 4 player serial. https://www.scribd.com/doc/25478804/StarCraft-Manual
Was a pain to setup but we used to do it that way before we all went out and bought some IPX compatible network cards.
This is hacking RS232 in to a bus network more or less.