The SBP-2 does not support login less operation. Is this mean that we
can not invoke login-less status-get operation? Is this a drawback of
the SBP-2? Answer is "No".
The SBP-2 does not forbid multiple login, thus we can invoke login just
for getting status. Or even if the unusual implementation of SBP-2 does
not allow multiple login, a Login ORB may specify status_FIFO address
and a target device may return command set dependent status block.
This feature gives us satisfaction for the question I asked to Alan at the
meeting held on 6/12 at Tokyo.
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to firstname.lastname@example.org
From: Eric W. Anderson [SMTP:email@example.com]
Sent: Tuesday, June 17, 1997 4:10 PM
Subject: P1394> Comments on recent PWG-C/PWG meeting
[Apologies if you receive multiple copies of this. There seem to
be several mailing lists to choose from. - Eric]
I have read the minutes from the June 11-12 meetings.
Thank you for making them available so quickly.
I would like to provide some input from a computer software/
operating system point of view.
** 1. FCP or SBP-2?
As mentioned in the minutes, there are some concerns about using
FCP for printers. The specification for SBP-2 seems to be very
complicated, but this is only because it has been documented very
carefully. I believe that SBP-2 would be the best choice for
printers, and I suggest that you give it consideration.
Protocol SBP-2 FCP
High performance? Yes No
Computer friendly? Yes No
Complicated? No No
Needs changes for flow control? No Yes
Multiple independent units? Yes No
** 2. Device Discovery
1394 and 1212 use a flexible CSR ROM. From a computer point of
view, it is very important that the CSR ROM be used as a tree,
so that multiple, independent things can be put inside it. For
this reason, it will be very hard for operating systems to use
a CSR ROM that has device discovery information at the root
level. It may be impossible for a computer to participate in
more than one such protocol at the same time.
I believe that the example below is most compatible with 1394 and
1212. This example is a fax/printer. Please consider it:
ROOT ---+--- UNIT1 (PRINT) ---+--- UNIT-DIR (SBP-2)
| +--- UNIT-DIR (Vendor-Unique)
+--- UNIT2 (FAX) ---+--- UNIT-DIR (SBP-2)
In this example, the Print function and the Fax function are
completely independent. Of course, you can build a module with
a single embedded controller that performs both functions. Or
you can use different controllers. Either way, the CSR-ROM looks
the same, and the same computer software can be used.
Why does independence matter? Unlike a printer, the CSR-ROM in
the computer will depend on what software is loaded. It must be
possible for many different units to share this CSR ROM. If they
all put their information at the root, there will be a conflict.
Consider this example: I have a legacy (parallel-port) printer.
I want it to operate with my 1394 scanner. I can write driver
software for my PC that emulates a 1394 printer. The PC will have
information in its CSR ROM, and the scanner will "see" a real 1394
printer. Now the scanner can print directly to the printer, using
the PC as a bridge. No application software or GUI is required on
But at the same time, I also have superior OCR software on my PC.
I want my 1394 fax/printer to send faxes to the OCR software. The
PC will have data in its CSR ROM to describe the OCR software, and
to make this software look like a printer, so that the 1394 fax/printer
will send data to it automatically.
Here is the general problem: Both the OCR software and the printer
emulation software must put data in the CSR ROM. But, these drivers
are made by different vendors. They do not cooperate, and they cannot
share a common root-level interface. They must have different register
addresses, so that they can operate fully independently. This is why
the original 1394/1212 CSR ROM model is so powerful.
By the way, FCP uses a fixed address (FFFFF0000B00), so it is
impossible to have independent FCP units within a node (such as
a PC). This is one of the reasons why I believe that SBP-2 will
work better for use with printers and similar devices.
I welcome your comments on these matters. Please be sure to send
them directly to me, because I have not yet managed to get on the
mailing list due to a problem with the server.
Eric Anderson firstname.lastname@example.org
Apple Computer, Inc. (408)974-8187