protocol analysis "disc get title"

Hi,

A happy new year everyone.

Thanks to both Petes for their comment.  I have now written my own small
test program that uses readline and allows me to send hex strings to the
device and watch the reply.  This led to some insight on a couple of issues.
If you try this at home, don't be fooled if things seem to work if you
truncate the request on subsequent runs: There seems to be some internal
buffer and the device doesn't really honor the request length at all, but
simply runs on the previous values it still has inside the buffer.  However,
you can send more bytes than expected and the device will ignore them.  This
way we can verify how many bytes in a request are really significant.

I will make my program available later.

I advise to be careful when trying such wrong commands.  We don't know
enough about the protocol and the hardware to be able to tell if the device
can recover fully from all possible things you throw at it.  If you break
yours, you own both pieces.


Get Disc Title
==============

00 18 06  02 20 18 01  00 00  30 00  0a 00  ff 00 00 00 00 00

Return the disc title.  Note that wchar is not supported on all devices, or
needs somehow to be enabled in hardware or EEPROM.  We know about the wchar
support from Tatsuhiro Nishioka (see mail "wchar related functionarity").
If wchar is not supported, the empty string is returned.

Let's go through those bytes:

1. "00": This byte is not significant.  It can be anything.  It only seems
         to have a function as a return value.  This byte is always
         overwritten on output with the return code.
         Return code 09: Operation completed.
                     08: Syntax error.
                     0a: Could not complete operation (for example,
                         because this is a blank disc or the track argument
                         is out of range)

2. "18": This byte is not significant.  It can be anything.  I think that
         this might be some sort of subsystem or device interface code and
         the device is possibly poor on error checking :)  This byte is
         echoed on output.

3. "06": This one is significant.  Changing it possibly leads to "08"
         errors (A reply with the first byte changed to 08).  I am not man
         enough to scan this field, but I tried 00 and 09 as values.

4. "02": See 3.
5. "20": See 3.
6. "18": See 3.

7. "01": We already know that given 3.-6. above, this means "disc" while
         "02" means tracks and "03" means tracks+wchar.

8. "00": This byte is not significant and is echoed on output.  Maybe it is
         for range extension of the next byte (which then would become a word).
         Other possibilities: Padding or fill byte.

9. "00": This byte is significant.  I did not try all values, but all
         individual bits flagged, and some other values.  The only accepted
         values are 00 and 01, otherwise, a 08 error is returned.  If 01,
         the disc title is returned in wchar format.

10. "30": This byte is significant.  I did not find any other accepted value.

11. "00": See 10.
12. "0a": See 10.
13. "00": See 10.
14. "ff": See 10.  Changed to 10 on successful return.

15. "00": This byte is not significant and is echoed on output.

16. "00": This byte is not significant and is overwritten on output (00).
17. "00": This byte is not significant and is overwritten on output
    (length of title + 6).  It would be interesting to learn what happens if
    you have a very long title (> 249 chars).  I would expect byte 16 to be
    "01" in this case.  Fields 16 and 17 are only used as output fields.

18. "00": This byte is significant.  If you change it to non-null, you
    receive a normal 09 reply, with this byte echoed, but without returned
    data.  Not even the "00 0a 00 00" empty string data will be returned.
    Byte 16 and 17 are both 00.

19. "00": See 19.

Conclusion:
===========

Disc Get Title has the following pattern:
?g ?h 06 02 20 18 01 ?i 00 30 00 0a 00 ff ?j ?k ?l 00 00

Returned data:
09 ?h 06 02 20 18 01 ?i 00 30 00 0a 00 10 ?j !u !v 00 00 !w !x 00 0a !y !z <data>

Where <data> is the title (or nothing if no title), !y!z is the length of
<data>, !w!x is !y!z + 4 and !u!v is !y!z + 2.

Things we can not be sure about, but would be reasonable assumptions:
* Sizes are usually given as words, not as bytes.  This is already assumed
  above (!u!v, !w!x etc.).  Can possibly be verified with long titles, huge
  number of tracks, etc.

* Some bytes seem to be skipped (echoed) by the device, possibly because they
  are only used as return values, have no meaning (reserved for future use,
  padding), or because they have a meaning that is not of interest to the
  device, like some interface number that is static and not even verified.

* Look at the significance of byte 18 and 19:

(netmd) send  00 18 06  02 20 18 01  00 00  30 00  0a 00  ff ab cd ef 00 01
Reply:
09 18 06 02 20 18 01 00 00 30 00 0a 00 10 ab 00 00 00 01

As you can see, the fields we interpret as "size" field have been changed to
00 00, and the ff has been changed to 10.  This is obviously bogus reply. 
For example, if you would manage to return this to OpenMG, it would be
interesting to know if it can cope or if it would crash due to a
segmentation fault :)  However, the size argument is consistent with our
usual interpretation.

Now, we need an analysis of all known commands that are as thorough as
above.  There _are_ differences.  For example, in disc get title, the first
three of the five 00s after ff are insignificant, while in the disc status
operation, only the first is.  These differences might not have a consistent
interpretation, but rather abnormalities in the parser.  But we simply have
to collect all the facts we can get and see.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/