Info about the coin mechanism.

diff --git a/doc/coinmech b/doc/coinmech
new file mode 100644 (file)
index 0000000..29206a7
--- /dev/null
+++ b/doc/coinmech
@@ -0,0 +1,72 @@
+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.
+