Welcome to session 501, FireWire. Thank you. Okay, every year we see new FireWire products and applications, all sorts of areas. The technology just keeps going further. The main reason is because of you, our developers. You keep innovating with this technology, finding new ways to use it, and that's great. That's exactly why we're here. We're trying to keep up with you. We've got a lot of new services, new features, new APIs, new sample code, new tools, even a few bug fixes.

This year, we're back at WWDC, just like every year, to bring all that to you. For those of you who are already developing with FireWire, we have a lot of new material this year, especially as relates to Tiger. And for everybody, we have a quick introduction to the hardware and the software, so that you'll all get the complete big picture.

So we're going to start by recapping where the FireWire ports are and why they're there, because that's where your device plugs in, that's where the opportunities exist. Then we'll quickly look at the software, how that works from drivers up to application. Again, where can you hook in, what's your part going to do? The bulk of the presentation is on what's new, what's new in Tiger, and what's new since last year. And then we'll wrap up with a quick look at some of the great resources that we have for you as developers to help you develop on FireWire.

First, the hardware. Where are the FireWire ports? This part is easy because they're pretty much everywhere. Every product that we make, every CPU from the iBook up to the XServe has FireWire ports. Built in, we've been doing it for years. Every iPod that we make has FireWire ports.

And there's two more products that have FireWire. One is the EyeSight camera, used with iChat AV. And the other, only introduced yesterday, is our new line of flat panel monitors, which have built-in FireWire hubs. So there are lots and lots of ports for your customer to plug your device into. Why?

Why do we have so many FireWire ports? What's so great about FireWire? In years past, we could get up here and say, well, it's hot-pluggable, auto-configuring, no terminators, no SCSI IDs, thin, friendly cables. These days, that's true of pretty much every I.O. Anything left in FireWire that makes it special? Well, there's a few things.

FireWire is really fast. FireWire 800, 800 megabits per second, that's 100 megabytes per second. It's the fastest general-purpose interface on the box. If you want to get data in or out in a hurry, we've got the speed for you. Multi-speed. FireWire devices shipped starting at 100 megabits and then moved up to 800. You can freely mix and match these on a FireWire bus. The slow devices go slow, the fast devices go fast, but FireWire can change speed on a packet-by-packet basis, so the fast devices don't get slowed down by having to speak at a common, slower speed.

FireWire can cover really long distances, longer than the other general-purpose I/Os. FireWire can go up to 100 meters. That's longer than a football field. If you want to get your device really far away from the user, FireWire is the way to do it. FireWire provides a lot more power than any other bus, too.

Maybe that's why you want to get the device far away. FireWire can provide 45 watts of power. Our machines provide less, but plenty to run an iSight or an iPod. But if you have a custom application, the cables, the sockets, they're all rated for 45 watts. You can do some really innovative things with that.

And customers love it. There's no extra power supply for the iSight camera. The iPod charges when it's plugged in on FireWire, and it charges quickly. Big advantage for FireWire. isochronous. Some other interfaces have this, but FireWire does this really well. Isochronous moves streaming data, audio, video, data that has to go in real time. FireWire has very low latency and guaranteed bandwidth for isochronous, so it works very well for delivering your media data.

FireWire is peer-to-peer. FireWire has been peer-to-peer from day one. The very first FireWire product was a digital video camcorder in 1995. There was only one other thing you could plug into it on FireWire, another digital video camcorder. You can't get more peer-to-peer than that, but it worked. You could copy one tape from one camera to another. You could edit DV. It was kind of cumbersome. We didn't have Final Cut back then, but you could do it peer-to-peer between those two cameras. Everything about FireWire is peer-to-peer. The host, the devices from day one. Some other interfaces, this may be cobbled on years later.

It may kind of work, especially if you only have two peers. It may work some of the time. Not in FireWire. It's been there from day one. It gives you tremendous flexibility. And all those together, that's really what FireWire is about, flexible. If you choose FireWire as the interface for your product, you won't get boxed in by design constraints. As your product grows, as you add new features, capabilities, speed, performance, FireWire continues to take you there.

FireWire has so many different ways of meeting your product's needs. It's open-ended. You won't get stuck on the limitations of the bus. And it's efficient. When you have lots of devices on a FireWire bus, the bus can run nearly 100%. There's no collisions in FireWire. There's no back-off. There's no lost packets. FireWire operates very efficiently, even under stress. So let's take a closer look at some of these key concepts.

One thing that makes FireWire really fast is the physical DMA. This is a feature in our products in the host controller that allows a FireWire device to directly read and write memory without getting the CPU involved. That speeds things up a lot. Let's look at how that works. Suppose we have a PowerMac G5 tower and the new iPod Mini. Of course, it's plugged in by FireWire. Let's look inside the G5 tower and look at just a high-level view of some of the system parts in there.

On the left, you see the CPU. In the center is the north bridge, and it connects the CPU to the memory, which is on the right, and the I.O. controller down below. The FireWire interface is in that I.O. controller. When the iPod has been directed to move data, it's going to copy data into or out of the system. So let's have a buffer here in memory. Let's have a buffer here in memory. The iPod requests -- the transfer is initiated by the iPod. It tells the Mac, "I want to read the buffer," or "I want to write the buffer here, here, here, and here."

