Re: protocol details

On Tue, Dec 31, 2002 at 12:47:35PM +0000, Pete Bentley wrote:
> * 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)...

The request value is not significant.  The return value seems to be 09 on
success, 08 on syntax error and 0a on invalid argument type of errors like
track doesn't exist, or no disc inserted (for disc title).

> * 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.  :)

ASN.1 inspired maybe.  Yeah, we should check that out.  My recollections of
ASN.1 are not even sketchy.
 
> 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.

That doesn't sound very convincing :)  The data we have is full of
abnormalities, and even simple rules like the one above don't really hold. 
For example, look at get disc flags:  It returns additional data beyond that
what was made space for by the request, but it already expects the request
to have the size information 01 and a spurious 0b that we don't understand
filled in.
 
> 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.

I have not seen this so far (which doesn't mean a lot, as I have not done
exhaustive searches and onyl covered a few operations so far).
 
> Note that this is in addition to the first byte of the reply also
> indicating success/failure....

My impression is that if 08 or 0a is returned, the rest of the request is
echoed unchanged.  But I have not paid special attention to that, so I might
be wrong.

> 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?

Yeah, that's annoying.  I think the only reasonable assumption so far is
that the two ff are really completely different.
 
> 0a often seems to be a string indicator
> 10 often seems to be an "int" indicator

Yup.

> 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?))

(40 -> 04)  I don't know much about the hardware, but there are a couple of
things that the register idea can not explain in a simple way:
Why does requesting 2 registers lead to three bytes output, and 3 registers
to 8 or 2 byte output, and four registers 7 byte?  Furthermore, why is the
register code not generic?  I tried the disc status call with all 64
(0,0)-(7,7) pairs in the 30 88 XX 00 30 88 YY 00 position and the only one
that doesn't give an 08 error is (0,4).

BTW, the "00" in the 30 88 ?? 00 sequence is not significant, you can change
it to anything and it is just echoed.

> 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.

For me it looks perfectly regular:

Type A
00 18  09 80 01 03  30 88  01 00  30 88  05 00  30 88  07 00  ff  00  00 00 00 00
09 18  09 80 01 03  30 88  01 00  30 88  05 00  30 88  07 00  10  00  00 0e 00 00
00 0c  88 05  00 08  80 e0  01 10  90 00  40 00

12 bytes, type "88 05", 8 bytes, and then the 8 bytes of pure data.

Type B
00 18  09 80 01 03  30 88  02 00  30 88  05 00  30 88  06  00  ff  00  00 00 00 00
09 18  09 80 01 03  30 88  02 00  30 88  05 00  30 88  06  00  10  00  00 08 00 00
00 06  88 06  00 02  xx yy

6 bytes, type "88 06", 2 bytes, and then the 2 bytes of pure data.
 
I dislike that the 88 is in the lower byte of the word in the request and in
the upper byte as "type" in the reply.  However, I don't know any other way
to look at it.

> 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).

00 18  07 02 20 18  01  00 00  30 00  0a 00  50 00 $u $v 00 00 00 00 DATA

"00 18" as known.
"07 02 20 18" write title
"01" disc.  Use 02 for tracks, and 03 for wchar title of tracks.
"00 00" the normal title.  Use "00 01" for wchar title.  Use track number for tracks
"30 00 0a 00" Hell, who knows.  Remember me of the 30 88 and 30 00 in the status ops
"50 00" no idea
"$u $v" length, although $u == 00 for now.

Note that the old length doesn't seem to be required for the MZ-N707.  Don't
know about other/older players.
 
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/