| |
|
July 3, 1997
EDN hands-on project:
Firewire
unleashes the power of digital video
Maury Wright, Technical Editor
The IEEE-1394, or Firewire, serial bus
promises to enable a number of new applications that rely
on rich, high-speed data streams, such as digital video.
Developing a simple digital-video application, shows the
potential as well as the limitations of the interfaces
and projects how you might use it down the road as
Microsoft makes 1394 support standard in Windows NT, 95,
and CE.
After
struggling for respect during a development effort led by
Apple Computer (Cupertino CA), the IEEE-1394, or
Firewire, serial bus has taken center stage at several
major events. At Comdex Fall in 1995, Sony made it clear
that it would use 1394 in digital consumer-electronic
devices, such as digital camcorders. And at WinHEC in
spring of 1996, Microsoft also designated 1394 as a
cornerstone of future PCs acting as a multimedia and
expansion bus. In mid-1997, the long-term potential of
1394 is clear, but you may wonder just how easy it is to
use the new interface. I set out to answer that question
by developing a simple digital-video application, which
reveals the level of effort required to use 1394 today.
Given the
short list of available products and the expected
prominence of digital video in 1394 systems, I defined a
simple 1394-based application to explore the new
interface (see boxes, "1394
products: a trickle now, but probably a flood later" (pg 58) and "The
1394 road map to 800 Mbps and beyond" (pg 52)). I wanted to code
an application to use a 1394 digital camera to capture
video footage.
When I
conceived and defined the project last fall, I did so
with typical assumptions about when certain technologies
would become available. I knew that, at a minimum,
digital cameras were already available and that one or
two host adapters would be available. Skipstone, a
start-up company dedicated to 1394 products, had been
shipping host adapters since 1995, and Adaptec had also
announced its host adapter.
I hoped that
a 1394 disk drive might be available, because the 1394
interface should allow a camera to directly transmit a
digital-video stream to a disk drive without help from
the host computer. Such peer-to-peer transfers could
minimize traffic on the bus and the performance load on
the host PC. Moreover, the 1394-based camcorders can
compress the video in the camera so you get compressed
video directly on a disk. Alas, no drives are yet
available, and drives that support isochronous transfers
could be several years away (see box, "Drive
vendors grudgingly move toward adopting 1394'' (pg 50)). The lack of a 1394
disk drive didn't jeopardize my project, though.
 A more important expectation,
however, was that a fair amount of software support for
1394 peripherals and applications would emerge in time
for my project. Microsoft had clearly defined its new
Windows Driver Model (WDM) early last year and pledged to
support this model in the next major Windows 95 release,
code-named "Memphis," and Windows NT. The
layered WDM architecture differs from the monolithic
drivers that Windows 95 currently uses (Figure 1). I originally figured that Memphis would
ship in at least beta form before my project. I also
figured that the new OS would include an improved Active
Movie facility and that capturing video would require
nothing more than a simple Visual Basic program and maybe
some application scripts. I was wrong.
Selecting
1394 equipment
Early this
year, I began to gather loaner equipment and investigate
the state of 1394 support for Windows. Considering the
capabilities and requirements of the available host
adapters, I realized that I would need to master C++ in a
Windows environment to develop any useful code for the
1394 interface. Higher level and easier to use 1394
software tools won't be available until after the Memphis
release, which has clearly been delayed until the second
half of '97 and probably will slide into '98.
For several
reasons, I chose to use a Skipstone host adapter. The
company had been working with 1394 since day one, and it
also had a product that was shipping with Windows 95
drivers. Adaptec had targeted its development at WDM, and
its product required Windows NT because versions 3.51 and
4.0 had WDM support. When Memphis ships, Windows 95 and
NT will both support identical WDM architectures.
For the
project, Sony offered me its CCM-DS250 camera, and
Microsoft provided a copy of the latest enterprise
edition of Visual C++. Microsoft offers Visual C++ in
three packages. A learning edition costs less than $100
and includes all the Microsoft Foundation Class (MFC)
support necessary to develop Windows applications. You
can use the learning edition, however, only to compile
code for the machine on which the compiler resides. You
must upgrade to the professional edition (around $250) if
you want to distribute compiled code. The enterprise
edition costs around $500 and includes support for
client/server applications, such as distributed
databases.
Once I sat
down with the Skipstone software-development kit and
Visual C++, I realized that I had taken on quite a
project. I had a rusty working knowledge of C but no
experience developing Windows applications and no
experience with C++. Moreover, my experience with Visual
Basic was clearly no help in dealing with a 1394 device.
The problems
I faced were twofold. I basically understood the
Skipstone 1394 application-programming interface (API),
but the API calls were low-level. I had expected to find
a software layer that would allow me, for example, to
call a function to open a channel to the videocamera and
call a second function to start a video stream in a
window. Instead, Skipstone developed the API
independently of device types, such as videocameras. The
programmer must handle such things as bus configuration,
device configuration, and device errors, as well as write
a program to handle video on a pixel-by-pixel basis.
Understand that this isn't in any way a slam on
Skipstone's fine work but rather an indication of 1394's
immaturity.
My second
problem was Windows 95 programming. Visual C++ is an
amazing tool, but it's incredibly complex--especially for
someone who hasn't developed Windows programs throughout
the evolution of the OS. Anyone with C experience can
write a simple, DOS-based program in minutes using Visual
C++. In fact, the application wizard and the MFC library
allow programmers to write simple Windows 95 programs
with little effort. On the other hand, Visual C++
includes hundreds, if not thousands, of Windows-specific
C functions that have evolved over time.
To further
complicate matters, Visual C++ ships with no manual. The
documentation is available online, but even with a 17-in.
monitor operating at 1024×760-pixel resolution, you
can't keep the code and documentation visible
simultaneously. I was in a frustrating situation, trying
to understand the programming samples in the 1394
development kit while struggling to track down mysterious
Windows functions. Note also that by common convention,
Windows programs spread code, data type, and class
definitions over at least a dozen files. Moreover,
Windows programs simply don't look like the traditional
inline C programs that I have had experience with. So, I
went back to square one and bought a Visual C++ book (Reference
3). I was able
to breeze through the first half of the book quickly. The
second half was especially helpful for learning about the
structure of Windows programs and about the MFC library.
Changing
host adapters
Meanwhile,
things were changing on the 1394 host-adapter front.
Adaptec bought Skipstone and shortly thereafter announced
that it would no longer offer the Skipstone host adapter
or development kit. In the short term, people using the
Skipstone products are still receiving support, but
Adaptec is migrating those customers to its own host
adapter and Firesoft API. In fact, the company is
supplying Skipstone's developers with a free Adaptec kit.
I could have
continued my work with Skipstone's kit because the end
result of my project needn't live for an appreciable
amount of time. On the other hand, I preferred to use an
API that would be available to you, and Adaptec has
pledged to continue support for its API even after
Memphis ships. Adaptec had also made its development kit
and driver available on Windows 95, so I decided to move
to the Firesoft platform.
No sooner had
I switched my focus than I discovered that Adaptec's
driver software didn't work on just any version of
Windows. The kit required OEM Service Release 2.1, which
was shipping only on brand-new USB-equipped PCs. USB and
1394 share a dependence on WDM; Microsoft issued Service
Release 2.1 to system manufacturers to kludge the Windows
NT version of WDM onto Windows 95, thereby enabling USB
to work in a limited fashion. Microsoft offers OEM
Service Release 2.1 only via new PCs and to members of
its Developers Network. For $495 a year (and a signed
nondisclosure agreement), you can join the network and
receive quarterly CDs with all versions, including betas,
of Microsoft OSs.
Adaptec,
however, has pledged that by the time you read this, it
will support older versions of Windows 95 via a
traditional monolithic driver. Micro-soft's ever-slipping
Memphis schedule convinced Adaptec of the need to develop
such a standard Windows driver that also will support the
Firesoft API. Without such a driver, Adaptec's customers
can't ship products to customers who don't have WDM, and
most end customers must either buy a new PC or wait for
Memphis for the WDM support.
I was able to
get Service Release 2.1 from Microsoft, and I then had to
deal with the logistics of installing a new OS while
keeping an existing version operational for safety. (See
box, "Big disk and multiple partitions
simplify development efforts" for details on how to manage
multiple OSs on one system and other tips on disk
management.) A third version also entered the picture in
my case. The prebeta WinHEC '97 release of Memphis
included limited WDM support, and Adaptec and Microsoft
used the software to demonstrate streaming video over
1394 as well as a transmission-control protocol/Internet
protocol (TCP/IP) link be-tween two hosts running over
1394. After I experimented with the WinHEC Memphis
release, I decided to stick with Service Release 2.1.
However, Memphis and the new version of Active Movie will
greatly simplify similar projects down the road.
Coding a
1394 application
Finally, I
arrived at the core of my project: coding a simple 1394
application. In all fairness, I borrowed most of the code
from Adaptec's development kit and Visual C++, but, let
me tell you, it's not easy to figure out how to borrow
that code and make it work.
Even when you
get down to 1394-specific code, you must deal with
multiple protocols or interfaces. First, 1394 is an IEEE
spec, yet, like other microcomputer-bus specs, it relies
on other industry standards. For example, ISO/IEC
13123:1994 defines a control-and-status-register (CSR)
architecture that the computer industry has used in other
standards ranging from system buses to I/O buses, such as
SCSI. The CSR definition includes a 1-kbyte block of
configuration ROM in which a device vendor places the
vendor name, the model number, and, in the case of 1394
devices, a unique serial-number-like ID called the
"Global Unique Identifier" (GUID). You can use
other portions of the CSR to set operational parameters
in a 1394 device or to allow remote nodes to read the
status or configuration of a device. Every 1394 device
includes a CSR and ROM area. Moreover, 1394 devices
generally will comply with some command set.
To date, the
1394 Trade Association has published two device-class
specifications. These specs define a device's baseline
set of capabilities and how a program can access those
capabilities via the CSR set or commands. The
specifications also define formats for data streams and
packets. One of the published specs, the 1394-based
"Digital Camera Specification," addresses
cameras such as the Sony CCM-DS250 that target video and
document conferencing, industrial vision applications,
and other nonconsumer applications. The 20-pg
specification is relatively simple and should ensure a
base level of compatibility among devices from different
vendors.
Not all
device types will be so simple, however. For example, the
1394 Trade Association has also developed the "AV/C
Digital Interface Command Set" for devices such as
digital camcorders and other digital consumer
electronics. The spec not only stretches to 64 pg, but
also relies on several standards that other standards
bodies have developed. Formats for the isochronous data
streams come from the HD Digital VCR Conference. The
actual commands are encapsulated within a
function-control protocol (FCP) that the HD Digital VCR
Conference specified, and the FCP specification is now
going through the formal IEC standards process. (See the
1394 Trade Association Web site to download the
digital-camera and audio/video-control specs and to find
references to the other pertinent standards.)
The
Firesoft API
After you
have a handle on the host-adapter API and key
device-specific capabilities, protocols, and commands,
you can start developing the application. Table 1 summarizes the Adaptec Firesoft
API functions and the command codes you can use with each
of the three functions. The GetPAPISupportInfo function
requires no command code, and you use it only to
initialize the 1394 driver and find out how many 1394
host adapters reside in the system. You can use the other
two functions, SendPAPICommand and BusConfig, with a
variety of command codes. The SendPAPICommand generally
deals with bus-I/O operations, whereas BusConfig deals
with host-adapter and bus configuration. You call all
commands for either function with a standard C++ data
structure, and each command code augments the standard
structure with other data types that the command code
requires. The Adaptec development kit ships with a
standard C++ header file that defines every data
structure necessary for the Firesoft API.
 Given this 1-minute tour of the
API, consider a flowchart that depicts a bare-bones
implementation of a program that takes a video stream
from a camera and displays the stream in a window (Figure 2). The flowchart does not detail the
Windows-specific functions necessary to control the
application and display video. Once you understand
Windows programming and Visual C++, however, the compiler
and application Wizard automatically generate most of the
Windows code. The flowchart also glosses over error
handling, but, in reality, every API call requires some
error processing to ensure that the command completes
successfully.
The flowchart
is relatively straightforward and demonstrates both the
potential of 1394 and the low level at which you must
deal with 1394 devices. You initialize the camera by
first reading the device ID, then using the ID to get a
logical "handle" to the camera, and finally
configuring parameters such as frame rate and video mode.
After reserving an isochronous channel, the program
starts a separate program thread to process the incoming
data. Only then does the main program turn on the camera
by writing the appropriate location and data in the CSR.
The program must start the second thread to allocate
buffers and enable the isochronous channel.
The program
must manipulate the incoming video stream on a
pixel-by-pixel basis--even performing a conversion from
YUV to RGB. Ultimately, the 1394-based digital-camera
spec will allow cameras to directly support RGB formats,
but the existing spec is incomplete in that area.
Eventually, you will be able to easily choose a mode that
will encompass a specified resolution and video format.
The simple
program in the flowchart may be all that your application
needs if you know which devices are connected on a 1394
bus and you have to worry only about peripherals. It's
likely, however, that you might want to develop a
slightly or substantially more robust program than the
flowchart example. For instance, the sample program
assumes that only the host adapter and camera are on the
bus. A more robust program could use the P_GET_HA_INFO
command to find out details about the host adapter,
including the number of nodes that are on the bus. The
program could then query each node with the
P_GET_DEV_INFO command. Should you plan on developing an
application that could work with a variety of cameras,
your program might need to automatically adapt to
whatever camera you install. The complexity skyrockets
once you attempt to support multiple peripherals.
You could
also enhance the video processing. For example, you could
use the Windows 95 DirectVideo API with a video-enabled
graphics card and direct the YUV stream directly to the
graphics accelerator. Writing video to disk requires some
simple Windows function calls.
With a
cursory understanding of a 1394 application, you might
ask yourself what could change over the next year and
whether development today is a safe undertaking. Although
it may surprise you, the answer to the second question is
"yes," provided that you can buy 1394 devices
that meet your needs and budget. Adaptec's purchase of
Skipstone caused a few problems for me, but it resulted
in a single source for a stable development platform and
de facto-standard API. Also, Adaptec promises to continue
supporting the Firesoft API on Memphis so you can migrate
your work forward.
Programming
on Windows 98
Still, the
interface will become easier to use next year as
Microsoft implements 1394 support in Memphis (Figure 1). Microsoft will provide a 1394
bus-class driver, just as it will provide a USB-class
driver. Minidrivers under the bus-class drivers provide
the hardware-specific code, and these minidrivers can
come from Microsoft or hardware companies, such as
Adaptec.
The upper
layers of Figure 2 show how Adaptec will support the Firesoft
API on Memphis, but the Adaptec protocol driver and
dynamic-link library implement just one of many
device-class drivers that reside at that layer in the
WDM. For example, Microsoft has defined several generic
device-class drivers, such as a streaming video driv-er,
an audio driver, and a still-imaging driver. Next year,
you'll likely be able to make high-level calls to the
streaming device-class driver and access the capabilities
of a camera such as the CCM-DS250. Moreover, bundled
applications, such as Active Movie, will make video
capture a snap. A single storage-oriented device-class
driver will provide a consistent interface to disk,
digital-video-disk (DVD), removable, and other drives.
Complex devices, such as DVD drives, may require two
device-class drivers: the storage-oriented driv-er to
read data and a streaming-oriented driver to process
MPEG-2 audio and video streams.
References
Wright,
Maury, "USB and IEEE 1394:
pretenders, contenders, or locks for ubiquitous
desktop deployment?" EDN, April
25, 1996, pg 79.
Wright,
Maury, "Designing
multiprocessing hardware--new architectures lead
the way," EDN, July 18, 1996,
pg 36.
Horton,
Ivor, Beginning Visual C++, Wrox Press
Ltd, Birmingham, UK, 1997.
Petzold,
Charles, Programming Windows 95, Microsoft
Press, Redmond, WA, 1995.
|
 |
The number of 1394
peripherals is still small, yet stable
host-development platforms are available.
The industry is finally
committed to 1394 disk drives, but such
peripherals are realistically a year
away.
You can deploy 1394 in
digital-video applications today.
Be prepared to micromanage
1394 operations with a low-level API in
the short term.
|
| Big disk and multiple
partitions simplify development efforts |
When you start a development similar
to my project--especially one that depends on a
new version of an operating system--make sure you
use a high-capacity disk drive and a
well-thought-out partitioning scheme. In doing
so, you can ensure the safety of programs and
data on your standard partitions yet selectively
boot into new versions of the OS when necessary.
Moreover, a good partitioning strategy keeps key
applications, such as the Microsoft Developers
Studio and Visual C++, usable from any boot
partition. Some relatively low-cost utilities can
also simplify disk management. I further
recommend buying a high-capacity removable disk
drive, such as a $499 Syquest Syjet, for archives
and backup.
At
the start of my project, I considered my 2-Gbyte
disk drive to be quite well-organized. I had two
partitions just smaller than the 1-Gbyte limit,
after which Windows 95 takes 32 kbytes of space
for every cluster. Using a single 2-Gbyte
partition in such a situation can waste as much
as 40% of the space on your disk drive. Although
I had avoided this trap, I hadn't separated the
OS from applications or data files.
The
partition experts at Powerquest, the maker of the
$49.95 Partition Magic software package, have
long advocated even more modular structures. They
recommend that you store nothing but the OS on
the boot partition and that you have separate
partitions for applications and data. I never saw
the need for this level of modularity, because
simply using a directory structure for all data
files made backup relatively easy. As I worked on
this project, I certainly discovered the need for
more partitions, and I realized that I didn't
know as much about Windows 95 and disk drives as
I thought I did.
I
began the project thinking all I needed to do was
find free space for Visual C++ and a 1394
software-development kit. Microsoft's enterprise
edition of C++ requires about 170 Mbytes for a
typical installation, and, ideally, you may want
to install the full developer's library, which
occupies around 500 Mbytes. A change in the host
adapter I was using, however, required me to load
a newer version of Windows. Moreover, I wanted to
experiment with the prebeta WinHEC release of
Memphis that included some 1394 support.
Maxtor
supplied me with a 5-Gbyte drive from its
DiamondMax family, whose performance equals that
of most SCSI drives. The DiamondMax family even
includes Ultra DMA/33 support for 33-Mbyte/sec
transfers if your host controller can support the
new scheme. Syquest also provided one of the new
1.5-Gbyte Syjet removable drives that I planned
to use for archives and backup. If you have a
SCSI host adapter already operational in a
system, you can get the Syjet running in 5
minutes.
I
then tried to copy my partitions to the new
Maxtor disk. I installed the new drive on the
secondary ATA channel in my system, formatted and
partitioned the drive, and got ready to copy the
partitions. I had followed this procedure dozens
of times in the days of Windows 3.1 but never in
Windows 95. I suddenly realized this fact when
Windows 95 aborted the copy operation anytime it
encountered system files. In the days of Windows
3.1, I would have handled the copy operation from
DOS using the XCOPY command, but XCOPY doesn't
copy Windows 95's long file names. You can use a
new program, "XCOPY32," in a DOS box
under Windows 95, but it doesn't copy the key
system files either. In this case, the Syjet
didn't help either, because you can't copy the
key system files to the removable drive any
better than you can to a second fixed drive.
By
this time, it was the weekend, and little help
was available, so I headed to the Windows 95 Web
site. I first found a shareware program,
"Transfer 95,'' from ITS Systems that
promised to solve the problem. Unfortunately, I
couldn't get the program to work, and it demanded
a rather convoluted sequence of steps to attempt
to transfer a partition from one drive to
another.
Back
on the Web, however, I found a program called
"Ghost" from Innovative Software, and
it flawlessly copied all partitions from one
drive to another. Innovative Software targets
Ghost at system administrators who need to clone
disk images across many systems. The company
doesn't even request a registration fee if you
use the software on a single system.
Coincidentally, Powerquest launched its Drivecopy
program the following Monday. The $29.95
Drivecopy works just as well as Ghost.
The
experience, however, left me wondering about
Windows 95 backups. Until I upgraded to a 2-Gbyte
drive, I had regularly copied my entire disk
drive to a 650-Mbyte Panasonic PD rewritable
optical drive. I had upgraded to Windows 95 and
simultaneously exceeded the capacity of the
optical drive, and I therefore started performing
data-only backups. I now realize, however, that
even with the Syjet, I wouldn't have an easy time
making a full copy of my boot partition. Both
Powerquest and Innovative Software have pledged
to ship software that will simplify exact copying
of a boot/Windows 95 partition or any other
partition to a removable drive. Today, Ghost and
Drivecopy can copy only an entire disk drive to
an equal-sized or larger drive, rather than
copying individual partitions. Expect a
single-user/end-user version of Ghost and a new
Powerquest product with
individual-partition-backup facilities this
summer. The utilities will sell for approximately
$100 each. Both companies also claim they will
allow such backups to span multiple cartridges,
so you can even use products such as Zip drives
to perform a true backup. A product such as Syjet
will be able to store an exact image of a
partition on one cartridge if you keep your
partitions smaller than 1.5 Gbytes.
Meanwhile,
having solved the partition-copy problem, I moved
the 5-Gbyte drive to the primary ATA interface,
made the drive the master, and booted the new
drive with identical partitions to my old 2-Mbyte
drive. The new drive also had plenty of room for
the additional partitions that would hold
multiple versions of Windows 95.
Powerquest's
Partition Magic made short work of creating the
new partitions, and I was able to install three
versions of Windows 95 and selectively boot from
any of the three. At that point, I discovered why
it would have been nice to have separated my
applications from my Windows partition: You must
install both of the new Windows 95 versions on a
clean partition rather than over an existing
installation. Therefore, I had no way of
maintaining access to applications and data when
I booted to either of the new versions of Windows
95. The data is easy enough to move, but moving a
Windows application is typically fatal. Assuming
that you have an application on a dedicated
partition, however, the application can remain
usable, no matter which OS you boot. You may have
to install the application from each OS to make
the application usable from all versions, but you
can install it to the same directory each time.
You don't have to gobble up disk space with three
separate installations.
So,
all's well that ends well. After uninstalling and
reinstalling Microsoft Office, Visual C++, and
other applications, I finally got to boot
different OSs from three partitions. Regardless
of the boot partition you choose, the application
and data partitions are always visible.
|
| Drive vendors grudgingly move
toward adopting 1394 |
Despite a less-than-enthusiastic
response from disk-drive vendors early on, it now
appears a safe bet that a variety of data-storage
peripherals will use the 1394 interface. The
isochronous capabilities and high data rate of
1394 perfectly suit applications such as
digital-video-disk (DVD) drives. Moreover,
400-Mbps data rates exceed the capabilities of
today's fastest ATbus-attachment (ATA)
interfaces. Hard-drive vendors, however, have
been generally reluctant to adopt 1394, often
citing speed issues. Realistically, the drive
vendors simply didn't want to spend the money to
develop and fully support a third interface in
addition to ATA and SCSI. Moreover, the 1394 road
map to 800-Mbps rates provides plenty of headroom
for faster disk drives. It was Microsoft's vision
of a sealed-case PC, however, that ultimately
forced the vendors to start working on 1394
drives. More recently, Microsoft, Intel (Santa
Clara, CA), and Compaq (Houston) have led a host
of vendors developing the "Device Bay
Specification" for add-on peripherals.
Device Bay relies on 1394 for peripherals such as
disk drives and will clear the way for 1394 to
challenge ATA as a disk interface.
Although
it's clear that 1394 has a future in disk drives,
several obstacles will determine how soon such
products will be available. First, the industry
must develop storage-specific command sets and
bus protocols that layer on top of the base-line
1394 interface. Then, it will take drive vendors
and their IC partners some time to develop
compatible products. Microsoft also enters the
picture because full support for the Windows
Drive Model (WDM) won't appear in Windows 95
until the Memphis release, which Microsoft has
pushed into late '97 or possibly early '98.
Finally, BIOS developers and Microsoft together
must address a number of issues before a system
can boot from a 1394 disk drive.
The
effort toward developing 1394 drives, however, is
well under way. The "DiskBoys"
committee, comprising disk-drive,
disk-controller-IC, and system-software vendors,
is working with the 1394 Trade Association to
develop the needed standards. Already, the group
has defined Serial Bus Protocol 2 (SBP-2), a
transport protocol that defines delivery
mechanisms for command and status packets. The
specification borrows heavily from the SCSI-bus
protocol, and, ultimately, the ANSI X310
committee that shepherds SCSI will own the
protocol. As it stands, SBP-2 supports only
asynchronous-bus operations, so the possibility
of directly transferring an isochronous video
stream from a camera to a disk drive will have to
wait for a follow-on effort to SBP-2.
The
DiskBoys have also done substantial work on a
command set that will closely resemble the
ATA-packet-interface (ATAPI) command set. The
committee largely derived ATAPI from SCSI, but
ATAPI and 1394 command sets will include far
fewer commands than SCSI does.
Tailgate
should spur development
Simultaneously,
the DiskBoys have developed Tailgate, a spec that
defines a common method for connecting ATA/ATAPI
devices to a 1394 interface. Essentially,
Tailgate is a translation layer that will allow
drive vendors to offer 1394 disk drives as soon
as this year. Drives with native 1394 controllers
won't debut until next year at the earliest.
Symbios Logic and Silicon Systems, however, have
already announced ICs that implement Tailgate.
Moreover, Maxtor and Silicon Systems demonstrated
a working tailgate drive at the WinHEC show in
April. You may not be able to buy such a Tailgate
drive on the open market today, but you can bet
that some developers have samples in hand.
The
timetable for shipment of Tailgate or native 1394
drives depends to some extent on software issues.
Nothing would stop someone from writing a driver
and connecting a 1394 drive to a system today.
Such a drive wouldn't be bootable, however, and
the implementation would necessarily differ from
the WDM-based drivers that will ship with
Memphis. Drive vendors seem content to time
widespread product availability for Memphis-based
systems that incorporate Device Bay.
Phoenix
Technologies, meanwhile, is working on the
bootability problem. The well-known BIOS vendor
was instrumental in working with Microsoft to
solve SCSI and ATAPI device-boot issues and has
published the "Device Boot
Specification," which is available on its
Web site. But 1394 introduces a new problem. The
1394 interface is truly plug-and-play, and you
can't ensure that a drive connected to the bus
assumes the same node ID each time you apply
power or reset the system. All 1394 devices,
however--even two identical drives from the same
vendor--have a unique code stored in the onboard
configuration ROM. Phoenix hopes to work with
drive vendors and Microsoft to use these
so-called Global Unique Identifiers (GUIDs) so
that a user can specify 1394 devices as boot
devices. Meanwhile, Phoenix has pledged to
develop BIOS work-arounds and support booting
from 1394 drives this year via the interrupt-13
interface.
|
| The 1394 road
map to 800 Mbps and beyond |
 The 1394 Trade Association
offers a road map that describes the realized
milestones and the expectations of the new
interface (Figure
A). As
you can see, 1394 applies equally well to the
living-room entertainment center and to the
desktop computer. In fact, 1394 will be a key to
the so-called convergence of communication,
computing, and consumer devices. The Consumer
Electronics Manufacturers Association (CEMA) has
even decided to specify 1394 as the basis for a
standard audio/video bus that will connect
high-definition TVs (HDTVs), digital-video-disk
(DVD) players, TV/PCs, and PC theaters. Moreover,
the 1394 Trade Association road map includes
extensions to 800 Mbps and beyond and has
garnered the interest of high-end computer
vendors, such as Sun Microsystems (Mountain View,
CA).
Today,
the 1394 specification defines a physical
interface that can operate at 100, 200, and 400
Mbps. Devices can support any of the speeds, and
any two devices on a 1394 bus communicate at the
highest rate that each supports. One 1394 bus can
connect as many as 63 devices, such as
digital-video camcorders, printers, scanners,
videoconferencing cameras, DVD drives, and disk
drives. The bus also includes provisions to
support isochronous transfer of real-time data
streams, such as video. Much of 1394's appeal is
due to its guaranteed bandwidth and predictably
low latency characteristics of isochronous
transfers. Reference 1 provides more details on
1394 basics, and you should also investigate the
Web sites of the 1394 Trade Association, Adaptec,
and Texas Instruments to obtain more 1394
information.
The
1394 Trade Association also plans to extend the
bus to support 800-Mbps transfers, and the
extension will almost assuredly remain
backward-compatible with the existing spec. It's
not clear at this time, however, that speeds will
be able to exceed 1 Gbps and still maintain full
backward compatibility, but extension to 1600
Mbps is under discussion. A second spec, called
1394.2, will exceed 1 Gbps but won't be
backward-compatible. Some prognosticators have
pointed to 1394.2 as a hindrance to growth of the
1394 interface due to the lack of backward
compatibility. Realistically, however, 1394.2
targets fundamentally different applications. For
example, expect to see system manufacturers use
1394.2 down the road as a multiprocessor bus
based on the scalable-coherent-interface (SCI)
standard (Reference 2).
|
| Table 1--Firesoft API
functions and their command codes |
| GetPAPISupportInfo |
Returns the number of host
adapters installed |
| SendPAPICommand |
Handles 1394 I/O requests
via command codes |
| P_GET_HA_INFO |
Get information on a host adapter |
| P_GET_DEV_INFO |
Get device's configuration ROM |
| P_QUEUE_ISOC_CMD |
Queue an isochronous transfer |
| P_START_ISOC |
Begin isochronous transfer on a
designated channel |
| P_STOP_ISOC |
Stop isochronous transfer on a
designated channel |
| P_EXEC_ASYNC_CMD |
Execute an isochronous transfer |
| P_NOTIFY_ON_ACCESS |
Notify client when a mapped area is
accessed |
| P_ABORT_1394_CMD |
Abort an outstanding I/O command |
| P_GET_BUS_EVENT |
Get report of asynchronous bus
events |
| P_GET_CAP_VERSIONS |
Get host-adapter capabilities and
chip version |
| BusConfig |
Get or set 1394 bus and
host-adapter configuration |
| P_GET_HANDLE |
Get a handle to a 1394 device |
| P_RELEASE_HANDLE |
Release previously obtained handle |
| P_GET_NODEID |
Get node ID of a 1394 device |
| P_ALLOCATE_BANDWIDTH |
Allocate bandwidth |
| P_DEALLOCATE_BANDWIDTH |
Deallocate previously allocated
bandwidth |
| P_ALLOCATE_CHANNEL |
Allocate channel |
| P_DEALLOCATE_CHANNEL |
Deallocate previously allocated
channel |
| P_SET_ROOT |
Force specified node to be Root node |
| P_SET_GAPCOUNT |
Set arbitration gap count |
| P_LOCAL_HA_READ |
Read host adapter's registers |
| P_LOCAL_HA_WRITE |
Write host adapter's registers |
| P_GET_SPEED_BTWN_NODES |
Get speed from Speed Map |
| P_1394_BUS_RESET |
Initiate a bus reset |
| P_LINK_ON |
Turn on the link of a physical ID |
| P_RESERVE_ISOC_RESOURCE |
Reserve a physical DMA channel |
| P_RELEASE_ISOC_RESOURCE |
Release a reserved DMA channel |
| P_MAP_1394_ADDRESS |
Map 1394 address to system memory |
| P_UNMAP_1394_ADDRESS |
Unmap previously mapped 1394 address |
| P_READ_MAP_CONTENTS |
Read contents of a mapped area |
| P_WRITE_MAP_CONTENTS |
Write contents of a mapped area |
| P_UPDATE_MAP_CONTENTS |
Update contents of a mapped area |
| Note: API
functions are in boldface. |
| Manufacturers of 1394-related
products |
| When
you contact any of the following manufacturers
directly, please let them know you read about
their products on EDN's website. |
Adaptec
Inc
Milpitas,
CA
1-408-945-8600
www.adaptec.com |
Consumer
Electronics Manufacturers Association
Arlington,
VA
1-703-907-7674
www.cemacity.org |
IBM
Microelectronics
Fishkill,
NY
fax 1-415-855-4121
www.chips.ibm.com |
Innovative
Software
Milwaukee,
WI
1-414-964-2200
www.ghostsoft.com |
ITS
Systems
Hugo, MN
1-612-426-7012
www.itechs-systems.com |
Maxtor
Corp
Milpitas,
CA
1-408-432-1700
www.maxtor.com |
Microsoft
Corp
Redmond,
WA
1-206-882-8080
www.microsoft.com
www.windows95.com |
Panasonic
Secaucus,
NJ
1-800-222-4213
www.panasonic.com |
Phoenix
Technologies Ltd
San Jose,
CA
1-408-570-1000
www.phoenix.com |
Powerquest
Orem, UT
1-801-226-8977
www.powerquest.com |
Silicon
Systems
Tustin, CA
1-714-573-6000
www.ssi1.com |
Sony
Electronics
San Jose,
CA
1-408-955-5623
www.sony.com |
Symbios
Logic Inc
Fort
Collins, CO
1-970-223-5100
www.symbios.com |
Syquest
Technology Inc
Fremont,
CA
1-800-245-2278
www.syquest.com |
Texas
Instruments
Dallas, TX
1-800-477-8924, ext 4500
www.ti.com |
1394
Trade Association
c/o
Adaptec Inc
Milpitas, CA
1-408-945-8600
www.1394ta.org |
|
|
| 1394 products: a trickle now,
but probably a flood later |
The list of 1394 products that are
available today is short. Sony has been shipping
a number of 1394-based digital camcorders for
some time, and Panasonic recently began shipping
such a product. These digital products typically
cost around $2000, and the price limits the
market for these cameras to "prosumer"
video-editing applications. Sony also offers the
CCM-DS250 digital camera, which targets
videoconferencing and industrial video-capture
applications. The CCM-DS250 costs $750 and offers
the most economical avenue to 1394 evaluation.
On
the host side, TI offers a 1394 host adapter that
the company primarily targets at users evaluating
its 1394 ICs. TI sells the board as part of the
PCILynx Designers Kit for $1000. Adaptec,
meanwhile, offers its host adapter in a
development kit targeted at OEMs that want to
design a 1394-based PC-add-on product. The 1394
Firewire developer's kit for Windows NT and
Windows 95 costs $599 and includes Adaptec's
AHA-8940 PCI-bus host adapter, a
software-development kit, cables, and other
accessories. OEMs have used Adaptec's kit to
develop and ship retail products based on the
AHA-8940 board. For example, you can already buy
turnkey video-editing systems with prices that
start at $995. These systems rely on the Adaptec
host adapter from several companies. All you need
to add is a digital camcorder for a complete
desktop digital-video-editing system.
There's
no shortage of 1394 ICs for designers who want to
develop host-side interfaces or 1394 peripherals.
Adaptec, IBM, TI, and others are offering chip
sets that meet the requirements of 1394 physical
and data-link layers. Visit the 1394 Trade
Association Web site, and you will also find that
specialized test equipment, such as bus
analyzers, is starting to arrive. With readily
available ICs, host adapters, and test equipment,
expect a flood of products in 1998.
|
|
