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”.
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).
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)
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.
4. Escape Sequences in the Days of Dumb Terminals
OK…let’s unhook the printer and let’s replace it with an “old fashioned” “dumb terminal”.
A terminal like the DEC VT-100 or WYSE-150. Again with dumb terminals we deal with escape
sequences. There are sequences to blank the screen, position the cursor, reverse video,
blink, underscore, etc.
What do we have to do from an OS perspective to make this terminal work? The answer
is–NADA–or at least not much. We already have a serial device driver to set parity and baud
rate and send/receive characters. At the application level we need to learn a new “terminal
control language” pertaining to the installed terminal (VT100, Wyse150)…but that’s about it.
5. The Original Hayes Smart Modem…the PINNACLE of Escape Sequences
OK, let’s take off the terminal and now attach an original 300-Baud Hayes External Modem.
The Hayes “Smart Modem” represents the pinnacle of the power and ingenuity of escape
sequences. Before Hayes modems, all modem phone calls were dialed with a handset. When the
far end answered, either the handset was placed in “a cradle”, or a button on the modem was
pushed to “take over the call”.
In the Hayes modem, touch-tone capabilities were embedded into the modem itself (for
embedded dialing capability) and the modem operated in one of two modes. “AT-command
mode”…or…”pass-through connected mode”. When first powered on, the modem was in
command mode, ready to accept all characters in what amounted to “a string of escape sequence
control characters”. They wer more commonly known as “AT dial command strings”. In this mode
the modem could “dial all by itself” as well as send back return/progress codes of the
dial/connect process. When the far end answered and “Carrier Was Established”,
the modem switched into pass-through mode.
Other modem manufacturers copied the idea with their own but different command sets–IBM
being the best example. However, IBM’s modems failed miserably in the marketplace. They
were good modems, but, the “command set non-compatibility issue” lead to their downfall.
Again, from the OS perspective, the driver for a serial port was accomplished back at the printer
example. It’s only the “modem command language” that presents a one-time challenge. And if
all modems utilize the identical command set language, the challenge needs only be faced a
6. The Moral of the Story
These examples show how a single physical connection and physical OS device driver can be
leveraged over multiple hardware devices. The “Physical” device driver development needs to
occur ONLY ONCE. And if the higher level command languages are standardized for each
device type–those devices essentially become Plug n Play accross any conceivable combination of… computer, OS and programming language.
7. How Powerful Concepts Tend to Repeat Themselves
We’ve alluded to the power of escape sequences as they relate to hardware connectivity. What
other manifestations of this concept can we identify in the general computing scene?
What about Ethernet? Couldn’t we consider the header of the Ethernet message a form of escape
sequence (containing control info–specifically destination address)? Extending on this theme
of enveloping data–what about IP? The entire Internet runs on this concept. Has the architecture
of the Internet ever had to worry about the trivialities of what kind of computer hardware, OS,
or applications are running at the host/user endpoints? Of course not — the Internet as we know it would never be possible!
What about the “markup” in HTML or XML. Markup sure looks like escape sequences. The whole Web
and HTML Browser technologies are based on it. And again, all of them are there tofacilitate
functionality…A One Size Fits All environment!
8. Time for the Meat and Potatoes
Now that we’re in the right frame of mind let’s put on our hardware designer hats. First let’s
select a transport mechanism that presents the flexibility of the old serial port. Three
options immediately come to mind: Gigabyte Ethernet, Serial Bus 2.0, and Firewire. Let’s choose
Firewire (just go with it for now…it’s the concept that is important.)
Now, let’s build the piece of the new hardware system that will, in the words of Jonathan Boyles,
“allow us to carry with us all of our programs, files, context…etc.”
We’ll start with a PDA sized box containing:
– A CPU (either an Intel, AMD, Power PC, Strong Arm, Mips…pick your poison.)
– A 30 gig. IDE mini-hard drive (loaded with our favorite OS…any one will do.)
– Flash Memory containing enough BIOS to run a POST and Boot the OS off the Drive.
– 1/2 gig. of DRAM.
– Time/Date chip with 10-year battery to constantly track date/time.
– A Firewire chip.
– And finally, a single Firewire port in the side of the box.
From a Physical Device Driver perspective our OS needs concern itself with primarily 2
physical device drivers. One to talk ATA/API to the hard drive. The other to talk to the
Firewire chip running the Firewire port.
Now, let’s build a second box. We’ll call it the “Base Station”. It’s the piece that sits on our
desk at home, office, library, dorm, hotel room, etc. It will include:
– A power supply.
– Multiple Firewire ports on the front panel that serve as Firewire Bridge Ports.
– Ports on the back: Ethernet, Cable modem, DSL, Telephone Line, antenna for wireless.
Now with a Firewire cable in hand, lets connect our Personal Box (PDA) into one of the Firewire
ports on the Base Station front panel. Immediately, power flows into our PDA through the 2
Power wires in the Firewire cable. The Firewire Specification actually calls for ports and cables
to optionally source some fairly decent voltages and amps, so for our needs the PDA will be
totally powered off the Base Station.
The CPU comes to life…BIOS runs POST…Boots OS. At this point the OS just sits and waits for
interrupts raised by incoming messages on the Firewire port.
Now let’s connect our “Open Firewire Peripherals”.
– Connect a Firewire keyboard to and empty port on the Base Station and hit a key.
– The resulting scan code is enveloped in a header that identifies it as a keystroke.
– The message is sent out over the Firewire Bus addressed to the PDA.
– It comes into the PDA port and the Firewire Chip sends an interrupt to the CPU.
– The Firewire interrupt handler looks at the header for the “message type”.
– Seeing it is a key stoke it takes the data and stuffs it into the keyboard buffer.
– Connect it up.
– It follows exactly the same principle as the Keyboard–but with mouse packets.
– Connect up the printer.
– This time run a program to send print data within Firewire Packets to print on the printer.
– Since most printers are PCL compatible, your print data packets need to include any of the
proper PCL escape sequences.
Auxiliary IDE compatible…Hard Drives, CD, CD/RW, DVD, Zip Drives…etc.
– Just plug into one of the base station Firewire ports.
Currently available Firewire to AT/API “tailgate chips” allow these to work seamlessly.
Firewire Scanners, Digital Cameras, etc.
– As before, just plug into one of the base station Firewire ports.
In all the above instances the Physical Firewire Device Driver that is resident in the PDA must
look at the incoming “Packet Types”. Then it simply acts as a “SUPER DUPER ROUTER”–routing data
to the proper application or internal buffers. Going the other direction, outgoing messages
have to be enveloped in the correct packet-type and routed out correctly.
Any “control language” tied up in the operation of the various hardware peripheral devices must
be embedded within the raw message data itself and standardized and documented so that
Software/Subsystems/and High-level Drivers can deal with the commands appropriately.
9. The Hard Part
As in all things…some pieces are easy…and some not so easy. The above devices strike me as
being fairly straightforward. But when it comes to Video Display and Sound–there are more
hurdles to overcome.
Sound is problematic in that I don’t clearly grasp it from a low-level standpoint. Sound,
especially the sound chips are extremely proprietary. And in reality, anything analog is totally
out of my realm of knowledge. So I’m just going to ignore it for now, and assume it can be
packaged-up and shipped-out over the Firewire.
From a Video Display standpoint, what I see as necessary is the totally new creation of a
“Standardized Graphical Command Language” used to drive the equivalent of a “Graphically
Capable Dumb Terminal”. Here too, I am a bit fuzzy on what, if anything, is currently available
out there in the marketplace. Does X-Terminal qualify? How about whatever runs that Windows
Terminal Server, MetaFrame, Citrix Systems thing? What is that? Is there an equivalent of a
“graphical terminal” used in that environment?
I believe that whatever would work needs to have a fairly “lean” “low-level” command language
providing capabilities like block-fill with color, line and curve drawing, BitBlit capabilities.
Low level 3-D may or may not be out of the question. What is not desirable is some large
piece of bloat. In this case, I see leaner as better.
Of course this display–whatever it is–would simply plug into the Firewire port.
10. Variations on a Theme
Having brought up Windows Terminal Services and Citrix in the previous section, let’s
momentarily shift gears.
Lets assume we’re at work. Let’s unhook our PDA from the base station, and keeping everything
else the same, replace the Firewire chip in the PDA with a Gigabyte Ethernet Chip. Then let’s
remove the outside covering and repackage our PDA into a “Blade Configuration”. Make the
Blade capable of being inserted into a huge rack along with hundreds of other blades in the
computer room of the large corporation we work at.
Now let’s connect each blade into the Gigabyte Ethernet Network running throughout the
building. At the desktop let’s connect the Base Station to the Ethernet network. Now assuming
correct addressability, the Blade directly communicates to the Base Station through the network.
A SINGLE TRANSLATION that bridges packets from Ethernet to Firewire must occur upon entry or exit
to the base station–before the packets hit the peripherals.
Of course what I’m describing goes by many names…Thin Client, Network Computer. But the overall concept survives package modifications–BLADE or PDA–everything works identically!
With the exception of a readily available “Graphical Display Terminal” and accompanying
“Graphical Display Command Language” it would seem to me that the possibility for this type of
architecture is well within our grasp.
The advantages are:
– True Plug and Play Compatibility.
– Flexibility in Physical Topology and Component Packaging.
– Peripherals increase in overall market scope leading to lower costs.
– Hardware (CPU), OS, Programming Language is totally neutral!
Early on I alluded to some current developments in chips that could be used to drive this vision.
Briefly some of the developments in Firewire chips deal with the concept of “tailgating”. For
instance, chips combining Firewire/ATA/API capabilities allowing for currently available IDE
hard drives, CD, and DVD drives to operate seamlessly over the Firewire. Or another class of
Firewire chips facilitating the streaming of A/V Mpeg from digital cameras. And, in addition,
the advent of open software specifications such as OHCI 1.1 and SBP-2 that facilitate the
utilization of these new firewire hardware chips.
But I’ve already gone on too long–and those discussions are full-blown papers in themselves.
In conclusion, the realization of the dream is to: Preserve personal preferences at the OS and
Application Level, and take advantage of cheap readily available OPEN PERIPHERALS, all in
a simple, fool-proof, PnP environment.
Or as Jonathan Boyles puts it–“To be able to work on your stuff everywhere!”
About the Author:
My name is Jim Kirkley from Columbus, Ohio and I have been employed in the computer field from the early 1980’s. I have been involved in programming everything from IBM mainframes and Series 1’s to PC’s and proprietary point of sale systems.