The last two years for Apple has been really exciting from a hardware perspective. We've totally revamped our product line. Similarly, we've totally revamped our I/O. For low-speed I/O, we've gone from serial and ADB to USB. For high-speed, we've gone from SCSI to FireWire. For analog video in and out, we've gone to digital video in and out over FireWire.

About two years ago when I was standing up here, we had one FireWire PCI card that you can put into your Bage G3, and that was it. Last year, we had just started shipping the blue and white G3, so that was one product that came standard with FireWire. We had a few ports out there, so developers were just beginning to adopt it.

Today, if you see the product line, about 70% of Apple's products come standard with FireWire. Three out of the four product lines, every customer that buys it gets a FireWire port whether he likes it or not. Well, that's a big opportunity for you to make devices to plug it in. And we've got a lot of good feedback from you and a lot of good response from both customers and developers that like this. So let's see what's been happening in the last year or two.

There have been new peripherals in every category. So scanners, printers, lots of mass storage of course, CDRWs, hard drives, MOs, you name it, and there are several products in the category. Actually, there are about 100 FireWire peripherals, excluding DV camcorders, that have already been announced and about 60 of them shipping.

It's been a really big deal in storage. I mean, you see hard drives, really cool ones, the small pocket ones from the CNVST, big ones, high capacity, you're seeing RAIDs. Here are a couple of solutions that are really hot. The pocket-sized drives from both the CNVST, I think they were a big hit. It was just awesome. In fact, these have two ports on them. They have both FireWire ports as well as USB ports. So that's kind of cool.

Here's a new product from Micronet. This is the SAN cube. It's a FireWire RAID array. So they've taken multiple drives and put it in. And they've got multiple, four, I think, four or five FireWire ports on it. But the cool thing about this is not only can you use it as a RAID drive, you can connect multiple hosts to it.

Remember, FireWire is a multi-host topology. So you can have two or up to four Macs connected to this box, and all of them can be accessing the data that's sitting on this drive. So that's a pretty cool product. VST, RAID array, really portable. It's got a battery up there. You can have up to 100 gigs of storage in this portable thing. Perfect complement for somebody using a PowerBook. that come with FireWire for digital video on the road.

Here's another cool product, a DVD changer from Eshant. Well, this is basically two DVD ROM drives in this box, and it's got a 200-disc carousel. So you can put all your 200, up to 200 DVDs in here, and you can load two at a time. So this is another cool product. Scanners, UMAX and Epson are shipping high-end scanners right now. And I think what we are going to start seeing is products like scanners and digital cameras. the price points drop quickly.

So, I often get asked this question from developers saying, "Oh, I have a product. Should I do it with a USB product or should I make it a FireWire product?" Well, that really depends on, I think the main thing it depends on is the performance that your product requires, right? We know that USB, theoretical, is a 1.5 megabyte per second bus, that's 12 megabits per second, but it really maxes out at about 1 megabyte per second. Very often, customers have got many USB devices attached to the bus.

Somebody can have a printer and a scanner, a mass storage device like a Zip or a hard drive or whatever. You're going to start seeing USB DSL modems and things like that. So maybe somebody will be browsing the internet at the same time he's downloading a file or scanning a file or whatever. So, when that happens, the total bandwidth to a single device, of course, is going to drop.

So you really need to weigh at what point do you make that switch from a USB device to a FireWire device. And we think that's probably around 800k per second. So if your device is doing more than 600, 700, 800k per second, make the switch, right? Because the customer really sees a benefit from using FireWire. Of course, FireWire has added advantages like bus power, and we'll talk a little bit about that a little later on.

So just to talk a little bit about performance, I've got a demo for you. If you could switch. I have this new drive from VST. It's got both FireWire ports, two FireWire ports, and a USB port. So what I'm going to do is, let's copy a big file over.

I have my PowerBook. So first thing you notice is that I have to plug it in. So I plug it in. When I say plug it in, I mean I plug it into the wall. And I plug in the USB port. So I'm going to first do a USB performance number. So there it mounts. I've got this huge, it's about a 29-meg file. If I do get info, it says 29 megs. So let's do a duplicate.

So you see it's not very fast. It takes about, let's say, it'll probably be a minute or two, so I can yap for two minutes more. And then after that we'll run the same thing on FireWire. So a couple more devices are starting now to show up that were USB and are now going to FireWire.

For example, iOmega has the new Zip 250, and they've come up with this cool FireWire dongle that you just plug it in. They have an ATA interface at the back, so you get all the benefits of FireWire by just plugging it in. Again, it's bus-powered and a single FireWire port.

On USB, this drive does about a megabyte, a little less than a megabyte, 800k per second. On FireWire, this does about 2 megabytes a second, and it's bus-powered. So there's a real improvement in the customer experience when using this on FireWire as opposed to USB. So my copy is about... Halfway done. Should we put it out of its misery? Okay, so I hit stop. There we go. So you get the idea. Let's now take the same device. I'm going to drag it to the trash.

Unplug the USB ports. So now on FireWire, of course, I don't need to plug in any power. Just plug it in. In a second or two it should mount. There we go. And let's just duplicate this file. So probably about five seconds. So here's an example where a really fast device gets a huge advantage on going to FireWire.

Now what devices do we expect to start doing this? Look at digital still cameras. Today, you're already in the three, four megapixel range, and of course that's probably going to increase. But the files are getting bigger and bigger and bigger. Flash memory or smart media memory is of course getting bigger.

When you plug your digital camera into your Mac, you want the pictures to transfer as fast as possible, especially when you've got these huge files. Scanners. I was in Taiwan a couple of months ago and talking to a big scanner company. They're working on this new scanner. They showed me a prototype. I unfortunately can't mention the name. But they had this same mechanism on USB and the same mechanism on FireWire. By the way, this is a consumer scanner.

The scan on USB is 600 DPI, eight and a half by eleven inch scan. It took about three minutes, three, three and a half minutes or so. On FireWire, the same scan took about forty-seven seconds. So there's a big difference and we're starting to really see customers understand it. So customers want it now. We have the systems out there, so there's no reason for you not to make your devices FireWire.

