When the coinmech is idle, it sends 0x31 which is ack'd by replying
to it with 0x00. Without this, the coin mech will not accept coins
(and they fall through to the return slot).

Every time the balance changes (or maybe when an 0xff is sent to the
mech), the coin mech sends a packet:

(columns are byte number, date, hex, ascii, binary)
004a [Fri Aug  8 18:37:19 2003] | 38 8 00111000
004b [Fri Aug  8 18:37:19 2003] | 24 $ 00100100
004c [Fri Aug  8 18:37:19 2003] | 20 . 00100000
004d [Fri Aug  8 18:37:19 2003] | 20 . 00100000
004e [Fri Aug  8 18:37:19 2003] | 20 . 00100000
004f [Fri Aug  8 18:37:19 2003] | 25 % 00100101
0050 [Fri Aug  8 18:37:19 2003] | 20 . 00100000
0051 [Fri Aug  8 18:37:19 2003] | 24 $ 00100100
0052 [Fri Aug  8 18:37:19 2003] | 20 . 00100000
0053 [Fri Aug  8 18:37:19 2003] | 39 9 00111001

The first 3 bits are always 001, saying this comes from the coin
mech. The 4th bit is 1 for a control byte, and 0 for a data byte.

Hence the first 0x38, is a "start of packet" byte. The next 8 bytes
are data bytes, so you only look at the lower nibble for data. The
next four bytes, and the following two after that denote two numbers
which you multiply together to get the value in the mechanism.

The second is an 8-bit number which I assume is the smallest
possible denomination (in all cases we have, 5c). The first number
is a 16-bit number which is the number of the above denominations.

eg, above we have (reading most-significant-nibbles last),
0000000000000100 = 4. and 00000101 = 5. 4*5 = 20 - so there was 20c
in the mech (a 20c coin namely, but the logic doesn't know that).

The next byte (0x24 here) seems to be the mantissa of the number to
convert to dollars. The firmware uses it to decide where to stick a
decimal point on the display. So here 0100 (read in binary) means
the decimal point is two places in.

The last data byte (0x20 here) is for whether there are coins in the
machine. Firmware only looks at the last bit - if it is set, it
displays "EXACT COINS ONLY".

Finally there's the "end of packet" byte, 0x39.


A packet is sent every time the balance of the machine changes, (and
possibly when an 0xff is sent - need to test this).


When change is given, what occurs is the controller board sends to
the machine a byte which is the number of "smallest denominations"
that the item cost. Eg, a $1.10 packet of chips is 22x5c. So the
logic board sends decimal 22 to the coin mech, and out pops 90c
change (assuming a $2 coin was put in).

Which means unless there's more to the protocol which doesn't occur
in normal conversations, there's no real way we can just "drop out
change". Even if we hook into the buttons on the side of the coin
mech that dispense money, we don't really have any reliable way to
know if there really is money in there or not to drop out.



The other problem noticed, is that the coin mechanism will respond
to any character written on the serial line, so the idea of using
the serial bus is somewhat defeated. (The manual says that using a
coin mechanism excludes other devices such as a bill changer or card
reader, and I presume this might be why). Which means we may resort
to putting a UART on a daughterboard after all.