We have two FireWire sessions this year, like we do every year. One is more in-depth and focuses on writing software. The other is more introductory and this year focuses a great deal on FireWire 800. But this year they are in reverse order. So you haven't missed anything. The next one is tomorrow at 9 a.m. I'm sure you'll all be up bright and early for that.

What this session is about is writing FireWire software. We're gonna talk about what's in Mac OS X, how the FireWire services work, what's available for you to tap into where you can hook your software into ours. And we have a new focus this year on a number of topics more in-depth. For example, we'll look at how Isochronous Transmit really works, which we've always glossed over in the past. And we have a bunch of new tools for you that I think you'll be really interested in. So let's launch right into this.

Wasn't expecting this to be tipped over like that. We're going to go over the architecture first. We'll look at the layers of FireWire software, the various modules, how driver matching and loading works, where you can hook in, how you develop software. Then we have special sections on TCPIP, the internet protocol running over FireWire, some detailed examples of how isochronous transfer works, what a DCL wheelie is and what happens when you run one.

We'll look at new AVC services, including new AVC target support that adds some great new capabilities. We'll talk briefly about SPP3, which adds some new performance capability. And then we'll have a detailed look at some new tools and other support that we have for you to help you develop for FireWire on Mac OS X.

Let's start with the architecture. Let's see if this thing works. Here's the stack showing the various elements in Mac OS X FireWire. The four that are brightly colored are the core services that are provided by the FireWire software team and some others are shown around them for context. Starting at the bottom, you see the silicon that represents the FireWire interface in the Power Macintosh system. The PHY, which we'll talk more about later, and the OHCI chip together, that's what you typically find on a FireWire card.

When that's detected, our services load in the Kernel. Pretty much all of FireWire is in the Kernel because FireWire is a resource that we can boot from. We can take a page fault from a FireWire device, so it's got to be there in the Kernel. Similarly, our IP networking services have to be in the Kernel.

Eric Anderson So we'll go over the layers in the Kernel, and we'll also talk about how you can hook into that from user space up on top. You can see the three layers in the Kernel there. The controller hooks directly onto the hardware, the family pulls everything together, the protocol layers where we start to differentiate into SPP2 or AVC, and then the user client interfaces up on top.

Let's start with the family right in the middle. The family is the layer that brings everything together. You've got multiple FireWire devices, multiple drivers, multiple applications. They all want to use the same FireWire bus at the same time. Well, there's only so many DMA contexts and address space and interrupts and so on. You don't want them trying to know what each other are doing. You want them all to function independently.

That's what the family does. It lets the different drivers make their requests. It queues them up and sends them on the bus. When packets come back in, it figures out which packets go to which driver and hands them out accordingly. So your drivers don't have to tiptoe around each other. You can write just to do your thing and not worry about everybody else. That's what the family is for. The family also provides some basic management services.

For example, the family may tune the performance of the FireWire bus to optimize some of the hardware settings. The family is provided in a kernel extension. extension called io-firewire-family KEXT. and there's going to be one of these for each FireWire bus in your system. Typically, you only have one FireWire bus in the system, but if you want, you can have more than one.

The layer below that is the Controller. This is what glues the family to the hardware in your system. In most systems, this will be Apple FW-OHCI, the Kernel Extension, although in certain very old systems, it will be Apple Lynx, such as on the blue and white G3. The Controller actually knows how to program DMA, knows how to handle interrupts, and knows how to do all the hardware-specific stuff.

This is the same whether you have an integrated controller, like Steve showed yesterday in the new G5 architecture where the FireWire controller is just built into the chipset, or if you have a PCI card or a CardBus card. It's all the same with the Controller layer. Now, as I described, all those things sharing the family, everything they do has to go through the Controller.

The Controller cannot be subclassed, even though it's in the Kernel. This is a location that has to please everybody. So if you go in there changing it to please your device, you're probably going to make someone else unhappy. So don't even think about trying to subclass the Controller. This does mean if you make add-in cards, be sure to pick silicon that works.

Now, moving up from the family protocols. This is where things start to differentiate. If you're a camcorder or an iPod or a printer, you start to have a different personality at this layer. For example, SBP, the Serial Bus Protocol, is what's used by storage devices like the iPod, hard disk drives. It's also used by other SCSI type devices like scanners or printers on FireWire. In comparison, the AVC command set is used by camcorders, TV sets, digital VCRs, sort of consumer electronic devices.

Each of these has a service layer that sits on top of the FireWire family that provides all the basics of that protocol so that you don't have to reinvent it from scratch just to communicate with that particular device. These layers also perform protocol-specific matching services. Now, we don't have our own matching.

We use I/O Kit for everything, but these layers know how to take a closer look at, say, an AVC device and figure out what subunits it has. Is it a tape or a VCR or a TV? This information goes into the registry so that you can use I/O Kit to match properly to your device.

Finally, outside the Kernel, we provide a variety of User Clients. Officially, these are known as Device Interfaces, but everyone seems to call them User Clients, so we'll do that here. This is a way to hook into all the FireWire services in the Kernel from an application or from your plug-in that's running in the context of an application in User Space.

