OSNews

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...

1. "Open Peripheral Hardware Connectivity, Part II - Page 1"
2. "Open Peripheral Hardware Connectivity, Part II - Page 2"
3. "Open Peripheral Hardware Connectivity, Part II - Page 3"
4. "Open Peripheral Hardware Connectivity, Part II - Page 4"