home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: Multimed / Multimed.zip / rio006-2.zip / RIO.TXT < prev    next >
Text File  |  1999-06-28  |  11KB  |  251 lines
  1.  
  2. Diamond Rio Protocol Investigation - Ashpool Systems (c) 1999
  3. -------------------------------------------------------------
  4.         Last updated 11/03/99
  5.         Author jab@cix.co.uk
  6.  
  7. Contents
  8. --------
  9.         1. Hardware used to determine protocol
  10.         2. Software tools used to determine protocol
  11.         3. PC parallel port access
  12.         4. Directory block layout
  13.         5. Transmitting and receiving data to the device
  14.         6. Block usage table and FAT
  15.  
  16.  
  17. 1. Hardware used to determine protocol
  18. -------------------------------------
  19.         The following hardware was used in determining the protocol
  20.         used between a PC and the Diamond Rio...
  21.  
  22.                 HP VectraXA P233 32M running MS Win98
  23.                 Diamond Rio PMP300
  24.  
  25. 2. Software tools used to determine protocol
  26. --------------------------------------------
  27.         A Win98 VxD was put together which intercepted and logged
  28.         all I/O traffic between the PC (running the 'Rio Manager'
  29.         software) and the Rio.
  30.         This data was then used to determine the protocol used to
  31.         upload and download data to the device.
  32.  
  33. 3. PC parallel port access
  34. --------------------------
  35.         The following ports are used (using the default 0x378).
  36.  
  37.                 0x378   Parallel Port Data
  38.                 0x379   Parallel Port Status
  39.                 0x37a   Parallel Port Control
  40.  
  41.         Data to be sent from the host to the Rio is written to this port
  42.         as normal 8 bit data. The host then writes a value to the
  43.         control port. This value is made up using a alternating bit 3
  44.         (used as a data latch) which informs the Rio that data is present
  45.         in the data port and is waiting to be retrieved.
  46.  
  47.         Data to be sent from the Rio to the host is done using the status
  48.         port. Only the top 4 bits are used so a single byte sent to the
  49.         host is split up into 2 nibbles which are sent with their bits
  50.         reversed. Also because bit 7 of the status port is an inversion
  51.         of the +busy line (pin 11) this bit needs to be inverted.
  52.         Below is a example of how the host would read the nibble pair from
  53.         the Rio to make up a single data byte.
  54.  
  55.                 UCHAR ucIn, ucRx;
  56.  
  57.                 // get first nibble
  58.                 ucRx = INPORT( ParallelPortStatus );
  59.                 ucIn = ((ucRx & 0xf0) ^ 0x80) >> 4;
  60.                 // get second nibble
  61.                 ucRx = INPORT( ParallelPortStatus );
  62.                 ucIn |= (ucRx & 0xf0) ^ 0x80;
  63.                 // reverse all bits in byte
  64.                 ucIn = BitReverse( ucIn );
  65.  
  66.         The Control port is used to latch data present in the data port
  67.         and to send commands to the Rio.
  68.  
  69. 4. Directory block layout
  70. -------------------------
  71.         The first 32K on the Rio is dedicated to the directory block
  72.         which contains the directory header, directory entries and the
  73.         file allocation table (FAT) used by he Rio.
  74.         Ammending the directory block is all that is required to delete a
  75.         file, rename a file or change the playlist order.
  76.  
  77.         The layout of the 32K directory block is as follows...
  78.  
  79.                 Description                     Offset  Size
  80.                 -----------------------------------------------
  81.                 directory header                0       512
  82.                 directory entries (60*128)      512     7680
  83.                 32K block used flags            8192    8192
  84.                 FAT (8192*sizeof(short))        16384   16384
  85.                                                         -----
  86.                                                 total   32768
  87.  
  88.                 Directory Header
  89.                 ----------------
  90.                 The CDirHeader class represents the directory header.
  91.  
  92.                 A description of the members are as follows...
  93.  
  94.                         USHORT m_usCountEntry;
  95.                         ----------------------
  96.                         Number of files currently on the device.
  97.  
  98.                         USHORT m_usCount32KBlockAvailable;
  99.                         ----------------------------------
  100.                         Number of 32K blocks available on flash ram.
  101.  
  102.                         USHORT m_usCount32KBlockUsed;
  103.                         -----------------------------
  104.                         Number of 32K blocks currently used by directory
  105.                         block and files or which are marked as bad.
  106.  
  107.                         USHORT m_usCount32KBlockRemaining;
  108.                         ----------------------------------
  109.                         Number of 32K blocks not is use or marked as bad.
  110.  
  111.                         USHORT m_usCount32KBlockBad;
  112.                         ----------------------------
  113.                         Number 32K blocks marked as bad.
  114.  
  115.                         long m_lTimeLastUpdate;
  116.                         -----------------------
  117.                         The Rio Manager software updates this with the
  118.                         current time ( taken from time(NULL) ) whenever
  119.                         data has been uploaded to the device.
  120.  
  121.                         USHORT m_usChecksum1;
  122.                         ---------------------
  123.                         Checksum of the directory header only.
  124.  
  125.                         USHORT m_usChecksum2;
  126.                         ---------------------
  127.                         Checksum of everything in the directory block except
  128.                         the directory header.
  129.                         Note that because m_usChecksum2 is part of the
  130.                         directory header it must be calculated first before
  131.                         calculating m_usChecksum1.
  132.  
  133.                         char m_acNotUsed2[ 2 ];
  134.                         -----------------------
  135.                         Unknown. Rio Manager software sets these to 0xff.
  136.                         The Rio utility on the otherhand sets them to 0x00.
  137.  
  138.                         USHORT m_usVersion;
  139.                         -------------------
  140.                         Rio manager v1.00 doesn't use this value.
  141.                         Rio manager v1.01 expects this value to be 0x0100
  142.                         otherwise it think's a earlier version has been
  143.                         used to update the device and will therefore
  144.                         reformat the device.
  145.                         The Rio utility sets this value to 0x0100 so both
  146.                         v1.00 and v1.01 of the Rio manager software will
  147.                         recognize the directory.
  148.  
  149.                         char m_acNotUsed3[ 512 - 22 ];
  150.                         ------------------------------
  151.                         Always seems to be 0.
  152.  
  153.                 Directory Entries
  154.                 -----------------
  155.                 The CDirEntry class represents a directory entry.
  156.                 Each directory entry is 128 bytes long.
  157.                 The maximum number of directory entries and therefore
  158.                 files which can be uploaded to the device is 60.
  159.  
  160.                 A description of the members are as follows...
  161.  
  162.                         USHORT m_usPos32KBlock;
  163.                         -----------------------
  164.                         Position of the first 32K where data for this file
  165.                         is stored.
  166.  
  167.                         USHORT m_usCount32KBlock;
  168.                         -------------------------
  169.                         Number of 32K blocks taken up by the file.
  170.  
  171.                         USHORT m_usSize32KMod;
  172.                         ----------------------
  173.                         Number of bytes in the last 32K block. If the filesize
  174.                         is divisible by 32K then this value is 0.
  175.  
  176.                         long m_lSize;
  177.                         -------------
  178.                         File size.
  179.                         The duration of a track as displayed by the device is
  180.                         calculated using the filesize and the properties.
  181.  
  182.                         char m_acNotUsed[ 5 ];
  183.                         ----------------------
  184.                         Unknown.
  185.  
  186.                         long m_lTimeUpload;
  187.                         -------------------
  188.                         Upload time ( taken from time(NULL) ).
  189.  
  190.                         char m_aucProperty[ 4 ];
  191.                         ------------------------
  192.                         The files audio property (bits per sample,
  193.                         sample rate...) taken from the first four bytes of
  194.                         the audio file.
  195.  
  196.                         char m_acNotUsed3[ 5 ];
  197.                         -----------------------
  198.                         Always seems to be filled with 0.
  199.  
  200.                         char m_szName[ 128 - 28 ];
  201.                         --------------------------
  202.                         File name.
  203.  
  204.  
  205. 5. Transmitting and receiving data to the device
  206. ------------------------------------------------
  207.         Although the directory header and directory entries use references
  208.         to 32K blocks, data is tx'ed and rx'ed in 512 + 16 byte blocks.
  209.         When uploading data the extra 16 bytes contains information about
  210.         the location of the previous and next 512 byte block. I assume
  211.         this information is used by the device so it knows which 512 block
  212.         of audio to goto when seeking forwards or backwards.
  213.  
  214.         To send or receive data a series of bytes which indicate
  215.         the upload/download command and a 512 byte offset is sent
  216.         to the device.
  217.         Data is then received or transmitted to the device.
  218.         If sending data the additional 16 bytes (described above) must be sent.
  219.         If receiving data the additional 16 bytes (which can be ignored) must
  220.         be received.
  221.  
  222.         Although the Rio manager software does not allow you to upload
  223.         non-mp3 files or to download files from the device it is possible
  224.         with the Rio utility.
  225.  
  226. 6. Block usage table and FAT
  227. ----------------------------
  228.         The directory block contains an array of 8192 bytes which indicate
  229.         which 32K blocks are in use or marked as bad.
  230.         0x00 Indicates that the block is ok and in use.
  231.         0x0f Indicates that the block is bad and should therefore not be used.
  232.         0xff Indicates that the block is ok and is free.
  233.  
  234.         Also in the directory block there is an array of 8192 16-bit values
  235.         which are used to determine the next 32K audio block in use.
  236.         A 0 signifies that it is the last 32K block.
  237.  
  238.         Investigation shows that the above two tables are not used by the
  239.         device for playback as information about the next audio block to
  240.         play is sent in the extra 16 bytes following a 512 byte upload
  241.         (see above). This means that the above tables are used as a means
  242.         of block management by the host software only and can therefore
  243.         be organized differently and/or used to store other information.
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.