Hi, everybody. Thank you. Okay, this is session 101, FireWire Overview. And that's me. What we're going to talk about in this session is FireWire's big picture. We're going to look at what's happened over the past year in the industry, in Mac OS X. We're going to take a look at where we are now, and then we'll discuss some of the directions that we're going in the future that we'd like you as developers to help us to get there.

With the particular focus in this session on, for you as a developer, what opportunities do you have for developing FireWire products? We're going to address six specific sections today. First is to review changes to the big picture since WWDC last year. We'll be looking at the industry and products.

Second section is to talk about what new services we've added to Mac OS X. We've been working really hard and exclusively on Mac OS X to provide services to facilitate developing for FireWire. Then we'll talk about future work in Mac OS X, things that we're working on right now that we're planning to add that we hope will enable you to take FireWire further, make new applications, new devices.

As we do every year, we'll have a section on do's and don'ts for FireWire. This is not a marketing session. It's things that we've learned by working with developers over the past year, what worked, what didn't, things that might help you to get faster to the product that you're trying to make.

Then we'll have a special presentation on IEEE 1394b, the future of FireWire, including a very interesting demo. And we will conclude by reviewing developer resources, things that Apple does for you specifically related to FireWire that you need to be aware of to help you develop your products. And, of course, we'll then have questions. So the first section is what's happened to FireWire since we got together last year at WWDC.

Apple today has FireWire ports in 100% of our Macintosh products. This was actually true last year at WWDC as well, but every single product has been changed since then, so it's worth repeating. It's also very important because, as developers, this really simplifies your position to your customers regarding FireWire. It's in all of our products. You don't have to list a bunch of products that you're compatible with as long as you're shipping from modern systems.

All of our desktop products, that's the G4 tower and the various kinds of iMac, all have two FireWire ports. And all of our portable products, the PowerBook G4 and the iBook, both have a single FireWire port. Aside from that difference, they're pretty much all the same. Every single one provides cable power so that you can do things like charge an iPod or run a hub.

And they all support the six-pin connector, which is the standard connector called out in the 1394 spec. And they all support all of the cable speeds, 100, 200, and 400 megabits. So you can talk to your iPod, which is a 400 megabit device, your DV camera, which is a 100 megabit device, or if you can find the odd 200 megabit device, we can talk to that, too. So the point here is that from your customer's point of view, it's all the same. All the products have FireWire. They all have the same capabilities. You shouldn't need to design in a product-specific way. You can just design for Macintosh in general. Thank you.

Since we were here last year, Apple shipped the iPod. This is a big step for us. It's Apple's first ever FireWire peripheral device. And the iPod is really a showcase of all the things that you can do with a product using FireWire. The iPod runs on cable power. The FireWire port provides electrical power on the cable in addition to the lines for data. This power is sufficient to not just run the iPod, but to recharge the batteries at the same time.

The iPod also demonstrates really good integration of plug and play. You plug the iPod into your Macintosh, iTunes will launch, iTunes will automatically synchronize all of your music with whatever you've lately downloaded or new playlists you've created. It's completely automatic. It could not be easier. Of course, you can turn that off if you want to manage things manually, but it really demonstrates the capability to make things easy to use.

speed. There's lots and lots of MP3 players out there. None have FireWire except the iPod. The iPod really demonstrates the speed of FireWire. The iPod can copy data ten times faster than any USB MP3 player on the market. Now, FireWire is 30 times faster than USB 1.1, but the very small hard drive in the iPod isn't the world's highest performance hard drive, so you actually get about a ten times speed improvement.

And finally, size. This picture may not suggest it, but you know the iPod is really a tiny product, and having the small six-pin FireWire port on there helps make that possible. If you remember when we had SCSI connectors on some of our products, the SCSI connector is actually wider than the iPod, so that just would not have worked on this device.

Also since last year, we have iPhoto. You've probably seen demonstrations of iPhoto hooked up to USB still cameras. Well, it turns out iPhoto is not limited to USB. It is a general-purpose camera application. And in fact, in Mac OS X today, iPhoto supports the Nikon D1 series of cameras with FireWire interfaces. We're also adding support for additional cameras already on the market that have FireWire support for still image transfer.

Let's talk briefly about that. Why would someone have put FireWire on that Nikon camera, for example? You've all heard of USB 2.0. It's kind of reaching the market. A USB 2.0 camera could be about as fast as a FireWire camera. There's no question about that. But there's this big installed base of USB. It's all USB 1.1. Tens of millions of systems out there. They could work with USB 2 devices, but they'll be slow.

Think about this as a developer. If you were selling this camera and it had a USB 2 interface, your customers, your first customers, your most important, would buy this camera, take it home, and most of them would plug it into a USB 1.1 system. It would work correctly, but they would be incredibly disappointed with the performance. They'd be calling your tech support, they'd be returning the cameras to the stores, you'd probably get bad press.

