There is some significant "context" that led up to this Idea. Please be patient.
The early days of personal computers is where I "cut my teeth" so to speak, on software programming. In 1982 I was programming in BASIC, the next year I began doing Assembly Language. My computer was formally known
as a Tandy Radio Shack TRS-80 Color Computer, or "CoCo" for short.
A couple years after doing a fair amount of Assembly Language stuff (I wrote a solver-routine for the cubical 4x4x4 puzzle known as "Rubik's Revenge"), I became acquainted with another fellow who had a Commodore 64 computer.
We had the usual arguments about which computer was better. I was willing to admit that his machine had better hardware hooked up to the "brain chip" than mine, if he would admit that mine had the better CPU. Anyway, the C64 software was certainly superior in one respect; it had a "screen-editor" system for entering commands and writing software. The CoCo only had a "line-editor" system.
Screen editors are the norm these days. Even here at the HalfBakery, typing in the Idea-entry box, all you have to do is press the up-arrow-key a few times to edit a previous paragraph. A line-editor won't let you do that. Each line has a "line number", and you have to tell the computer to EDIT 30 if you want to edit the line numbered 30.
So I decided to see if the software that was built-in to the CoCo ("ROM code") could be modified from a line-editor to a screen-editor. I bought books sold by people who had completely "disassembled" the ROM code, so that it could be analyzed for improvements.
The project took a year and a half, but I succeeded. More, I succeeded in getting ALL my new code to fit in the ROM space without sacrificing any significant aspect of the original code (except the EDIT command, of course).
In the process, though, I learned that there was some rather oddball code sitting in the ROM, never used, called "DLOAD". This command had the purpose of DownLoading data over the computer's RS-232 port. It was DownLoad **only**; no code existed to UpLoad data.
I took that as a challenge. Could I rewrite DLOAD so that if two CoCos were connected via RS-232, they could send data to each other with simple BASIC commands? An immediate problem with the idea was the fact that a certain region of the ROM code was devoted to holding all the possible BASIC commands, and there was no room to add, say, a "ULOAD" keyword.
However! One thing that did exist in the ROM, often-used and working well, was a means of saving data to a tape recorder, and retrieving it later (this was before disk drives became common). Those two commands were called CSAVE and CLOAD (the "C" referred to "cassete" tapes). The computer had a unique hardware connector, for plugging into a cassete recorder. It was not an RS-232 connector, and all the data went through a Digital-to-Analog converter, because tape recorders tend to work with sounds better than bits.
Well, suppose I hacked into the CSAVE and CLOAD code, so that the memory-data it worked with could go through the RS-232 port? Then the DLOAD code wouldn't need to have any code for fetching/saving to the system memory, and it wouldn't need any "Cyclic Redundancy Checking" for error detection, because the CSAVE/CLODE code already had all of that. So the ROM space devoted to DLOAD only needed to hold a driver that could either receive or send data out the RS-232 port.
In theory the idea seemed workable, but in practice, serial-port software can be very very finicky. When two devices are connected, they have to test each other to see how fast they can communicate. That timing-testing-code takes a fair chunk of ROM space, and reduces the range of possible communication speeds. DLOAD either worked at 300 bits per second, or 1200 bits per second, and those were the only choices available.
I might point out that when data was transferred between the CoCo and a cassette recorder, the transmission speed averaged about 1800 bits per second. Why would I want it to go slower, over the RS-232 port?
Well, about this same time I obtained access to a special gadget that plugged into the CoCo (the computer's main "system bus" was accessible by game and other cartridges) and provided a parallel port for sending data to a printer. Sheer curiousity led me to look at the code for the parallel-port driver. I was amazed!
The parallel port had a special signal line devoted to telling the Sender device that the Receiver device was Ready to recieve the next byte of data (one bit on each of eight wires, simultaneously). There was no timing at all involved!
I decided to adapt that notion to sending data over the RS-232 Serial port. If two computers were connected, there were two signal wires passing between them. One computer could use one wire to send a data-bit, and the other computer could use the other wire to send a Ready signal.
The Ready signal would simply be a bit-flip; each time it **changed** from 0 to 1 or from 1 to 0, that would be the signal for a data-bit to be sent. The overall speed of transmission would then depend only on a **very** simple timer: How long does it take, after sending the Ready signal, for a data-bit to be received from the other computer?
After writing the code, I was able to determine that timer value by experiment. When done, I could tell one CoCo to CSAVER the data in memory, **as if** it was saving to the cassette recorder, and I could tell the another CoCo to CLOADR, **as if* it was loading from the cassette recorder, only instead both computers used their RS-232 ports.
Meanwhile ordinary CSAVEs and CLOADs still worked, with the cassette recorder. I had modified the code to test for that extra "R", without needing new keywords. Anyway, over an RS-232 connection, the second computer would simply/directly load the data being sent by the first.
At about 30,000 bits per second! That was a very impressive speed for those days!