Recently, an article published in OSNews by Joshua Boyles entitled “The Edge Computing System” captured my attention. This led me to publish my own article entitled “The Next Big Thing? Open Peripheral Hardware Connectivity.” I appreciate all the feedback, but I feel that there is still a certain amount of confusion concerning what I was proposing. So, here is a Part II. follow-on article…with some insights that hopefully may flesh things out a bit more.
First of all, a quick rehash.
Joshua Boyles in his original article was trying to come up with a world of computer pervasiveness. A world that would allow you to sit down at computers at different physical locations (schools, libraries, hotel rooms) and have your data, programs, and preferences follow you around. Joshua’s solution was mainly “software-based”. By utilizing a flash memory card containing all your programs, documents, and settings; you could insert this card into standardized computers loaded with a standardized OS. And thus you could carry everything with you and run your applications anywhere.
On the other hand, I presented an idea that was based more on the “hardware side”. I tried to come up with a “minimal PDA-sized box” that consisted of CPU, memory, and hard drive. This would be the piece that you take with you. And on the desks at the remote locations are “base stations” (really a firewire bridge) with multiple firewire ports on the front panel. Into these firewire ports are attached what I will term “open firewire peripherals”. These are the bulky or loose things you don’t want to drag along. Things like keyboards, mice, printers, displays, scanners, etc. In addition, on the back side of the base stations would be ports for phone(modem), Ethernet, cable modem, wireless antenna, etc.
The most important piece of this vision is that the portable piece that you carry with you is totally agnostic as to the choice of CPU and operating system. Your PDA needs only contain the CPU/OS flavor you prefer. Intel running Linux or Windows. Power PC running Apple. Any combination works! Everything from file systems to document types, applications and personal setting–they all work as they always have. And why wouldn’t they? It’s your PDA hard drive that boots your normal OS and runs your normal programs, isn’t it?
However, there is one thing different that OS’s in this new world must do: On boot-up, these OS’s must present the user with the “option” to load Open Peripheral Environment Support. In the event this option was chosen, the OS would to agree to communicate with the peripherals over a single “physical bus protocol” and also agree to communicate with each peripheral in a predetermined and standardized “logical open peripheral protocol”.
Just what is this thing…protocol? And why are there two protocol’s…physical…and logical?
A “physical protocol” represents a set of rules that apply at a very low level. They are mostly electrical in nature. Usually these physical protocols tend to be no-brainers. Physical protocols are all buried down within the chips themselves. Just simply plug things together and they work–at the “physical level” that is. Plug in a wall-lamp and the light goes on. In this case “physical” is tied up in concepts like, voltages, amps, alternating current, power plant, power grid, wires, filament–VOILA!
The “bus-part” of our physical protocols are concepts like Ethernet, USB, and Firewire. Each of these different buses is a sort of “unique power grid”…and each follows its own set of voltage, amperage, and all sorts of other electrical rules. But the primary purpose of these “grids” is not to deliver power…but data. To use the properties of electricity to “encode and transmit the
information”…in either electrical analog waveforms…or electrical binary digital pulses.
The bottom line is, we have to choose one of these buses to become our standard. I’m going to choose Firewire. (We can argue if that’s the best alternative in the posted comments.)
Now, turning to the “logical” side of the equation…specific logical protocols for each device must be specified and adopted. Logical protocols are rules proscribing “the how” of the conversation. For instance, who talks when (the back and forth banter)…and “the content” of the conversation (the data format of the banter). For example, key boards converse in scan codes, mice in mouse
packets, printers in printer control languages.
Does this mean we force new standards on everyone? No! Not at all! We could adopt something like the following:
– keyboards would follow Microsoft/PC “scan code” conventions including the new multimedia keys.
– mice would follow Microsoft Mouse Packet format.
– printers would follow HP PCL 6.0.
And even if you don’t buy-off on the PDA/Base Station concept–that works too! But at least preserve the basic thesis–and modify OS’s to provide the “option” to run Open Peripherals. If the OS becomes “open peripheral compliant”, then any open peripherals will be capable of running on any: desktop, laptop, tablets, game consoles, embedded systems, banking terminals, point of
sale systems, cash machines, kiosks, etc…
1. Preserve and expand freedom of choice in that even the most obscure CPU/OS combination would never suffer from a lack of potentially supported peripherals.
2. Peripheral makers would enjoy a wider market for their products.
3. Certification testing of open peripherals against required specifications need happen only once (see original article).
4. True PnP compatibility.
5. Flexibility in component packaging and physical topology (see original article).
And…that’s it in a nutshell.
The original article garnered much in the way of feedback. Some were worried about stifling
competition. Others were more vehement. Maybe this would cause companies to go out of
business, or some people to lose their jobs. Others opined that we already have standards. Many
said that what I proposed “was already here today”. Some were for using the UDI specification to
facilitate device driver development. Some were fuzzy on what a device driver was, confusing it
with the firmware in a peripheral. Some had the notion that this would ruin file system and
One commenter pointed out that: even though I may be a veteran programmer (old)–I sure didn’t
know anything about hardware! Another asked if I had ever been affiliated with the “Communist
Party”? No he didn’t…I’m just kidding! But, I really did enjoy all the comments, and thank
everyone who took the time to respond–in any vein…
Anyway, what I’d like to do now, in the balance of this article, is to figuratively put my money where
my mouth is. I’d like to demonstrate this open peripheral idea in more practical terms. What
follows is a sort of “case study” laying out in more specific terms how all of this would work.
The case study will involve the birth of a new company–JGP–Joe’s Game Peripherals. Now it’s
time to begin our story…and set up the straw man. So that when the story is over, all the old posters
out there, and hopefully some you new ones–can take a whack at it!
We’re going to do 5 things (I’ll try to be brief):
1. Do a basic walk through of the 1394 Firewire Specification (only a dozen bullet points).
2. Design a minimal Open Firewire Peripheral API conformant device driver:
– a. Define the driver requirements to interface “down” to the firewire chip (5 bullets).
– b. Define the driver requirements to interface “up” to the application programs (6 bullets).
In other words…an Open Firewire API.
3. Create a company to build an open firewire peripheral for the game industry (case study).
4. Write a game program that will be able to use the open firewire peripheral.
#1. Learn Firewire in 12 easy steps:
– Firewire is a bus topology that allows nodes to communicate peer to peer.
– Up to 63 nodes can share the bus.
– Nodes on the bus each have a unique address from 0 to 62.
– When power is applied to the bus or a new device is “hot-plugged” into the bus
all bus traffic stops and an “automated self-address phase” occurs.
– Automated self-addressing results in each node being assigned a unique node
number between 0-62.
– This self-addressing should be thought of as “totally random”…never assume that the
address for any single node can be predetermined.
– Nodes communicate with one another by sending information packets out on the bus.
– Firewire packets contain a leading header and trailing raw data.
– The header contains 4 important pieces of information:
1. Source Node address – i.e. node number of the sender.
2. Destination Node Address – i.e. node where this packet is intended to land.
3. Destination Port Address – i.e. application at the destination node to which this packet is intended to be delivered (like a TCP port#).
4. Length of Raw Data portion.
– Packets containing a Destination Node Address from 0 to 62 will be delivered “only” to “that specific node”.
– The Destination Node Address of 63 is the special case “Broadcast Address”.
– A packet with a destination of 63 (broadcast address) will be delivered to all nodes.
OK…that wasn’t too bad.
On to #2a, the Open Device Driver physical interface.
#2a. Defining the Open Firewire Driver interface to the “lower physical layer”:
– Driver must after each bus reset, save the currently assigned “local” node address.
– Driver must be able to receive & parse any delivered packets (full header and data).
– Driver must be able to create & send packets (obviously full header and data).
– Driver must reserve a buffer to fully store the “largest possible” broadcast packet.
– Driver must permanently store the “last received” broadcast packet in this buffer.
That was simple. Now, let’s tackle #2b, the Open Firewire API.
#2b. Defining the Open Firewire Driver API:
– Driver must minimally give user applications the capability of calling the equivalent of the following 6 functions:
1. AllocFireInboundBuffer (BufferLength) – Very much like a File Open statement.
– Allocates buffer space for inbound firewire packets in kernel memory.
– The function also returns a “PortNumberHandle” that serves two purposes.
1. The “PortNumberHandle” acts as a handle in all other firewire functions.
2. The “PortNumberHandle” also serves as the local destination port address.
2. GetFireNodeAddress (PortNumberHandle) – Returns the current local node address.
3. GetFireLastBroadcast (PortNumberHandle) – Returns the last received “broadcast” (data only…no header).
4. ReadFire (PortNumberHandle) – Returns data from last “regular” received message.
5. WriteFire (PortNumberHandle, AppBuffer, DestNode, DestPort)
– Packetizes the application data and sends it off to the DestNode/DestPort.
6. CloseFire (PortNumberHandle) – This is just like a File Close Statement.
– Recoups kernel buffer memory and the Port Number.
OK…all the messy details are over (heck, it was only one page). I hope at least some of you have
Now for the fun part:
#3. The Birth of a Company…Joe’s Game Peripheral’s:
Joe has always been a hardware junkie. Small embedded CPU’s, bread boards, soldering irons.
Joe’s lifetime dream has been to design, build, and market a game controller. Something along
the lines of airplane controls.
His concept is…a shaft, extending out from the controller base that you can push-in and pull-out.
A steering wheel attached to this shaft that turns right and left. And finally, right and left foot
petals, like a car accelerator. The shaft and steering wheel simulates the pilot’s yolk. Push in on
the wheel to dive…pull back to climb (elevator control). Turn the wheel in either direction to
simulate aileron control. Push on the petals for rudder control.
Joe knows exactly how he can interface all these things up to a micro-controller. He knows he
can create packets of information containing the “state” of each control surface. And he can
comfortably bundle all these into “a single packet snapshot”–and send it off at any sample rate
up to 500 times a second.
But where does this leave Joe? What kind of physical connection does the computer or game
console at the other end want?
Most game consoles are closed from a peripheral standpoint. And even if he could pony up the
money to get non-disclosure information–do you think that Sony, Microsoft, or Sega are even
going to give Joe the time of day?
OK…consoles are out…let’s move over to the PC world. Let’s take a Window’s flavor box and
look at doing an async port connection. But, what if this PC is already using both it’s async ports.
Now I’ve got to get the customer to buy one of those “add-in” boards–crack open the case.
BONG! You’ve probably just eliminated a major portion of your market.
But for those who “do” have an available port…somehow it’s got to get activated. How many out
there have tried to hook something to a mother board async port–and failed miserably. Then
weeks or months later, when doing something with the BIOS, you discover the problem! The
BIOS has had that port deactivated all this time. It was probably some card (from long ago)
that required the deactivation. So now, Joe only sees this as a potential can of worms. He can just
envision tech support on the phone with the customer for a half hour trying everything. Finally,
there is only one thing left to try. To take the customer into—THE DREADED BIOS SCREENS! Talk
about a minefield! Can you imagine trying to navigate 1000 different flavors of BIOS?
Ok. Let’s bag the async port for now. Let’s instead tap into the “newer, better, faster”
Universal Serial Bus. Joe knows for a fact that most newer computers have USB up and running with
a keyboard and mouse already plugged in. And there’s a empty port right there–just waiting for us!
But, what does it take to do USB in Window’s? Let’s surf into MSDN and find out. Ok, here’s a
FileOpen command. Let’s see. It says it works with disk files, com1-8, lpt1-8, named pipes,
mail-slots, allocated consoles–but USB is nowhere to be found! There’s no native WIN32 API’s
for USB access…OUCH!
But our Joe…good old Joe…he’s persistent! He keeps surfing MSDN and searches on “USB DDK”.
DDK is short for Driver Developer Kit. He gets a hit in Windows CE DDK…but nothing in
regular Windows DDK. Well this is going nowhere fast! Finally, Joe calls Microsoft directly,
and after repeated phone calls, Joe finally gets an engineer on the other end of the phone line
who seemingly knows his stuff. And Joe asks him the following:
“The customer is going to expect a device driver to come with the peripheral…right? I want to do
it in USB. Does that require me to write something with the SDK…or do I need the DDK…and
what about PnP? HDI, what’s that? Human Device Interface…is there a tutorial? Oh, there’s
courses you can take…OK. Yeah…you think I really need see the big picture…Uh-Huh.
Compatibility may not be the same? But you say you don’t really know. Yeah you told me
you’re not really a device driver developer. Right…you know just enough to be dangerous–don’t
we all! I realize people are still running Windows 95–so compatibility “is” important. Book?
800 pages? Look I just need to pass a half-dozen different types of strings. No, I understand it
not as simple as plain old Win32 calls! Oh, you “do” know about those–so do I! No I don’t
have any Win32 questions. Listen, do you have the names of any device driver developers?
Wait…we must have a bad connection…HOW MUCH money did you say?
Joe has finally come to the realization that even to “get to the prototype stage” will require a long
and arduous learning curve. And if he fails in that…then things will quickly become excessively
Hold it! Let’s stop things right there!
Before we let Joe’s dream crash and burn, let’s switch gears into an “Open Peripheral World”.
In an Open Peripheral World:
– The driver is already there and active when the OS boots.
– Only a single driver is required to service all peripherals on the bus.
– The driver is there to act only as a middleman (or router), that is, to facilitate communications between the user applications and the peripherals themselves.
– The driver must provide only a minimal set of functionality to start things up and keep the messages passing.
– In all other aspects of the conversation between the peripherals and applications, the driver is to know nothing–and is to “just stay out of the way”!
Now Joe merely has to post the specification for the controller on his website so prospective game developers or even “regular old end-users” can peruse it to see if it meets their needs. Here is the specification document that could viewed and/or downloaded in PDF format.
********** Joe’s Mark I Airplane Controller…Specification Version 1.00. **********
This device complies with Open Firewire Peripheral Standards.
This device consists of:
– A steering wheel that has freedom of rotation 180 degrees in either direction.
– A shaft that has a 4-inch throw “into” and “out from” the peripheral base.
– And finally, two separate foot petals…right and left.
The transmitted state information can be used for any purpose but most commonly in games.
The state of each control will be measured as follows:
– Wheel position will be reported in “full degree” angle increments:
0 is straight, +180 is full right, -180 is full left.
– Extrusion of shaft will be reported in whole integers as follows:
0 is half-way extruded, +100 is fully extruded, -100 is fully inserted.
– Separate state for each petal will be reported in whole integers as follows.
0 no depression to +100 fully depressed.
– The Controller will accept and send messages in double quoted delimited strings.
– A logical protocol state table will follow.
– In the state table, information contained in “square brackets” is only “descriptive” in nature
and indicates the destination port#/destination address# of the above packet.
Mark I Logical Protocol State Table
Step 1. Bus Reset:
After any firewire bus reset the Mark I will shift into a state where it will send and
receive “only broadcast packets”.
Step 2. Session Negotiation and Node Address/Port Number Exchange:
Host CPU –>>> “Pinging Joe’s Mark I Controller” –>>> Mark I
Host CPU <<<-- "Mark I on Node 07/Port x000001" <<<-- Mark I [Broadcast] Host CPU -->>> “Host on Node 3/Port x000009” –>>> Mark I
Step 3. In-Session:
Mark I will now send “the state of the 4 control surfaces” bundled into/and sent in
“single data packets”.
Mark I will accept “Reset” and “Speed Control” commands sent to it from Host.
When the Mark I first comes In-Session, it will send “a state packet” every 1 second.
Sample State Packet:
Host CPU <<<-- "Wheel+035,Elevator+000,RRudder+047,LRudder+000" <<<-- Mark I [Node3/Port9] The host optionally controls packets per second sample&send rate by sending a Speed Command in the format ..."Speed x###". ### can range from 000 to 500 with full integer resolution. Example: Change Sample&Send rate to 100 packets per second. Host CPU -->>> “Speed x100” –>>> Mark I
Example: Change Sample&Send rate to 499 packets per second.
Host CPU –>>> “Speed x499” –>>> Mark I
Example: Change Sample&Send rate to zero packets per second (turn off).
Host CPU –>>> “Speed x000” –>>> Mark I
Finally, Mark I will accept a “Reset” command from the Host, causing the Mark I to
return to Step 1 (soft reset), and revert back to accepting “Broadcasts Only”
and restore capability to establish “New Sessions”.
Host CPU –>>> “Reset” –>>> Mark I
********** End of Specification **********
I hope you were able to follow that. If you aren’t used to back and fourth protocol diagrams you may have to take another look. If all peripherals adopted such open protocols, reading these protocol diagrams would become second nature.
Well, that’s about all we need to discuss about Joe’s company. I’m sure everyone can add something to the “Mark I Protocol Language”. We can save those for the posted comments. (I’d probably offer a “terse mode” as well as retaining this full-string “verbose mode”.)
And, the very last step of our straw man was to:
#4. Write a game program that would use the peripheral.
Needless to say, we’ll leave this as an exercise for the reader. The very few API calls that there were in this straw man follow a very generalized Win32-like format. Most games usually end up being large infinite loops that get state information (including that from the controllers), process reams of data, then build and display a “single frame buffer”…and then, start the process all over again.
The prospect of establishing a session and collecting controller packets “is trivial”–when put up against the other 99.9% of the task!
I could go on, but I think this is as good a stopping point as any. For those of you who have always been a little bit fuzzy when it comes to the “hardware to device driver interface”, I hope that this at least succeeds as a basic primer on the subject. I also hope that I’ve sparked some insight into the possibility of such a notion as “open peripherals”.
Finally, the questions I want to leave with, are these: Is what I’m proposing, really “already here today”? Would this lead to more choice? A choice not only in the standard peripherals of today, but foster the development of totally new ones? And wouldn’t simpler more fool-proof interconnectivity lubricate the wheels of development leading to whole new generations of alternative “host-side” programmable devices? Would something like this really stifle competition? Or would something like this give Joe and his vision,
at least a fighting chance?
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.