Talking about FireWire in the PC market space, of course you know that we ship a whole lot of systems. Earlier on I said 70% of our systems now ship standard with FireWire. You're seeing the same trend in the PC space. So from Apple, we've done already about 3 million systems last year with FireWire. Each of them have two ports, so there are like 6 million ports out there. But in the PC space, you're seeing big names like Compaq, Gateway, Dell, Sony of course, Toshiba, Panasonic, Sharp, all these companies are now jumping on the FireWire bandwagon.

Another interesting thing is Taiwanese logic board makers are putting FireWire standard on their logic boards. Asus is one example. So we're really seeing the numbers increase. I was talking to somebody at Microsoft a couple of weeks ago, and they're expecting that this year, they'll see about 15 million PCs, that's about 15% of the market space, ship standard with FireWire. So that's a big number. If we could switch back to slides. So now to get into the technology details about FireWire, I'd like to welcome Eric Anderson. Eric is our lead engineer on FireWire and is the software manager for all of core FireWire development. Eric.

Thanks, Jai. Thanks, everybody. Okay, we've talked about FireWire for many years here at WWDC. I'm sure many of you know it's been a long time coming, but as Jai's explained, it's really a mainstream technology now. It's in most of our products, and the number is rising every time we introduce a new product.

So what I'm going to talk about today is some of the basics of the FireWire hardware, especially, that will hopefully help you to understand what FireWire can really do, how it works, and what features it has that are suitable for developing a product. If you're going to make a FireWire product, you definitely need to know this. If you're developing for Mac in general, I hope this will be helpful in understanding what FireWire can do and how you might develop to be friendly for FireWire.

Okay, first of all, the name of this standard is IEEE 1394 High Performance Serial Bus. FireWire is just a word. It's a trademark that's owned by Apple, but it's just a word. It's not an implementation. It's not a different spec. You're all welcome to use this trademark if you license it from Apple. The trademark license is completely free. Just talk to Jai. There's no difference between FireWire and 1394.

1394 is a serial bus, and that means exactly what it says. It's serial. This works best for longer cables. Parallel is better for short distances. And as a result, we have a very thin, friendly, easy-to-use cable because there's only a few wires in it. And it's a bus. This means that when you send a packet, it goes to every device on the bus. This is really important for high speed and low cost when you have a moderate number of devices.

Okay, this is a diagram that shows the hardware used in FireWire. I'm going to describe this briefly, then I'll go into the details on each part and then come back to this diagram later. What I've shown in this diagram are three typical FireWire devices. Of course, the Macintosh, that's the most important on the left, a FireWire disk drive in the center, like Jai demonstrated, and a FireWire camera on the right, like a digital video camcorder, like the millions that are available today.

I'm going to start at the bottom and talk about the PHY. This is the chip that actually drives the signals on the FireWire bus. Then I'll talk about the link layer, which is where knowledge of packets, checksums, headers, and so on takes place. And then the communications up to the higher levels of the device, which will differ depending on what kind of device this actually is.

Okay, the PHY chip, PHY stands for physical layer. This is silicon that actually implements the electrical protocol for FireWire. FireWire is a low-voltage differential signaling interface that uses a 200 millivolt signal. This is important because it's very low power, which keeps it cheap and makes it easy to go fast.

The PHY will have one transmitter and one receiver for each port, which corresponds to a socket for a FireWire plug on the device that contains these transmitters and receivers. Because FireWire is low voltage, the cables are fairly short. There's a limit of about 15 feet to a FireWire cable.

After more than 15 feet, 200 millivolts starts to look more like zero millivolts, and that doesn't work very well. So FireWire is definitely not a local area network. You might think of it as a room area network or a desk area network, but it's not, for most people, a good choice for trying to implement a local area network.

The PHY actually implements a series of point-to-point links. Each FireWire cable represents a single serial communication path. There's no electrical continuity between the ports on FireWire because each PHY will regenerate the signal that comes in one port and send it out all the other ports. It's important to know that this is completely done in hardware, which means there's no burden on the software, and there's also no chance for the software to get in there and either mess this up or slow it down. At this level, FireWire is always a bus. Every packet will go to every device. There's no buffering, there's no routing. These things make it fast, cheap, and simple.

So there's a variety of PHY silicon available. The key features that distinguish a PHY are the number of ports that it offers, which is how many FireWire connectors the device can have, and the speed that the PHY can operate at. FireWire defines three speeds for operation with FireWire cables, which are 100, 200, and 400 megabits per second.

The digital video camcorders available generally use the 100 megabit PHY speed, because this is what was available in 1995 when these products were introduced, and this is plenty fast enough for a camcorder. All of the products that we sell use the 400 megabit interface, because this is much better for hard disk drives and gives you far more bandwidth to work with.

But FireWire is a mix-and-match bus. You can connect devices of different speeds any way you like, and they will automatically work out the fastest speed that they can communicate at. In the picture I showed where there was a disk drive and a camera, if we need to send a packet to the camera, of course we'll send it at 100 megabits, because that's the only speed the camera can receive.

But if we want to communicate with the disk drive, or if it wants to send data back to us, this can happen at 400 megabits per second. That packet won't be received by the camera, but that's okay, because the camera doesn't need to see that packet anyway. So multiple speeds can operate simultaneously on FireWire. This is very convenient.

The next layer up from the PHY is the link layer. This is the layer that knows what packets are. It knows how to assemble a packet, how to arrange the header, how to compute the CRC, and it contains buffering for preparing a packet before it goes out or absorbing a packet when one comes in. And importantly, this is where the bus ends. All packets come into the link, but the link will examine them and decide which packets are actually important for the device that it's in and pass only the important packets up to the controller.

Generally speaking, the link layer will have DMA so that it can efficiently move data into or out of the device that it's connected to. There's lots of link silicon available to choose from in designing products. The key features that differentiate it are the packet formats that it can support.