Just about everything you can do in the Kernel in FireWire, you can also do from User Space and you'll find it's usually a lot easier. There's direct APIs for sending and receiving packets. You can also access the protocols like SPP and AVC from User Space. When you do this, you're not using a copy of the services.

You're not using some user safe version of the services. You're using the real SPP2 or the real AVC that's in the Kernel. So you're going to get the exact same behavior, the same performance. Places where buffers have to move across the User Kernel boundary, we map memory. We don't copy your data across. We just map it directly into the DMA so data moves as fast as it can. Writing and debugging your software out in User Space is much easier than doing so in the Kernel. So please do that if you can.

Somebody wasn't listening to the announcement before we started about cell phones. Now, how does driver matching work? As I said, we use standard I-O kit services. There's nothing special about FireWire like we had in Mac OS 9 where we had our own unique FireWire matching. In Mac OS X, it's all just I-O kit.

But we put FireWire-specific information in the I-O registry so you can find the unit directory in your device or the vendor ID or the GUID, all the FireWire information that you expect. The FireWire family discovers nodes on the bus that have configuration ROMs and creates a device object for each one of them in the I-O registry.

It then scans the ROM further, and if it finds unit directories, it creates unit objects, typically one per device, but there could be more than one. The unit is where you start to differentiate whether you become SBP2 or AVC or something else. So the appropriate protocol layer loads, and it takes a further examination of the device.

If the SBP2 layer loads like is shown in the picture, it will create a target object, then it will scan the device further and create logical unit objects with SBP-specific information, such as the device type, whether it's a disk or a tape or a printer. So the matching is iterative.

These items build up one by one in the registry. At each stage, you have the opportunity to do active matching if you need to actually talk to the device and find out whether it's really the one you want to drive. If you're working in the kernel, you can do subclassing at the various layers as well.

In addition to the devices we find on the bus, there's also a device in the registry called the Local Node. The local node is there whether anything is plugged in or not. It represents the Macintosh itself, but it doesn't mean you're talking to yourself. It's just an all-purpose portal onto the bus. If you want to talk to a single device out there, you should probably match against that device.

But if you're talking to several devices, the local node gives you a way to do that. For example, IP over FireWire or the MLan protocol or multi-node cluster computing. The local node might be a good way to hook in for those because it's always there no matter how many or how few devices are there. The local node might be a good way to hook in for those because it's always there no matter how many or how few devices are there.

Now that you've seen the layers and you know where to hook in, where exactly should you develop your software? Your first choice should be to write software out in user space. As I said, just about every service that we have in FireWire is available to a user client in user space. IO FireWire Lib is the primary user client. It has direct access to all the packet send and receive services. And there's specific user clients for AVC and SBP that are listed here as well.

However, if you're looking to use SBP, you may instead want to use the SCSI Task User Client. We'll talk more about that later, but if your device complies with SAM, the SCSI Architecture Model, SCSI Task User Client is going to be a lot easier than SBP2 User Client. If you're working in user space, we have lots of sample code available. If you've installed the FireWire SDK, you can look in this path and you'll find all the sample code for writing drivers and applications out in user space.

Now, I said writing in user space should be your first choice. You only actually have two choices. Writing in the kernel is your last choice. You really don't want to do this if you can avoid it. All FireWire services are available, and you may need to write in here if you're writing a bootable driver, although we provide one for you, so you shouldn't have to. If you're writing a networking driver, same caveat, or something else that supports another kernel service. But many kinds of things simply can't go in the kernel. You can't put a printer driver in the kernel.

There's no way to hook it into Print Center. The same goes with a scanner driver. But if you need to write in the kernel, you can, and that may give you the opportunity to subclass some of the layers that we have in the kernel. For example, we do this fairly extensively in the mass storage class. We subclass so that we can provide the best possible support for each of the different kinds of bridge silicon that's out there in FireWire hard drives.

Sample code for working in the kernel is limited. Basically all we have to offer is the source code for FireWire itself, which is in Darwin. So you can start there and you'll see how it works and you can figure out how to hook into it. Debugging and testing is more difficult in the kernel than in user space.

If you crash in user space, you can just run again. But if you crash your driver in the kernel, you'll get to reboot the machine. That'll give you some time to ponder when you last ran your backups. So you should really develop out in user space if you can.

If that wasn't enough incentive, here's all the sample code that we have now in SDK 16. Once you've installed SDK 16, that path is where you'll find all of this. There's some very general purpose sample code, like FWSampleProject, it's very non-specific, IOFireWireLibBasics. If you want to cause trouble, you can start with the ResetStorm sample code.

We have some new stuff that's very exciting, the DVHS Capture Sample and the FireWire MPEG. If you have FireWire devices like a Digital VCR or FireWire TV, try these out. You'll find some really interesting new capabilities there. So whatever you're trying to do, we've surely got something on this list that's a good starting point.

Now I mentioned SCSI Task User Client and SAM. Lots of devices that use SBP2 also comply with the SCSI Architecture Model. So SCSI Task User Client may be a lot easier for you. If you use SBP2 User Client, you have to deal with bus resets, logins, reconnects and so on. All that's handled for you in SCSI Task User Client. You can just form the commands or tasks and hand them down to have them executed. So if you'd like to try that, this shows where it's located. It's inside ioscssiarchitecturemodelfamily KEXT.

