Computer: Algorithm
Serial Connection with Less Timing Dependence   (-1)  [vote for, against]
Inspired by parallel-port software

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!
-- Vernon, Feb 24 2012

I smiled as I read this; my dad was a tinkerer of this sort back in the late 70s/early 80s. I wonder if hardware enthusiasts still muck about in this fashion with the modern machines?
-- bungston, Feb 24 2012


The journey, man - the journey!
-- bungston, Feb 24 2012


//I wonder if hardware enthusiasts still muck about in this fashion with the modern machines?//

I recently acquired and have been playing with an Arduino kit, and I admit that the thought of being able to use it to connect essentially any electronic device to any other one makes me a bit giddy.
-- ytk, Feb 24 2012


// if he would admit that mine had the better CPU //

The secular conflict between the adherents of the 8080A and the Z-80A, and the supporters of the 6502, only ended in the virtual extermination of both clans. There is still an underlying current of bitterness between those who espouse the AXY architecture and the followers of multiregister CISC.

More prolonged bloodletting is inevitable.

On the Commodore Pet, it was possible to cross-connect two machines via the spare 6522 "User" port and the CA1 and CB2 lines as handshakes and achieve EVEN FASTER 8-BIT PARALLEL TRANSFERS ! MUHWHAHAHAHAH ! WE'LL CRUSH YOU ALL ! ALL, DO YOU HEAR ? AHAHAHAHA !

Ahem.
-- 8th of 7, Feb 24 2012


[8th of 7], the CPU in the Color Computer was a 6809, the same that NASA used in the first computers installed in the Space Shuttle. Its I/O bus was only 8 bits, but internally it had several 16-bit registers, any of which could be directly loaded from memory in 2 blocks of 8 bits. And the instruction set made it easy to write position-independent code. And, there was a UNIX-like multitasking operating system available for the CoCo, which ignored the ROM code altogether, and booted from floppy disk.

I'm pretty sure that my claim to have a better CPU, than the 6510 in the Commodore 64, was quite valid.
-- Vernon, Feb 25 2012


Yes, but Commodore used the 6809 on the CBM 8096, the 80-column screen version (still monochrome, though).

Ultimately the 6809's parent was the 6802, a kissing cousin of the 6502. It has a nice 16-bit index register, but apart from that it's rather more limited; the 6502 has some nice addressing modes that effectively allow Page Zero to be used as 256 extra accumulators.
-- 8th of 7, Feb 25 2012



random, halfbakery