Ask yourself as a developer, do you really want to put yourself and your customers through something like that? You could choose to design with FireWire ports instead. Virtually every computer out there with a FireWire interface supports the fast S400 speed. So your customers can have a good experience right out of the box, get very high performance by using FireWire. Additionally, there's much more power available on FireWire than on USB. Even USB 2.0 does not add any more power.

So the still cameras that are out there now are able to run and charge the batteries from FireWire cable power. That's something that really wasn't practical or would be much slower on USB. So there really are reasons to consider using FireWire for this kind of device, even though USB 2.0 might enable you to reach about the same speed.

Also, since last year, Apple made a very important acquisition. We have acquired a company called Zionte that was exclusively staffed with experts in 1394 technology. I'd particularly like to welcome Michael Thiener back to Apple Computer, and Prashant Khan here, and many other talented people. We are delighted to have them.

It's going to be a big boost to Apple in our ability to incorporate FireWire in our products, and we want to make it a big boost for developers as well by increasing the number of services that we can provide and the breadth that we can cover on 1394. We're going to have Mike up here later talking about 1394B.

Finally, since last year, FireWire won an Emmy. That was kind of unexpected. This Emmy was presented simply to FireWire, not to any particular product, just to the technology. Apple's product, Final Cut Pro, is used extensively in the broadcast television industry. It has really revolutionized some of the work they do, and they chose to recognize this by presenting an Emmy to FireWire.

Okay, now we'll go into a little more depth about what we've added in Mac OS X for FireWire. probably the number one question that we get on our mailing list is answered by this, the SCSI-TASK user client. This was announced last year but has only become available since then and now is ready for developers to use.

There's a lot of devices out there, like printers, scanners, certain kinds of still camera, certain kinds of storage or mass storage related device, that have a SCSI architecture model in their design. They may have an ATA interface or they may have a FireWire interface, but at heart they use this architectural model.

Previously, developers had to use the raw SPP2 services, perhaps even in the kernel, in order to talk to this kind of device. And it was possible to do that, but you ended up doing a lot of 1394 and SPP2-specific work rather than focusing on what your device did. So the SCSI task user client for most kinds of these devices will make it much, much easier to access your device and do so from application space, which is vastly preferable to working in the kernel.

Also since last year, we've added an AVC user client. AVC is the command set that's used to control consumer electronic audio/video types of devices, such as the camera and television shown here. The protocol that transports AVC is a function control protocol, and the command sets for AVC are defined by the 1394 Trade Association.

There are command sets for televisions, tuners, satellite receivers, camcorders, any kind of audio or video equipment that you can imagine. So there's a wide variety of command sets available, and the devices that use them are starting to appear. You can put the two together with the AVC user client and create innovative software applications for controlling these devices.

Something else we did since last year is that we've made the source code available to the DV driver. We know for years folks working with Mac OS 9 have sent us questions about how does this thing really work, how can I hook into it, how can I communicate with DV cameras.

For years it was secret. We finally fixed that. We've put it in Darwin. It's open source. You can get at it and see exactly how it works. The project is IO FireWire DV. Now, the way it hooks in is changing slightly because of the ABC user client, but it should be an excellent reference for people who are working with isochronous devices, which is real-time. Anyone who's trying to write drivers to send or receive real-time video or who'd like to understand how the DV driver hooks in to higher layers such as QuickTime, iMovie, and so on.

That was the old number one question on our mailing list before our SCSI task user client came along. Other new things that we've added in the past year, we've greatly expanded the HeaderDoc in FireWire for Mac OS X. Almost 100 methods, classes, and so on are now documented. We have an all-new document for writing user clients called "Working with FireWire Device Interfaces." It's available on the web on developer.apple.com. You can get that today. It has a wealth of information about how to access your devices from applications rather than trying to write kernel drivers.

We continue to publish software development kits for Mac OS X. We have distributed 12 of those to date, including five new ones since last year. Additionally, Apple provides CPU developer technical notes on the web that show architectural details of the FireWire implementation in our various products. For example, for the G4, for the iMac, for the iBook, you can see what the controller is hooked up to, what the internal architecture of the system is like. It also has information about the pinout, the amount of power provided, and so on. Those are all available in public on the developer website.

Okay, moving on. Future FireWire work in Mac OS X. We have a very strong set of services today. You can write applications, you can write drivers, printers, scanners, DV, hard drives, other mass storage, but there's still more to do. Starting in Jaguar, we are going to provide a standard driver for IIDC-type cameras. These are commonly known as DCAM cameras.

I've pictured two commercial ones here, the iBot and the ADS camera that you may recognize. In Jaguar, QuickTime will provide a standard driver for these cameras that's capable of very high frame rate, high resolution input. This is a big jump from the sample code that we've provided previously in the SDK that only ran at very small image sizes. In fact, we have a demonstration of this. We have the demonstration video. Thank you.

This is one of those IIDC-type cameras. This one's made by Sony. It's a somewhat professional model, a little more rugged. And you can see, if you were here last year, this demo would have been a little postage stamp up in the corner. You can see here, well, some of you are sitting in the dark, that we have very high frame rate, high quality, very fast input. So we hope developers will make use of this to create new applications for this kind of camera or even new products like this camera. Okay, let's go back to the slides.