The computer can use the packet format to support the packet format. The computer needs to speak all packet formats, but a device like a camcorder or a hard drive may get by with only some packet formats, and considerable simplicity can be had in the link by limiting it to the formats that are needed.

The DMA in a link may vary depending on the application, and the host interface may vary as well. A camcorder link typically would have an 8-bit microcontroller interface, very simple, very good for a one-function device, whereas in the Macintosh, we have a complex PCI interface that's very high-tech. So it's a very simple interface.

And it's also a very complex PCI interface. The PCI interface is a little bit more complex than the PCI interface. It's a little bit more complex than the PCI interface, and it's a little bit more complex than the PCI interface. It's a little bit more complex than the PCI interface. interface that's very high performance.

All of our products today use the 1394 Open Host Controller Interface. This is an industry-standard link interface for computers that's very powerful. It can send or receive every legal kind of packet on the FireWire bus, and depending how you count, it has 16 or more independently programmable DMAs optimized for the various different kinds of packets that can be sent or received on FireWire.

So let's talk about these packets that go across the bus. There's two primary kinds of packets for moving data that I will talk about, and there's a few others that are used for management operations. Asynchronous packets, or non-real-time packets, are used for devices like disk drives. Each packet contains a small amount of data from one byte up to two kilobytes, depending on the speed that it's being sent at and the amount of data needed by the application.

An asynchronous packet is addressed by a node ID, which identifies one other device on the FireWire bus, and a memory address. These two together make up a 64-bit address space. The memory address is 48 bits, and it selects where in the destination node the packet is being sent to.

What exactly these memory addresses mean may depend on what kind of device you're using or what protocol you're speaking. On the Macintosh, if that 48-bit address is less than 4 billion, meaning that the top 16 bits are all zero, then it simply identifies a physical memory address inside Macintosh memory.

This can be used by a hard disk drive to directly move data into or out of buffers on the Mac without any involvement by software, which is tremendous for performance because this data can flow without interrupts, without software latencies. In fact, the CPU can be used for something else during this time.

Addresses above the 4-gigabyte range do not go to physical memory because there can't be memory at such a high address. Those do go to software, and those cause an interrupt when they arrive. Software will examine the packet that came in, figure out what it's supposed to mean, and take corresponding action.

So, for example, with a FireWire hard drive, we might ask the drive to move one megabyte of data. We might ask it to read that data and put it in Macintosh memory. It will get the data from the medium, break that up typically into 512 packets, each of which is 2K. It will send those across FireWire to the different addresses in Macintosh physical memory where we specified that we want the data.

All of that will happen without causing any interrupts or without any software overhead. When the data is entirely in place, the drive will send one additional packet to some address off the end of physical memory. This will cause an interrupt that software will notice. Then software will learn by examining the packet that the I/O is complete. So this is extremely efficient. It supports multiple devices at once. It means that data can flow in and out of the Mac at very high speeds on FireWire.

Again, I want to stress that FireWire is a bus, which means that when we send an asynchronous packet to one node, electrically it will go to all nodes, but all except one will look at the address and say, "That's not me," and they won't bother processing the packet.

The one that does receive the packet will check the CRC on that packet, and if it's received correctly without overflowing the buffer or any other problem, will send an acknowledgement that indicates the packet was received correctly. So with asynchronous transmit, you always know that your data made it, or in the rare case when it doesn't make it, you can send another copy.

Asynchronous packets generally look like memory accesses. Most packets sent asynchronously are either read or write requests on the FireWire bus. A packet requesting a read simply specifies the number of bytes that it wants and an address that it would like to read from. This is a very small packet, but this will cause a response to be sent that contains all of those bytes that were requested, so this will be a fairly large packet.

This is fully symmetric. Any node can read from any other node. Also, any node can initiate a write operation by sending a packet that specifies an address, the length of the data, and actually includes the payload, up to 2 kilobytes of data in that packet. The receiving node, if it absorbs that write correctly, will simply send an acknowledgement that says the packet got through okay, or an acknowledgement that says something went wrong and please send the packet again. As I described in the disk drive case, often these packets can be sent with a response with no interrupts, and this frees up the CPU to do other useful things.

The other kind of packet commonly used on FireWire is an isochronous packet. This is used for real-time transfers, such as when a DV camcorder is sending digital video into the Macintosh. These packets are also a small chunk of data, although the size range is twice as big as for asynchronous packets. Isochronous packets are sent at fixed intervals. 8,000 times per second, there's an opportunity to send an isochronous packet. This is not configurable. This is just a number that Mike Teener picked 10 years ago, and this is what we use.

What's special about Isochronous is that the hardware enforces a guarantee that says 8,000 times a second the bus will be available only for the people who have a reservation to send Isochronous packets. This means that the packets will go out on time and they won't get held off because disk drives or something else are hammering the bus asynchronously. There may be a small delay while you wait for whoever's currently talking to shut up, but then the Isochronous packets will all get to flow.

Again, FireWire is a bus, so the isochronous packets go to every node, but they're not addressed like asynchronous packets. They're not sent to one node. Instead, the header of an isochronous packet contains a channel number that specifies one out of 64 possible channels. And each node can examine this and decide if it wants to receive data on that channel or not. For example, the open host control interface that we use can be configured to receive four different isochronous channels simultaneously, and programmed with buffers for where to store that data in memory.

The isochronous packets are not sent to a memory address. Instead, the meaning of one packet after the next is protocol-dependent, based on what time they arrive or what order they arrive in. There's no time travel on the FireWire bus. Packets will arrive in the order that they're sent.

It's also important to note that isochronous packets are not acknowledged. Because two or more nodes might receive this packet, there's no simple way for each one of them to indicate whether it arrived or not. Also, because it's real-time, there's no time available to retransmit the packet if anything went wrong.

So in principle, data can be lost in isochronous transfer. But the bit error rate on FireWire is phenomenally low. So low that in practice, it's perfectly realistic to use this for professional digital video editing or for watching TV or for MLan without any concern about data loss. Data loss really is not a problem in a properly designed system. Of course, you do need to wire it up correctly.

