doc/coinmech

   1 When the coinmech is idle, it sends 0x31 which is ack'd by replying
   2 to it with 0x00. Without this, the coin mech will not accept coins
   3 (and they fall through to the return slot).
   4
   5 Every time the balance changes (or maybe when an 0xff is sent to the
   6 mech), the coin mech sends a packet:
   7
   8 (columns are byte number, date, hex, ascii, binary)
   9 004a [Fri Aug  8 18:37:19 2003] | 38 8 00111000
  10 004b [Fri Aug  8 18:37:19 2003] | 24 $ 00100100
  11 004c [Fri Aug  8 18:37:19 2003] | 20 . 00100000
  12 004d [Fri Aug  8 18:37:19 2003] | 20 . 00100000
  13 004e [Fri Aug  8 18:37:19 2003] | 20 . 00100000
  14 004f [Fri Aug  8 18:37:19 2003] | 25 % 00100101
  15 0050 [Fri Aug  8 18:37:19 2003] | 20 . 00100000
  16 0051 [Fri Aug  8 18:37:19 2003] | 24 $ 00100100
  17 0052 [Fri Aug  8 18:37:19 2003] | 20 . 00100000
  18 0053 [Fri Aug  8 18:37:19 2003] | 39 9 00111001
  19
  20 The first 3 bits are always 001, saying this comes from the coin
  21 mech. The 4th bit is 1 for a control byte, and 0 for a data byte.
  22
  23 Hence the first 0x38, is a "start of packet" byte. The next 8 bytes
  24 are data bytes, so you only look at the lower nibble for data. The
  25 next four bytes, and the following two after that denote two numbers
  26 which you multiply together to get the value in the mechanism.
  27
  28 The second is an 8-bit number which I assume is the smallest
  29 possible denomination (in all cases we have, 5c). The first number
  30 is a 16-bit number which is the number of the above denominations.
  31
  32 eg, above we have (reading most-significant-nibbles last),
  33 0000000000000100 = 4. and 00000101 = 5. 4*5 = 20 - so there was 20c
  34 in the mech (a 20c coin namely, but the logic doesn't know that).
  35
  36 The next byte (0x24 here) seems to be the mantissa of the number to
  37 convert to dollars. The firmware uses it to decide where to stick a
  38 decimal point on the display. So here 0100 (read in binary) means
  39 the decimal point is two places in.
  40
  41 The last data byte (0x20 here) is for whether there are coins in the
  42 machine. Firmware only looks at the last bit - if it is set, it
  43 displays "EXACT COINS ONLY".
  44
  45 Finally there's the "end of packet" byte, 0x39.
  46
  47
  48 A packet is sent every time the balance of the machine changes, (and
  49 possibly when an 0xff is sent - need to test this).
  50
  51
  52 When change is given, what occurs is the controller board sends to
  53 the machine a byte which is the number of "smallest denominations"
  54 that the item cost. Eg, a $1.10 packet of chips is 22x5c. So the
  55 logic board sends decimal 22 to the coin mech, and out pops 90c
  56 change (assuming a $2 coin was put in).
  57
  58 Which means unless there's more to the protocol which doesn't occur
  59 in normal conversations, there's no real way we can just "drop out
  60 change". Even if we hook into the buttons on the side of the coin
  61 mech that dispense money, we don't really have any reliable way to
  62 know if there really is money in there or not to drop out.
  63
  64
  65
  66 The other problem noticed, is that the coin mechanism will respond
  67 to any character written on the serial line, so the idea of using
  68 the serial bus is somewhat defeated. (The manual says that using a
  69 coin mechanism excludes other devices such as a bill changer or card
  70 reader, and I presume this might be why). Which means we may resort
  71 to putting a UART on a daughterboard after all.
  72