I mentioned already that we had added a user client for AVC. We're doing further work in Jaguar to extend its capabilities. Specifically, we're adding a service layer called asynchronous connections. This is a protocol, one of those that I mentioned that you can get from the 1394 Trade Association, for moving data serially between two devices through the ABC and FCP protocols.

It's not the world's fastest protocol. If you're looking to create an all-new device, it might not be your best first choice. But if your device already speaks ABC and you need to add still image transfer to it, for example, it might be a reasonable choice. And in fact, there are DV cameras on the market today from Canon that implement this protocol, and they use it to move still images out of the camera.

Additionally, we are adding a subunit enumeration capability to the AVC user client. The AVC spec defines subunits within a device that represent its functions. For example, there's a camera storage subunit, using the example I just gave. There's a DV camera subunit. There's a tape transport subunit. There can be a TV tuner subunit.

We now, in Jaguar, we discover these for you by querying each AVC device when it's connected, and we publish appropriate information in the I/O registry. So you can now make sure that your software finds, loads, and talks with devices that have the particular functions that you actually need, such as the still camera--sorry, the camera storage subunit that's in that Canon camera.

Another feature that we've added in the AVC User Client is support for AVC targets. A target means that the Macintosh would be the recipient of commands from another AVC device. In the past, we've always taken a controller's point of view. We can control the devices out there, but now they can talk to us. So if you'd like to write a truly peer-to-peer application using one of the AVC command sets, you can now do this.

Finally, and perhaps the biggest change, the DV driver itself has been moved to user space, together with the changes to the AVC user client. This is pretty big work because the DV driver is a real-time resource that's used, for example, by iMovie and Final Cut Pro when capturing video or when exporting video back to the camera. That video has to be transferred in a frame-accurate way. We can't lose any data. So, initially, the service was put in the kernel because we knew it would work there.

Since AVC services became available in the user client, we have moved the DV driver itself out into user space, and it continues to deliver frame-accurate video for import and export. So if you were not convinced previously that user space was a reasonable place to work, this should help change your mind about that. The user space APIs allow for data movement without data copying, but your driver can all be in user space where it's much easier to debug, has much greater ability to coexist with other things on the system.

Another major area that we are working on is the support of the TCP/IP protocol on 1394. Now, this is a feature for after Jaguar, but we are working on it now. The Internet Protocol, IP, is a great protocol because it's been deployed in lots and lots of different devices and services and so on.

But you have to keep in mind that IP was designed to connect the world. It does that well. It can connect devices all over the world. They can interoperate even though they have different operating systems. It was not designed for a small local area bus like FireWire. IP can run on FireWire, but it doesn't take advantage of all of the characteristics that FireWire has due to being a smaller bus.

So, consider using IP if you want to interoperate with a wider area device, application or service. Consider IP for leveraging existing software, existing services. Or consider it for managing a device, doing something that doesn't require the highest possible bandwidth. Don't consider it for, say, a video camera like you just saw or a high performance disk drive.

IP may, however, be more convenient because of its peer-to-peer nature. If you think about target disk mode, that's the ability in our products today to make the Macintosh emulate a FireWire hard drive. It works great. It's very fast, but it requires rebooting the Macintosh. That's slightly inconvenient. Using IP 1394, it may be possible to connect two Macs together with the same FireWire cable, use the IP protocol to do file sharing or FTP or whatever your favorite transfer protocol is, to move files in the same way as you would do with target disk mode, but more conveniently. Now, we don't have a schedule to announce for IP 1394 because this is where you come in. We need developer input about how you're going to adopt this in order to help us set the right schedule.

We would like to produce this software when you're ready to use it and do our qualification when you have prototypes or initial applications ready so that we can make sure we've given you what you actually need. If we went and did it next month and we overlooked something that you needed, we'd have to go do it again, re-qualify it, ship it to customers a second time. That would be silly. So, don't stand up right now, but we would like to hear from you what you want to do with IP 1394 and when.

You can come to our feedback forum on Friday or you can send us information on our mailing list or in private using the contact information that's at the end of these slides. So, we're ready to do it. We think it's a good thing, but we need your help.

Another area that we're working on is SBP3. That's Serial Bus Protocol. It's the transport that's used by FireWire hard disk drives, as well as other items like the printers, scanners, and cameras I talked about that use the SCSI-TASC user client. SBP2 is the one that's shipping today. SBP3 is backwards-compatible enhancements to add new services and new performance.

There's three main categories of things in SPP3. Fast start is a speed-up that allows us to make a device start doing something faster. Basically, fast start takes all of the information that the device will need, bundles it into a single packet, and sends it to the device all at once.

This is faster than the way it works today, where the device has to collect various bits of information from the host before it can get started. We have done performance tests that show improvements of 30% or more for certain kinds of I/O when using fast start. Some of the major vendors of silicon for 1394 on SPP have shown interest in this. One worked with us to give us prototypes for that measurement. We expect a big boost in performance for devices when this is deployed.