This transfer goes through the I/O controller, which receives the requests over FireWire, and goes directly to DRAM to service them. The CPU is simply not involved. There are no interrupts, there's no polling, no PIO, no handshake, nothing. It goes as fast as it possibly can, and the CPU is available to do other important work.

Of course, when the transfer is done, we send a special packet that does cause an interrupt, because we do want to know the date it made it, where it's trying to go. But this makes FireWire extremely fast. Also, the pacing is under control of the iPod. This is a very unequal system. The iPod has a very small disk.

It's just not quite as fast as the G5's memory system. The iPod controls the pacing. I want to read data now, now, now. Everything goes exactly at its speed, so there's little need for flow control or congestion with the iPod. driving. It can do absolutely the best that it can.

Another important feature is the guaranteed isochronous bandwidth. This is for real-time services. If you want to connect a camera or a microphone, a device that streams media, FireWire gives it guaranteed access to the bus. Its packets will get through, they'll get through on time, even if someone else is trying to drive the bus to 100%. Let's take a look at how that works. We'll start with the iSight camera.

This camera, made by Apple, sends video and audio over FireWire into a Mac, and is commonly used with iChat AV. If we look at a graph of the activity on a FireWire bus from an iSight camera, it's very flat. Let's suppose the camera is set to a very high-resolution, high-quality video mode. The camera might be using 50% of the FireWire bus. If it's the only device on there, nothing magic is happening. Of course, it can get 50%. It's all about the location of the bus. Let's consider a more complicated case.

Let's take a non-real-time device like a hard drive. A hard drive has a lot of moving parts, so the rate at which it can transfer data is going to vary over time, especially if you're doing complex transfers like directory copies. If we look at the access pattern of a hard drive on FireWire, we'll see it's all over the map.

If it gets going, it may go up to 100% and saturate the FireWire bus, but then it may drop off while it waits for the media to rotate around and grab some new data. If it gets going, it may drop off while it waits for the media to rotate around and grab some new data.

on the same FireWire bus. Well, the bandwidth for the iSight is guaranteed. The iSight's going to get its 50% all across time perfectly smoothly, and the hard drive is going to get everything that's left over. The hard drive doesn't have to back off or moderate its requests. It can go out and say, "I want to move data, and I want to move it now," and the hardware in FireWire makes sure that as soon as the iSight is done moving its isochronous data, the hard drive can get every little bit that's left over.

So in this combination, the bus efficiency can be pushed basically to 100%. The hard drive can just go full bore. It'll take a little longer because the iSight is also on the bus, but there's no impact at all on the iSight. The audio and video keep flowing completely smoothly. This guarantee is provided in hardware, so you can't mess it up.

Finally, I said FireWire can go really long distances, but you may have noticed that we don't have long-distance ports on our products. Why is this? Does this really work? Well, most of the devices our customers connect are things they want to use nearby, because they're probably interacting with the device as well as with the Mac, such as an iSight camera, an iPod, a DV camera where they may be changing the tape.

But there are some kinds of devices that are very interesting at long distances, such as a security camera, or a music studio application, or an industrial application where you want to put some distance between yourself and the device. So, we can do that. What you do is get a 1394B hub. This is a very simple device because it's just one piece of silicon.

The Hub has regular FireWire 400 ports on one side, which you can connect, say, to our iBook, as shown here, and it has long-haul 1394B ports on the other side, such as plastic optical fiber, glass optical fiber, or Category 5 unshielded twisted pair. You can choose the media that's most appropriate to your application.

This way, we don't have to pick between those three for the port on our computer, and you can still get the long distance. Now, if your device is something that's always going to be used, or often going to be used at long distance, it may make sense for you to incorporate the long-haul connector directly. Then the customer doesn't need two hubs, they only need one.

Other important thing to note about this picture, the two devices at either end, the iBook, the iSight camera, those are not 1394B devices. They're FireWire 400. Can they work with this long distance? Sure. 1394B is completely backwards compatible. The hubs understand how to talk to a FireWire 400 device and how to talk to the long-haul connection, and the data flows seamlessly through from one end to another.

So this means if you want to put some distance between the devices, you're not limited to our latest models like the G5 and the PowerBook that have FireWire 800. Your customers can use this with all of our products that ever had FireWire ports going back many years. So this is very flexible technology.

Let's move on into the software. You've seen where the ports are, why they present unique opportunities. Where do you hook in if you're writing software? Consider the Macintosh. Suppose you have some FireWire devices that you'd like to use. You're going to have some applications that launch when you want to use these devices. Now, as I explained earlier in the diagram with the iPod, every Macintosh has one built-in FireWire controller. It's the industry standard 1394 OpenHCI, Open Host Controller Interface.

All of these devices are going to have to share. They all want to use it at once. Someone's going to have to mediate this. So you've got different applications, different drivers, different devices, each doing their own different thing on a single controller. That's the main job for the FireWire family. The family steps in, takes ownership of the controller, and moderates so that everybody can do their thing without even worrying about what else is going on. That's the main function that the family provides.