So let's come back to this hardware diagram, and I'll talk a little bit more about what's happening in the system. Let's suppose that the Macintosh here on the right, I hope you can see the cursor up there, wants to send a packet to the camera to tell the camera to start playing the tape that's in there.

The Macintosh will select the command bytes that indicate play and send those across PCI to the link. The link layer will form this up into a packet by computing a checksum and properly arranging the bytes. And when it's already in a buffer or a FIFO to be sent out on the bus, the link will tell the PHY that it wants to arbitrate for the permission to transmit on the FireWire bus. Often, this permission will be granted immediately because the bus is idle. There might be a delay of up to 100 microseconds if the bus is heavily congested.

When the PHY wins arbitration, it will tell the link to start transmitting, and the link will send the packet down to the PHY, which will then send the packet serially out each of its ports. So our command to the camera telling it to play would first flow over to the disk drive.

The PHY here will receive the packet and do two things with it. It will send the packet up to the link layer, because the PHY doesn't know who this packet is for, and it will retransmit the packet on all of its other ports, except the port the packet's arriving from. So this is important. The PHY does not have any buffer, and it doesn't have any routing tables. It simply sends the packet everywhere instantly. Because this is a bus, nobody else could be talking anyway.

In the disk drive, the link layer will examine the packet. Even though it arrived at 100 megabits, it will still look at it. It will see that it's intended for somebody else and just ignore it. So the controller isn't bothered with any information about this packet. But the packet does flow out into the camera, whose PHY also receives it, passes it up to the camera, and then passes it up to the link layer, which recognizes that this packet is intended for the camera. The link then does two things.

It passes the packet up to the controller, which processes the packet and starts the tape playing. Also, the link signals an acknowledgment to the PHY that says this packet was received correctly. And that acknowledgment flows back through these PHYs to everyone, but only the Macintosh who sent the packet is looking for it, and then notes that the transmission was successful and signals this back up to software. of devices on the FireWire bus.

A couple other things I'd like to talk about. The automatic configuration in FireWire. One of the big advantages that we tout for customers is that FireWire is plug-and-play. You just plug things in. There's no SCSI IDs to set. There's no terminators. That's because there's enough information provided by the hardware that we can hide all of that. Of course, there still are node numbers that identify the nodes on the bus. They're simply hidden and selected automatically. On a bus with three nodes, the nodes will simply be numbered 0, 1, and 2.

What order this happens in may be random. It may depend on how the cables are connected. It may depend on various factors. It can also change over time. If devices are added or removed, we're going to have to change the numbers, especially if one of the low-numbered devices gets removed. That all happens automatically in the hardware. We don't get involved in that.

But what the FireWire software layer does is it hides these changes. Device drivers don't need to know the node number of their devices. They simply use a handle to refer to the device, and our FireWire layer keeps everything straight so the packets go to the right place. If you really do need to know your number, we provide an APA to find out, but most software won't need to know this. And you'd never want to show a number like this to the user because it may change at any time, and it really doesn't mean anything to them.

Every FireWire device has a configuration ROM. This is a small ROM that describes what the device does. The ROM is located at a fixed address that's standard for every device. So when a new device is plugged in, we simply send a FireWire read request to that address to get the ROM and find out what it is. You might notice that this address is way off the end of physical memory, so this is not going to collide with any Macintosh address.

What's in the ROM describes the features of that particular device, what protocol that device speaks, may have other useful information, like the ID of the vendor who sold the device. We use this information to figure out which device driver to load for the device. The ROM also contains a globally unique identifier, a GUID.

This is a serial number that's 64 bits long that uniquely identifies a device. This is critical because if you plug in two VST FireWire hard drives, the contents of the ROM other than this GUID are identical. If the node numbers change, we might forget which drive is which. That could be really bad if you have files on those drives. So it's critical that every device has a truly unique serial number.

So what's happened recently in FireWire? As I mentioned earlier, we have the 1394 open host controller interface in all of our products today. This is a second generation host controller interface that provides very powerful DMA, has provided us with a big performance boost, and has a lot of capacity that will take us forward over the years. All products today that have FireWire ports can boot from a FireWire hard disk drive. I'll talk more about that.

Last year we said that we'd provide FireWire power in desktop and consumer products, but probably not in PowerBooks. Turns out we figured out how to do that. The new PowerBook with FireWire provides six watts of power, just like the iMac. That's plenty of power to run a hard disk or another small peripheral.

The IEEE 1394A standard was recently ratified. It's been several years in the works, but it is absolutely finished and voted on. This is a standard that provides a lot of cleanup over the original 1394 standard. It fixes bugs, it clarifies a lot of things that really weren't described very well.

It has some modest optimizations, but it's not a big leap forward in performance. But it's very important if you're designing products to use 1394A silicon. All the vendors who sell FireWire parts are offering silicon compliant with 1394A. You'll have much better interoperability with other devices and with the Mac if you use this modern silicon that complies with this standard.

IEEE 1394B is the effort to define 800 megabit FireWire, even higher speeds, and a variety of other useful features like plastic optical fiber for certain applications, protocols that can be used for wireless FireWire, and various other advances. 1394B recently passed its initial round of balloting. This basically commits the team to stop adding features and start debugging the spec. So it will be a number of months more while they actually agree on how everything should work and how to describe it. But it is moving toward completion, and of course we're looking forward to adopting that technology as soon as it's available.

I was quite surprised when I wrote the slides for this year to notice that we were talking about USB 2.0 last year. There really isn't anything new to say about USB 2.0. It's still not there. I think Jai is going to rag on it later, so I'll skip it for now.

So let's talk about FireWire booting. Every product that we sell today that has a FireWire port can boot from a FireWire hard disk on that port. That includes the Power Mac G4, the iMac DV, and the PowerBook FireWire. Older products that we already sold cannot boot from FireWire. Sorry. If you try to copy the software onto the old product, you'll find it still can't boot from FireWire. So I want to prevent some confusion and save you some time. Don't bother.