The standard for SPP3 is still being written, but the fast start portion has been declared stable by ANSI, which is the parent organization. This means that it's not anticipated to change. It would take a large vote of a large number of people to make any changes at this point.

If you'd like to start working with fast start, please do so now. You can be pretty sure that it won't change, and we will have software support for it by the time you're ready with products. The next area in SPP3 is 1394.1. This is a fairly complex area. It's bus bridges. The ability to connect two 1394 buses together and have them continue to operate even though they are not the same bus.

SBP, as defined, doesn't have all of the structure needed to work in a .1 bridge environment, so SBP3 is adding that. And it has a beneficial side effect. Bus resets do not cross a 1394.1 bridge, so life has to go on without knowing about them. Consequently, SBP3 is defining ways for bridge-aware devices to continue operation across a bus reset without having to stop like they do today and get reconnected and restart their orbs.

This means that even if you don't have a 1394.1 bridged environment with multiple buses, your device may get a significant performance and robustness improvement just from using the .1 awareness in SBP3. So, that's the first step. We're looking forward to that as another big improvement to that kind of device.

Finally, SBP3 is working to define isochronous services. This is by far the most complex part of the work. Today, if you run, for example, iMovie, and you connect a FireWire hard drive and a FireWire DV camera, and you capture video from the camera to the hard drive, the video actually moves into the Macintosh first, and then cross FireWire a second time onto the hard drive. That works, but it's inefficient. It uses the bus twice for every packet.

A hard drive built with SBP3, capable of isochronous transfer, may be able to directly exchange video with the camcorder, yielding higher performance, greatly reduced CPU and memory demands on the host, and greatly increased efficiency of the 1394 bus. This work is the most complicated part of SBP3, and it's still being hashed out, but it has great potential.

Okay, the next part of the presentation is FireWire Do's and Don'ts for 2002. These are things that we've learned working with developers making our own products, things that are helpful, and things you want to avoid. So we'll start with the Do's. Innovate. The FireWire standard is really rich. It provides a lot of performance, capability, service, flexibility. There are some great products out there that you can make. Look at the iPod, for example.

Developers should find new ways to use FireWire. We're doing pretty well on hard drives and DV cameras. There's a lot more clever things that you can do. Use FireWire to make products faster than they were before. Or use it to make products work together. iMovie was a good example of that.

A FireWire hard drive, a FireWire TV camera, together they can do more than either one can do by themselves. Because FireWire is a peer-to-peer bus, and because FireWire is suitable for so many different kinds of devices, there's a great deal of potential out there to find two devices, figure out a new way for them to work together, and make a new product around that.

But while you're out there innovating, try to stay focused. We don't want you to innovate on ways of deviating from the official standards. As I said, it's a peer-to-peer bus. This means everybody on that bus has to play according to the rules or things break down pretty quick. So if you find that you want to do something that the spec just doesn't cover, participate in the standards process. It's an open community of very talented people.

What you need can be added. Or even more likely, what you need is probably already there and you just can't tell it from reading the spec. So please, before you think about trying to do something that doesn't comply with the spec, talk with us. Come to 1394 events. You can probably do it in the spec. And everyone will be a lot happier if you do.

This has been a very important topic for the last year: test your products with bus resets. The concept of a bus reset is widely misunderstood. On FireWire, a bus reset is an ordinary event that indicates a perfectly healthy bus. It's like a packet collision in Ethernet. It happens routinely, causes no harm as long as everyone complies with the standard. It's not an error. It's not an excuse to tell the user something went wrong. A bus reset could happen because a new device was connected. FireWire is hot-pluggable, so the user is allowed to do that at any time. A device could be removed for the same reason.

Even if a device remains connected to the bus, it might be turned on or turned off, and either of those could cause a bus reset. The device might even change state. For example, some of the video cameras, if you change it from camera mode to VCR mode, it's never losing power, but its operational state has changed, and a bus reset may result in order to alert devices on the bus that its capabilities have changed.

So the point is, your customers may have bus resets on their bus, even though they're using the bus in completely legal ways. So your devices and your software need to react accordingly. If you follow the standards, it's not a problem. For example, SBP2 defines exactly how to continue your operation across a bus reset. But you do need to pay attention to that. It's not automatic.

And equally important, test your devices and your software with bus resets. We are going to be providing a tool in one of the upcoming SDKs that will generate bus resets automatically, so this should make it much easier to run this kind of testing. Very important, if you do these things, you'll have a much more reliable, robust device. You'll get better reviews, fewer phone calls, everyone wins.

Next, operate on cable power. This is one of FireWire's strongest areas. There's no other bus technology out there in common computers that provides anywhere near this kind of power. I talked before about the iPod. It shows how to really take advantage of that. Apple products, especially our desktops, provide lots of power on FireWire. So take advantage of it. If your device is going to be connected by FireWire, maybe you don't need a separate power adapter. On the iPod, FireWire is the only power input. There is no DC power jack. You have to use FireWire to charge it.