Now, you may not see it, but consider the two devices on the left, the still camera, the iPod Mini. They actually have a lot in common. They both use a mass storage-oriented protocol. They use the FireWire transport called SBP2, Serial Bus Protocol 2, and they communicate using a SCSI architecture on top of that. So we provide a standard software layer.

is the director of the FireWire software development team. He's been working with Apple for a long time, and he's been working with FireWire for a long time. He's been working with Apple for a long time, and he's been working with FireWire for a long time. He's been working with Apple for a long time, and he's been working with FireWire for a long time. He's been working with Apple for a long time, and he's been working with FireWire for a long time.

He's been working with Apple for a long time, and he's been working with Apple for a long time. He's been working with Apple for a long time. He's been working with Apple for a long time. He's been working with Apple for a long time. He's been working with Apple for a long time. He's been working with Apple for a long time.

He's been working or a IO FireWire IP can provide networking services. Those are both kernel services, so FireWire has to be in the kernel to make those possible. But we've gone out of our way to make everything in FireWire available in user space as well as in the kernel. So odds are, you can write an application or a plug-in for an application. You can run it and debug it in user space, which is much more pleasant than trying to do your development in the kernel.

Now that you've seen the basics, let's look a little more at the details of the layers. Here's the items from before. At the bottom, we have the hardware interface. Apple FW-OHCI is a system kernel extension that effectively is the device driver for that interface, and it has sole control, sole direct access to the hardware. Above it is IO FireWire family, also a kernel extension, and it has sole ownership of the OHCI driver.

Above the family, first we find protocols, such as you saw on the previous slide, such as AVC or SPP2. Above protocols, we have drivers for particular devices or classes of devices. For example, a mass storage device uses the IO FireWire Serial Bus Protocol Transport Driver as its gateway up into mass storage and the file system, whereas the DV Camera uses IO FWDV components as its gateway up into QuickTime. Other drivers are more specific, like Apple EyeSight or IO FireWire IP. In fact, these drivers don't use a separate protocol layer. They really are a protocol and driver all wrapped up in one, so drivers can also hook in directly to the FireWire family.

Above this layer, we have what I call everything else. Once you move above this layer, you're not in FireWire anymore. You're in QuickTime. You're in Final Cut. You're in the file system. Somewhere else. Not my problem. So, say, iTunes, Final Cut Pro, QuickTime, they're good places to be. They're above FireWire. These could be applications, or they could be additional kernel layers.

So this is the basics of how the FireWire software hooks together. I mentioned that in applications, you can access all the FireWire services. So of course, applications can talk directly to drivers, but there's two other paths as well. We provide what's formally known as a device interface, and is often called a user client. This is a library API that lets you talk directly to a protocol, or even directly to the FireWire family itself from an application. So we're very flexible. You can hook in anywhere you need, in the kernel, in application space. We provide lots of ways to do it.

Now, I mentioned IO FireWire IP. What's that doing here in FireWire? IP is a protocol that's designed to span the globe. It works well on slow, comparatively slow, unreliable links. Doesn't sound like FireWire. Well, turns out it works great on FireWire. It doesn't depend on anybody dropping packets. But a lot of devices already have IP in them for one reason or another, generally because it's ubiquitous. A lot of printers today have a little web server inside that lets you browse the status of your device.

Or configure the device, even if the main data is sent over some more native protocol, say SBP2. So if you already have IP capabilities in your device, you can carry these into your FireWire device, and the user will have full access to these services. In Mac OS X, we implement IPv4 and IPv6 in FireWire. It fully supports Rendezvous. If you have a surfable device, you can get to it through FireWire. No special effort is needed. So we're very flexible there. Please think about taking advantage of it. that.

The FireWire family. This was the master control layer that provides all the services. Just what are those services? First and most important, when your device gets plugged in, we have to find it. The family knows how to notice that a new device is on the bus, and the family will ask the device, hey, what are you? Why are you here? The family takes these answers and puts them in the I.O. registry, which is not a FireWire structure. It's a general I.O. kit service. I.O.

kit then comes along and matches drivers or protocols to your device based on the information that FireWire provided. And this process may be iterative. Your device might say, well, I speak the AVC protocol. So we would match the AVC layer, which would then ask your device further questions saying, okay, what kind of subunits do you have? Your device might say, I have a tape subunit, an audio subunit. We put that information in the I.O. registry as well and then match further so we can get just the right driver for your device.

On a FireWire bus, the node IDs may change. They're assigned randomly. As devices come and go, they may change. It's the last thing your driver wants to deal with. No problem. Every FireWire device that we can talk to has a unique serial number called a GUID, Global Unique ID. The family will track this down, and it'll follow it around the bus, so the family always knows what node ID your device is on. It will automatically send your driver's packets to your device, so you don't have to worry about this.