The Firewire services on these new products are included in the Mac OS ROM. This is because prior to that, we included them in extensions, and we can't load an extension from a device that we can't talk to. So the Firewire services are built into the Mac OS ROM. However, the copy in the Mac OS ROM will only be used if we actually boot from a Firewire device.

In any other case, we will load the extensions normally. This means that you can upgrade those extensions with a newer version, such as Firewire 2.4, which I'll talk about later. So you're not locked into it in the ROM. However, Apple can ship a new Mac OS ROM, such as was included in the recent Mac OS posting. So we can improve the booting if we need to.

This means that you should always have the FireWire extensions in the extensions folder, even though it's also included in the ROM. Also, the extensions cannot override the ROM. Basically, we tried and that turned out to be awfully hard, so for now at least, when you do boot from FireWire, you'll be using the version that's in the Mac OS ROM.

How do you boot from FireWire? It's really very simple. You just go to the startup disk control panel, pick your FireWire disk, and reboot. Now, if you try to do this, you might find that you can't pick your disk in the startup disk control panel. This means that the driver software that came with that disk doesn't yet know how to boot from FireWire.

But our vendors have been working on this, and new software should be available to make disks bootable from FireWire. When a disk is bootable from FireWire, the driver for that disk should be stored in a boot partition on the media of the disk. This works the same as how we boot from SCSI or ATA or I think everything except USB.

This is so we can load the driver. We can't load an extensions-based driver when booting from FireWire because we can't see the extensions folder when we're trying to find the disk. So third-party formatting software that supports booting will put their driver in a partition on the disk. Now if for some reason we fail to find a third-party partition on the disk, we will use a built-in Apple driver so that you can try to access your data.

But this driver may not support the disk that you have very well, or it may be slow. So we highly recommend that you get the third-party driver and for you third parties that you provide this driver so that you can provide the best performance and features and support to your customers who are using FireWire booting.

Another new feature we have is Target Disk Mode. This is a lot like SCSI Disk Mode. For some reason, we didn't call it FireWire Disk Mode. But it lets you use the PowerBook FireWire like a FireWire hard disk. If you reboot the computer and simply hold down the letter "T" until you see a big FireWire logo, which should be about five seconds, the computer will act like a FireWire disk. And you can plug it into any other Macintosh and it will show up on the desktop through FireWire.

This actually is implemented in all current products. It's probably most useful in the PowerBook, but you can use an iMac DV or a PowerMac G4 in target disk mode, and that may be a convenient way for you to get files on or off of that machine over FireWire. Note that... Thanks.

This capability is actually implemented in open firmware, so I can't take very much of the credit for this, but I'm glad to hear that you're happy about it. Note that you do not need a special cable. In SCSI Disk Mode, you didn't hold down a key, you used a special cable, because SCSI, for practical purposes, is not peer-to-peer, so normally you wouldn't connect two computers together by the SCSI port.

For FireWire, it's perfectly okay to do that, so the normal cable is used, you have to hold down the letter "T" so that we know that you want to use Disk Mode. On the other Mac, which is running Mac OS, you will need FireWire 2.3.3, or a later version, in order to see the FireWire disk. That's because this version of FireWire has the driver for an Apple Target Disk Mode disk built into it.

Okay, FireWire 2.4 was declared GM on Monday of this week, and as soon as we can get the installer working, we'll make that available to everybody. We expect that to be just a couple more days. 2.4 is bug fixes and performance tuning only. I'm sure you've gotten the message by now that Mac OS X is the future, and most of our staff are now working on Mac OS X FireWire. Tomorrow, we'll have a presentation from William Gulland, who has done a terrific job in implementing Mac OS X FireWire. He'll tell you all about it. He'll also be here today for the Q&A period.

So FireWire 2.4 is just bug fixes and performance tuning. In particular, disk drive performance should be useably faster on most systems. Write performance especially will benefit. What we've really done here is raise the ceiling for how fast it can go. So if you have a fast disk or one of those VST RAIDs, you'll see a big performance. If you have a FireWire ZIP drive, we probably weren't holding it back anyway, so this change may not make it any faster.

Another interesting thing in FireWire 2.4 is that if you have the PowerBook FireWire and you install 2.4, you'll find that your battery lasts longer. I can't say exactly how much, but it should be about 5 to 10 percent longer. What we do is, if you have no FireWire devices connected, we simply turn off the FireWire circuitry, which is fairly complicated circuitry, and we save a useful amount of power by doing that. If you then plug in a FireWire device, we'll turn it back on. It might take a couple of seconds for us to notice, but it always works in our tests.

What did Steve say in the keynote? Trust me, you'll love this. Okay, this will be available by software update in Mac OS 9. If you just go to the software update control panel within a few days, you should start to see FireWire 2.4 listed there. And it will also be available on the web if you'd prefer to download it and install it manually.

There will be a FireWire 2.5, even though we're mostly focused on Mac OS X, simply because, I hate to say this, but we do have a few more bugs. So we will work on those. We may be able to improve the performance a little bit more. If there are bugs that are affecting your ability to develop products, by all means, let us know about it.

Jai will talk later about how to contact us about our mailing list. We will try to fix bugs for FireWire 2.5. That will be out sometime this summer. That will be made available through the software update mechanism in Mac OS 9. Okay, next I'd like to bring up Wil Oxford, who's going to talk about MLan, which is audio on FireWire.

Wil? Thanks, Eric. Not sure how long this leash is here, so I might not get to move around too much here. So, the title of this session is FireWire: What is the title? Now and the Future. So I want to talk a little bit about some of the future developments that we're going to be pushing out towards the end of the summer. You should know that the M-LAN spec is still undergoing some slight changes, but basically it's very solid at this point. I don't know how many of you are familiar with M-LAN, so I'll just go into a little bit of detail about M-LAN itself. Oops, backwards.