Keep in mind that USB does provide power, but it's limited to, at most, 2.5 watts, and in many cases, just 0.5 watts. For example, the USB ports on our keyboards provide only 0.5 watts. That's not a good place to connect some device that needs a lot of power. The FireWire ports on our products provide anywhere from 6 to 15 watts. Generally, the battery-powered portable ones are at the low end of that range. The desktops, the iMacs, are at the high end of that range.

attend 1394 Trade Association PlugFests. This is a group we haven't stressed quite as much before, but they made a big change this year. They opened up their PlugFests to non-member companies. The Trade Association is a group of approximately 150 companies, all promoting 1394 in their products and in the industry.

They hold plug fests about four times a year where you can test a device against a broad collection of devices from other participating companies. But in the past, it was limited to member companies, and membership costs $4,000 to $8,000 a year. So for an independent developer, that might have been prohibitive.

These are now open to everybody. You can sign up as a guest. You can learn a lot at one of these events. You can meet engineers, software, hardware, and testing engineers from other 1394 developers. You can test against prototype devices, or you can test against devices that you might not otherwise encounter.

The Trade Association is deploying standard test suites, for example, a base test that will test whether you have a PHY, a configuration ROM, all the basic 1394 aspects. Then they will deploy more sophisticated suites for things like AFI or SBP. Since this is now open, it's a really good resource. Apple goes to all of these. We learn a lot every time we go. We'd definitely like to encourage you to attend these, too. Of course, we learn a lot about other people's bugs, not our own.

As a developer, one of the most valuable things you can do is attend the 1394 Trade Association's Developers Conference. This is coming up in June. It's being hosted at Microsoft up in Redmond. We did this last year together with Microsoft. We had a really good turnout. We had excellent technical presentations. The value of this is that it's a completely different focus than what you'd get here at WWDC.

This is mostly a hardware-oriented conference. There's presentations on protocols and software as well, but you can get access to information about board design, silicon selection, things that we just don't offer here at WWDC. You also get a very different perspective because it's extensively participated in by PC vendors and people from the general Wintel community. FireWire, as you know, is an open industry standard. It's completely cross-platform between Mac and PC. So you can design devices for Mac and sell them to customers who buy PCs as well.

Perhaps the most interesting session at DEVCON was the Ask the Experts panel. We had a free open Q&A with both the experts and the developers. Both Apple and Microsoft answered questions, sometimes agreeing, sometimes not. It was very interesting. We learned a lot about what people are trying to do with FireWire from their questions. So I would recommend anyone interested in making FireWire devices seriously consider attending this event.

Okay, now let's move into the don'ts. This one's not actually new this year. We knew this all along. Don't use this four-pin connector. This is what you find on DV cameras. It was not in the 1394 standard. It was added under some protest subsequent to the standard. It provides no power, so right off the bat, it's pretty useless. It's awkward. If you've tried plugging one of these things in, it's so small, it's so hard to line up, it's really not easy to use.

And finally, it's fragile. This is a pretty subtle point, but... This connector puts the parts that break, the spring-loaded parts that have to move, they're in the socket, which means if you jam the connector in the wrong way and you break something, you've broken the socket. Your cable will be fine.

Your camera may have to go in for repairs. The six-pin connector that we use in all of our products is the opposite. The spring-loaded parts are in the cable. The socket on our product has all of the fixed parts that don't break off. So by and large, if you plug something in wrong and break it, it's going to break off.

You'll have damaged the cable. You can throw the cable away and keep using your Mac or your iPod with some other cable. So there's really a lot of problems with the four-pin connector. You don't want to use it. Even if you don't use cable power in your product, use the six-pin connector. Power is always optional. You can use the six-pin connector even if your device ignores the power.

If you're a hardware vendor, please don't design your products just using silicon vendor data sheets. 1394 is a fairly rich, it's a very rich, fairly complex standard. The vendor's data sheet for their PHY silicon or their LINQ silicon is not going to tell you everything that you need to know to make a successful product. Read the standard. Pay attention to the standard. Make sure you understand what you're doing.

please don't ask us to work around somebody else's mistakes you guys are great about this compared with other bus technologies that i won't name fire by products are really very good compliance with the spec is very high we want to keep it that way okay it's important it's a peer-to-peer bus all these devices are doing different things they have to play by the rules or it's not going to work if something is broken maybe a software workaround would be possible for that device but it may have impact on everyone else on the bus so occasionally uh... somebody does ask us to fix something that they broke or they made a bad choice we have very simple answer for that which is no There's great products out there. You've all been doing a really good job. Let's keep it that way. And to encourage you to keep it that way, we are not fixing mistakes like that.

Finally, don't think of USB 2.0 as being equal to FireWire. There's definitely some similarities. USB 2.0's high speed delivers about the same performance as today's S400 FireWire ports. But that's where the similarities end. Operating system support for USB 2.0 is extremely limited. Power on USB 2.0 is extremely limited compared with FireWire. The installed base of USB can be viewed as a liability rather than an asset, as I described before talking about the cameras. That installed base is all slow host controllers that's going to provide low performance even if you plug in a high-speed capable device.