On a FireWire bus, I mentioned you can have mixed speeds. Maybe your device does FireWire 800, but your customer plugged it into an iBook that has FireWire 400. We don't want your driver to have to figure that out. The family figures that out. The family looks at who's connected to who, finds the fastest path between devices, and automatically routes your traffic at the best speed that it can do. Also, the family, having looked at the bus topology, can perform an optimization to tune the bus to make it operate as fast as possible. Again, something your driver won't have to worry about.

Okay, so your device has been discovered. It's on the bus. We're keeping track of it. Now you want to talk to your device. The most basic communication on FireWire is an asynchronous request, a read or a write directed at a memory location in your device. The family will do this for you.

It'll send the packet to your device, and if your device is so kind as to respond, the family will fish the response out from all the traffic on the bus and hand just that response back up to your driver. So you don't have to worry about the other devices that are on the bus.

You may want to do the reverse. Maybe your device will initiate the communication. If so, it needs an address that it can talk to in the Macintosh. So the family will allocate an address space for you, and as packets come in to that address space, it will hand them to your driver and say, here, do something with this. So you can go either way.

You may want to communicate in real time. We'll get to that in a moment. The family also publishes a configuration ROM. This is the structure that tells every device on the bus what you do. For a device like an iPod or an iSight, that function is probably locked in at the factory, so this may truly be a ROM. But for a device like a Macintosh, its capabilities may change as new applications are loaded, new drivers are installed. So that's why I put quotes around ROM. On the Macintosh, the configuration ROM really comes out of RAM and is managed by the FireWire family.

For example, when IO FireWire IP loads, it says, "Please tell everybody that IP services are now available on this node." So the family puts that information in its configuration ROM and announces it on the bus. If you want to communicate in real time to send or receive streaming data, the family manages that for you, and we'll go into a lot more detail about how that works. Additionally, the family can get you your reservations on the bus. If you want to reserve bandwidth for your real-time communication, just ask the family. It will get the reservation, and it will keep the reservation valid for as long as you're using it.

Now, there's a second completely independent implementation of FireWire in the Macintosh, and that's in the boot ROM. Why? Well, you can boot the computer from a FireWire disk. So somebody has to load Mac OS X from the disk over FireWire. It can't load itself. The boot ROM does that. You may not do this every day.

I do. But this is very helpful. You might need to install Mac OS X on a lot of different computers, say, in a laboratory or classroom environment. Installing from a hard drive is a lot faster than installing from optical media. Or you may need to install Mac OS X over and over and over again if you're testing or debugging or checking different versions and you only have one system. FireWire booting is great for this. It really speeds things up.

The other thing that the boot ROM can do is a service called Target Disk Mode. This is where FireWire's peer-to-peer capability really shines. In Target Disk Mode, the Macintosh will emulate a FireWire hard drive completely in software. You can then plug it into a second Macintosh, and it will show up on the desktop as a FireWire hard drive.

Here, too, you may be wondering, why would I do this? Well, it's a real easy way to move data quickly between systems. It's also a great way to fix up a system if it's not booting properly. If you're developing kernel drivers, and you've installed a new KEXT and rebooted the system, there is a chance the system will crash in your KEXT. Well, that makes it very hard to get your system working again, because you can't boot to Finder and get rid of that KEXT. No problem.

Put the system in Target Disk Mode, plug it into your other Mac, go delete the offending KEXT, take it out of Target Disk Mode, and you're good to go. Now it'll boot fine. It's a very quick recovery. It's a lot better than reinstalling the OS. So two capabilities in the boot ROM that you may find useful.

We also have a third completely independent implementation of FireWire, and that's called the FireWire Reference Platform. You may recall that we purchased a company called Zyante a few years ago, and they had a product called TNF1394. That's what this is. This is software that's designed for pretty much anything except a computer, a peripheral device, a multifunction device. It's a rich, modular software stack designed to run within the limitations of a real-time software.

It's a very simple software that can run on a single device, and it's very easy to use. You can download the entire TNF sources from our website. They're posted for everyone to use. If you want to incorporate the source in your product, you need to sign a license from Apple, but it's free, no problem.

The TNF has very rich services. It has lots of examples, what it calls applications, which is sort of the heart of whatever your product does. It especially has good AVC services. So if you're doing an audio or video device using the AVC command set, there's really rich capabilities here that could give you a huge head start. It's available on the web. You can take a look at it and see if it meets your needs.

Okay, now that everyone's well-versed in FireWire, let's move on to what's new. First, and most importantly, what's new, you guys have been great. You've shipped a ton of products this year, all sorts of innovative things. So a big thank you to our developers, really happy with all the stuff we've seen. New product I'm sure you've seen is the iPod Mini, but maybe you didn't know it has SPP3. What is that?

It's the same SPP2 that we use for mass storage devices, but it has a new feature that makes it go faster. Let's look at what happens with an older iPod and a Power Mac as we try to read 2K of data from the device using an operation that has a page table.

Here's the two devices. There's going to be seven packets exchanged on the FireWire bus to complete this operation, to signal it, to move the data, and to indicate that it's done. The packets are very efficient, so this isn't bad. We get good performance from this. But Fast Start makes it a little bit better.