If your device is some kind of optical media burner, you may want to move to an even higher level. We now have APIs for disk recording, for DVDR, CDR and so on. You can find documentation as listed there. That would be generally even easier than using SCSI TASK and certainly than using SPP2.

Eric Anderson If your device has some SPP2 unique behavior or it isn't quite SPP2, then you may need to move back down the software stack and use SPP2 itself or even the basic FireWire APIs. Whatever your device does, there is some way we provide that you can hook into it and there may be several ways to choose from.

New this year, possibly late last year, TCP/IP, the Internet Protocol. We now support this on FireWire. This is an industry standard. IEEE standard 2734. It's very straightforward. It's only a few pages. It shows how to send IP datagrams on FireWire. You can get it at the IEEE website if you want.

Internet Datagrams are simply packaged up in FireWire block writes. Each FireWire node that supports IP allocates an address in its own address space where it will receive these packets. And that address is published in the node's configuration ROM so that other nodes on the bus can discover it. So our driver finds all the other nodes that speak IP and then can send datagrams to them.

Broadcast packets are supported. That's used, for example, for ARP, the Address Resolution Protocol. That's done with a FireWire asynchronous stream packet. It's like an isochronous packet, but it's not sent in real time, so no reservation is required. So it's fine for ARP. It's also very low bandwidth, so it doesn't interfere with anything else.

So, in the case of 1394A, set aside isochronous channel number 31 for this purpose and certain related purposes. If you have a device that's hardwired to channel 31, I don't know of any, you're going to have to move to another channel. But you'll see these packets in Firebug as isochronous packets. They're actually asynchronous stream packets. Firebug can't tell whether it was sent in real time or not. It only knows when it arrived, so it shows it as if it was isochronous.

So what's this good for? The Internet's good for a lot of things. Everyone you ask will have a different favorite use. There's no restriction here. We support IP, so anything that runs on IP should run on IP over FireWire. HTTP protocol, file services like FTP or AFP, whatever you want. Now you may find this interesting if you're presently using target disk mode. Using AFP or personal file sharing, you may want to investigate that.

Is it faster? That depends. You don't have to reboot twice, so that may help, but you do have to log in and set up personal file sharing. The actual performance is likely to depend on the kind of files you're moving, how much of the CPU you're using, and so on. So give this a try. You may find it to your liking. Many cluster computing APIs use IP.

Because it's ubiquitous. Nobody makes a computer that doesn't have TCP/IP, or they certainly don't sell very many of them. So if you have a cluster computing application that you'd like to run on FireWire and it's based on IP, you can run it immediately on IP over FireWire. However, FireWire's direct memory access model, where memory space is visible on the FireWire bus, is very well suited for certain kinds of cluster computing that exchange a lot of data between the nodes. So if that's the kind you're doing, IP will work, but you may get the best performance by going to a FireWire native solution.

So how do you get this configured? Like any other IP interface, you start in the Network Preferences Panel. In the upper left, there's a pop-up menu called Show. If you'd pick that, at the bottom, there's always something called Network Port Configurations. You've probably mostly tried this. Once you pick that, you'll find FireWire is in your list of network ports. Unless you're running Mac OS 10.2, in which case you may instead find Ethernet Adapter EN2. We're working on that. If you see that, just double-click on it and rename it to FireWire.

Once you've done that, and be sure to turn on the checkbox, you can then drag FireWire to the top of the list if you'd like to use Rendezvous to automatically provide an IP address for your FireWire port. Just drag it up to the top like is shown there. Then if you'd like to further configure it, go back to the network port pop-up and just pick FireWire from the list. Then you can select your IP address or whatever else you like.

Now, in Mac OS 10.2, it will allow you to configure AppleTalk and PPPoE, not F-E, and neither of those make any sense on FireWire, so ignore those. You can try to set them up, but they won't do anything. We fixed this all in Mac OS 10.3. Here's where we have deployed support for IP on FireWire. There's two developer preview releases. They're available through the ADC website. Anybody can download those. They run on 10.2.5.

It is also included in Mac OS X Server version 10.2.5 and it's pre-installed on every XServe. In Mac OS 10.3, it is pre-installed for everybody using the seed that you received from this conference. You can go turn it on and try it out right away. Eric Anderson In Mac OS X version 10.3, we have fixed all the little user interface issues because we were able to change everything at once rather than just adding our new text. And we've added support for IPv6 and we've improved the performance quite a bit. Let's look at that.

Now, this is somewhere where the Ethernet guys have a big advantage over us. Ethernet is an IP network. Hardly anyone uses it for anything else. Ethernet hardware is designed for optimal transmission and reception of IP datagrams. FireWire hardware is not. It's designed to do everything: iPods, camcorders, still cameras, TVs. It can do a lot of things really well, but it's not customized for IP. So we had a little bit of a disadvantage when we started. So how do we do? In the first preview release, our standard benchmark is to run NetPerf between two X-SERVs.

The first preview release on 10.2.4 could get 216 megabits per second. That's more than half of the FireWire bus. It's not bad. And in fact, if you were running this on your iBook or your eMac, that's twice as fast as the built-in 100 megabit Ethernet port. So this already may be very useful to a lot of people. But of course, we'd like to go faster.