So as developers, you may want to consider avoiding that. You may want to consider whether FireWire is really a better choice for your product and for your customers. Okay, now I'd like to welcome Michael Teener back to Apple Computer after about five years. He's going to talk to us about 1394b. Michael? Thanks, Eric.

It's good to be back. You people laugh at the jokes. When in heck they don't laugh at the jokes. uh...

So what we're going to do is do a little demo here. And over here, what the gang is doing is they're going to show you that little demo we did earlier. That was running over glass optical fiber.

So what we're going to do is turn it on and now we're going to start showing you what this really means. What we've got here is a glass optical fiber. Remember glass optical fiber when running full speed can go 3.2 gigabit a second, but we don't have a 3.2 gigabit a second here, so this is only running at S400. But as the guys unwind it here, it, remember it's 100 meters. It can go 100 meters. The back of this room is about 20 meters.

So they could probably go out to the lunch room and we can do a, we're going to do a David Letterman thing here for you. And that's one hop. Remember, one hop, you can put a hub out there and keep on going as far as you want to go. It's pretty extensive. That could be, as I said, it could be glass optical fiber, it could be a category five unshielded twisted pair.

Same stuff that we use on ethernet. As a matter of fact, we use two pairs, ethernet, 100 megabit ethernet uses two pairs, so you could run them on the same It looks like we're going to come back right now. But we don't have time here to go all the way. So if we get back to the presentation here, I think we're done with David Letterman.

So, what do we see there? Well, we start out with a Mac, as normal, and we went from the Mac. This Mac, by the way, is a, you know, off-the-shelf, standard, last-year model iBook. Nothing fancy. Thank you, Shana. We have a hub. This is a little hub device that can carry plastic. This one's a glass optical fiber with with two A ports on it. goes out on glass fiber out to another hub, which is hidden in Eric's hand there.

Notice the clever packaging we use. And out to the camera with the standard one. But we had this reel of cable in there, showing a little bit more distance. Well, it is glass optical fiber, so we couldn't carry the power. They wouldn't allow us to launch enough optical power down there to do it. So we have a battery hidden in there.

So are you going to hold up the battery? I'm going to break the demo here by holding up the battery. Notice the clever wiring system that the guys did. Now, what did we do? What has 1394b got to it that's kind of cool, besides the fact that it's fast? One of the key things to get it to go this fast is we used something called BOSS arbitration.

And it's much more efficient than 1394a and the Legacy. Well, a little sidebar here. I'm going to go over here. This sidebar. Okay. Sidebar. BOSS. That stands for Bus Owner Supervisor Selector. And indeed, as you suspected, we came up with that acronym after we invented the word BOSS. boss, I'll go way over here.

Okay, I'm in the blue part of the screen. BOSS was an acronym picked by the engineers at Intel that were working with us on this, and it's very radical by Intel standards because it is a four-letter acronym. Very important. This is a radical bunch of Intel engineers. Okay, back into the center.

The key thing about what this BOSS arbitration did, which I had a minor part in inventing, mostly it was invented by people from Intel, is we came up with something that pipelines the arbitration, which means that instead of sending a packet, arbitrating for the bus, finding out who owns it, send another packet, is we figured out a way to send a packet. While that packet's being sent, we're arbitrating for the bus for the next packet.

So as soon as we finish sending a packet, we know who's the next guy to send and they can send, which means there's very few gaps between packets. The result is we get about 97%, a bit better than 97%, of the bandwidth at S800 is available for data, using big packets, of course, 4k byte writes. That's very efficient. 1394a is not bad, but it's closer to 90% efficient.

Well, 1394b also has a new connector. Sorry about that, guys. I know you love connectors. Today's existing 1394 cables cannot run at 800 megabits a second. They were designed to run 400 megabits a second. Furthermore, the existing connector has a great deal of difficulty running faster than about 400 megabits a second.

So we figured if we're going to make the speed change, we're really going to go for it. So we designed new media and a new connector. This connector and media is capable of running, and in fact has been tested, at 3.2 gigabit a second. So, one more cable, but at least you're going to get some more lifetime out of it.

So, in order to support this new connector, we have three new cables. We have one that uses the 9- to the 4-pin connector. I don't recommend this for all the right reasons, but you've got to connect to those old camcorders somehow. The 9- to 6-pin connector, which carries power, the 9-pin connector does have power, same kind, and a 9-to-9, which is what you need to do to go to the full high-speed capability of the system.

Well, I said there's three new cables, but actually a typical customer, consumer only needs one new cable, and I'll show you what I mean. This is the way things work right now. You've got a computer, a disk, a scanner, a camera, for example. And what you do is use a 6-to-6 cable going between the computer and the disk, and a 6-to-6 between the disk and the camera, or a scanner, and, well, darn, there's that 6-to-4 connector to go out to your camcorder.

