Re: protocol details

On Tuesday, Dec 31, 2002, at 04:27 Europe/London, Marcus Brinkmann  
wrote:
> I pondered the protocol data I got hold of from this list and xmd's
> proto.txt file.  I will have to produce my own log data to verify some
> ideas, however, what Pete Ryland said earlier here was pretty  
> suggestive.
> I am ot sure how much of this is already well known, at least as an  
> idea,
> however, here are some bits that look interesting to me:

As you must have noticed, there are significant problems with proto.txt,
but I have not really had the chance to do a complete, more coherent
re-write, nor enough information to make it completely worthwhile.

* The whole [2][2] etc notation with "parameters" split out below
is remarkably unreadable...Sorry. (it came about when I was editting
text files to compare "request" and "reply" data blocks).

* The "3 byte group code, 4 byte opcode" notion is bogus (for a start,
the disc init command is only 6 bytes long). We now understand the first
byte a lot better (it's 00 in requests and generally 09 or 0a in  
responses
but other values are possible)...

* As you noticed the 2 and 4 byte parameter idea doesn't work well  
either.
My memory says I compared the actual scheme to ASN.1 back in
http://gargoyles.monochromatic.net/pipermail/netmd-dev/2002-May/ 
000149.html
but the archive says otherwise.  :)

Unfortunately, not having cracked things much further, those concepts
have polluted libomd (or at least, the netmd_cmd.c file)... I knew
they were wrong at the time, but at least they could be bent to fit
the known behaviour....


> In the request, there is usually some "ff" that is changed in the  
> reply.
> One common pattern is that the ff is followed by some zeroes, and later
> becomes 10 00 00 XX with some number XX.
> [...]
> I think it is a bit strange that such commands seem to encode the  
> parameters
> after the "ff" instead before it.  This is still unclear to me.

I think it helps if you think of a request or reply as having fixed  
length
"arguments" (eg track number) and variable length ones (eg track name).
The fixed length stuff all goes before the "seperator" and is generally
returned unchanged in the reply apart from the "seperator" byte.

Also, I am fairly sure that when I have sent some bogus request packets
I have seen the seperator byte *not* change. So possible it has some
success/failure indication too.

Note that this is in addition to the first byte of the reply also
indicating success/failure.... I would guess that in Open MG the
first byte might be decoded at the transport layer, while the
seperator byte may provide detailed status to the application layer.
(that's maybe another reason for things being encoded the way they are,
so that the transport layer can shift them about without needing
to know details of what the data means)

If you look at some of the "simple" commands like play/stop,
this still kind of fits except the seperator byte seems to
appear really early... theories anyone?

> Here is an interpretation of the disc capacity call:
> [...]
> "ff"   ->   "10": Data was appended.
> "001d" -> The number of bytes appended (0x1b)
> "0000" -> unknown, probably further specifies the type of the reply
> "001b" -> The number of bytes of the packet with the reply data.
> "8003" -> "80" array (Rylands suggestion) of "03" elements.
> "0017" -> The number of the bytes in the array.
> "8000" -> Indicates that the array members are following.
>           (As every packet must have a header, this serves as one).
> "0005" -> Number of bytes of the first entry.
> "00t4t3t2t1" -> First array entry.  I suspect that the leading 00 is  
> the
>                 number of days.

Neat... I had spotted all the 'length' structures in this, but this
shows the typing indicator thing fits (eg the 80's).

I'm short of time just now, and probably going to be offline for
a bit (New Years), but if someone has time to try and take this
theory further, here's some random thoughts:-

0a often seems to be a string indicator
10 often seems to be an "int" indicator
In request blocks, track numbers are often preceeded by 10 01


88 seems to often be followed by a 24 bit number in requests...
This occurs a lot in the unit status commands - I have a vague
theory it is to do with  reading/writing status registers or memory
locations on the unit. However, look at the response to the
get player status, the part I refer to as data2, you get either
             data2 = 88 04 00 03 40 ff 40  ("Normal")
             data2 = 88 04 00 03 80 ff 40  ("No disk")

Perhaps
the 88 04 00 means 'contents of register 04 ( or 0x400) which is
3 bytes long (the 03) then 3 bytes of actual data.

Actually, the request makes more sense if you interpret part of
it as:-
<30 88 00 00> <30 88 40 00>
(read contents of of register 40 00 (but why the reference to 00 00  
first?))

Note the similarities with the get playback status (ignoring the way
proto.txt tries to interpret that as 16 bit values ;) and the  
*differences*
with get playback position.

Note also with all three of those commands, the start of the command
buffer is:-
00 18 09 80 01 xx
Where xx is the number of 4 byte blocks which follow.
Each of those blocks is 30 xx nn 00
where xx is either 88 or 00
and nn seems to be between 01 and 07 (register number?).

Also note that the what I have tagged data2 in variant (i) of
"get playback status" seems to return unstructured data...
it doesn't seem to have any length indicators.

It would also be good to try and develop a theory for the commands
which *send* variable length data (eg set track title, set disc title).

Sorry that's all a bit random, but hopefully it'll trigger some
ideas in other people who've been staring at the numbers.

Pete.