Eric Anderson In the second preview release and what's in Mac OS 10.2.5 Server, we got that up to 277 megabits per second. We're never going to hit 400. There's overhead, there's arbitration, there's acknowledgements. We're going to get somewhere in the 300s, but we're never going to hit 400. But we're going to keep trying. Eric Anderson So how have we done for Mac OS 10.3? Same test. We're now up to 317 megabits per second.

And if you hook up the FireWire 800 ports that are now included on the X-SERV, we're getting 660 megabits per second. Eric Anderson Now these are preliminary and they're benchmark numbers, so nothing will ever go this fast in real life. But you can see we're making it a lot faster and it's really getting very competitive with gigabit Ethernet. So if you want to run IP on FireWire, we think we've put you in pretty good shape to try that out.

Next, Isochronous Services. Every year we talk about the fact that we have Isochronous Services and we say they're complicated and we kind of gloss over how you actually use them. This year we're going to go into depth and try to explain the basics of how it works. We have something called a Data Stream Control Language, DCL.

Isochronous transfer on FireWire sends or receives 8,000 packets per second. Each one is very precisely spaced on the FireWire bus. You wouldn't want to do this through some kind of system call API. 8,000 system calls per second, even if you can do it, is very expensive and it's going to be almost impossible to get them at the right time and meet your real-time guarantee. So that's just not how it's designed. Nobody's ever done it that way. We have hardware that can send or receive the packets according to a fixed program of when they should appear.

But that hardware is also complicated. So it has different register sets on different models of Mac, requires taking interrupts, knowing physical memory addresses. You don't want to be exposed to it. That's what DCLs solve. A DCL is an abstract description of data flow on FireWire. A DCL program that you write in memory, describes on a packet-by-packet basis how, where, and when you'd like to send or receive data.

You write the program, you hand it to us, we figure out how to make the hardware do what you told us to. So it's very precise. It gives you packet-level control, but you don't have to make frequent system calls. You don't have to hit real-time guarantees yourself, at least not 8,000 times per second.

A DCL program is a linked list of operations and they're going to execute in the order of the linked list. Each operation in there does one basic thing. It sends a packet or it receives a packet, though you can't mix those in a single program, or it may invoke a callback to tell you that it's reached a certain point in a program, or it may jump to another DCL if you don't want to run the program exactly in the order that it's written. For example, you can make a loop and jump back to the top so that you keep going.

We will compile your DCL program to execute natively on whatever hardware we actually have. But because of this, there's some restrictions to what you can do while the program is running. If you make changes to the source, they won't necessarily affect the DMA unless you tell us what you've done. And there's some limitations on the kind of change you can make. Here's a picture.

Here's a DCL shown on the left as a linked list of operations. The solid arrows pointing down are the linked list. Very important, at the bottom you can see it links to zero. If you link it back to the top, the compiler will hang trying to find the end of your program, so please don't forget to link it to zero at the end.

Eric Anderson The last instruction, though, is a jump instruction, and you can see the dotted line going up to the top, which is a label instruction. This causes the program to run in an endless loop, even though it's only actually about nine steps long. Eric Anderson This program sends data continuously. All of the operations that move packets are send operations. Each one points to a buffer that contains a packet. Eric Anderson Interspersed between the send operations are call proc operations.

After sending three packets, this program will cause your callback to be executed and you'll know that those three packets have been delivered onto the bus. This gives you the opportunity, in a looping program like this, to update those three buffers so that the next time through they send something fresh.

Time waits for nobody, and neither does the DMA. It's really important to understand when you write these programs. Packets 1, 2 and 3 are sent approximately 125 microseconds apart on the FireWire bus and then we call your callback. But we also send packet number 4. We don't wait for your callback to finish. Your callback may not have even started yet when we get to packet number 4 if it's on your work loop and you're waiting for something else to run.

The DMA is going to march through those packets exactly on time according to the FireWire clock. This means if your callback is going to fill in new data for buffers number 1, 2 and 3, you have to do so quickly. Now, an ordinary program is not really this small. This program sends only three packets and then has a callback. So at 8,000 packets per second, you'd have 2,700 callbacks per second.

That's really a little too fine grained. Typical program will have 20 to 200. So you'd have 2,700 packets for each callback. And that depends on the latency that you need in processing the packets. Typical program may also have more than two clusters. It might have three or four so that you have a little more time. There's less danger of the DMA wrapping around and catching you by surprise.

There's another thing in the program that I'm not showing because it doesn't fit on that slide, so let's zoom in. Very important is an update DCL. Update the DCL. If you change the contents of one of the transmit buffers while the program is running, we need to know about it.

In particular, we usually have to byte swap the header so that the transmitter will be able to pick it up over PCI where everything ends up getting byte swapped. So after every callback in a transmit program, typically you'll have an update. This doesn't take any time from the DMA's point of view. It still just marches through from send number 3 to send number 4.

The update, though, tells the FireWire family that some previous or some DCLs in the program may have changed. The update instruction has a list of pointers to other instructions. You can see here it points to the three send operations just before. You don't have to tell us what changed. We'll figure that out because we know what kind of operation they are, but you do have to tell us when they've changed.