Well, in the hypothetical future, the computer could be replaced by one that supports 1394b. It has a 9-pin connector in it, but everything else stays the same. So you can use the existing cables. The one place for your new one is to go here. There's a 9-6 pin connector. Of course, if the customer goes out and buys new stuff everywhere, it can have a new cable coming with it, and that could be a 9-9 if it was a hypothetical 800 megabit or 1.6 gigabit disk drive.

So, where can 1394b be used in products? It's key to think of 1394b as a package. The electronics and the connector are tied together. You can't separate them. The new connector, the nine-pin connector, means that there's a new PHY, the new, what's called, beta-capable PHY in it. A new PHY, one of those new things, has to be used with a new connector. Don't mix the two. It won't work. There's all kinds of scenarios I can show that will lead to everything from inconvenience to smoking computers, so don't do that.

1394b is an official standard as of now. It passed its final ballot. The technical work was all finished on January of this year. Final draft revision is 1.33. It was approved by the IEEE for actual publication, which means it's done. It's actually called IEEE 1394b-2002. And they're right in the middle of actually getting it so you'll be able to order it on their website.

What kind of product opportunities are there in the short term? Well, certainly you can do PCI cards for all those older Macs. It can be 800 or, you know, basically my suggestion is get the fastest one you can when you ship the card. Another one which is really interesting are these hubs. Those hubs, for either unshielded twisted pair or one of the optical fibers, are useful even for legacy products, which means that if you could buy the parts right now, you could instantly have a network of Macs in the peripherals going out 100 meters or more.

So those hubs are useful for legacy products right now. They're really useful for something in the future, but they're really needed right now. Cables, the 9-4, 9-6, and 9-9, and the long-haul cables. The good news is the long-haul cables are standard. That glass optical fiber connector in there, it's the same one used for gigabit ethernet when it's running optical fiber. That plastic optical fiber, well it's new because nobody does plastic optical fiber, but the UTP5 is a standard RJ45. So not much new that you have to do there.

Storage, it turns out ATA drives already are fast enough that a 400 megabit a second connection is not good enough. You can saturate on one drive. Now, that's a peak rate, but really it's one drive. So you really want to go to 800 megabits on your hard disk things as soon as possible. In fact, my buddies in the business say, in about a year and a half they're going to need that 1.6, so please get the silicon ready forthwith. But you need 800 as soon as possible.

Another big product, and indeed where people are actually shipping things that aren't quite 1394b, but they needed to ship them anyway because they needed it, was professional networks. Some of my friends at a company called Amion Video Networks have a 800 megabit glass optical fiber network that's used for HD studios, HD production equipment. Wimbledon, for instance, was produced using that equipment this year. Yamaha is demonstrating various pro-level things that would be highly enabled if they could get B-level products and hubs, because that way they could build big studios, they could build it for performance equipment, digital projection, things like that.

Finally, innovate. There are a lot of things that I couldn't think of, that anybody at Apple probably couldn't think of, that you can do. But remember, innovate but don't deviate. We don't believe in deviates around here too much. So, I think that's it. I'll be around a little bit for people that want to talk to me about this. But if there's anything more on the B stuff, I'll be glad to answer that at that time. Okay, thank you, Michael.

Not just Mike, but we've got a bunch of really talented, smart people from Zyante. It's going to be a really big boost for us. On the demo that we showed, I'd like to thank Nunex for providing the fiber optic transceiver and cable. They are here at the show, and you can visit them in the vendor area. So please go take a look at what they've got.

Okay, we're getting close to time for Q&A, which is always my favorite part. But let's quickly recap the developer resources that we make available to you. Apple has a big developer program. Go to developer.apple.com if you're not already familiar with it. There's a lot there. First of all, Thursday this week we are having a plug fest. That's where we get all the FireWire devices together, we plug them in, we see that they work just fine and don't have any bugs, and then we just go eat and drink. That's Thursday.

It is during the Apple Bash, which, if the weather holds up, I believe is supposed to be held back at Apple, just like we did last year. Last year this worked out great. If it is at Apple, it's in a room called Garage, which is nicer than it sounds. It's above the cafeteria. It's a big conference room. Bring your FireWire devices. The whole FireWire engineering team will be there. You can ask us questions. You can meet other FireWire developers.

The 1394 Trade Association also has PlugFests. I mentioned this before. These are much bigger events. Our PlugFest this week will be a few hours. At the 1394 TA PlugFests, well, they don't serve beer and food, but it runs for three days, and you can test with a whole bunch of other devices. You do one-on-one testing and a sort of melee, which is like the one we'll be doing on Thursday, where everybody plugs in at once.

There's one coming up soon in August in Bellevue, Washington. There's one scheduled for October in Taiwan. Another one next year somewhere here on the West Coast. And then in April every year, there's one in Tokyo. The Tokyo and the Taiwan ones are especially big, representing a huge number of developers over there. Apple attends all of these, so we welcome you to do that, too.