So this is the outline. This is really intended just to be a very short introduction to MLan. We'll get into some more details later on, especially with William's session tomorrow, which I encourage you to go to. And also there's going to be a session later on this week, that's Friday afternoon, to talk about multi-channel audio and that kind of stuff. So definitely I encourage you to go to both of those sessions.

So basically what is FireWire Audio or MLan? And so the idea here is that MLan is just a sub-protocol, if you will, of the FireWire protocol itself. So MLan was actually invented by Yamaha, and they were very gracious in providing that service, opening it up to the rest of the FireWire community. So we have them to thank for that.

Basically what MLan is, is a sub-class of... The IEC 61883 spec, which really doesn't necessarily... Something you have to remember, other than we call them ABC devices, and that's audio/video control devices. The 61883 spec is actually a sub-class of the FireWire spec, the 1394 spec. The 61883 spec actually comes in six flavors, if you will. It's a little bit different from the books to the specifications, six sections. The MLan protocol is described in the section 6, the final section of the spec.

So if you look at the family of FireWire devices, there is the overall umbrella, 1394 umbrella. And then you can divide that up into ABC devices, or 61883 devices, and other FireWire devices, such as mass storage devices, scanners. You've seen all the other things that Jay's talked about. Within the ABC device category, then we have yet another sub-class, which is the MLan devices, or the -6 devices, and other ABC devices.

And these include DV camcorders, AV hard drives, which some of you may know a little bit about. But basically the key to know here is that MLan effectively is 61883-6, just like FireWire effectively is IEEE 1394. So, what exactly is--what exactly is the How does it fit into the data format? Those of you who care about how this all fits together on the bus, I'm not sure that the lines actually came out very well on the slide, so I apologize for that. But you remember Eric talked earlier about isochronous and asynchronous packets.

Well, if you look at 1883 spec, most of the data is actually transferred in isochronous packets. There are some control packets that are sent asynchronously, but mostly isochronous. And so what I've got here on the left is just a isochronous packet header, just a schematic of that. Isochronous packet, sorry.

And the isochronous packet is divided into three fields. There's the packet header, which indicates things like what kind of packet it is, also how long the packet is, and that kind of thing. And then there's a data field. And then at the bottom is a little CRC. So again, I apologize for the fact that they didn't quite come out. But anyway, sort of imagine, as I point.

Inside that data field for the isochronous packet, then that's where the MLan packet actually resides. And so the MLan packet has yet another header. It's actually an ABC packet, sorry. The packet itself has another header, which is the SIP header, or common isochronous packet header. And then below that, optionally, are a set of data fields or more headers. And basically, it's just to try to explain to you that it all fits within the isochronous packet.

So, why MLan? Why should you care? Well, MLan, to me, is one of the most exciting developments in digital audio since the original AES/EBU spec. And the reason it's so exciting to me is because, basically, it has all the great things about FireWire. All the really great things about FireWire, basically, number one, is it's a single bus. So, you don't, it's not a point-to-point thing. You can daisy-chain your devices. You don't have to worry about inputs and outputs. It has lots and lots of bandwidth.

So, just as an example, you know, 400 megabits per second, you can get hundreds, literally hundreds, of 96 kilohertz, 24-bit audio channels. And those of you who care about that kind of thing should think that's actually a pretty adequate number. We could do things like hot-plugging devices, so you don't have to worry too much about powering down your internet.

You can do that in an entire studio before you start the moving connections, that kind of thing. So, the integration, the other, one of the other advantages is the integration of video, MIDI, and AES/EBU all in a single wire. So, basically, if you've ever been into a large studio setup and you see all these enormous patch bays and MIDI patch bays, which are electrical devices that do the same kind of thing, and video and audio connections that are run together and then split apart, and then there's synchronizers. Basically, this is going to make life a lot easier.

It's not going to solve all the problems in the world, but it's certainly going to make life a lot easier as far as keeping audio and video signals synchronous, routing them from one place to another in the studio. And for me, the biggest deal here is the illumination of the studio patch bay. And I don't know how many of you have killed your fingers on the backside of patch bays, but, yeah, those of you who are clapping, yeah. So, I have more cuts and bruises on my knuckles from patch bay work. And I'm rewiring.

And it's certainly the largest single contributor to studio downtime, I think. So, the disadvantages are, and of course there always are disadvantages. For now, there are some issues with clock recovery. Right now, it's sort of a highly contested field as to exactly what the best kind of jitter of respect that you're going to be able to get with unmodified FireWire. But for now, I think my perspective on it, and don't take this as gospel. Certainly go out and find out for yourself.

But FireWire as it stands today is good enough for almost all applications. And it's only the ultimate, really highest end, you know, $8,000 A to D converter kind of market where it really is going to matter, the clock jitter, as it stands today. We are working on that in the 1394 Trade Association and also in the AES standards committees. And I think that before long, we'll have some good work to do. And then after long, we'll have some method figured out where that really won't be a concern for the future. There are still some clarifications of the spec, as I mentioned earlier.

But those are well underway. And I expect that before we -- certainly before we meet next year, everything will be pretty much ironed out. So how do you use it in your application if you're a software writer? And the good news here is you don't have to worry about that. We're going to take care of that for you.

We'll use it just as any standard sound in or out device or both. One of the things you probably want to know about is OS X versus OS 9. To my knowledge, at this point, we are going to do simultaneous OS 9 and OS X releases. It'll be later on in the summer.

As far as OS 9, how you use it, it's the standard SDEV on the output side and the sound input device. So you really don't need to change your app in any way to take advantage of FireWire unless you're adding new features that FireWire allows you to have.

On the OS X side, I highly encourage you to talk to both William Gullen or attend William Gullen's talk and also Jeff Moore's talk on multichannel audio and that architecture. All that stuff will be gone into in great detail. If you insist on rolling your own driver, we certainly can help to some extent. We're looking at the open source issues.

Certainly for OS X, we believe that's the right thing to do and we just need to make sure we can legally do that with all the licenses and whatnot. For OS 9, I'm not clear right now whether that'll be open source or not. But certainly we can help you out even if we're not going to be giving you all our sources.