The callback will execute to completion before the update happens. They're both done in the CPU, so even though the DMA may have marched on many packets into the future, your callback will finish before the update happens. Eric Anderson In a transmit DCL, you have to update the packets before they get sent.

In a receive DCL, you have to update the packets after they've been received, but before you look at them. If you don't do this, or if you get out of sequence with the updates, you may find packets that don't make any sense because we haven't byteswapped the headers or done other necessary adjustments.

DCL programs don't have to loop. You could have a one-shot program, that's very rare, or you can change the jumps on the fly in order to keep feeding new data to the DCL engine without ever actually making a loop. That's what our DV transmitter does. You'd never want to send stale DV data. Every packet has a sequence number in it.

So we make sure that the program always ends somewhere, and if we fall behind, the DMA is going to hit the end and stop. So we won't confuse any TV or camcorder, we'll just stop sending data. Of course, our goal is to never let that happen and just keep running, which we usually do.

There's another operation called a timestamp. This is something you can insert into the program if you want to find out exactly what time it was when the DMA reached that point. You could use a timestamp, which returns the FireWire cycle time, to synchronize two programs or synchronize a program with some external activity or to make sure that the program is really running on time and you're not losing packets or having some other problem. Timestamps also have to be updated before you look at them because they're generated by hardware, so they may come in byteswapped or they may need other modification before they're accurate.

In Mac OS 10.3, we're adding a new kind of DCL. DCLs were invented about seven years ago, back when we didn't have OHCI, so they're very flexible, so that we had room for growth. Now we have OHCI everywhere, and that's not going to change. So we've adapted DCLs to really fit well on OHCI.

Previously, there were a lot of hidden rules in DCLs, like a label had to be immediately followed by a send op or a receive op. The compiler didn't enforce that, but if you forgot, your program wouldn't work. It wasn't hard to code around these rules, but it was hard to remember to follow them. The new style DCLs map much better to the hardware, so they don't have this kind of rule. The new style DCL has one operation for each cycle.

It's going to send or receive a packet, or do nothing at all, if that's what you want. And for that one operation, you have one call. You can send one call back if you want it, one update, one time stamp, you get one of everything. This is being added. Mac OS X 10.3. It's not yet in the SDK, but we will have it out there soon.

Because it maps better to the hardware, we can now do some new things too that we couldn't do before. In particular, we can give you the error status for any particular packet, which may be very important if you have to check data integrity, and we can let you change the length of the packets in a transmit program, which was really difficult to do before. The old style of DCL will still be supported, but they are compiled into the new style, so if you're doing anything new, as soon as the new style is available, you should try to use it.

We have new services for AVC. First of all, if you need to manage plugs, these are connections established between devices on the FireWire bus that represent an ongoing data flow isochronously between two devices. We have APIs now to make that easier. You can call these APIs to establish input or output plugs and we will take care of them so that they remain set up. Every bus reset invalidates all the plugs that are out there and they have to be re-established. So if you've used these APIs, we'll do that for you. You don't have to keep tracking them.

So that should make it easier. We've also added a lot of stuff to help you become an AVC target. Up till now, the Mac has been really good at telling other devices what to do. Camcorders should play, tuners should go to Channel 37 and so on. But AVC, some of those devices want to control the Mac, or they may if you write software that makes the Mac do something interesting when they talk to you. So we have APIs to help you do that.

Publish AVC Unit Directory causes the Mac to publish in its own config ROM a unit directory telling everyone that it speaks AVC and you can send commands to it. Add Subunit adds an AVC subunit to the Mac so that when someone asks us what subunits we have, we'll respond accordingly, that we have a tape subunit or a tuner subunit or whatever it is that you've added. Now, you'd actually call those in the reverse order. First add your subunits, then publish. Otherwise, you may start getting requests before you're ready. The Publish API will cause a bus reset. That's how AVC lets everybody know that something new is available or might be available.

If you want to handle commands that come in, say, to the subunit that you've added, you can use these APIs. You can install a command handler, and you can specify which subunit and which opcodes you're going to handle, and there's wildcards so you don't have to enumerate everything. And, very important, most things that you get require some kind of response, so you can now call sendABCResponse to send that response back to the device to tell it what happened with that command that it sent to you.

We handle all of these commands automatically, but there is a mechanism for you to handle them too if you know what you're doing. For example, Unit Info and Subunit Info there at the bottom, we handle those based on the subunits you've added. We automatically respond and say, yes, we've got one of those.

Here's a list of the existing AVC APIs before we went and made all these changes. All but one are still available. We have deprecated the one at the bottom, Set AVC Request Callback. That was the old way to handle incoming commands and it really wasn't right. So if you were using that, you really want to use the new functions instead.

SBP3. This is a new revision of the SBP2 standard. That's the standard used for hard drives, iPods, storage devices on Firewire. We've added support for something called Fast Start. If you've watched in Firebug an SBP2 device, you may have noticed it takes up to five packets just to get the device to start doing I.O. You send it the orb pointer, it asks for the orb, you send it the orb, it asks for the page table, you send it the page table.

Finally, it can move some data. That's okay if you're moving megabytes of data, but for small I.O.s, it's really expensive. Fast Start defines a way to send all that information in a single packet. The drive can immediately start moving payload. We have measured a 30% performance speed up for optimal I.O.s using this technique, so it's definitely worth having. This technique is in ballot now within ANSI, which is the standards group that owns it.