Just a few days ago, the 1394 Trade Association agreed to accept an offer from Apple to use our firewire logo with their compliance program. This is the compliance logo that Apple has provided. I'm sure you'll recognize it. We've just added 1394 compliant. And the Trade Association is rolling out a big compliance effort to award compliance logos to products that pass testing at these plug fests. So this is a way to show your potential customers that your product has actually been tested and is likely to work. This can't be obtained from Apple. This can only be obtained from the 1394 Trade Association.

If the Plugfest schedule that I showed you is not convenient for you, you're ready sooner, or you'd like to test with a little more privacy, you may want to contact a company called Quantum Parametrics. It's the vendor that is being used by the Trade Association to develop the tests in this program. And my expectation is that Quantum Parametrics will also be able to run those tests on your product and issue the logo.

Kitchens. A FireWire kitchen is three or four days where we meet one-on-one with key developers We give tutorials on the latest developments in FireWire in much more detail than we're able to do here at WWDC. We have hands-on development and debugging. Every developer gets a Mac with our latest stuff pre-installed right in front of them. And we sometimes have related presentations. For example, at the last kitchen in Tokyo, we gave a presentation on how to use FireWire for Pima-type still-image cameras.

We hold these in Cupertino and in Tokyo. We do it two or three times a year. Typically, we get 20 or so of the most interested developers together with our engineers. It's a really intense, really good way to get up to speed quickly. At our last kitchen in Tokyo, we had several developers who left with working drivers, not shipping, but working drivers for devices that they had brought.

I mentioned before that we provide software development kits. We've done 12 so far for Mac OS X as of last month. These kits are posted for free public download on the web. Each one has our very latest drivers, including things that we may be planning to ship in a future version of Mac OS X so that you can start testing with them right away. Each one includes all of the source code for convenient access.

Each one includes sample code for, like, we have an SPP2 demo application. We have sample code for that camera. Each one includes all of the documentation that we have. And there's usually some tools included as well, things just that you'll need when developing for FireWire. They're available for free public download on the web, so if you haven't already, please pick one up and give it a try.

Okay, here's the roadmap to other sessions here at WWDC this week. I talked about SCSI-TASK User-Client earlier. If you want to learn more about how it actually works, it will be covered in Session 111, which is on Wednesday in the Civic Auditorium. That's the big theater across the street from the Convention Center. It's actually a really interesting place, so you should check it out. If you don't go for this one, come see us on Thursday. That's where we'll be. And that's what's next, 115 Firewire In-Depth.

We will talk in much more detail about the new services in Mac OS X, things like IP 1394, software impact of 1394B. We'll cover the entire architecture for Firewire in Mac OS X, and we'll have a how-to session for I've got a device, what do I do to write software for it? We have our Plugfest.

That's on Thursday starting at 7. It is scheduled to be at the Apple campus at the Bash in that garage room. And then Friday, 9 a.m. Don't stay too late at the Plugfest. We have our FireWire and USB feedback forum. It's a smaller session. There's no presentation. It's one hour where you can come and give us feedback.

What are we doing right? What are we doing wrong? What are we doing that you just don't understand? What should we put in our SDK? What should we put in our APIs? It's your chance to influence the work that we do for the next year so that we can come back next year and talk about all the great stuff that we've added. You can also ask general questions, but the primary focus for that is to tell us what to do.

A couple more roadmap sessions. In Steve's keynote, he talked about rendezvous and zero-configuration networking. We're adding TCPIP for FireWire, so those are two things that will definitely play together. That session, which was not shown on the agenda until very recently, is session 811, and that's on Thursday at 2, just before our session. That's in room J, down at the other end of the convention center. Finally, there's a session 008, the APIs for disk recording.

If you've been using SPP2, maybe moving to SCSI Task User Client, because your device is a CD-ROM burner, DVD-R, or something, you may find that we have APIs that you can just do exactly what you want to do without any of the messy, low-lying details. That's in hall 2 on Thursday, also at 2, so pick networking or disk burning. Here's contact information. You'll meet him in a second. Guillermo Ortiz is with Apple's Developer Relations. He handles technology management for FireWire. If you've been sending questions to [email protected], Guillermo is the one who's been receiving them.

We have a public mailing list for FireWire developers. You don't need to be a member of Apple's developer program. It has a pretty wide audience, including a lot of people just lurking, like Mike until recently. You can reach a wide audience of Apple people and other developers. It's a great place to ask questions. It's even better when developers answer questions for each other, which happens more and more. We love that. You can subscribe by visiting the URL shown there.

There's also a public mailing list for mass storage development, and about half the questions that we get on the FireWire list relate in some way or another to mass storage devices, so sometimes we point people over to this other list. The subscription mechanism is a little different, but it's also public, and you can subscribe as shown here.

For further information about FireWire, here's the URL where you can download the latest FireWire SDK from ECOS 10. This page actually has pointers off to several things that you might need, one of which is the SDKs. The new document I described earlier, working with FireWire device interfaces, is available on the web at developer.apple.com, as shown there. And you may want to visit the 1394 Trade Association to learn more about the PlugFests, the Developers Conference, other events that they do, or to pick up some of those AVC standards. There's the URL.