So what does the device roadmap look like? Well, right now, this summer, we will see the first M-LAN devices available. In fact, you'll see a couple of them sitting right up here. Right now, they're really only sound output devices, meaning they're speakers or things that actually generate sound from a digital signal, generate audio from a digital signal.

Sort of towards the end of summer or early fall, we should see a second wave of M-LAN devices on the market. And I don't want to pre-announce anyone's product, but basically, we're looking at several different chipsets available and several products based on those chipsets also. So we're looking at audio in and out and MIDI in and out devices in that time frame.

And those of you who are looking to develop hardware devices like that, certainly get in touch with our fine team of developer support people. And then, towards the end of this year, sort of the Christmas selling season, if you will, we expect to see the first consumer devices, first consumer M-LAN devices. And as I put up there, I think then the fun really begins.

First of all, if you're a developer or a hardware developer, what's great about that is that the volume for consumer devices is just enormous compared to the sort of semi-pro music market. And so, if you're a developer or a hardware developer, what's great about that is that the volume for consumer devices is just enormous compared to the sort of semi-pro music market. And so, if you're a developer or a hardware developer, what's great about that is that the volume for consumer devices is just enormous compared to the sort of semi-pro music market. And so, with all the silicon being generated, the price will go down quite a bit.

Also, the consumer devices tend to have a lot more, well, there'll be a lot more shelf appeal because they'll be in every circuit city and, you know, Best Buy, whatever, around the country. So, M-LAN devices will actually start to, I think, exponentially grow sort of towards the end of the year.

To me, that's really exciting because, for the first time, I think, we're going to have a lot of new devices. For the first time, and I think one of the, if I recall, one of the early discussions on the 1394 TA, the Trade Association website, there was an absolutely concerted effort to make sure that this was a spec which was clear across both consumer and professional applications.

And to me, that's very exciting because always in the past, we've had this sort of imaginary line, if you will, between professional or semi-pro, equipment and consumer equipment. And they didn't always talk together correctly or there was some sort of protocol difference. And we've been very careful to make sure that M-LAN is a completely cross-boundary application, protocol.

Basically, you shouldn't have any problem connecting up an M-LAN consumer device like your home stereo, home theater, or a television set to a professional device. They should be able to talk together. And they should be able to talk together quite well. So for me, that's very exciting because it opens up a whole lot of new applications and the market is just much larger than if you fragment it.

So what I'm going to do now is just give a real quick M-LAN demo. Those of you who attended the hardware keynote saw pretty much the same demo. So I will tell you, this is running under OS 9 right now. I don't have an OS 10 demo set up. But bear with me. So if you can switch over to the number 2, please. Number two, please.

Great. OK, so the first thing I want to show you is just if you go into the sound control panel, Then you'll see that the FireWire, as I mentioned before, M-Lan FireWire shows up as just a standard sound output device. And those of you who can hear it up here, these speakers are not probably loud enough to get all the way to the back of the hall, but we'll try.

So what I want to do then basically is just show you... if I can find the demo... Just a standard SoundJam MP. Just, again, if you saw the hardware keynote, you saw this. But, I don't know if you guys can hear that or not, but... So there's no difference really as far as the OS knows between the standard built-in sound hardware and the MLan demo, so the MLan speaker.

So you really, again, just to reiterate, your application really doesn't need to know anything about MLan in order to take advantage of it. Okay, so that's pretty much all I wanted to talk about. We can bring Jai back up and answer or go on to the resources side. Thanks.

Thanks, Wil. We really think that M-Lan is going to be cool, especially in the consumer electronics space. Just think about consumers wiring their home stereo systems with wires running all over the place. FireWire will make it so much easier, just one cable going all over the place and bam, you're ready to go.

So to talk a little bit about resources... We have an SDK available for all developers on the developer seat site. Go up there, get it, and start doing development. That has all the necessary documentation and everything else. We have a free FireWire mailing list for you to subscribe.

So if you have technical questions and want to post them, of course you can ask DTS. But there's a good community of FireWire developers, and we've set up this website. You should post your questions there. All our DTS engineers that do FireWire, all our engineers that do FireWire, are subscribed to this list. And they will answer your questions. Other developers are subscribed to this list.

So this is a good community where you can post your questions, and usually I've seen that people respond pretty quick. If you have general questions on FireWire, send them to [email protected]. They all come to me. I try and respond pretty quick, so you should hear from me pretty soon.

So there was some confusion some time ago regarding FireWire licensing. There was this big hoo-ha about a dollar report and everybody's saying, "Oh, we can't do it, we can't do it." So we worked on it a little bit. There's a new patent pool established for FireWire licensing, and it's really, really simple. That was the idea.

What happened is that previously when a developer or a silicon maker needed a patent license for FireWire, he had to go to each company that owned patents, right? Because there are several companies that own the patents on FireWire. There's Apple, there's Sony, Toshiba, and several others. So previously you had to go to each of these companies separately, pay an amount, and that amount was really dependent on the type of patent and things like that. Well, what we did is establish a patent pool with the 3094 TA, helped out a lot on that. And the eight companies that own the patents put their essential patents in this pool.

So they threw it in the pool, and now for a patent license, you don't need to go to any of these companies separately. You don't even need to come to Apple. You just go to the patent pool, and it's really, really easy. Every device you ship, you pay 25 cents, period. And it's also not per port. It's per device.

Also, it's per system, right? So think about it. Let's say some future computer has internal FireWire ports and uses an internal FireWire hard drive and has two external ports on it. The system manufacturer will yet pay 25 cents, although he's using a FireWire hard drive internally. It's per system, not per port.

Also, it's paid for by the end developer, not the silicon vendor. And the reason we did this was is that there is this effect that when you charge the source, every time it changes hands, the price keeps increasing, right? So the silicon vendor will charge his distributor, if he pays 25 cents, he will charge 50 cents.