Fast Start has been stabilized, which means nobody's going to change it. In fact, we've been supporting it since 10.5. Now, your device has to understand this new packet. You can't just turn it on and it goes faster. But if your device does understand this new packet, publish the appropriate key in your configuration ROM so that we know you understand it, and we'll send you Fast Start packets. If you're doing hardware that does this, we'd like to hear from you, because we've only seen one so far. So please let us know. We'll try it out and see if it works. Thanks.

Now, that's covered new and more detailed information about what's in FireWire software in Mac OS X for you to develop with. Let's talk about some of the resources we provide to help you do this. Software Development Kits. We've made 16 of these so far. It's our biggest product for you developers.

It has lots of sample code. I showed you the list earlier. The SDKs often have pre-release versions of the FireWire KEXTs so that you can try out new APIs or new bug fixes before your customers are exposed to them. The SDKs also have tools, utilities and lots of documentation to help you program on FireWire. These have always been available for free public download at the URL shown on the slide.

We have something new in the past year, the FireWire Reference Platform. This is completely independent from our Mac OS X FireWire. This is a software stack that can run on embedded devices. So if you're making a set-top box or a TV or a FireWire multi-function printer, take a look at our Reference Platform. You'll find a lot of code, especially for the AVC protocol and command sets. They can give you a big head start for implementing FireWire on embedded systems. There's also a session on this later this week.

We hold several developer events for FireWire. We have PlugFests at Macworld and here at WWDC. In fact, we had 40 devices submitted that are now being tested by the 1394 TA for PlugFest testing and we will bring them all Thursday during the campus bash down at Apple. Plus, you're welcome to bring additional devices then. We'll plug them all in.

We hold Developer Kitchens. This is where we bring our core engineers and meet with your engineers for two to three days of hands-on debugging development. Often we introduce new SDKs and new APIs at these sessions. These have been held in Tokyo and Cupertino. We've done about ten of these so far. We hold these on demand, so when you're ready for one of these, contact Apple Developer Relations, let us know, and we'll try to schedule one.

Eric Anderson And we participate in the 1394 TA Interop Workshops. These are like plug fests, only they're much more rigorous. There's three kinds of testing done at these events: pairwise testing of each device against each other device, The official test suites which go through the spec line by line, electrical testing, config ROM testing, all kinds of things.

And the grand melee where we plug all the devices together and try to get a 63 node bus to work. That's always a lot of fun. These happen four times every year. There's one in Tokyo, usually in April, one in Taipei, usually in October, and two on the West Coast, either in the Bay Area or up in Redmond for some reason.

These are not limited to TA members. Anyone can come to these. There is a slight fee reduction if you belong to the TA, but it's not expensive either way. We learn a ton of stuff about our own products and other products we've never seen before. You should come to these events. They're really valuable.

1394 TA is an industry trade group that promotes 1394. That's where all the AVC specs come from. They also do a lot of marketing and evangelism work, so you may want to consider joining the TA if you make 1394 products. Okay, now let's look at some new FireWire tools.

I mentioned this earlier. This is related to tools. We'll get to it in a second. What exactly is a PHY? There was a box marked PHY in that architecture stack right at the beginning. PHY is short for Physical Layer. It's the chip that actually drives differential voltages on the FireWire cable and makes ones and zeros. And it receives them at the other end and turns them back into bits.

The PHY acts as a repeater if it has two or more ports. And the PHY performs the arbitration. So there's no software control for the PHY. It's all automated. It makes the arbitration go very fast. In comparison, the link layer, which in a Mac is OHCI, is much higher level. It knows about DMA, CRCs, isochronous time. It's higher level than the PHY.

The PHY does not have a device driver. It's not programmable. But it does have a small register file. This is a page from the 1394A standard that shows the registers in the PHY. Each one is 8 bits wide. But there's some very interesting information in there, like the status of each of the ports on the PHY. Often, when you find some unique and interesting thing happening on your FireWire bus, you may want to look at the PHY ports to find out why it's doing that unique and interesting thing. 1394A defined these bits, 1394B defines a few more.

We now have a tool that lets you examine these directly. This was possible in Mac OS 9 if you dropped into Mac's bug, but it was really tedious. I think you'll find this a little bit easier. FiTool is a real-time browser and editor for FiRegisters. It displays the FiRegisters just like the specification, except each one of those boxes is now a checkbox or a pop-up menu, and it has an explanation of what its current value is and what that means. FiTool has integrated documentation.

If you move the mouse over one of the bits, like "Enable Standby," the text from the specification itself will appear at the bottom of the screen, telling you exactly how that bit is supposed to work. FiTool can examine the Fi in your Macintosh, or it can reach out across the FireWire bus and examine the Fi in other devices, if they support 1394A or 1394B.

It also provides a continually updated summary of the PHY it's looking at and the status of all of its ports, so you can see devices that are plugged and unplugged in real time. PHY tool doesn't require any special hardware. PHY tool runs on every Mac that we sell. It runs on the 1394 OHCI controller.

Eric Anderson Here's a full screen shot. You can see the center portion looks just like the spec. Down at the bottom there is the text explaining what the speed field means, where the cursor is located on line three. Eric Anderson Over on the left, you have a summary of what all the ports are doing.