With the new iPod Mini, that same operation takes just three packets, a 57% improvement. This gave us a good performance improvement we were very happy to have. Fast Start in SPP3 has been supported since Mac OS 10.2.5. We encourage you to try it out in your products if you use SPP2.

AVC, the Audio Video Command Set. We've had support for AVC since day one, because that first product was a camcorder. But there's one thing we've never done quite right, and that's a kind of command called notify. The notify command in AVC is something that may complete later. It may complete a lot later. You're telling the device, I expect something to happen in the future.

Please tell me when it does. But our API for sending this kind of command is synchronous. So you call this API, saying, hey, tell me what's going to happen. It may be days later before it returns and says, okay, it happened. That doesn't really work. So we still have the old API, no change at all there, AVC command, lets you send a device out, send a command out to your device. But we have a new service that's also available. You can create an AVC asynchronous command and assign to it a callback.

When you submit the command, it returns right away. Later, when the device completes the notify or sends the status, your callback will be called. So this is perfect for use with the notify command. You can also use this with other types of commands, but they'll generally complete right away.

If you're familiar with our software development kit, you may have seen our MPEG framework. It's a pretty rich collection of services that allow you to stream MPEG on FireWire on a Macintosh. Well, we've taken that a lot further. That was in SDK 19. We've extended it and renamed it, and now it's the AVC Video Services Framework.

What we've done is added DV, the completely second video format, and we've integrated all of the AVC commands and control that are necessary to set up, discover, and maintain these streaming connections. So your device, your driver, doesn't have to worry with these details. All in all, it provides better support than our older APIs like the Isochronous Data Handler. For example, only with the new framework can you do DVC Pro HD.

In writing your applications, keep in mind this is still a very low-level way of talking to your devices. Depending on what you're doing, this may be appropriate. However, application software may want to use higher-level APIs, such as QuickTime. If you use QuickTime, you can talk to any kind of video device without worrying about whether it's on FireWire or something else.

But if it's appropriate, you can use this framework. We know several developers are already shipping products based on the framework that's in the SDK. In Tiger, this will be a private framework, but it will continue to be in the SDK, and you can pick it up there and build it into your products.

We would like to consider making it a public framework, so you can just count on it being there. We need to hear from you. We want to hear how you're going to use it, how it's going to help your product, and what you're doing with it. That kind of feedback will help us to take this into a public framework. So please take a look at this, evaluate it for your needs, and then let us know.

Isochronous data. We've talked about sending real-time data on the bus. How do you receive this data in your driver? We have a new capability called Buffer Fill IsocReceive, but I haven't really described how to receive any data, or even really said what isochronous is. Let's do all three. Isochronous literally means equal time. So if we take a timeline and divide it up into equal chunks, that's isochronous. Then we send the packets on the bus in these equally spaced cycles. Here's six packets going across the bus at regular intervals.

The FireWire bus provides these cycles 8,000 times per second. If you're receiving isochronous data, you probably don't want us calling you 8,000 times per second to say, hey, a new packet arrived. Quick, better do something, because there's another one coming in 100 microseconds. Isochronous, whether you're sending or receiving, it's about planning ahead. What you do is you make a list of instructions for us in memory using an abstract structure called a data stream control list.

You give this list to FireWire and say, here's a plan. I want to receive the next 100 packets as so. It might look like this, a series of instructions, each of which says receive one packet, and here's a little buffer to put the packet into. Then, when you run this program and start the isochronous stream, the packets flow into the buffers just like you'd expect. This is what we've had all along. This can serve any kind of isochronous reception need. But this is not always what you want.

The particular stream shown here has packets that are not all the same size. This depends on your kind of device. Some devices always send a single size of packet. Others may be all over the map. In the later case, you may waste a lot of memory, a lot of buffer space, because if you don't know which packet's going to come when, every buffer has to be big enough to hold the largest possible packet.

The hardware in the industry standard OHCI provides a way to pack the packets together neatly, and this may be what you want, depending on the kind of data that you have. So, while maintaining the existing services, in Tiger, we're adding a new way to receive isochronous data called buffer fill, which is simpler. Here, we simply have a list of buffer pointers and some significantly larger buffers.

The hardware in the industry standard OHCI provides a way to pack the packets together neatly, and this may be what you want, depending on the kind of data that you have. So, while maintaining the existing services, in Tiger, we're adding a new way to receive isochronous data called buffer fill, which is simpler. Here, we simply have a list of buffer pointers and some significantly larger buffers.

The hardware in the industry standard OHCI provides a way to pack the packets together neatly, and this may be what you want, depending on the kind of data that you have. So, while maintaining the existing services, in Tiger, we simply have a list of buffer pointers and some significantly larger buffers. speaking of DCLs, which is the Data Stream Control Language for sending or receiving packets, we've made some improvements in Tiger.

We've cleaned up what happens when the computer sleeps. Isochronous means real time. But if you're sending packets and the computer goes to sleep, that's not real time anymore. When the computer wakes up, any packets that you had prepared are way out of date. Nobody's listening. Nobody cares. So we used to try to keep sending, and that was a mistake. We've cleaned it up. Now we stop your program.