By the time it goes from the distributor to the retailer from 50 cents, it goes to a buck. By the time it comes to the developer, it's more than a buck. By the time it comes to the customer, it's like $5. So we don't want that to happen. So what we said is, let's go to the end person and charge 25 cents. So it's now the end developer that pays that 25 cents.

The patent pool is managed by the 3094 licensing authority. So you can go to the website. It's 3094LA.com. Go there. They'll have all the details about how you need to pay and all that good stuff. So, but the idea here, it's really, really easy. Don't get confused about it. If you have questions, send me an email or send an email to [email protected]. We'll be happy to take it up with you and answer your questions.

So a couple of things that you should do. I think one of the key features of FireWire, especially from a customer perspective, is bus power. Customers love the idea that you can plug in a peripheral, don't need to connect it to the wall, just power it up, and you're ready to go. Well, so that of course depends on the type of peripherals that you have. So for peripherals that consume low power, use this feature. Our customers love it, and it just makes life so much easier.

The iMac DV and the new PowerBook G3s provide 6 watts of power. Our professional desktops, that's the G3, the blue and white G3 and the G4, provide 15 watts of power. But keep this in mind when you're designing your products. Now if your products use more than 15 watts, of course you have to be plugged into the wall.

But if they don't, also you should keep in mind that you have to provide for optional power. So that if the customer, for whatever reason, needs to use, let's say, a PCI card or a PC card that doesn't provide any power, your product should be optionally powered so that you can plug it into the wall and get power.

Take advantage of the multi-host topology. As Eric mentioned, FireWire is a peer-to-peer network. You can have multiple computers on the same bus. A couple of examples of products that have taken advantage of this are scanners and the Micronet SandCube. This is really huge, especially for scanners. If you look at a typical publishing environment, you've got one scanning station, a scanner attached to it.

Person goes to the scanning station, does a scan, then goes back to his computer and copies it over the network. That's a pain, right? What you could have is in the small work groups that typically our design customers work in, you can have multiple computers connected to the same scanner. You just scan straight from the scanner to the computer. The SandCube, of course, is a low-cost fiber channel replacement, and that's really cool.

The 3094A spec says that when you're providing power, you provide from 8 to 30 volts. Make sure that your device works under this requirement, right? We don't guarantee, we just guarantee that it will be between 8 and 30 volts, and we guarantee the amount of power we provide. We don't guarantee exactly what the voltage is. We've seen some devices that don't work in this case, so make sure that you follow the spec correctly.

We use the standard 6-pin connector out the back of our systems. These connectors are much more reliable and durable than the 4-pin connectors that you see on camcorders. So please use the 6-pin connector. Use 400 megabits PHYs for all your devices, especially when you're daisy-chaining and things like that. You don't want your 200 megabit PHY not to be able to transmit a 400 megabit packet. So that's really important.

On devices that are big, use 2 or 3 connectors. People like to daisy-chain FireWire. They know FireWire as a daisy-chainable bus, so make use of that. We know it's a couple of cents, maybe a buck more expensive because you have to add an additional connector, but this is something that our customers really like. Eric mentioned earlier on, use a unique GUID. The GUID, that's a unique serial number. He explained why, saying that if you have two VST drives with the same ID, the Mac doesn't know how to defer, and that would be bad.

The way the FireWire works is that every device has a config ROM in it. Don't use the minimal ROM. Use the entire ROM and put information about your device in there so that the Mac appropriately knows how to deal with your device when it's plugged in so it can match the appropriate drivers and things like that.

The FireWire logo. Eric mentioned it earlier. FireWire is an Apple trademark. We license the name FireWire and the FireWire logo, the yellow Y-shaped logo, for free to developers. Use this. In all our marketing materials, we tell our customers, "Buy FireWire devices." That's how our customers know what to connect. So don't call your devices iLink. I mean, don't call your devices 3094. You're just confusing the customers more and more. Call it FireWire. It's free. Use it.

Use the Mac logo. When you walk on an island, CompUSA or Fry's or whatever, how do you know which device works on the Mac? Well, you don't. I mean, you don't want to pick up each and every box, look at it, and put it back in. Use this logo. That's how the customers identify that this device works on the Mac.

In fact, CompUSA has gone to the extent of telling us to tell you folks to put this Mac logo on all the six faces of the box, because sometimes they stack the boxes like this, sometimes it's like this, sometimes it's vertical, any side. Use the Mac logo. Again, a license to use the Mac logo is free.

Just go download the form, fill it in, and fax it back, and you're ready to go. Artwork for both the FireWire logo and the Mac logo is available on the website. If you have any problems getting to it, drop me an email and we'll take care of you.

So there are a couple of sessions that you should really attend. Tomorrow, there's an important session on FireWire. We go into deep technical details about FireWire and Mac OS X. X is clearly the future for Apple. So all of you doing devices, it's time to start writing drivers, or if you're creating new devices, it's time to start working on Mac OS X. That's absolutely the way to go. We have a feedback forum on Friday for both USB and FireWire, so come to that. Tell us what you think.

If you can't attend that, send me an email and we'd be happy to exchange emails or send post emails on the mailing list. Tomorrow, we've got a good surprise for you, actually. What we're going to do is, you know that there's a party tomorrow thrown by Apple on the Apple campus.

I think they're going to bus everybody from here to the Apple campus. I think it's at 7:00 or 7:30 in the evening. What we're doing is we have a separate part on the Apple campus itself where we're going to have a FireWire plugfest. So Eric and the testing team are going to set up a couple of computers there. You bring your devices. If they're prototypes, that's not a problem. Bring your software. They'll plug it in and they'll see how the devices interconnect, drink a lot of beer, and have fun, basically.

We did it last time for USB, actually, and that's when we broke the 127 device limit for USB. For FireWire, again, if you have questions, you can email them to me directly or you can email them to [email protected]. The email comes to me. Again, I try to be really good about responding quickly. Just email is the best way to get a hold of us. There's also Craig. You can send email to Craig. Again, send it to either of us and we'll try our best to take care of you.