Port number one is connected. The other two are disconnected. Eric Anderson And there's pop-up menus to pick which interface, if you have multiple interfaces, and which node, if you want to look across the bus at another node. Eric Anderson So it's really easy to use. Believe me, if you've never tried Cocoa programming, you won't believe how easy it is to get this kind of stuff working. This was a lot of fun, and I think you'll really enjoy this tool. Eric Anderson Even if you don't have problems in your PHY, this tool is very educational, just looking at the bits, seeing them change, finding out what's happening on a running PHYWIRE bus.

We have another new tool for you. This is called Fire Starter. This tool was written for plug fests. All of the commercial FireWire analyzers out there can show the topology of the FireWire bus, but none of them does it very quickly. Like I mentioned the Grand Melee where we get 63 nodes on the bus, which we've really done. Some of the commercial analyzers take 30 seconds or more to try to figure out how to draw a picture of that. By that time, one of them has caused a bus reset and everything's changed. It's just too slow.

Firestarter can draw a slightly simpler version, but topologically accurate map of the bus and it can update it 10 times per second. So it gives you a very real-time idea of exactly what's actually on your bus. In the picture there you can see on the right a simple ASCII rendering of the bus, and on the left various information that's especially applicable to plugfests, like how many nodes, what's the maximum hop count, how long has it been since the last bus reset, and what's the longest time we ever survived between bus resets.

There's also a bunch of data in the lower left that sorts all the nodes and shows you how many are S400, S200, how many are 1394B. So you can get a very rapid snapshot of what's connected to your bus. Here's a full screen display. This is a bus with just six nodes on it. You can see in the upper right the hierarchy showing who's connected to who. Here's a picture from one of the plugfests where we got 63 nodes on the bus.

I didn't actually have a big enough screen. You have to stretch the window down a little bit to see the last seven nodes, but it's showing the topology of how everyone's connected to everybody else. And I'd like to point out that the bus was stable for, I believe, more than a minute.

We have one more new tool, FW Busy Bus. This is a traffic generator. FWBusy Bus can send any kind of asynchronous packet on the FireWire bus. It can also send bus resets and it can cause bus reset storms. It will even enable and disable its own ports to simulate hot plugging. It's automated.

It can automatically ramp up and down the level of activity, so you can leave it running over a period of time and test different levels of activity on your bus. You can also turn on and off every different kind of packet, packet speed, bus reset, everything that it does. All three of these tools are available on our website. Work on OHCI, so you don't need any special hardware. Here's a full screen picture of Busy Bus.

The sliders at the top let you adjust the intensity level and how quickly it ramps up and down. The check boxes in the middle let you turn on and off every different kind of packet and packet speeds. And the control at the bottom gives you a brief summary of what's on the bus and what the tool is doing at any particular moment.

Plus, on the left, we have the PHY status that is copied from... FW Busy Bus can send any kind of packet. If you configure it properly, it can write garbage data onto physical memory in your Mac. Be careful what you turn on and what you don't in this tool. The default settings are safe.

Now, if there are interesting things happening on your FireWire bus, if somebody's writing garbage data into your memory, you might want to examine the FireWire bus and see what's going on. We have a tool for that called Firebug. I'm pleased to announce today that Firebug is now available for Mac OS X. Really. There it is.

Firebug is a real-time packet snooper. It can decode every packet on the bus and show them to you in a sort of semi-English ASCII way. Firebug provides precision timestamps to within one cycle time, usually much better than that. Firebug can decode common protocols like SPP2 and AVC, so you don't have to pull out the spec and look up hex codes. It'll tell you if that's a block read, he told the camcorder to play.

Firebug also provides some simple bus configuration services. If you'd like to tune the gap count or cause a bus reset or go poke at the PHY, you can do that from within Firebug. Firebug still requires the TI PCI links interface. We made it run on Mac OS X, but OHCI just doesn't have the snooping hardware. These interfaces are still available. You can get them on Cardbus card or PCI card. And if you have a really old Mac like the blue and white G3, it actually has one of those built in.

But we've not only brought it to Mac OS X, we've made a few improvements. We've improved the decoding. We added a bunch of new AVC commands, especially the unit info command, so you can see when that's happening. The SPP2 decode can now survive a bus reset almost every time, whereas usually it almost never survived. It would just go back to showing hex because it didn't know what was going on.

There's a tool called the PHY Register Dump. If you don't have PHY Tool handy, you can just ask Firebug to do the same thing, and you can see in the picture there, it has dumped out the contents of the PHY in a concise ASCII format. We've added Node ID filters. You can now look at packets only going to or from or between whatever nodes you choose. You can select which isochronous channel you'd like to look at.

You can get an isochronous summary. Usually you don't look at isochronous packets because there's 8,000 per second. It just wipes out the display. But Firebug will now tell you, even if it's not showing the isochronous packets, ah, channel 63 has gone active. In fact, it's active at S100. It's coming from Node 2.

It's NTSC video. So now you'll know something's happening even though you didn't get the display blown away by thousands and thousands of isochronous packets. And because it runs on Mac OS X, we've been able to make Firebug support dual processors, so now it's even faster than it ever was before. So let's demo Firebug on Mac OS X.