When the computer wakes up, we send you a message saying, "Hey, your program stopped because the computer went to sleep. You want to start it up again? Go right ahead." You should check and see if your device is still on the bus, see if there's anyone listening, but then go ahead and start your program up.

Every DCL has a callback known as the force stop proc. It gets called if your program is stopped against your will for some reason, such as the computer went to sleep, or such as you lost your isochronous reservation, which is very rare, but there's a special case where it can happen.

So be sure you hook up this callback, pay attention to the hardware slept message, then just call stop and start to get your stream going again. You don't have to tear down your DCL, just make sure it makes sense, fill it in with fresh data, and get it started again.

Some kinds of isochronous, since it's real-time, the system may be trying to meet various real-time deadlines. Especially in the case of receiving audio on FireWire, there may be very high-priority threads running, trying to do everything with the lowest possible latency. This may work at cross-purposes to FireWire, because it may hold off the execution of FireWire's processing of your packets that are going in or out.

So we've added a method you can call that will directly force the update of your program, regardless of the priority. So if you are running on a high-priority thread, and you want FireWire up-to-date, call this method, FireWire will run even if it's being held off otherwise, and your data will be up-to-date. The typical case to do this is with audio. We've made further changes.

If you have a transmit program, it's common to make changes to the program while it's running. You can change the size of the packets on the fly. You can change the buffers the packets come from on the fly. You can even rearrange the program order on the fly.

This is often done because the programs typically run either in a loop or in a sort of open loop that's constantly being refreshed with additional data. Previously, if you changed either the length or the pointer to a buffer, it was very inefficient as we went through and updated that, and we've greatly streamlined that. So it's much more practical now, especially if you have a big program, to use this technique.

I mentioned that the callbacks for audio processing, you can have priority problems. In addition to the direct service method you saw on the last slide, we have a new capability to assign a dedicated thread to your DCL. If you have multiple DCLs, this will let you prioritize them or prevent deadlocks between them.

If you're running in the kernel, you can allocate and create the thread of your choosing and set all the parameters just the way you like, then assign it to your DCL. On the other hand, if you're running in user space, you can simply set a flag saying that your DCL should be processed on a separate thread so it doesn't depend on anybody else.

More isochronous, in a way, the EyeSight camera. It sends audio and video on FireWire, but no one really knows how the audio works because that's not in the spec that it otherwise complies with. The camera complies with the 1394 Trade Association, IIDC, camera specification. Apple extended that a little so this camera would work well with iChat AV. We added some video formats that work well with internet chat, and we added an audio capability.

We have prepared a developer technical note that explains how these work, and some of the other subtleties of the device, like how to find out if the shutter is open, and what's in the config ROM, and what all those unit directories mean. This tech note's about 90% done. We hope to have it out to you in the SDK, or post it on Apple's developer support site in the very near future.

Let's talk about some changes to tools. Color Firebug. You may be saying, "Hey, I like color. That sounds good, but what's Firebug?" FireBug is Apple's packet analyzer. It's a snooper. It requires a special PCI card or card bus card, but it lets you see every packet on the FireWire bus, and this can be tremendously useful in trying to debug your device. FireBug is the poster child for crude but effective.

You can see the user interface is somewhat lacking, but it shows you every packet on the bus and has lots of options for how to arrange the data. Here, if you're a FireBug whiz, you can see that it's showing operations to an iPod as we read and write data from the disk, but some of you may still not really see that so clearly. Does that help?

ColorFirebug can colorize the packets based on various different criteria. The goal is to help you quickly identify what you're looking for. Here the packets are colored based on their type: reads, writes, blocks, quadlets, requests, responses. Each one has a different color. You can color based on the packet speed, based on the sender ID, the target ID, the isochronous channel, the acknowledge code.

Depending on what you're looking for, this may make it jump out. If you've got one packet that's at the wrong speed, it's real easy to spot one red line in a field of blue, then it goes through trying to read all of the digits and the speed codes. So if you use Firebug, download the latest SDK. This is in Firebug 1.9. Try it out.

We've also enhanced our FireStarter tool. This is a tool that was designed primarily for FireWire plug fests, or anywhere that you have a lot of FireWire devices connected together on one FireWire bus. It uses the same code as FireBug for displaying the bus topology there on the right-hand side in a simple ASCII rendition showing what's connected to what. This is based on receiving the self IDs, and no special hardware is required for that, so this tool can run on any of our products.

FireStarter also sorts all the self IDs and tells you things like how many nodes are running at each speed. FireStarter 1.4 has some improvements. In particular, there's an options menu that lets you select several different things. You can configure some subtle details about the role FireStarter will play on the bus in bus management. You can ask FireStarter to announce itself to FireBug by sending a packet after every bus reset to say, "Hey, I'm here. I'm on node 7."

You can even ask FireStarter to play the system beep sound on every bus reset if you need to know these are happening. And finally, there's a new display mode that shows the raw self IDs. When would you use this? Well, if you have a really low-level problem in FireWire, the self ID sequence may not complete properly. A defective hub or an out-of-spec cable may cause some kind of problem where the self IDs get messed up.

