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…
The advantages?
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
document compatibility.
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
hung around…
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
expensive.
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.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.
many in the computer industry think numerical when they thing about computer link. But, if you want really multiplatform multi standard interoperability you need to think real world connection.
i said many time the biggest letdown of the computer industry since the early 80’s is the abandon of the IO concept that interface to real stuff that do real things. This mean that to connect to the analog world that we live in we need analog aware protocol.
For a computer that don’t know (yet) what the next computer he will communicate with will be like, he have to assume all possibility. All possibility mean analog chanel. I don’t mean trow away checksum concept and all, just that the signal need to travel on their own frequency (to be totally asynchronous and remove net congestion acordeon style) and be voltage independant (or current or laser, or IR etc..)
Another advantage of being analog is that it remove any hardcoded limitation of a protocol, 127 limit for USB (don’t remember that one exactly), gone. The limit become only the scope of the emitter receiver, while in numerical protocol both protocol coded limit and the hardware block the performance increase over time.
Analog was removed for weird reason from computer. The obvious one like error propagation of re-addition of variable (like a =a +1 ) are gone for good reason, but in many place (especially IO) it was a big fashion move that every computer company followed blindly.
I expect I am probably just being stupid, but I still don’t get it. I am not criticising, but I do have a few questions that I feel neither of the articles to date have adequately answered.
Does the example used mean that an application developer would have to write all the handling code for every possible controller?
Would a flight stick require different control code in a program to a yoke type system?
Isn’t this a case of the system making life easier for the few (hardware developer) and more difficult for the many (software developer), after all if I want to access a controller in a game at the moment it is usually just a case of asking for a value from a controller number and axis/button.
Personally, I like the idea. I don’t see how this would stifle competition or make companies go out of business.
This would especially be ideal for users of alternative OSes, who usually end up suffering from limited peripheral availability. This I know from my BeOS days.
The trick would be getting hardware vendors to actually adopt this. Most are under MS’s heel and would get slammed for participating in something like this.
Maybe I just don’t get it, but what exactly is the deal here? I mean that as sincerely as possible without internet sarcasm. If I truly don’t get it, just ignore the rest of the article.
We have devices, which need a standard interface. The devices communicate with the OS via this interface via a protocol which everyone standadizes. The OS then routes this packet to the appropriate application.
I mean really, what is the purpose of the PDA in this example? Why don’t you just work on the base station and not route the packet to the PDA? Do people really want to do their work on the PDA, while just using the base station to plug in a keyboard?
Why don’t we just say something like this:
1. All devices use firewire
2. Some committee standardizes all possible types of devices and their communication packets
3. computer uses this standard to read from firewire port and route data to applications.
There is no magic bullet here. By that matter, why don’t we just standardize everything and store settings on a PDA…which the base station could just read off.
-desktop settings
-desktop resolution
-wall paper
-faourites location
-recent documents
…
Hell, let’s standardize word documents, spread sheets….wait a minute…I got it. Let’s transfer all data using XML with standardized keys. Yes!
Then when you boot, the base station reads these and all is done magically. Yeah, we could get everyone to standardize these
And what happens in the future when new types of desktops are invented?
Wait a minute….even better….Let’s skip the PDA concept. Why not just store all your settings online? Yes, and transfer everything online in XML standard…. .NET anyone?
Standardizeing everything is a dream that works in hindsight. You cannot predict what future needs are, so you cannot plan for them in your standard. Standardizing products before they are made also limits innovations and delays product delivery.
are you saying you do not like the idea of virtual hardware?
That’s why great ideas like this will never happen but crap like DRM will make it’s way to hardware. When you have a monopoly calling the shoots in the OS world they won’t settle for anything that would allow others to compete. Thus they will use whatever influence they have on hardware makers to make sure something like this does not happen and IF it does it will be proprietary as hell ! Along with a full set of razor sharp and pointy DMCA issued teeth !
Opening up hardware peripherals to operate on any platform-os combo would by a testing nightmare not to mention prohibitively costly in not only time but in purchasing software and hardware.
You can’t just declare that since a product adheres to a standard that it will interoperate perfectly with its environmnet. You actually have to go out there and do the testing if you expect customers to purchase your hardware.
The fact is that companies just want to target the top 2 or 3 groups of OS/platform users. Less to support, big enough market and cheap to do it.
So in a nutshell after removing all the fluff the author proposes that hardware vendors should open up their device interface, something that they have always avoided doing e.g. binary only drivers for video cards, modems, etc. Hmmm… it would be nice but alas.
On another note the example you give is a perfect world example for it does not propose how to actually stardardize the way in which the information is sent and recieve, and skips completely what to do with devices that can’t live within the standard “packet” templete…
I just don’t see any commercial interests on this topic.
targeting 3% of “install base” that expect everything is free ?
Sorry if this is irrelevent.
“… 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 ….”
This sound awfully like Plan 9 from Bell lab (designed by the same creaters of Unix). In Plan 9 you can run a program using the processor on one machine, and get the files from another computer, and display it on a third computer.
However it is a very os-centric solution.
Knoppix (bootable CD/DVD), 64MB USB portable drive etc
works on basiclly every machine from 486 to whatever…
from the hardware point of view open standards have been around forever… there are also open motherboard designs etc.. which i think IBM and other companies created.
(did not get past the first couple of lines of the artical)
Analog was removed for weird reason from computer. The obvious one like error propagation of re-addition of variable (like a =a +1 ) are gone for good reason, but in many place (especially IO) it was a big fashion move that every computer company followed blindly.
It was not something followed blindly. It was about cost (cheaper to use digital), and the fact that most analog paths were being used to transmit digital data, often with redundant channels to compensate for the other problems with transmitting in an analog fashion. There is currently a huge market in D/A and A/D converters that handle the conversions in a fairly generic fashion so companies can convert their old analog equipment to digital over time (ie convert the controllers to digital first, then convert the equipment being controlled to digital later), or to reuse old hardware in new systems. I’ve seen equipment using 8 analog paths to send 3 digital bits and a timing line (which is also 1 line mirrored), and equipment using 50+ analog paths to send 16-bit data words. It’s really just rediculous.
Debman,
i don’t know what you refer to. Virtual hardware for me is emulator, i don’t see the link.
PainKilleR,
i don’t think it cost less being numerical. Any IO device controller cost something. The problem with current situation is that we need around 15 adaptor to interface physicaly all thoe peripheral to our PC.
BeBox Geekport and Mac Geoport become more and more intelligent way now that PC have a lot bigger choice of peripheral. Imagine a PC with only 1 kind of connector that you can fit on any device as long as it’s electrically in the range of tolerance. Seem a lot simpler to me.
this remember me of digital audio (yeah right
sound travel in binary form in the air anyway 
), this was only to sell new cable because the other model could have lasted 50 year. Now they limit their life time by standard change of connector and comm protocol 
My whole point is, if you want to stay in control of your hardware use and not corporation, analog is better (keep in mind that analog can do digital ALSO, analog = digital but digital =/= analog).
Knoppix (bootable CD/DVD), 64MB USB portable drive etc
works on basiclly every machine from 486 to whatever…
Actually not it doesn’t. I tried to get it to boot on an onld Cyrix MII based emachine and it hung. I could not get Red Hat9 or Madrake 9.1 to load on that old beast. I did get Lycios to load, Who knew.
I don’t get it…was what I heard time and time again.
Or…what is the deal? What is this guy advocating?
Everything already works?
The issues are hard to grasp unless you have delved into chips, and how they operate, along with device drivers and interrupt service routines.
Most people who are extremely knowledgable with OS’s and high level languages are very comfortable when it comes to CPU’s and Memory. But when it comes to the chips that drive the Ethernet, Firewire, IDE, serial, USB connections…and the peripherals on the other end…and how it all comes together–that’s when the uninitiated enter the “twilight zone”. Not because they are stupid. But, because they have not exposed to “what amounts to a whole different world”.
My major beef here is on the “peripheral side”.
I want to make it easy…and level the playing field for users and hardware and software companies of all sizes.
Some perpherials have historically been very open in their methods of controling the peripheral itself. Modems, Printers, Dumb Terminals…all these come with optional Technical References on how to make them work.
I don’t have to go out and “buy” or “download” communications program, or a GUI program with a “Print Button”, or a Terminal Emulator program. I have enough information that can write my own program to talk to and control these perpherials and make them do the things I want them to do.
I can make a modem dial a phone number, connect at a certain baud rate, hang up…a printer formfeed a page, go into compressed print or a different font…a dumb terminal to clear the screen and position the cursor,etc.
And openness helps not only the true end users…but those developing alternative OS’s and the people writing programs to run on those alternative OS’s. They shouldn’t have to suffer from not being able to run the same peripherals as the Windows guys.
On the other hand, other types of perpherals, “especially recently”, are becoming pretty much totally closed. USB Game Consoles and USB Mice are just one example. If you don’t believe me just e-mail Logitec(Mouse) or GH Products(game perpherials) and see if they will give you any information on communicating with even one of their products. I’ve contacted Logitech about a mouse and generically asked GH about User API’s for a game controller both to no avail.
Is this just the tip of the iceberg in what for Microsoft could be a whole new front of MS vs. the OS alternatives?
But in this instance, an MS attack from the hardware side.
Isn’t it funny that the old serial devices were fairly open in their operation. Then along comes USB(Intel) and the devices connected all of a sudden start becoming very closed from a user perspective…and yet all the game companies writing the games for the Microsoft OS’s have seemingly little trouble getting the info. Just a coincidence???
And as more and different devices tap into this USB…will this follow the same scenerio? Microsoft bending over backwards to help peripheral hardware and software partners to use USB to tap into the ubiquity of Windows OS’s and applications. And of course, in doing so, won’t the pheripheral makers feel coersed (even subconciously not to byte the hand that feeds it).
The MS vision to the partners would go something like this. Users really “don’t need to know”, “nor do they care” how these things work. They don’t want get their hands dirty programing these perpherials. Just let them buy a peripheral and package from one of our MS hardware and software partner’s. But really, the alterior motive all along is to withhold informatiion and make this difficult for alternative OS’s to use these as perpherials as well?
For the life of me, I don’t know how any of these myriad of distributions of Linux, or any of the other alternative OS’s will ever have the clout to wring out the necessary info to even begin thinking about using these different peripherals.
If you’re a maker of game peripherals doing nearly 100% business with Microsoft games…are you going to risk you good standing with MS by making your peripherals easy and readily available to alternative OS’s for what amounts, at least initially, to table scraps?
Back in the old days IBM was sued (and lost) because they locked outside peripherial makers from attaching non-IBM tape, disks, printers, to IBM mainframes.
Are we seeing the first glimpses of what is simply a variation on a theme? As the serial, parallel, keyboard and mouse ports transition to USB (providing the oportunity for mischief)…are we just seeing the beginnings of a Microsoft shadow distorting the hardware peripheral market?
The scary part is–what sort of restraints did the antitrust settlement put on Microsoft from the hardware side–if any. And secondly, what happens if Microsoft really begins to feel competetive pain at the desktop?
I have to ask again. What are you advocating?
I mean can the article basically be summarized into saying:
“Companies need to open up their device interfaces?”
Well I don’t think you’d get much disagreement there. I’d love to able to call up Logitech or whoever and learn to talk to their mice…I personally think it should be criminal to hide your interface unless its actually technologically ground-braking or somthing like that. But then again, I don’t make the law.
Where does the PDA fit in to all of this? Perhaps I am just a high-level guy who doesn’t grasp the issues of bits going in one end, and coming out the other; Packeting these, and notifying applicationsl or reversing the process. Perhaps you could write an article explaining the issue and then the solution to the problem. Perhaps with the help of a diagram or two showing how things currently are then how this solution will play out.
If what you’re saying is that drivers should be unnecessary, I agree. There’s no reason that any operating system above the firmware level should care what kind of hardware you have – it should all be a standard interface. See USB HDI drivers for an example of that done right.
I have to nitpick, though – how do you choose your standards? For keyboards and mice, the USB HDI standard has existed since the beginning of that bus, and is platform/company-independent. For printers, PostScript is the world standard. There’s no reason to use anything but.
i propose a change in protocal from firewire. How about Fibre Channel? This is a simple single pair line with Cu, that can run for 10+meters. I can support 100+ devices and assigns device ID based on physical location on the line. it is a loop channel to 2 pair would be needed to complete the circut but ethernat cableing can handle this with ease, in fact it could handle two channels of Fibre Channel if necessary. Fibre Channel is also a 1Gb link/channel, and uses open SCSI protocals. The chips are fairly inexpensive fore this limited production and would come down dramatically in price if used on a larger scale. Another advantage is that the Fibre Channel(FC) controller handles all data and passes only relevant data to the CPU or memory system making it ideal for PDA style devices that need to conserve as much CPU time as possible.
I think this would follow the guidelines set out for your “Open Hardware” system, allowing just a single driver for an OS to get access the the FC subsystem, and just make every device have a simple controller onboard to communicate the proper data.
FC also has the ability to use Fiber Opticals as a medium, and can reliably transfer data 5+Kilometers without a repeater, at 1Gb/s or faster. and a single Optical line can cary a number of FC links using different frequencies of light, make this a viable option for higher end systems and not just desktop and mobile users.
with 1Gb/s, you can handle everything you need in periferals including a display device with ease, Including external storage devices.
FC also would allow a “storage port” in enterprise environments where users could attach their mobile system or PDA to the file servers with a 1Gb/s link and giving the TCP/IP network a break.
—–
article is a good read
btw