May I have number three please? There we go. It's right here. Launches just like that. This system running Firebug, it's a G4 tower, so I installed a PCI links, PCI card into it. It's connected to this other G4 tower, and you can see the packets there as the other G4 tower scans the bus.

So I'm going to plug in my iPod, and we'll see all the activity that this generates, and we'll see that Firebug can decode the SPP2 protocol that the iPod is using. It takes the iPod a few seconds to switch from MP3 mode over into disk mode, but it should be ready to go right about now. There we go.

Mac OS X is mounding it as a file system, so it's reading different blocks, it's figuring out that it's HFS+. You can't see it, but it drew the icon on the desktop over on this other Mac. You can see here some of the new features in the decode of the normal command orb there at the bottom. It says read one block at LBA 900E3C.

So you no longer have to figure that out for yourself from those 12 bytes of hex under command. Additionally, I can cause a bus reset and fire bug and then go ask this Mac to do something with the iPod and you'll see that it's still decoding the commands even after the bus reset, which almost never worked before.

I mentioned Firebug takes advantage of dual processors. It also no longer completely monopolizes the machine like it did on Mac OS 9, so if you want, you can leave your other apps open. Now it's not doing anything, but let me ask it to show cycle start packets, and you'll see that it gets quite busy.

This is a pretty fast G4 tower. I have on slower units maxed out both processors at 100% running Firebug, but you can see it is using them both. So if you are a long time Firebug user, if you're tired of booting back into Mac OS 9 to run Firebug, if you'd like some of these new features, I think you'll be pretty happy with this. Let's go back to the slides.

Okay, so I've announced all these new tools. FiTool, FireStarter, FWBusyBus, those all run on OHCI, so you can use them on any Mac that we have today, plus Firebug, which still requires PCI links. All of these tools require Mac OS X 10.2.5 or later. Very important. If you're familiar with Firebug, you know how it works. It touches the hardware directly. All of these tools do that. That's good and bad.

We displace all FireWire services when you run the tool. We do it in a clean way. If you have an iPod or a disk mounted, the tool will refuse to run. It won't just displace the driver and leave you with a corrupt iPod. You will have to unplug any disks or iPods that you have in order to run these tools.

But because we displaced the software, you no longer have Mac OS X on the bus trying to manage the bus. So if you're trying to run FiTool to figure out why some camcorder keeps resetting the bus, you don't have to wonder. The Mac OS X is also on there trying to manage the bus. It's not. We've displaced it. The tool is the only thing touching the bus.

These are all new. We've tested them as best we can, but please be careful. They do touch hardware directly, so they can crash the machine. Make backups or run this on a dedicated machine, at least until you're sure that it's really going to be stable in your environment.

And watch our mailing list for updates regarding these tools because, again, they're new. So you're probably wondering, where can I get all these great tools? These sound like I want to try them out today. Well, you can. FireWire SDK 17 is available live today on the web. The only catch is that because they redesigned the whole ADC website yesterday, the link is missing. I know you can all figure this out. Go find SDK 16, copy the link, change the 6 to a 7, and you'll get the disk image for SDK 17.

Okay, let's wrap up. Here are the FireWire sessions at WWDC this week, not including 505, which you're in right now. Tomorrow morning, 504, Developing with FireWire 800. That's the higher level session, but we have a ton of new content this year about how FireWire 800 works. We have a feedback forum for both FireWire and USB. Like we do every year, you can get all your serial bus feedback in one convenient location.

We have a new session this year on Thursday, 5:08, the FireWire Reference Platform. We'll go into much greater detail about what's in there and how you can use it to make products. Finally, Thursday evening during the Apple Campus Bash, we have our FireWire, USB and Bluetooth Plug and Unplug Fest, and I'm sure that will be very interesting.

If you'd like to contact Apple, if you want to come to a FireWire kitchen, if you need help developing, you want to license the reference platform, here's contact information. Prashant Kanheri, he'll be up here in a moment, is the Program Manager for FireWire Technologies. You can also contact Yermo Ortiz and Apple Developer Relations. Eric Anderson We have a public developer mailing list. Anybody can join.

There's a lot of people on there. This is a place where developers can ask questions, developers can answer questions, we answer questions too, we announce new tools, we announce things about Firebug. Just follow this link and you can subscribe. At the same place you can subscribe to the Reference Platform mailing list, which is the same thing but it's focused on the Reference Platform.

If you'd like more information about developing FireWire on Mac OS X, our standard document is a book called Working with FireWire Device Interfaces. I said earlier that's the formal name for a user client. It's available online. It has a lot of information about how to use the user client to talk to FireWire devices.

Eric Anderson Our Software Development K its are all available on the web, SDK 17, as I just described. We also have a Tech Note coming, I don't think it's live yet, that goes into more depth about how to use DCLs. It should be posted soon and we'll announce it on the mailing list when it is. Eric Anderson The IEEE 1394 standard itself is available from the IEEE on the web.

The 1394 TA, also on the web, has standards for AVC command sets, the IIDC digital camera, automotive 1394, various other standards. Eric Anderson And if you're working with AVC, you may also need some standards from the ISO, such as the format for DV video. It's also available on the web.