In which case, FireStarter can't make sense of them, and it won't even try to draw the tree. It'll just show you a blank page. So select this new option, and the page changes to show the hex values of all the self ID packets exactly as they came in. This will help you figure out what's going on. Also, we like color so much, we added some here, too. If there's a bus reset, FireStarter will tell you about that, too, just like that.

Some other tool updates. We have a tool called FiTool that we described in great detail last year. It lets you view and edit the registers in the Fi in the Macintosh, and you can view these registers on other nodes on the FireWire bus. FiTool 1.7 has some important new features. Among other things, it properly supports Panther and Tiger.

There's no user interface problems. And it has some important bug fixes, especially if you were changing Fi registers. The earlier versions would change a little bit too much, so you might get confused. It won't break anything, but you might really wonder what's going on. If you're using FiTool, please be sure to get version 1.7.

Vigilante is a new tool in our SDK. It really doesn't have anything to do with FireWire, but it tracks memory allocations for objects in the kernel, and we used it recently to track down a big memory leak in the Tiger version of FireWire. It was so effective, we said, hey, this is great. Let's put it in the SDK. We'll let everybody use it. So give this a try. It's another good tool.

Another capability we've never talked about before is the ability to put debug information in the I/O registry when you're working with FireWire. What is this? This is kind of like a dynamic printf. Rather than logging out information constantly, you can arrange to grab information from your driver at exactly the moment of interest. This is really flexible, although it's a little complicated to set up. If you get FireWire SDK 19 and you install it, you can then navigate down through the folders as shown here.

And for the different versions of FireWire, there are installer packages that will install new FireWire KEXTs into your system. Choose the package that has "debug" in the name, and it has a few special tricks. After you've installed this package and rebooted, you'll be running with a slightly different version of FireWire.

Look in the Applications folder in the SDK, and you'll find a tool called MrRegistry. This is a browser that our team produced that can look at properties in the I/O registry. If you look down towards the bottom, as marked in orange, you find the FireWire controller. Pick that and show the properties, and you'll notice something new. Marked in orange on the right is a property called DebugInfo. That's not usually there. That's added by the debug build of the extensions. So open that up. It has some information about the isochronous DMA contexts. This is pretty low-level stuff. Why would you use this?

Suppose you're transmitting isochronous on FireWire. It's pretty easy to use FireBug to see the packets are going out across the bus. You know your transmitter is working. Receive is another story. Your device may be sending packets in, FireBug shows them, but they don't seem to be making it to your driver. You don't even know if the Mac is listening. Here's a technique that can give you a bit of a hint. a clue. I just happen to know that my receiver is running on context 2, but there's only 8, so it shouldn't take you too long to find.

Open up Context 2, and you can see direct information about the OHCI controller, its command pointer, and its command state. If you refer to the OHCI spec, you can see that that state, 8431, indicates the DMA is running, it's active, and it records event complete, meaning it has received at least one packet. So that's a good sign. We're getting somewhere.

But maybe that's all that happened. It received one packet, it stopped, and now your application is not getting anything. What more can we learn? Look at the part marked in orange. That's the command pointer. This shows where in the DMA program the DMA is executing. Well, press the refresh button, and it changed. Another good sign. This means the DMA right now is still running, it's receiving packets, it's doing something with them. So everything looks very good at this point.

This is pretty esoteric stuff. Not everybody's going to need to dig down in here to see if their DMA is running or not. But the point is, this gave you a real-time printf. Rather than constantly logging information about what it's doing, you were able to reach in and look just when you wanted to and see a key piece of information.

The way this works is that the property that's created in IO Registry has a callback that says, when you need the value for this, just call me and I'll tell you. When Mr. Registry asks, up-to-date information is provided. You can do this in your driver to see almost any kind of information. There's examples in our source code. Get the SDK and look in the source code for the IP driver or the SPP2 service layer, and you can see how to do this.

Another capability we haven't talked about before: debugging with FireLog. This is not new, but we've never explained how it works, and we'd like you to give it a try. This is one of the oldest techniques in the book. You take two systems, you run on one of them, you use the other to look and see what's going on.

So your driver is running on the G5. FireLog creates a buffer in memory where your driver can log some messages. The other system is connected by FireWire, and it runs an application that can view these messages. So your driver runs along, recording information. This all shows up in the other Mac. Pretty basic stuff. You could do this with a serial port, you could do this with Ethernet. Why do this with FireWire? Well, there's a difference.

This system uses the physical DMA, just like the iPod that you saw before. What does that mean? When your driver logs a message, it's nothing but a sprint F into memory. There's no I.O. You don't have to call the Ethernet driver, the serial port driver. No interrupts, no context switches. It's extremely lightweight. Going through other I.O.s could add variables to what's happening on the system that you're trying to debug. This is not likely to change very much on the system you're debugging.

Suppose your driver is in the kernel. Suppose your driver panics. It happens. Even worse, suppose your driver hangs and doesn't have the good grace to panic. Well, you may not be able to get the very last message that it wanted to log. If you're logging in the system log or on a serial port or Ethernet, you may have panicked before that message really got all the way out.

