Back on June 9 2003, OSNews posted an article by Joshua Boyles entitled "The Edge Computing System". In that article Joshua lays out his vision, "of a new and very unique computing system". In this new article, an attempt will be made to further build on Jonathan's ideas through what can be termed, "Open Peripheral Hardware Connectivity".1. Introduction
In the original article, Joshua proposed: "A system of computing that allows you to carry with you at all times your documents, configuration, and even programs stored in flash memory. And then upon arrival at your destination...your home, your hotel room, libraries...all of these destinations would be equipped with generic computers. So that you would just plug in your very own personalized context(flash), and using your own files, you could e-mail, surf the Web, edit documents, essentially do anything you would do at home or work."
And then Joshua sums it all up, "That's the point of this entire system, to be able to work on your stuff everywhere, to never have to worry about anything being left behind." My apologies to Joshua if I, in my paraphrasing, have mangled any of his insights. But, this is pretty heady stuff for an 18-year-old. And in my estimation...HE'S RIGHT ON!
But, hasn't this always been the computing Holy Grail? To have something portable you can take with you. Something that's ubiquitous. Something, similar to, and as simple as the telephone. Just plug it into the wall...and have it work every time, giving the equivalent of "digital dial tone". Yes, that's definitely the idea. But, in my mind (up to now) the quest for this envisioned level of ease and simplicity has not happened.
2. Where We Have Been
I'm over twice Joshua's age (coming up on the big 52), and I have been in this PC arena since the early 80's. I've built my own homegrown computer systems (about one every 3 years) and in every case I've struggled! Why did things magically work when I reloaded it for the 5th time? I did nothing different!
For all those "old-geezers" out there, remember back in the early days. It was jumpers and conflicting IRQ's. Or config.sys files listing the device driver files that needed to "be loaded in a specific order". Remember all those memory managers and extenders? Then along came P&P...Plug and Play that is. Has It Really Ever Worked? Oh let's not forget the dreaded DLL. The one that every software vendor on Earth has the opportunity to overlay with his own version -- breaking everything!
No things really haven't gotten much easier. BUT, there are some recent developments on the scene that have the opportunity to change things and make things much more seamless. And that THING can be expressed in one word......CHIPS!
But before delving into the meat and potatoes of this proposal I want to go back to my very first computer and explore a powerful concept that permeates the computing landscape. This is a concept that has wide ranging implications towards what I'm about to present.
3. What the Heck's an "Escape Sequence"?
My Dad worked his entire career for IBM. And as soon as the Original IBM PC hit the scene, he got on the waiting list to purchase one. Finally, it came. The printer it came with was the IBM Epson Printer (dot matrix, 80 characters per second). It ran off the Parallel Port...but for our discussion, let's assume it ran off the Asynchronous Serial Port.
Of course the first thing I did was to learn the IBM Interpreted Basic Language and make the printer print something. I soon grasped the concept of "escape sequences". Escape Sequences are "non-printable characters" that can be randomly intermixed with the other "printable characters", to do things like: Turn On wide character printing, Form Feed the paper, etc.
For me, the most important concept I learned regarding escape sequences is this. The printer didn't know what was attached at the other end of the cable. It could be an IBM PC, an Apple, DEC Rainbow, a Mainframe. Also, the printer didn't know or particularly care what OS or Language was running at the other end. The bottom line was that as long as the printer received ASYNC characters at the proper baud rate and parity...the printer would work as designed.
The printer just looked at each character coming in--and it either:
1. Printed the character (if it was printable).
...or...
2. If it was an escape sequence, the printer preformed the "required change of state".
(i.e...Turn on compressed print or maybe do a form-feed)
...or...
3. If the character were unrecognizable, the printer would simply ignore it.
It would just figuratively drop it on the floor...and then go on the next character.
The second most important point of all this was the following. The designers of the printer only had to test that printer a single time. As long as the characters coming into the Printer met the Physical Connectivity Specifications of Asynchronous Serial Ports--that printer would work as specified. And as new computers, OS's or Languages came along; the only reason to retest the printer would be to uncover bugs in the new Computer, OS, or Language.
The sole challenge on the computer side of things was to develop a Physical Serial Device Driver for the computer's OS. The main function of the driver would be to provide an API to allow a language to set parity and baud rate, as well as send and receive characters.
Furthermore, as the IBM line of printers added capabilities, new escape sequences would be added to what could be termed as "the printer control language". But these extensions were always just that...extensions. Another way of saying it is that minus new functionality, the printer command language was always backward compatible to the previous level.
- "Open Peripheral Hardware Connectivity, Part I"
- "Open Peripheral Hardware Connectivity, Part II"
- "Open Peripheral Hardware Connectivity, Part III"
- "Open Peripheral Hardware Connectivity, Part IV"
