From: Bernard Blackham Date: Sun, 10 Aug 2003 11:04:38 +0000 (+0000) Subject: Info about the coin mechanism. X-Git-Tag: ROMW~81 X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=b972d45cf49cd4530fc8fd412a17b4e78d80a292;p=uccvend-snackrom.git Info about the coin mechanism. --- diff --git a/doc/coinmech b/doc/coinmech new file mode 100644 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. +