No problem with FireLog. The physical DMA does not depend on the CPU. Even if the machine has panicked, the remote machine can reach in, look at the buffer, and see what's there and get the very last message that your driver logged before it died. And odds are, that's the one you want to see. So this is a really unique capability on FireWire. Give this a try. This is a bit tricky to set up. There's two ways to do it.

You can rebuild the FireWire family to turn on FireLog, or you can install the debug. Like you saw on the previous slide, where this should already be turned on. But we're trying to make this easier. We hope to provide a KEXT that you can drop into any version of FireWire that will automatically make FireLog available. Take a look in the SDK. There's instructions for how to get this set up.

Okay, let's quickly review FireWire resources. We've got a lot of great stuff for you developers in addition to the tools and code that you saw here. I keep mentioning the SDK, our software development kit. It's available on the web for free download. We've made 19 of these since we started on Mac OS X, and of course we're hard at work on number 20. SDK has lots of source code, sample code, application stuff, kernel stuff, great place to get started.

Often, the SDK has advanced versions of FireWire software. If we've made some fixes or added some features, we can use the SDK to get those out to you so you can try them out before your customers do. You can let us know if they work. You can let us know what we need to change.

All of the tools that you saw are all built into the SDK, and there's various notes and documentation. There's a lot of stuff. We've had 19 spins on it. We've really put a lot in there. Pick this up. It's on our SDK website. It's really easy to get.

We have some public mailing lists. There's a main list for FireWire. Any kind of Mac OS X FireWire development questions are welcome. We will try to answer, and often developers answer each other's questions, which is great. There's a second mailing list for the reference platform, where there's some very specific discussion about porting to specific real-time operating systems, specific hardware interfaces. That's another active list.

There's a third list a lot of you may want to visit, which is the ATA and SCSI list. Why would you go there? A lot of FireWire devices that use SPP2 have a SCSI architecture in their command set, even though they may have no actual SCSI hardware. If you're talking to that kind of device, most likely the easiest way to do it is through the SCSI task user client provided by our mass storage team. Support for that interface is discussed on this mailing list. For all of these, you can subscribe at one common place on Apple's developer site. It's very easy to do.

Apple owns the FireWire trademark, but we're not very selfish about it. Use this on your products. Your customer wants to know the product has FireWire. Put this on the product, put this on the box, put this in the marketing, on the web page. Go nuts. Just license it from us, and do be sure to use it correctly. If you license it from us, you'll get high-quality artwork, so you won't mess it up.

There's another logo that shows your product has passed the compliance testing from the 1394 Trade Association. This one you can't get from Apple because we don't run those tests. Attend one of the 1394 TA events, or send your products in to one of their vendors, and have them tested. You can get tremendously useful information about your product from this testing, and we send a lot of our products in. We always learn something new. This is a really good program.

Okay, a little bit more. If you'd like to talk to Apple about FireWire, Craig Keithley, who will be up here for Q&A, our main contact, or if you're located in Asia, you're welcome to contact Stephen Chick in our Japan office. Or if you're not sure who to talk to, just write to FireWire at Apple.com, and we'll find somebody.

In the reference library on Apple's ADC website, FireWire itself, we have some basic information about the technology. There's a substantial document for working with FireWire device interfaces. This is the user client I talked about earlier that lets you talk to FireWire from an application or from a plug-in that's running in the context of an application.

Apple publishes developer notes for each of our CPU platforms. They're quite detailed. They will tell you how many FireWire ports there are, if it's FireWire 400 or 800, how much power is provided, what's the internal architecture of that system. Lots of valuable information there, so please take a look. Finally, if you do have to write in the kernel, there's a starter document, Device Driver Fundamentals. It's not specific to FireWire. Take a look at that. That should get you up and running.

We have a good tech note on DCL programs. If you're going to be sending or receiving isochronous data, take a look at this technical note. For sample code, there's some basic sample code for FireWire, SCSI, and general mass storage posted on the ADC website independently, and then there's a good deal more in our FireWire SDK, as I discussed before.

Since you're here at WWDC, there's two more things you should know about. Tomorrow and Thursday, we will have Firewire engineers in the IO Technology Lab. If you go out these doors, turn left, it's right down the hall at the end. We'll be happy to take your walk-in questions. We can demonstrate the tools. We'll try to debug your code. Come on by and see us. Tomorrow, we'll be there from 9 a.m. to 6.30, except during the Firewire feedback forum in the afternoon.

And on Thursday, we'll be there from 9 a.m. to 5, and then we'll all leave for the other event, which is the ADC Plugfest at the Apple Campus Bash. So on Thursday, we will have a bunch of Firewire devices that you all brought, and we'll connect them together in one big bus. And you'll get to see, for example, Firestarter in operation and see what happens when there's lots of devices all sharing the bus.

A lot of the devices we already have, but you're still welcome to walk in with more, and we'll plug them in and see what happens. We'll have more engineers, more opportunity to try. Try the tools or ask questions. That's Thursday evening from the start of the Campus Bash until the close.