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.
Logical Protocol:
- 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
[Broadcast]
Host CPU <<<-- "Mark I on Node 07/Port x000001" <<<-- Mark I
[Broadcast]
Host CPU -->>> "Host on Node 3/Port x000009" -->>> Mark I
[Node7/Port1]
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
[Node7/Port1]
Example: Change Sample&Send rate to 499 packets per second.
Host CPU -->>> "Speed x499" -->>> Mark I
[Node7/Port1]
Example: Change Sample&Send rate to zero packets per second (turn off).
Host CPU -->>> "Speed x000" -->>> Mark I
[Node7/Port1]
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
[Node7/Port1]
********** 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!
Conclusion
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.
- "Open Peripheral Hardware Connectivity, Part II - Page 1"
- "Open Peripheral Hardware Connectivity, Part II - Page 2"
- "Open Peripheral Hardware Connectivity, Part II - Page 3"
- "Open Peripheral Hardware Connectivity, Part II - Page 4"
